Native or cross-platform for your first app?
The honest answer depends on four questions, and none of them are about technology preference.
· 2 min read
Every app project starts with this question, and it usually gets answered by whatever the development team prefers building. That is the wrong basis for the decision. Here is the framework we actually use.
Four questions that decide it
1. What hardware does it touch?
If your app is mostly screens over an API — listings, forms, dashboards, ordering — cross-platform handles it comfortably. If it leans on the camera in a non-trivial way, Bluetooth peripherals, background location, or on-device processing, native gets easier the deeper you go.
2. How much does the interface matter?
For an internal tool used by staff who have to use it, a competent cross-platform interface is fine. For a consumer product competing for attention in a crowded category, the last 10% of polish is where native still has an edge — and that 10% is often what gets reviewed.
3. How often will you ship?
One codebase means one set of changes, one test cycle, one release. If you plan to iterate every few weeks, that compounds into a real saving. If the app will be built once and touched twice a year, the advantage shrinks.
4. Who maintains it in three years?
A practical question that gets ignored. React Native and Flutter developers are easier and cheaper to hire in most markets than a team holding both Kotlin and Swift. If you intend to bring this in-house eventually, that matters more than the build cost.
Rough numbers
For a comparable feature set targeting both platforms, cross-platform typically lands around 60 % of the cost of two native builds. Where that ratio breaks down is when a project keeps hitting the edges of the framework and needs native modules written anyway — at which point you are paying for both approaches.
A reasonable rule of thumb: if you find yourself listing more than two or three features that "might need a native module", price the native build properly before deciding.
What we recommend by default
- Internal tools, B2B ordering, field-force apps: cross-platform, almost always
- Consumer products where the experience is the product: native, usually
- Anything heavy on camera, sensors or background work: native
- An MVP testing whether anyone wants this at all: cross-platform, and revisit once you know
The part that costs more than either
Whichever you pick, the backend, the admin portal and the ongoing maintenance usually exceed the app build itself over three years. OS upgrades break things annually whether you went native or not. Budget for the life of the product, not the launch — a cheap build with no maintenance budget is the most expensive option on the table.
Filed under
