Stack360 Logo
Stack360
Stack360 Icon
Stack360
Skip to main content
Stack360 Logo

Mobile

React Native or Flutter? How We Choose for Client Apps

By M. Awais Aslam, Co-Founder · Reviewed by Azmat Rana

  • October 12, 2026
  • 5 min read
  • 5 sections

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. 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.

    Our Flutter developers built StoreBevy, 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?

Common questions

Is React Native or Flutter faster? Both are fast enough for most business apps. The design, the data and the backend usually matter more.

Can we switch frameworks later? Only by rebuilding the screens. The backend and APIs can stay, so choose with the long term in mind.

Can one team build for iOS and Android? Yes. With React Native or Flutter, one codebase ships to both stores.

Do you take over apps another team built? Yes. The first step is getting the project building on current tools and reading its crash reports, before changing anything.

Ready to build the next success story?

Partner with a studio that ships production systems — and stays accountable after launch.