Cross-platform until something hurts
The technology argument is largely settled and mostly irrelevant. What decides this is how many engineers you have and how close your product sits to the hardware.
Our bias, declared
We build both and we start most clients cross-platform, including some who arrive convinced they need native. For the vast majority of apps (content, commerce, booking, workflow), a single codebase shipped by one team beats two codebases shipped by two teams, and the user can't tell. Native earns its cost when the product depends on something the bridge doesn't expose well: sustained camera or sensor work, heavy background processing, or an interface where a few milliseconds of input latency is the product.
Side by side
| Factor | Cross-platform | Native |
|---|---|---|
| Engineering cost for two platforms | One team, one codebase | Two teams or two skill sets |
| Time to first release | Faster, often substantially | Slower, everything twice |
| Feature parity across platforms | Free by construction | Maintained by discipline |
| Access to new OS features | Waits for the framework | Day one |
| Sustained camera and sensor work | Possible, awkward at the edges | Native strength |
| Animation and input latency ceiling | Good, bounded | As good as you engineer |
| Background processing | Constrained by the bridge | Full platform control |
| Binary size and cold start | Larger runtime overhead | Leaner |
| Hiring pool | One skill set to recruit for | Two, both scarcer |
| Cost of changing your mind later | Rebuild per platform | Already paid |
Choose cross-platform when
Your team is small
The decisive constraint is rarely technical. One team shipping one codebase moves faster than two teams coordinating parity, and below roughly a dozen mobile engineers the coordination cost of native usually exceeds any performance gain the user would notice.
The app is screens, data and forms
Content, commerce, booking, dashboards, internal workflow. This is most apps, and cross-platform frameworks handle it well enough that no user has ever identified the difference unprompted.
You need both platforms at once
Launching iOS first and Android eight months later is a real commercial cost that gets waved away in technology discussions. Simultaneous release is the most underrated argument on this side.
The product is still moving
Before the model settles, the ability to change everything quickly matters more than the last increment of performance. Committing to two codebases early makes each pivot twice as expensive.
Choose native when
The hardware is the product
Continuous camera processing, audio pipelines, sensor fusion, anything doing sustained work close to the metal. The bridge is a real constraint here and working around it costs more than writing native would have.
Latency is a feature
Drawing tools, instruments, games, anything where input-to-pixel time is what people are actually buying. If a user would feel a few milliseconds, that is a native argument.
You need OS features on release day
Widgets, new system integrations, platform-specific capabilities as they ship. Frameworks catch up, and if being three months behind is commercially unacceptable, don't wait for them.
You already have two strong platform teams
If native expertise exists and isn't the bottleneck, the main argument for cross-platform disappears. Do not force a shared codebase onto teams that would each ship faster in their own.
The cost nobody puts in the comparison
Native's quoted cost is roughly double for the obvious reason, but the recurring cost is the one that surprises people: every feature is specified once, built twice, tested twice and released twice, forever. Parity doesn't maintain itself, and the drift between platforms becomes a permanent source of bug reports that are really coordination failures.
Cross-platform's hidden cost arrives later and is narrower. You will eventually hit something the framework handles badly, and the answer is usually a native module. That means you now need the native expertise you were avoiding, for one component, maintained by whoever wrote it. Budget for one or two of these instead of being surprised by the first.
Our practical framing is the same one we apply to platform choices generally: pick cross-platform unless you can name the specific thing it won't do for you. If you can name it and it's central to the product, build native and skip paying twice. If you can't name it, you're buying performance headroom you have no use for at the cost of shipping speed you definitely need.
Related questions
For most app categories, no. And this is worth testing, not debating. The tells that do exist are specific: scroll physics under heavy lists, keyboard handling, and transitions that fight platform conventions. All three are addressable with effort. If your app is a drawing tool or an instrument, users will absolutely tell, and no amount of optimization closes that.
Other comparisons
Services referenced
Get the audit before you decide anything.
Thirty minutes, free, no obligation. We'll tell you honestly whether you need an agency at all, including when the answer is that you don't.