Native or cross-platform app: how to choose before requesting a proposal
Choose a native app when the experience depends heavily on one platform, deep system integration, predictable performance or a team that already specialises in that stack. Choose a cross-platform approach when iPhone and Android share most of the product, native differences stay limited and your team can maintain the common layer without hiding each operating system’s requirements.
The decision does not come from an abstract fight between Swift, Kotlin, Flutter and React Native. It comes from your primary journey, devices, integrations, delivery plan and the people who will maintain the product after launch.
Start with product risk
List the capabilities that make the app difficult: real-time camera work, audio, Bluetooth, on-device processing, offline synchronisation, widgets, share extensions, payments, notifications, background tasks, accessibility and complex animation. Add the actual devices and operating-system versions you need to support.
A form-based app with a straightforward API leaves several architectures open. An app that depends on an iOS extension, low-latency video and precise background behaviour needs technical validation before anyone fixes the proposal.
When native becomes the clearest choice
- you launch on one platform first;
- the product adopts new system APIs quickly;
- performance, memory or latency forms part of the value;
- the team already knows Swift and iOS, or Kotlin and Android;
- you want fewer layers between your code and the system.
Native code does not guarantee a good product. It gives direct access to platform tools and removes some integration compromises. If you need iOS and Android, you may maintain two implementations.
When cross-platform creates real leverage
- both platforms share the same journey and data model;
- most screens use conventional interface components;
- a small team must ship and maintain both versions;
- you accept native code for integrations that need it;
- you test on real devices from both ecosystems.
Cross-platform does not mean one codebase with no platform differences. Flutter documents platform integration, React Native uses native modules, and Kotlin Multiplatform can share logic while leaving interface or system work native. A proposal should name those boundaries.
Compare maintenance, not only the first build
| Question | Native | Cross-platform |
|---|---|---|
| Two very different interfaces | Direct control | Less useful sharing |
| Nearly identical journey | Two implementations | Strong sharing may help |
| New system API | Immediate access | Framework or module may be needed |
| Team skill | Two specialties may be needed | One common team plus native edges |
| Testing | Per platform | Still per platform |
Ask who will update dependencies, handle Apple and Google changes, fix a device-specific regression and monitor performance. A shared codebase can reduce work, but it also adds framework and plugin dependencies.
Prototype the risky boundary
Before you sign a full scope, test the capability that could invalidate the architecture. Measure camera, audio, Bluetooth, offline work or a system extension on the target devices. A focused technical prototype teaches you more than a general framework debate.