React Native or Flutter? How We Choose for Client Apps

Choose React Native if your team already builds for the web in React. Choose Flutter if the app has a custom design that must look the same on every phone. Choose native Swift or Kotlin if the app depends on device features. We build all three, and here is what decided each of our apps.

1. 01When we pick React Native

   React Native apps are written in JavaScript or TypeScript and render real native components. Developers who know React can work on them, and some code can be shared with a React website.

   We recommended React Native for Nextflag, a social travel app with a map of location flags, following and wishlists. Orchyd, a private cycle and fertility tracker with an AI assistant, is React Native too. Trusted Tastes, a restaurant app built on recommendations from people you follow, uses React on the web and React Native on mobile.

2. 02When we pick Flutter

   Flutter draws every pixel itself with its own rendering engine. A custom design looks identical on iOS and Android, with no native view in between. Apps are written in Dart.

   We built Houzi, a real estate app in Flutter, with 360° views of each property. StoreBevy is a white-label app in Flutter: one codebase, configured for each small retailer that wants its own branded store app.

3. 03When we go native

   Some apps lean hard on the phone: health data, widgets, background location or heavy animation. Those are better built in Swift for iOS and Kotlin for Android, even though that means two codebases.

   Slumber & Sprout is a native iOS app that tracks children’s sleep and builds routines. We built the Rails backend it talks to, which recalculates sleep schedules with Sidekiq when a routine changes.

4. 04Where the time goes

   Four things have cost us the most time on cross-platform apps, whichever framework the app uses.

   1. Package upgrades. The framework, its packages and the iOS pods have to move together. Nextflag lagged until we upgraded all three and tuned the app.

   2. Store review. Apple and Google can reject or hold a release, so leave room for review in every release plan.

   3. Older Android phones. An app that runs smoothly on a new iPhone can stutter on a low-end Android phone, so test on both.

   4. Push notifications. iOS uses Apple Push Notification service and Android uses Firebase Cloud Messaging, so each needs its own setup and testing.

   On Nextflag we also rewrote the post-upload screen, which often crashed the app, and saved onboarding progress at each step so people could resume.

5. 05The questions we ask first

   1. Who will maintain the app after launch, and what do they already know?

   2. Is there a web app, and is it built in React?

   3. How custom is the design, and must it match exactly on both platforms?

   4. Which device features does it need, such as the camera, location, health data or widgets?

   5. Does one codebase have to serve many customers, like a white-label app?