Flutter, React Native, or native: choose for your product

Flutter’s documentation explains shared UI development and integration with platform-specific features when needed. React Native’s documentation describes native module routes. Neither means every feature is written once with no platform work. Notifications, camera, sign-in, and accessibility must still be tested separately on iOS and Android. Payments or maps may require different configuration and review even when screens and business logic are shared.

Ask a supplier what portion of *your* project they expect to share, which parts require native code, and how library upgrades will be handled as platforms evolve. A blanket claim such as “save half the cost” is not a useful estimate. Backend services, UX design, testing, and store operations remain significant whatever front-end framework is selected.

A technically attractive choice can be poor for a company that cannot maintain it or take over code from its vendor. Ask for relevant production examples, code organisation, test strategy, and documentation of third-party dependencies. Ownership of store accounts, source repository, and build environment should be explicit. If a key developer leaves, can another build a release and fix a defect without weeks of reconstruction?

Do not choose solely by popularity. React Native may fit a team skilled in JavaScript and React. Flutter may suit a team experienced with Dart and custom UI work. But when your product depends on a lightly supported device capability, test that integration rather than assume it. A capable team and reliable handover reduce delivery risk more than a broad argument about which framework is “best”.

If the product deeply uses operating-system components or needs materially different behaviour on each platform, two native applications or substantial native modules may be the right investment. Apple documents SwiftUI and Android documents Kotlin support for their ecosystems. “Native” alone does not guarantee speed, however. A poorly designed native app with a slow server may feel worse than a well-built cross-platform product.

With a limited budget, ask whether both platforms are necessary on day one. A capable mobile website or one application for the dominant audience might be a better test. This does not mean abandoning the second platform forever. Clear backend services and data ownership make a later client possible when demand is demonstrated.

Define a scenario: opening hundreds of items, taking and uploading a photo on a weak connection, updating a map, or saving a form offline. Prototype it on an ordinary device representative of buyers, not only the newest phone in the development office. Measure responsiveness, stability, and battery use where relevant, then diagnose the cause of delay. A slow database query or oversized image may matter more than the UI framework.

Set an acceptable user outcome before testing. For example, input must survive temporary disconnection and critical actions must show understandable progress. Without a user-centred target, a technical benchmark alone cannot settle the decision.

Include operating-system and store updates, package upgrades, compatibility with payment and map services, defect fixes, and tests on new devices. A cross-platform product may update shared code once, yet an abandoned dependency can require urgent native work. Native products offer direct platform control but maintain two development and test tracks. Ask for a maintenance plan and clear responsibilities, not a build price alone.

Test the technology decision against an expensive real workflow rather than a polished demo screen. If the app relies on camera access, maps, notifications, or offline work, build a small version of that task and measure stability and response on an ordinary device. Also rehearse a minor release: an excellent prototype can still have a slow, fragile build pipeline. Identify who will maintain third-party packages over the next two years and how operating-system updates will be tested. A written spike result gives management evidence for the choice and makes remaining risks visible.

To decide, write down five central user journeys, unusual device features, launch platforms, team expertise, budget, deadline, and the largest unknown. Prototype that unknown first. Choose the approach that delivers reliable experience with a sustainable total cost.