Swift vs React Native: When to Use Which

I’ve shipped apps in both Swift and React Native, and the question of which to reach for comes up enough that it’s worth writing down how I think about it.

The short version: Swift when the platform is the product, React Native when the web team is the team.

Where Swift wins

SwiftUI and UIKit give you the full platform. When the user experience lives in gestures, animations, haptics, and native controls — things like a camera app, a fitness tracker, or anything that needs to feel exactly like a first-party Apple app — Swift isn’t just better, it’s the only real choice.

The same goes for anything that needs deep OS integration: background processing, HealthKit, CoreBluetooth, ARKit, on-device ML. React Native has bridges and community libraries, but they’re almost always a version behind and occasionally just broken on the latest iOS.

The tooling is also genuinely good now. Xcode previews have improved, Swift concurrency (async/await, actors) is solid, and the language itself has gotten markedly cleaner over the last few years.

Where React Native makes sense

If you have a TypeScript/React web team and you need a mobile app, React Native gets you there without splitting into two separate codebars, two code review cultures, and two deployment pipelines.

Expo in particular has changed the calculus significantly. EAS Build, OTA updates via expo-updates, and the managed workflow mean you can ship a real app without touching Xcode or Android Studio for most of the lifecycle.

Navigation with react-navigation, state with whatever you’re already using — the ecosystem is mature enough that you rarely hit gaps on the common paths.

The honest tradeoffs

React Native still has a performance ceiling on UI-intensive work. The bridge (or the new architecture’s JSI) adds latency that you can work around, but not eliminate. If you’re building something with complex animations or real-time interaction, you’ll feel it.

Swift is iOS-only. If Android matters — and it usually does — you’re either writing it twice or you’re on React Native.

My default: greenfield mobile product with a dedicated mobile team → Swift. Mobile surface for an existing web product, or anything that needs to ship on both platforms → React Native with Expo. The choice is almost always made by the team structure before it’s made by the technology.