Most clients who ask us for a mobile app start with one question: should it be native, React Native or Flutter? The honest answer is that all three can ship a good app. The right one depends on a few things about your business that have nothing to do with which framework is fashionable this year. This is how we work through it with a client before we write any code.
Start with what the app has to do
Before comparing frameworks we write down the five or six screens that matter and the device features they touch. Most business apps turn out to be forms, lists, login, push notifications, a map or a camera, and a connection to an API. That kind of app is well served by a cross-platform framework.
The answer changes when the app depends on something the platform does unusually well:
- Heavy camera or video processing, AR, or custom audio
- Bluetooth devices, NFC readers or other hardware that needs vendor SDKs
- Background location, health data, or widgets that need close integration with Android or iOS
- A UI that has to follow each platform's conventions very closely
In those cases we lean toward native Kotlin and Swift, or at least native modules for those specific parts. Hardware vendors usually ship their SDK for Android and iOS first and wrap it for cross-platform tools later, sometimes never.
What we usually recommend
React Native when the client already has a React.js web product or a team that knows JavaScript. We can share types, API clients and validation logic with the web app, and the same developers can move between both. Navigation, forms and API-heavy screens come out well. The cost is that native libraries sometimes lag behind OS releases, and someone on the team has to be comfortable opening the Android and iOS projects when a dependency breaks.
Flutter when the design is very custom and has to look identical on both platforms, or when the app is mostly its own interface, such as dashboards, onboarding flows and animated screens. Flutter draws its own UI, so you get consistency and good performance. The trade-offs are Dart (a smaller hiring pool in many markets) and that platform widgets are re-implemented rather than used directly, so small details like text selection or accessibility behaviours deserve testing.
Native Android and iOS when the points above about hardware and platform features apply, when the app will live for many years with a dedicated team, or when the client wants only one platform at launch. Starting Android-only is a sensible choice in many markets, and nothing stops iOS coming later.
Questions that decide more than the framework does
Technology is usually not what makes a mobile project fail. These questions matter more:
- Who owns the backend? If the API is not designed yet, that is the first piece of work. A clean Laravel or Python API with versioning and token authentication makes any of the frontend choices easier. A messy API makes all of them hard.
- What happens offline? Field staff, delivery drivers and anyone on patchy mobile data need local storage and a sync plan. This affects architecture early and is expensive to add later.
- How will updates reach users? App store review, forced upgrades when the API changes, and a minimum supported OS version all need a decision. We agree a policy up front so an API change does not lock out older installs.
- Who maintains it after launch? A framework your future team can hire for is worth more than a theoretical performance gain.
- Which stores, and who holds the accounts? The Google Play and Apple developer accounts should belong to the client, not to the agency. Set this up in week one, because Apple's organisation verification can take longer than expected.
UI and UX decisions that belong in the choice
We design the key screens in Figma before committing to a toolkit. Designing first shows how much of the interface is standard (lists, tabs, forms) and how much is truly custom. If most of it is standard, the platform-native feel from React Native or native code is a benefit. If the design depends on custom motion and branding, Flutter is more attractive.
We also test the design on small and older phones early. In the markets we serve, a large share of users have mid-range Android devices with limited memory, so a design that feels smooth on a new flagship can be slow on a typical handset. Touch targets, readable type size and a sensible response to slow networks matter more than any animation.
Where AI features fit in
If you want an assistant or document search inside the app, the mobile framework barely matters. The model call should go through your own backend, not from the phone. That keeps keys off the device, lets you log and limit usage, and lets you change models without shipping a new app version. The app then only needs a good chat or result screen that handles streaming text, loading states, failures and clear labelling of what is machine generated. All three options handle that equally well.
A rough way to decide
- Existing React team and an API-driven app: React Native.
- Brand-heavy interface, same look on both platforms, small team: Flutter.
- Hardware, deep OS features, one platform first, or long-lived product with its own team: native.
- Unsure: build one or two real screens, including the hardest one, in the leading candidate before signing off the full scope. A short prototype costs far less than changing direction at month four.
What we ask you to bring
For a first conversation we only need a short description of who uses the app, the main tasks they do, any hardware or integrations involved, and whether a web product or API already exists. From that we can usually give a recommendation, a rough scope and the questions we still need answered. If you have a mobile project in mind, get in touch with the Rayaxis team in Lalitpur and we will talk it through.