If you need to build an app for iOS and Android, the first thing you have to decide is: native code for each platform (Swift + Kotlin), or cross-platform with a single codebase (React Native, Flutter, Capacitor). In this article I tell you when each option makes sense, with real data and no marketing.
TL;DR
- React Native: I use it when the app is about management, content, forms, login, chat, calendars, API integrations. Huge JavaScript ecosystem, easier hiring, my main stack.
- Flutter: I recommend it when the UI is very custom (animations, transitions, off-the-beaten-path design), pixel-perfect performance is critical, or the team comes from Dart/frontend.
- Pure native (Swift + Kotlin): only if you need access to very specific system APIs, extreme performance (games, AR, video processing), or an app with deep hardware integrations.
- Capacitor / PWA: if the “app” is basically a mobile web with push notifications, Capacitor gives you the shortest path.
Why I work with React Native (transparency)
Before going into the comparison, full transparency: I work best with React Native because I have been in the JavaScript/TypeScript ecosystem for years. If you come with a Flutter project, I can help but I will probably recommend someone I trust who knows the stack better. With that clear, let’s go to the analysis.
React Native: the ideal case
Pros (what it does well):
- One codebase for iOS, Android and web (with React Native Web). Your app reaches 3 platforms with one team.
- Massive JavaScript/TypeScript ecosystem: any frontend library has its RN equivalent.
- Hot reload: you see changes instantly without recompiling. Speeds up development a lot.
- Hiring: there are many more JavaScript developers than Dart. Easier to find a team.
- Native library integration: if you need a native SDK, there is almost always a wrapper on npm.
- Shared backend: if your backend is Node/TypeScript (as I usually do with Supabase or Firebase), you share types and logic.
Cons (where it falls short):
- Performance: for apps with heavy animation or graphics, it lags behind Flutter.
- Native debugging: when something fails in the JS-native bridge, debugging can be a nightmare.
- Third-party library dependency: sometimes a library is poorly maintained and blocks you.
- System updates: when Apple or Google change something, RN takes weeks to support it (although lately it does it fast).
Use cases where it shines:
- Internal management apps (appointments, orders, stock, CRM)
- Content apps (blogs, news, podcasts)
- Marketplaces
- Apps with login, forms, dashboards
- MVPs to validate ideas
- Apps with strong backend integration (Supabase, Firebase, REST/GraphQL)
Flutter: the ideal case
Pros (what it does well):
- Near-native performance: compiles to native ARM code, no JS bridge. For apps with animations or graphics, it is better than RN.
- Consistent UI across platforms: if your app has very custom design, Flutter nails it on iOS and Android.
- Own widgets: the framework includes widgets that replicate Material Design and Cupertino, without depending on system ones.
- Excellent for animations: Flutter animation engine is best-in-class.
Cons (where it falls short):
- Smaller ecosystem: fewer libraries than JS, and quality varies more.
- Harder hiring: fewer Dart developers than JS.
- App weight: Flutter apps weigh more (because of the embedded engine).
- Smaller community in Spain: you will find less local help.
Use cases where it shines:
- Apps with very custom UI (animations, transitions, off-the-beaten-path design)
- Apps that need pixel-perfect performance (drawing, design, image editing)
- Teams that already come from Dart or want to learn it
- Apps that feel more like a “game” than a “traditional app”
Pure native: when it is the only option
- Augmented reality / Virtual reality
- Real-time video or audio processing
- Access to very specific system APIs (complex Bluetooth LE, advanced NFC, etc.)
- Games with intense 3D graphics (for that you use Unity or Unreal, not Flutter)
- Apps with very specific platform requirements (Apple Watch, Wear OS)
Capacitor / PWA: when the “app” is a web
If your app is basically a webapp with push notifications, geolocation and some camera, Capacitor (which I use as a complement) gives you:
- Minimum development time because it is wrapped HTML/CSS/JS.
- Same code for web and app.
- Publishing on App Store / Google Play without issues.
- Minimum bundle size compared to RN or Flutter.
Limitations:
- Limited access to native APIs (less every day, but some are not there).
- Lower performance than RN/Flutter on long lists or complex animations.
- “Wrapped web” feel in some UI details.
Technical and cost comparison
| Aspect | React Native | Flutter | Native |
|---|---|---|---|
| Language | JavaScript / TypeScript | Dart | Swift + Kotlin |
| Performance | 90% native | 95% native | 100% native |
| Development time | Low | Low-Medium | High |
| Initial cost (MVP) | EUR 800-3,000 | EUR 1,000-3,500 | EUR 3,000-8,000 |
| Maintenance cost | Low | Low | High (2 codebases) |
| Ecosystem | Huge | Big | Platform-specific |
| Hiring in Spain | Easy | Medium | Specific |
| Bundle size | 5-15 MB | 8-25 MB | 2-8 MB |
| Learning curve | Low (if from JS) | Medium | High (2 languages) |
| Apple Watch / Wear OS support | Limited | Limited | Total |
My honest recommendation
For most business apps (management, appointments, orders, content, marketplaces):
- React Native if you come from JavaScript/TypeScript or have a team like that. It is what I use the most and where I deliver fastest.
- Flutter if the UI is very custom, you want maximum performance or your team comes from Dart frontend.
- Capacitor if your “app” is essentially a webapp with notifications and you want the shortest path to market.
- Native only if you have a very specific technical reason (AR, intense graphics, specific hardware).
If your project is an MVP to validate an idea, React Native almost always wins: time-to-market is the lowest, initial cost is the most contained, and if the idea works you can invest in native or Flutter later without rewriting everything.
Real case: the Clínica Pepa Ramon app
When the clinic asked me for an internal management app (appointments, real-time earnings, patient chat, clinical history, push), I went with React Native because:
- Backend in Supabase + TypeScript -> I share types between backend and app.
- Management UI, not creative -> calendars, forms, lists, dashboards. No need for crazy animations.
- Need for iOS + Android + web panel -> React Native + React Native Web covers all 3.
- My delivery speed -> I already master RN, I deliver faster than learning Flutter from scratch.
- The client will not know the technology -> they do not care, as long as it works on their iPhone and Android.
Result: functional app in 6 weeks, with a single codebase, ready to iterate sprint by sprint.
Conclusión
There is no universal winner. There is a winner for your specific case, and it depends on your team, your budget, your timeline and the type of app. If you want me to help you decide, write to me or by WhatsApp and we look at it in 15 minutes on a call. No commitment.