If you are commissioning an app, one of the first technical decisions is also one of the most expensive to reverse: build one app that runs on both iPhone and Android, or build two separate native apps. Your developers may have a strong preference. Here is what the choice actually means for you.
The two approaches
Fully native means two apps: one written for iPhone in Apple’s tools, one written for Android in Google’s. Two codebases, often two sets of specialists, and every feature built twice.
Cross-platform means one codebase that produces both apps. React Native is the most established way to do this, and its own documentation recommends starting with a framework such as Expo. The app still installs from both stores and still uses each phone’s real buttons, lists and gestures. It is not a website in a wrapper.
What one codebase buys you
- One team, one set of decisions. Features ship to both platforms together instead of one lagging behind the other.
- Less to maintain. Every bug is fixed once. Every operating system update is handled once.
- Faster fixes. Changes to the app’s own code and content can often be sent straight to users’ phones without waiting for a full app store review, within the stores’ rules. Changes to native parts still go through the stores.
- A wider pool of people. The code is TypeScript, one of the most widely used programming languages, rather than two platform-specific ones. That matters when you need to bring someone new in.
For most business apps (accounts, content, bookings, payments, notifications, dashboards) this is the right default, and it is how we build.
When native is worth the extra cost
There are good reasons to go native, and a good team will tell you when one applies:
- Heavy graphics or real-time processing: advanced games, augmented reality, live video processing.
- Deep platform features that need a lot of custom native code, used constantly.
- An existing native team you intend to keep, or an existing native app with years of investment in it.
Even then, the line is rarely all-or-nothing. A cross-platform app can include native code for the one part that needs it.
Questions to ask your developer
- Why this approach for this app, not for apps in general?
- Which of our features, if any, will need platform-specific work?
- How will updates reach users, and how fast?
- If you left tomorrow, how easy would it be to find someone to take this on?
- Whose accounts will the apps be published under? (The answer should be: yours.)
The short version
If your app is mostly screens, data and the services behind them, one codebase will usually get you to both stores sooner and cost less to look after. If your app’s core experience is graphics, sensors or something only one platform does well, native may earn its cost. Either way, the decision should be explained to you in terms of your product, not your developer’s preferences.