Native or cross-platform app? The three questions that decide it
Most business apps should be cross-platform: one codebase that runs on iOS and Android, built and updated once. Build native only when the app leans on special hardware, when speed is the product, or when it must feel exactly like Apple's and Google's own apps.
Everyone has an opinion on this. In practice it comes down to three questions, asked in order. Each one either sends you to native, or on to the next question.
What the two words mean
Native means two apps: one written for iOS (usually in Swift) and one for Android (usually in Kotlin). Each gets full access to its phone, and each is built, tested and updated separately.
Cross-platform means one codebase, written once in a framework such as Flutter or React Native, that produces both the iOS and the Android app.
We build both, so we've no reason to push either. Here's how we'd decide.
Question 1: does it lean on special hardware?
Bluetooth devices, augmented reality, an advanced camera, or tasks that run for a long time in the background. Cross-platform frameworks can reach most of a phone's features, but the further you go into hardware, the more of the app ends up written natively anyway.
Yes → native. You'd be paying for a cross-platform layer and then working around it.
Question 2: is speed the product?
Games, heavy graphics, real-time video. When every frame counts, the extra layer between your code and the phone becomes something you notice.
Yes → native. Build for each platform and squeeze it.
Question 3: must it feel exactly like Apple's and Google's own apps?
Down to the last animation and gesture. Cross-platform apps can look and feel very good, but an app that has to be indistinguishable from the platform's own apps, on both platforms, is easier to get right natively.
Yes → native. You pay for two apps to get each platform's exact feel.
No to all three? Cross-platform
That's where most business apps land: ordering, bookings, loyalty, field teams, dashboards, customer accounts. One codebase means one set of features to build, one set of bugs to fix and one release to plan, for both stores.
A quick reality check before either
Ask whether you need an app at all yet. If customers won't open it every week, a fast mobile website or a web app may do the job for less. A mobile app earns its place when people come back to it often.
Next step
If you're weighing an app, a free discovery call is the fastest way to an answer: we ask about your users and what the app has to do, then recommend native, cross-platform or no app at all. Book a discovery call.