Say you get two quotes for an app, one for iPhone and one for Android, and together they come to nearly double. That price can be fair or not, depending on the technology the agency picked. Choosing how to build the app is the first decision and the hardest to undo, so it is worth thirty minutes before you sign anything.
This post explains the three common routes in plain words, then shows how to choose by budget, timeline, team and features. I checked version details against official documentation on 21 October 2026.
Three routes, in plain words
Picture a coffee shop with two branches in two countries. Each country has its own rules and its own power sockets.
The first route is building separately for each operating system, called native. On iPhone that means the Swift language and Apple's Xcode. On Android it means Kotlin and Google's Android Studio. It is like hiring two crews, each building a shop to local standards. Both shops feel right at home, but you pay twice and fix things twice.
The second route is one codebase that runs on both phones, called cross-platform. The two names you will hear most are Flutter from Google, written in the Dart language, and React Native from Meta, written in JavaScript or TypeScript. One crew follows one blueprint and fits it to both countries. You build once and fix once, though sometimes a local specialist has to handle a special case.
The third route sits between them: share the "brain" of the app (pricing rules, talking to the server) and keep the screens separate. This is Kotlin Multiplatform. Google's Android documentation currently describes it as stable and production-ready, and you can share anything from a small piece of logic up to the whole app.
Where things stand in 2026
Here are the three sources I checked, so you can open them yourself.
Flutter: docs.flutter.dev shows version 3.47. Its supported-platforms table lists Android 24 to 37 (Android 7 and up) and iOS 15 to 27. Beyond phones, it also targets web and desktop.
React Native: the newest release on the reactnative.dev blog is 0.88, dated 19 October 2026. The "New Architecture" became the default in 0.76 in 2024, and 0.82 was the first release to run entirely on it. The setup guide recommends that new apps use a framework such as Expo rather than assembling everything by hand.
Native: Apple's Xcode page presents Xcode 27, and the stable Android Studio is 2026.2.1 (Rabbit 1). Both companies update their tools every year, and new apps must be built with recent SDKs to reach the stores. I cover that in Getting Your App on the App Store and Google Play: A 2026 Checklist.
I am not quoting speed benchmarks, because I found no fair official comparison. For most shop, booking and news apps, all three routes are fast enough. How smooth an app feels usually comes from how it was built, not from the name of the technology.
Choosing by budget and time
With a tight budget and a need to launch on both systems soon, one shared codebase is usually cheaper and faster. You do not pay twice for the same login screen and the same cart. When something breaks, you fix it once.
If you only need one system first, say your customers mostly use iPhone, going native on that one can be the simplest path. You can add the other later.
Budget is also more than the first build. An app needs updates whenever Apple and Google ship new operating system versions, and new store requirements appear every year. Two native apps mean carrying that load twice. I wrote about upkeep in Monthly Website Maintenance: What It Includes and Why Neglect Costs More, and most of it applies to apps too.
Choosing by team
The most practical question is who will fix the app after handover. If your company already has people strong in JavaScript or TypeScript, React Native lets them move quickly. If you outsource once and manage it yourself, pick a technology where you can easily find the next developer nearby. A beautiful app nobody dares to touch is a real risk.
Something that happens easily: the agency often picks the stack it knows best, not the one that suits you best. Ask them directly why they chose it, and who will fix bugs when they are busy.
Choosing by features
Most apps are screens, lists, forms, login and server calls. All three routes handle that well. Three groups of features deserve a closer look.
Camera and sensors. Scanning codes, photographing documents, augmented reality: Flutter and React Native both have libraries, but the more specialised the need, the more likely someone writes a bit of native code to connect it. If the camera is the heart of your app, native tends to be less trouble.
Payments. Physical goods (clothes, laptops) can use an ordinary payment gateway. Digital content or subscriptions inside the app must use Apple's in-app purchase under guideline 3.1.1 of the App Review Guidelines. This does not depend on which technology you use, so settle it early.
Background work. Reminders at an exact time, location tracking, syncing while the screen is off: the operating systems restrict this tightly, and iOS and Android differ. Every route has to handle it with care, but native gets access to the newest operating system options more directly.
A quick way to decide
If you run a small business, need both phones, have ordinary features and a moderate budget, start with Flutter or React Native (with Expo), depending on what your team knows. If the app revolves around the camera, graphics or deep features of one operating system, go native. If you already have a native app and want less duplication, look at Kotlin Multiplatform. And if all you need is an internal tool or a shop page that installs to the home screen, read Can an Installable Web App (PWA) Replace a Mobile App? first, because you may not need a full app yet.
Common mistakes
A common surprise is finishing the app and only then finding out you need an admin website so staff can enter stock. The app is half the cost. The server and the admin screens are the other half. Count both, and write a clear brief like the one in What to Prepare Before Hiring Someone to Build Your Website or Software (With a Brief Template).
Another mistake is choosing a technology because it is fashionable. Every stack changes versions regularly, so what matters is that your team keeps following and upgrading it.
What to do next
Write down three things: which operating systems the app must run on, its three most important features, and who will maintain it after launch. With those three lines you can ask for quotes properly and compare them fairly. If you want a second pair of eyes, you can message me through the contact page.
