The first question on almost every mobile project, and the one most often answered by preference rather than evidence. What actually separates the two, and how to decide without guessing.
Almost every mobile project starts with the same question, and it is usually asked in the wrong form. “Should we build native or cross-platform?” invites an answer about technology when the real answer depends on your product, your team and your budget over the next three years.
The honest position is that both approaches ship excellent apps, and both have shipped disasters. What separates them is not quality. It is where the cost lands, and when.
Native means building separately for each platform, using the tools and languages each platform vendor provides. Two codebases, two builds, two sets of platform conventions honoured exactly as their designers intended.
Cross-platform means writing the application once and running it on both, through a framework that translates your code into something each platform understands. One codebase, one team, one set of decisions — with a translation layer in between.
That translation layer is the whole of the trade-off. Everything else follows from it.
One codebase costs less to build and much less to maintain. This is the argument people lead with, and it is true, but the maintenance half matters more than the build half. A feature added once is a feature added once — not twice, in two languages, by two developers who then have to reconcile the differences in behaviour they did not intend.
Features arrive on both platforms at the same time. With two native codebases, one platform is always slightly ahead. That gap is invisible in a demo and very visible to a support team fielding questions about a feature half the users cannot see yet.
A smaller team can sustain it. For a company that is not going to hire two mobile specialists, this is often the deciding factor. A single team that understands the whole product will outperform two teams that each understand half of it.
Anything that touches the hardware directly. Sustained camera work, real-time audio processing, background location, complex gestures, on-device machine learning. Cross-platform frameworks reach these capabilities, but through a bridge — and when something behaves oddly at that boundary, you are debugging two systems and the layer between them.
Performance at the edges. For most applications the difference is imperceptible. For a few — dense animated interfaces, very large lists, anything rendering continuously — it is the difference between an app that feels considered and one that feels approximate.
Day-one platform support. When a platform ships a new version, native apps can adopt it immediately. Cross-platform apps wait for the framework to catch up. Usually that wait is short. Occasionally it lands in the middle of your release window.
Interfaces that must feel exactly right. Each platform has conventions its users have absorbed without ever being taught them. Cross-platform frameworks approximate these well. Approximating well is not the same as being right, and a certain kind of user notices.
Is your application's value in what it does, or in how it does it?
If the value is in what it does — showing information, moving a process along, connecting people to a service — cross-platform is very likely the right answer, and the money you save belongs somewhere else in the product.
If the value is in how it does it — the responsiveness, the feel, the direct use of the device — native earns its cost.
Most business applications are the first kind. Most people building them assume they are the second, because it is a more flattering description of what you are making.
Hiring. Native means recruiting for two specialisms, or accepting that one platform is always the weaker one. Cross-platform means a smaller pool of candidates for a narrower skill.
Framework risk. A cross-platform framework is a dependency you do not control. Frameworks are abandoned, and their major versions can require significant rewriting. Choose one with a serious organisation behind it and a track record of migrating people forward.
The escape route. Ask early what happens if you have to move. Moving a cross-platform app to native is a rewrite. Moving native to cross-platform is also a rewrite. Neither is a disaster if you planned for the possibility; both are if you did not.
Divergence. Two native codebases drift. Not through carelessness — through a hundred small decisions made independently. Within two years you have two products with the same name.
Write down the five things your application must do well. Not everything it will do — the five that would make a user recommend it or abandon it.
For each, ask whether it depends on the device itself or on your logic and your data. If four or five are logic and data, build cross-platform and spend the saving on design and on the systems behind it. If two or more genuinely depend on the hardware, cost both approaches properly before committing.
If you are unsure, that itself is information: uncertainty usually means the hardware is not central, because when it is central nobody has to ask.
We make this decision per project rather than carrying a house preference into every conversation. We have shipped both. What we will not do is choose based on what our team already knows and present it as an assessment of your product — which is, if you ask around, how the choice is often actually made.
If you are weighing this up, tell us what you are building and we will talk it through, including the case for the answer that earns us less.
Tell us what you are building and we will scope it with you.
