React Native is fine. Flutter is fine. But fine isn’t always what you need. Here’s our framework for deciding when native development is worth the investment.
We get this question a lot: “Should we build native or cross-platform?” The honest answer is that it depends, but not on the things most people think it depends on.
The usual arguments (and why they’re incomplete)
The standard case for cross-platform is efficiency: one codebase, two platforms, faster time to market. The standard case for native is performance and platform fidelity. Both arguments have merit, but they miss the bigger picture.
When we go native
We choose native development (Swift for iOS, Kotlin for Android) when:
The product is the experience. If the app’s core value proposition is tied to how it feels (gesture interactions, animations, camera integration, real-time audio) native gives you control that cross-platform frameworks can’t match. You’re not fighting the abstraction layer.
Platform APIs are central. If you need deep integration with HealthKit, ARKit, Core ML, or other platform-specific frameworks, going native avoids the overhead of bridging and gives you first-class access.
Performance is non-negotiable. For real-time applications, complex rendering, or apps that need to feel instantaneous, native eliminates the JavaScript bridge bottleneck.
Long-term maintainability matters more than speed to market. Native apps tend to age better. When Apple or Google ships new platform features, native apps can adopt them immediately. Cross-platform frameworks always lag behind.
When we don’t
We choose cross-platform (usually React Native) when:
Speed to market is critical and the experience is standard. If the app is primarily forms, lists, and navigation, and the team needs to ship fast, cross-platform makes sense. The 80/20 rule applies: you get 80% of the native experience at a fraction of the development time.
The team already has strong React expertise. If the client’s engineering team knows React and will maintain the app long-term, React Native is a pragmatic choice.
Budget constraints are real. Building and maintaining two native codebases costs roughly 1.5-2x what a single cross-platform codebase costs. For early-stage startups validating an idea, that difference matters.
Our framework
We don’t have a religious position on this. We ask three questions:
- What’s the core experience? If it’s commodity UI, cross-platform. If it’s differentiated interaction, native.
- What’s the timeline? If it’s “we need to validate this quarter,” cross-platform. If it’s “we’re building for the next five years,” native.
- Who maintains it? If the client has a React team, React Native. If they have platform engineers (or us), native.
The worst decision is choosing cross-platform to save time and then spending months fighting the framework to achieve native-quality results. Know what you’re optimizing for, and choose accordingly.