Native or cross-platform: decide from product risk

“Native or cross-platform?” is often asked too early. The choice becomes clearer after the team names the product's hardest constraints: device integration, background execution, offline behavior, UI performance, accessibility, release cadence, and who will maintain the code.

This is the decision framework we use. It does not begin with a preferred framework, and it does not assume that one shared codebase automatically means lower total cost.

The decision framework

We evaluate five factors before recommending a technology approach. No single factor determines the outcome. It is the combination that matters.

1. Hardware integration depth. BLE, camera processing, background execution, and sensors do not automatically require a fully native application. They do require native platform work, a clear ownership boundary, and testing that includes the bridge or plugin layer. If the hardware path is the product's main risk, prototype that path before choosing the rest of the stack.

2. Performance requirements. Replace “the app must be fast” with a budget you can measure: startup time, frame consistency, memory, battery, data latency, or sustained throughput. Then build the riskiest interaction in the candidate stacks and profile it on representative devices.

3. Time to market. Cross-platform development can reduce duplicate work, but a “percentage of shared code” is not a delivery estimate. Account for platform-specific design, native integrations, release work, debugging at framework boundaries, and the team's existing skills. Rebuilding later is also a product decision with real cost, not a free escape hatch.

4. Team composition and long-term maintenance. Who will maintain this app after we hand it off? If the client has an in-house iOS team but no Android expertise, it may make sense to build iOS native and use React Native for Android, or vice versa. The maintenance cost of a technology stack the internal team cannot support is often underestimated.

5. Platform-specific features. Some features are only available through native APIs. Widgets, App Clips (iOS), Instant Apps (Android), Siri Shortcuts, and deep OS integrations require native code. If these are central to the product experience, native is the path.

When we recommend native

• BLE or hardware-intensive apps (medical devices, IoT sensors)
• Apps requiring maximum performance (video processing, real-time data)
• Products where platform-specific UX patterns matter (financial apps, enterprise tools)
• Long-term products with dedicated platform teams
• Apps that rely on new OS features at launch

When we recommend React Native

• MVPs and early-stage products validating market fit
• Content-driven apps (news, e-commerce, social)
• Apps with standard UI patterns and moderate complexity
• Projects with tight budgets that need both platforms
• Teams with strong JavaScript/TypeScript talent

The hybrid approach

Increasingly, we build hybrid architectures. The core business logic and UI lives in React Native, while performance-critical modules are written in native Swift or Kotlin and exposed through native bridges.

The best technology choice is the one that solves today's problem without creating tomorrow's bottleneck.

For example, a workforce management app we built uses React Native for the main interface (forms, lists, navigation) but drops into native code for the offline sync engine and BLE checkpoint scanning. This gave the client the speed-to-market of cross-platform with the reliability of native where it counted.

What about Flutter?

We get asked about Flutter frequently. It is a capable framework with excellent UI performance thanks to its custom rendering engine. However, our team's deep expertise is in Swift, Kotlin, and React Native. We recommend the tools we know intimately and can support long-term. If a client comes to us with an existing Flutter codebase, we are transparent about that boundary.

The honest recommendation

We do not have a default technology. Every project is assessed on its specific requirements, timeline, and budget. Sometimes that means recommending React Native when the client expected native. Sometimes it means recommending native when the client assumed cross-platform would be cheaper.

The useful recommendation is the one your team can explain six months later: which risks drove the choice, what was prototyped, where native code remains, and who can maintain every layer.

DEVSFLOW evaluates mobile architecture options against product requirements, platform constraints, team capability, and lifecycle cost. Send the relevant constraints for technical review.

Jean-François Duval

Lead iOS Developer at DEVSFLOW Technologies