Every client who comes to us wanting a mobile app asks the same question within the first fifteen minutes: "Should we go native or cross-platform?" It's a fair question. It's also the wrong framing.
The real question is: what are you building, who's building it, and how fast do you need to move? The answer to those three things determines the right path. Not a blog post from 2019 about React Native being slow.
We've shipped cross-platform apps with React Native and Expo. We've also advised clients toward native when the project demanded it. Here's the framework we actually use, drawn from real projects — including Edge Athlete OS, a coaching and athlete development app we built on React Native + Expo.
The Decision Framework: 5 Questions
Before we write a single line of code, we walk clients through these five questions. The answers almost always make the decision obvious.
1. Does Your App Need Deep Device Integration?
If you're building an AR experience, a real-time gaming engine, or something that needs to squeeze every frame out of the GPU — go native. Period. React Native has come a long way, but there are categories where native Swift/Kotlin still wins by a meaningful margin.
But here's the thing: most apps don't fall into this category. If you're building a platform with feeds, forms, maps, push notifications, camera access, and real-time data — React Native handles all of that without breaking a sweat.
2. Do You Need Both Platforms?
If you only need iOS or only need Android, native is a reasonable choice. You're not paying the cross-platform tax (which is smaller than people think), and you get the most idiomatic experience possible.
But if you need both — and you almost always need both — the math changes fast. Two native codebases means two teams, two sets of bugs, two release cycles, and twice the QA surface. That's not a 2x cost increase. In practice, it's closer to 2.5-3x when you factor in coordination overhead.
3. Does Your Team Know React?
This is the underrated question. If your existing team (or your agency's team) is deep in React and TypeScript, React Native lets them ship mobile without learning an entirely new ecosystem. The mental models transfer. The component patterns transfer. Even some of the libraries transfer.
At Aetheris, our entire web stack is Next.js, React, and TypeScript. When we picked up Edge Athlete OS, there was zero ramp-up time on the core paradigm. We were productive on day one because we already thought in React.
4. How Fast Do You Need V1?
Cross-platform wins on speed. One codebase, one team, one deployment pipeline. For Edge Athlete OS, we shipped the initial version in under two months — on both platforms. A native dual-platform build with comparable features would have taken 3-4 months minimum with a larger team.
When you're validating a product idea or racing to market, that timeline difference isn't academic. It's existential.
5. What's Your Post-Launch Iteration Speed?
This is where React Native's advantage compounds. After launch, every feature, every bug fix, every UI tweak ships to both platforms simultaneously. With Expo's OTA (over-the-air) updates, we can push non-native changes without going through app store review. That means we can fix a critical bug in production in minutes, not days.
Edge Athlete OS: The Case Study
Edge Athlete OS is a mobile coaching platform — athletes log workouts, coaches assign programs, both sides track progress with real-time data syncing. Here's why React Native + Expo was the obvious choice:
- Shared codebase, small team. We had two developers on it. Native would have required four, or forced us to stagger platform releases.
- Heavy on forms, feeds, and data. The app is fundamentally about displaying and capturing structured data. No AR, no complex animations, no GPU-intensive rendering.
- React expertise already in-house. Our team didn't need to context-switch. Same TypeScript, same component patterns, same state management approach we use on every web project.
- Fast iteration was critical. The client needed to test with real athletes and coaches quickly, gather feedback, and iterate. We couldn't afford a 4-month V1 timeline.
- Expo made the hard stuff easy. Push notifications, camera access for progress photos, secure authentication — Expo's managed workflow handled the native plumbing so we could focus on product logic.
The result: a production app on both platforms, built in under two months, with a codebase that any React developer can contribute to. Post-launch iterations ship weekly.
The Expo Ecosystem Advantage
We need to talk about Expo specifically because it's the reason React Native went from "viable but painful" to "genuinely excellent" for production apps.
Five years ago, React Native meant wrestling with Xcode and Android Studio, managing native dependencies manually, and debugging platform-specific build failures. Expo has eliminated most of that friction:
- Managed builds. EAS Build compiles your app in the cloud. No local Xcode/Android Studio setup required for most development.
- OTA updates. Push JavaScript bundle updates without app store review. Critical for fast iteration and emergency fixes.
- Prebuild system. When you do need native modules,
expo prebuildgenerates the native projects cleanly. You get escape hatches without losing the managed workflow. - Expo Router. File-based routing that mirrors Next.js conventions. If you know Next.js, you already know how to structure navigation in Expo.
- Universal libraries. Camera, notifications, location, secure storage, haptics — Expo maintains high-quality native modules so you don't have to rely on abandoned community packages.
For Edge Athlete OS, Expo Router gave us a navigation structure that felt immediately familiar. The file-based routing meant new screens were trivial to add, and deep linking worked out of the box.
Common Myths, Debunked
We hear these constantly. Let's put them to rest.
"React Native apps feel janky"
This was true in 2018. With the New Architecture (Fabric renderer + TurboModules), React Native now communicates with native modules synchronously. Animations run on the native thread. The performance gap for typical apps is imperceptible.
"You can't access native APIs"
Wrong. Expo modules and community packages expose virtually every native API. And when they don't, you can write a custom native module in Swift or Kotlin and bridge it. We've done this exactly once across all our React Native projects — and it took a day.
"Cross-platform means lowest common denominator"
React Native lets you write platform-specific code trivially. .ios.tsx and .android.tsx file extensions, Platform.select() calls, and conditional rendering let you tailor the experience per platform when it matters. Most of the time, it doesn't — users want your app to work, not to feel like a different app on each platform.
"It's harder to hire for"
React Native developers are React developers. The talent pool is massive. Finding someone who knows Swift AND Kotlin AND can ship on both platforms? That's the harder hire.
The Cost and Timeline Comparison
Here's a rough but honest comparison for a mid-complexity app (think: Edge Athlete OS level — auth, real-time data, push notifications, media uploads, role-based access):
| Factor | React Native + Expo | Native (iOS + Android) |
|---|---|---|
| Team size | 2-3 developers | 4-6 developers |
| V1 timeline | 6-10 weeks | 12-18 weeks |
| Codebase | 1 shared (~95%) | 2 separate |
| Post-launch iteration | Ship to both instantly | Coordinate dual releases |
| Annual maintenance | 1x | 1.8-2.2x |
| OTA hotfixes | Yes (Expo Updates) | No (app store only) |
These aren't hypothetical numbers. They're drawn from our actual project history.
When We Still Recommend Native
We're not dogmatic. Here are the cases where we'd steer a client toward native:
- Performance-critical graphics or gaming. If you're building something that needs Metal or Vulkan, go native.
- Deep OS integration. Widgets, watch apps, or tight integration with platform-specific features that don't have good cross-platform support yet.
- Existing native team. If you already have Swift and Kotlin developers who know the codebase, rewriting in React Native to "consolidate" usually isn't worth the migration cost.
- Single-platform bet. If you're genuinely only building for one platform and have native expertise, the abstraction layer doesn't buy you anything.
The Bottom Line
For 80% of the apps that come through our door, React Native + Expo is the right answer. It ships faster, costs less, iterates quicker, and the quality gap that existed five years ago has effectively closed.
Edge Athlete OS is proof. A production coaching app, on both platforms, built by a small team in weeks — not months. That's the power of choosing the right tool for the job instead of defaulting to what sounds more "serious."
If you're planning a mobile app and aren't sure which path fits, we're happy to walk through this framework with your specific requirements. The answer is usually clearer than you'd expect.