Most people arrive at this decision having read that cross-platform is cheaper. It often is. That is also not usually the thing that should decide it.
The real question is narrower: what does your app do in the twenty percent of its life where it is doing something hard? Answer that and the choice tends to make itself.
What the two approaches actually mean
Native means writing the iOS app in Apple's toolchain and the Android app in Google's. Two codebases, two skill sets, full access to everything each platform can do on the day it ships.
Cross-platform means one codebase, usually React Native or Flutter, compiled to both. You get most of the platform, most of the time, for meaningfully less work.
Where each one wins
Cross-platform fits when
- The app is mostly screens, forms, lists and API calls.
- You want both stores covered from one budget.
- Your team is small and will stay small.
- Speed to a testable product matters more than polish at the edges.
- Feature parity across iOS and Android is a requirement, not a nice-to-have.
Native earns its cost when
- You lean hard on the camera, Bluetooth, background location or sensors.
- Sustained graphics or heavy on-device processing are core to the product.
- You need new OS features the day they ship, not months later.
- The interface must feel unmistakably native on each platform.
- You are building for one platform first and can stage the second.
The honest position is that for a large share of business apps, cross-platform is the right call and the debate is less consequential than it feels. Where it goes wrong is when a genuinely hardware-heavy product is squeezed into a cross-platform stack to save money, and the saving evaporates in workarounds.
The costs nobody puts in the quote
Whichever way you go, these land afterwards and catch people out.
Ongoing mobile costs, by how often they surprise people
OS version upgrades, twice a year, forever
App store review, including rejections
budget for a second attempt
Device and OS fragmentation testing
worse on Android
Store fees and developer accounts
Crash monitoring and release tooling
A mobile app is not a website. A website you can fix in an afternoon and everyone has the fix immediately. An app has to be built, submitted, reviewed, approved and then actually installed by the user, who may simply not bother. That changes how you plan releases and how much you invest in getting a version right before it goes out.
The order we would put it in
Deciding without a six-week debate
- 1
List the hard parts
Name every feature that touches hardware, runs in the background, or must be fast. That list decides more than anything else.
- 2
Pick the first platform
Work out where your users actually are. Launching well on one beats launching thinly on two.
- 3
Choose the stack
If the hard list is short, cross-platform. If it is long or central to the product, native.
- 4
Ship narrow
One workflow, done properly, in real hands. What people do with it tells you what to build next.
South African context matters here too. Android share is high, devices skew mid-range, and data is expensive relative to income. An app that assumes a recent flagship on uncapped fibre will feel broken to a large part of your market. Testing on modest hardware and a throttled connection is not a nice extra, it is the actual test.
What to have ready
Before you brief anyone
- The single job the app does that a mobile browser cannot do as well.
- The features that touch camera, location, Bluetooth or offline use.
- Whether it must work with no signal, and what happens to data when it does.
- Which platform your users are actually on, with something to back it up.
- Who owns the Apple and Google developer accounts, or that they do not exist yet.
- What existing systems the app has to talk to.
If you are weighing this up, tell our concierge what the app needs to do. It scopes the work with you and passes a proper brief to the team.