Native vs cross-platform app development was a real argument in 2018. In 2026 it is mostly an argument agencies have with themselves. We build cross-platform by default, one codebase for iOS and Android, and the reasons we used to hear for going native (performance, hardware, platform features on day one, hiring) have mostly stopped being true. Native still has a place: a handful of platform surfaces, and companies with the engineering headcount to run two codebases cheaply. If you are commissioning an app for your business, you are almost certainly not that company.
Native vs cross-platform app development: what is the difference?
A native app is written separately for each platform, in Swift for iOS and Kotlin for Android, using the toolkit the platform owner provides. A cross-platform app is written once and runs on both from a shared codebase, with a framework such as Flutter or React Native translating to each platform. Cross-platform is mainstream: in the 2024 Stack Overflow survey of 65,437 developers, 9.4 per cent had used Flutter and 8.4 per cent React Native in the past year, and Google said in May 2025 that Flutter accounts for nearly 30 per cent of new free iOS apps, quoting Apptopia. Kotlin Multiplatform is the middle path: it shares the business logic and keeps the interface native on each side, with Google's backing since May 2024 and a stable iOS interface option since May 2025.
Is cross-platform really 30 to 50 per cent cheaper?
Nobody can show you where that number comes from. The closest thing to a primary source is a 2014 survey in which half of the people already using a cross-platform tool said it saved them more than 30 per cent of development time: self-reported, by people who had already chosen the tool, twelve years ago. What is documented is code sharing. When Shopify committed to React Native in January 2020 it estimated roughly 80 per cent of code shared between iOS and Android, with two smaller apps at 95 and 99 per cent.
The saving that matters to a buyer is simpler than a percentage. You pay for one app, not two. One team builds it, one set of tests covers it, one release goes to both stores on the same day, and every change you ask for after launch is made once. The share of the budget that is screens, forms and business logic is written once; the share that is platform glue is small on most business apps. That is the whole case.
What does the case for native get wrong?
Four arguments come up, and the 2026 evidence has moved against each of them.
The argument for native | What the evidence says now |
|---|---|
Performance | Shopify reported sub-500 millisecond screen loads and over 99.9 per cent crash-free sessions on React Native in January 2025. One 2025 peer-reviewed test measured cold start at 1.5 seconds native, 2.4 Flutter and 3.0 React Native on one app and one device: real, and rarely the thing a business app lives or dies on |
Platform features on day one | Apple previewed Liquid Glass on 9 June 2025 and shipped iOS 26 on 15 September 2025. Expo shipped Liquid Glass views for React Native on 10 September 2025, five days early, and React Native defaulted to Android 16 behaviour within two months of release. Flutter's official Liquid Glass is still pending after 15 months, so the lag is a framework question, not a native one |
Hardware and Bluetooth | The main plugins (flutter_blue_plus, react-native-ble-plx) cover the central role, which is what a phone talking to a device needs; the gaps they declare are the peripheral role, bonding, beacons and Bluetooth Classic. Apple's background Bluetooth rules (coalesced scans, about ten seconds when woken, possible termination) bind native apps just as hard |
Hiring | UK job adverts in the six months to October 2026 cited Kotlin 280 times, React Native 217, Swift 72 and Flutter 24. The cross-platform pool is at least as deep as the native one |
The hardware row is where we get tested, because most of our portfolio is Bluetooth: the commercial dishwasher app that updates firmware over the air, the smart water bottle, the fire-detector tester, the connected injector and the EV charger. Some of those were built native and some in Flutter, and the hard part was the same in both: the firmware protocol, the reconnection logic and the fail-safes around a slow link. None of that got easier for being written twice.
Why did Shopify go back to native, and does it matter to you?
Because coding agents made writing everything twice cheap for a company with a mobile department, and that is not your situation. On 10 September 2026 Shopify's head of mobile announced that "native is now the future of mobile at Shopify", moving four apps back to Swift and Kotlin. The reason, in Shopify's words: "coding models have gotten dramatically better, and for our apps and our team, building the same feature in Swift and Kotlin no longer carries the cost it used to." The rewritten Shop app took six engineers 12 weeks and cut cold start from 3.2 to 2.5 seconds on iOS and 4.4 to 2.2 on Android, with some of that gain from screens they chose to retire. Shopify still calls React Native "an excellent framework".
Read that as a buyer. Shopify runs four apps with hundreds of screens, a dedicated mobile organisation and a reason to squeeze every second from cold start on a consumer shopping app. The economics that moved for them have not moved for a business commissioning one app from one team, and the two-codebase cost they can now absorb is one you would be paying in full. Airbnb's 2018 exit from React Native, the other story agencies tell, was a landmark about bolting a framework into two large existing native apps and ending up with code on three platforms. Neither is a story about a new business app.
Churn is the one native argument with something left in it, and it cuts both ways. React Native made its New Architecture the default in October 2024 and removed the old one by February 2026; Flutter shipped 12 releases with 81 documented breaking changes in the same period. Native churns too: Apple has required builds on the iOS 26 SDK since 28 April 2026 and Google Play required new apps to target Android 16 by 31 August 2026, and those land on two codebases instead of one.
When does native still make sense?
When you can name the feature that needs it, and the list is short. Shopify's own boundary, drawn while it was committed to React Native, is the best one published: on-device machine-learning models and camera pipelines, home and lock screen widgets, Apple Watch apps and complications, App Intents and Siri, and long-running background work. Add a Bluetooth peripheral role, where the phone pretends to be the device. If your app needs one of those, build that piece native inside a cross-platform app, which every framework allows. If you cannot name the feature, you do not need native, and an agency telling you otherwise is selling you two apps.
That question gets settled in discovery, alongside what the app has to talk to, because integrations move the price far more than the language does. Our published ranges put a mobile app at £25,000 to £60,000 for one platform and £40,000 to £100,000 for both, excluding VAT, and a shared codebase is how the second platform stays at the bottom of that second band rather than doubling the first. If the answer turns out to be "a website would do", that is a different post.