Native or cross-platform? A decision framework that actually decides

The honest summary

This debate generates far more heat than it deserves. Both approaches produce good apps. The question is not which technology is better in the abstract — it is which set of trade-offs suits your product, your budget and your team.

The compressed version: if your app is your product, build native. If your app supports your product, build cross-platform. Everything below is the detail behind that.

Where native genuinely wins

• Performance-critical paths. Real-time video or audio processing, complex graphics, AR, large-scale on-device computation, 120Hz scrolling through enormous lists.
• Deep platform integration. Widgets, Live Activities, App Clips, Siri Shortcuts, Apple Watch, Wear OS, CarPlay, advanced Bluetooth or NFC, background processing.
• Immediate adoption of new OS features. Cross-platform frameworks lag WWDC and Google I/O by months. If shipping the new thing in week one matters commercially, that lag is disqualifying.
• Long-lived consumer products. If the app will be actively developed for five or more years by a growing team, the cost of two native codebases amortises and you avoid dependency on a framework's roadmap.
• Best-in-class feel. Native gets you platform conventions, gestures and animation for free. Cross-platform gets you close; the last 5% is expensive.

Where cross-platform genuinely wins

• Constrained budget, both platforms required. The most common real-world situation, and the strongest argument.
• Business applications. Forms, lists, dashboards, bookings, approvals, documents, notifications. Nothing here strains a cross-platform framework.
• Internal and field tools. Nobody is judging your engineer-facing app on animation polish.
• Small teams. One codebase, one skill set, one release process. If you have two developers, two native codebases will hurt.
• Speed to market. One build, both stores, meaningfully faster.
• Existing React expertise. If your team already writes React, React Native is a short step rather than a new discipline.

React Native or Flutter?

Both are production-ready and both are used at very large scale. In the UK, hiring pool is often the deciding factor and it favours React Native. If your app is visually distinctive and animation-led, Flutter is the better tool.

The criteria that should decide it

Work through these in order. The first one that gives a clear answer usually is the answer.

1. Is the app the product, or a channel to it? Product → lean native. Channel → lean cross-platform.
2. Does it need device features beyond camera, location and notifications? Yes → native, or accept native modules in a cross-platform app.
3. Is there a performance-critical path? Real-time media, heavy graphics, enormous datasets → native.
4. What is the budget for both platforms? Under about £60,000 for both → cross-platform, or one platform natively.
5. Who maintains it in three years? A small in-house team → one codebase. A growing dedicated mobile team → native is sustainable.
6. How long must it live? Under three years → cross-platform. Five-plus years as a core product → native reduces framework risk.

Common mistakes

• Choosing native for prestige. "Proper apps are native" has cost a lot of companies a lot of money on internal tools.
• Choosing cross-platform then demanding native behaviour. If you want every iOS convention pixel-perfect, you are paying native prices inside a cross-platform codebase.
• Ignoring the backend. Teams agonise over the client framework and give no thought to the API, which is usually where the real complexity lives.
• Assuming cross-platform means no platform knowledge. You still need people who understand both stores, both permission models and both release processes.
• Treating it as irreversible. A well-architected app keeps business logic out of the UI layer. Migrating a clean React Native app to native later is unpleasant but survivable; migrating a spaghetti one is a rewrite.

We make this call with clients during discovery rather than in a proposal. If you want a second opinion on a decision you have already made, that is a conversation we are happy to have — see mobile app development.