If you are planning a mobile app, one of the first decisions your development partner will ask you to make is also one of the hardest to reverse: build two native apps, or build one cross-platform app with Flutter or React Native. The choice affects your budget, your launch date, who you can hire later and how the app feels in a customer's hand.

Much of the advice online is out of date. React Native finished a multi-year rebuild of its internals, Flutter replaced its rendering engine, and Kotlin Multiplatform has become a credible fourth option. This guide explains where each approach stands in October 2026, what actually drives cost and risk, and how a business in the United States or United Kingdom can make the decision without needing to read source code.

Quick answer

• Choose native (Swift for iOS, Kotlin for Android) when the app's value depends on deep device integration, the newest operating system features, heavy graphics or media processing, or when you only need one platform.
• Choose Flutter when you want one codebase with a consistent, custom-branded interface on both platforms and your team does not already have strong web (React) skills.
• Choose React Native when you have, or plan to hire, React and TypeScript developers, when you want standard platform controls on each OS, or when you want to share code and skills with a React web app.
• For most business apps (booking, e-commerce, account portals, field service, internal tools), all three can deliver a good result. The deciding factors are usually team, integrations and long-term maintenance, not raw speed.

What each approach is and how it works

Native development: Swift and SwiftUI, Kotlin and Jetpack Compose

Native development means building a separate app for each platform using the tools made by the platform owner. On iOS that is the Swift language with SwiftUI, Apple's UI framework for all Apple platforms. On Android it is Kotlin with Jetpack Compose, which Google describes as Android's recommended modern toolkit for building native UI.

Both are current and actively developed. Swift 6.4 was released on September 15, 2026, and the latest stable Compose UI release listed by Google is 1.12.1, dated September 9, 2026.

The practical consequence is simple: you get two codebases, two sets of specialist skills and direct access to everything each operating system offers on the day it ships.

Flutter

Flutter is Google's open-source UI toolkit. You write the app once in the Dart language and compile it to machine code for iOS and Android. The important architectural detail is that Flutter does not use the operating system's own buttons, lists and switches. In the words of the Flutter architectural overview, it "has its own implementations of each UI control, rather than deferring to those provided by the system", and it draws every pixel itself through a rendering engine that ships inside your app.

That engine is now Impeller. According to the Flutter documentation, Impeller is the only supported rendering engine on iOS and is enabled by default on Android API level 29 and above, with a fallback to the legacy OpenGL renderer on older or unsupported devices. The current stable line is Flutter 3.47, announced on August 12, 2026.

Result: the same screen looks the same on an iPhone and a Samsung phone, which is ideal for a strongly branded design and less ideal if you want each platform to look exactly like its system apps.

React Native

React Native is Meta's open-source framework. You write the app in JavaScript or TypeScript using React, the same library used on many websites. Unlike Flutter, React Native maps your components to the real native views of each platform, so a text field is an iOS text field on iPhone and an Android text field on Android.

If you last evaluated React Native a few years ago, its internals have changed. The old "bridge" that passed serialized messages between JavaScript and native code has been replaced by what the project calls the New Architecture. The timeline from the official React Native blog and documentation is:

• The New Architecture has been enabled by default since version 0.76.
• From version 0.82 it is the only architecture. Attempts to switch it off are ignored.
• Version 0.84 started removing Legacy Architecture code from iOS and Android builds and made the Hermes V1 JavaScript engine the default. An interop layer for older libraries remains in place.
• The latest stable release on the official versions page is 0.87, published on August 11, 2026.

The React Native team also recommends building new apps with a framework rather than assembling everything by hand. In practice that usually means Expo, which handles navigation, native APIs, builds and updates.

The fourth option: Kotlin Multiplatform

Kotlin Multiplatform (KMP) takes a different route. Instead of sharing the interface, you share the business logic (networking, data, validation rules) written in Kotlin, and keep a native interface on each platform. Google states that KMP is officially supported for sharing business logic between Android and iOS and describes it as stable and production-ready.

JetBrains also offers Compose Multiplatform for sharing the UI. Its stability table lists Android, iOS and desktop as Stable and web (Kotlin/Wasm) as Beta. KMP fits best when you already have a native Android team and want to stop writing the same logic twice. It is less common as a first choice for a company with no existing mobile team, so the rest of this article focuses on the three mainstream routes.

Side-by-side comparison

Performance: what the difference means in practice

For the screens that make up most business apps (forms, lists, maps, checkout flows, dashboards), a well-built app in any of the three approaches will feel smooth on modern phones. Users cannot tell which framework was used. Poor performance in these apps is far more often caused by slow APIs, oversized images or careless code than by the framework.

The differences appear at the edges:

• Native has the least overhead and the most control. It is the safe choice for real-time video or audio processing, complex camera pipelines, augmented reality, advanced Bluetooth work and high-end games.
• Flutter compiles Dart to machine code for release builds and controls its own rendering, so animation-heavy custom interfaces tend to be predictable across devices. The cost is that the engine is bundled with the app, which adds to download size.
• React Native runs your logic in a JavaScript engine. The New Architecture lets JavaScript call native code directly instead of sending serialized messages, and the renderer can now measure and render synchronously. That removed the main cause of the lag older React Native apps were known for. Very heavy computation still belongs in native modules.

We have deliberately not quoted benchmark numbers. Published figures vary widely with the device, the test and the skill of the team, and none of them predicts how your specific app will behave. If performance is a real risk for your product, ask for a short prototype of the hardest screen before committing.

Access to device features

All three approaches can reach the camera, location, push notifications, biometrics, secure storage, payments and Bluetooth. The question is how much work it takes.

Native code talks to these features directly. Flutter and React Native reach them through plugins, which are small pieces of Swift and Kotlin code wrapped for use from Dart or JavaScript. Common features have mature plugins. Three situations need care:

1. Brand-new OS features. When Apple or Google ships a new capability, native apps can use it at once. Cross-platform apps wait for a plugin or write their own native code.
2. Features that live outside the main app. Home screen widgets, watch apps, lock screen activities and car integrations are generally written natively even in a Flutter or React Native project.
3. Specialist hardware and vendor SDKs. Payment terminals, medical devices or industrial scanners often ship only native SDKs. They can be wrapped, but someone on the team must be comfortable in Swift and Kotlin.

The honest summary: a cross-platform project still needs access to native skills. It needs fewer of them, not none.

Team, hiring and maintenance

The framework you choose decides who can maintain your app for the next five years, so treat it as a staffing decision as much as a technical one.

• Native means two specialist skill sets. Every feature is designed once and built twice, and the two apps can drift apart unless someone actively keeps them aligned.
• Flutter means one team working in Dart. Dart is rarely used outside Flutter, so you are hiring Flutter specialists rather than drawing from a general pool.
• React Native means one team working in TypeScript and React. If you already have React web developers, they can become productive on mobile faster, and your web and mobile teams can share conventions and some code.

Maintenance is where expectations most often go wrong. A cross-platform app is not "write once, forget forever". Flutter and React Native both ship several feature releases a year, some with breaking changes. React Native 0.87, for example, raised its minimum Node.js version and changed its default TypeScript API, while Flutter 3.47 raised its minimum supported iOS version from 13 to 15. Third-party plugins must keep pace as well, and an abandoned plugin can block an upgrade.

Native apps have fewer moving parts between your code and the operating system, but you maintain two of them. Whichever route you take, budget for ongoing upgrades from day one.

Cost and timeline drivers

We are not going to give you a price or a "percent saved" figure, because any such number would be invented. What can be said reliably is which factors move cost and schedule.

• Number of platforms. If you need iOS and Android at launch, one shared codebase removes a lot of duplicated UI and logic work. If you only need one platform, most of the cross-platform advantage disappears.
• How much is truly shared. Standard screens share almost completely. Platform-specific features (widgets, wallet passes, deep OS integrations) are built per platform in every approach.
• Design ambition. A custom design system is roughly the same effort to build once in Flutter or React Native, and twice in native. A design that must match each platform's conventions closely takes extra effort in Flutter.
• Testing. Shared code reduces the logic you test twice, but you still test on real iPhones and real Android devices, across OS versions and screen sizes.
• Backend and integrations. For many apps the server side, payments, CRM or ERP integrations and admin tools are a larger part of the budget than the mobile UI, and they cost the same whichever framework you pick.
• Team availability. A framework your team already knows is cheaper than a theoretically better one they must learn.
• Years of ownership. Framework upgrades, OS releases and store policy changes are recurring costs. Compare approaches over three to five years, not only to launch.

When you compare quotes, ask each vendor to separate mobile UI, backend, integrations, QA and post-launch maintenance. That makes the real difference between approaches visible.

App store requirements that affect the decision

Apple and Google apply the same rules to every app, regardless of how it was built. A few of them interact with your framework choice. The details below are correct as of October 2026 and change regularly, so check the linked pages before you plan a release.

• Apple build tools. Apple's requirements page states that since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK or later. Your framework version has to support that toolchain, which is one reason you cannot leave a cross-platform app on an old release for years.
• Google Play target API level. Google's target API policy requires new apps and updates to target Android 16 (API level 36) or higher from August 31, 2026, with an extension available on request until November 1, 2026. Existing apps must target at least Android 15 to stay available to new users on newer devices.
• 16 KB memory page sizes on Android. Google Play requires apps that target Android 15 and higher to support 16 KB page sizes. Apps written only in Kotlin or Java are compatible by default. Apps that include native libraries are affected, and that includes Flutter and React Native apps and many SDKs, so framework and plugin versions must be current.
• More than a wrapped website. Apple's App Review Guideline 4.2 says an app should include features, content and UI that "elevate it beyond a repackaged website". Flutter and React Native apps are real apps and pass this test. A thin web-view wrapper around your site may not.
• Remote code updates. Guideline 2.5.2 says apps may not download or execute code that introduces or changes features or functionality. Over-the-air update tools used with React Native should therefore be treated as a way to ship fixes, not as a way to skip review for new features. Ask your developers how they stay within this rule.
• Account deletion. If your app lets users create an account, Apple requires account deletion inside the app (Guideline 5.1.1(v)), and Google Play requires both an in-app path and a web link. This needs backend work in every approach.
• Privacy disclosures cover your SDKs. Apple requires you to declare your app's privacy practices, including those of third-party code you integrate. Cross-platform apps often pull in many plugins, so keep an inventory of what each one collects.
• Google Play testing for new personal accounts. Personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers for 14 continuous days before applying for production access. Build that time into your launch plan.

US and UK factors to check early

These rules apply to the app, not the framework, but they influence scope and should be raised before development starts. This is general information, not legal advice.

• Accessibility for public bodies. In the UK, public sector mobile apps developed for use by the public must meet the WCAG 2.2 AA standard. In the US, the Department of Justice's ADA Title II rule applies to mobile apps that state and local governments provide or make available, with WCAG 2.1 Level AA as the technical standard. If you sell to government, education or healthcare bodies, expect these standards in procurement.
• Children's data. In the US, the FTC confirms that COPPA covers mobile apps directed to children under 13 that collect personal information. In the UK, the ICO's Children's code applies to apps likely to be accessed by children.

All three approaches can produce accessible apps that work with VoiceOver and TalkBack. Native and React Native use platform controls, which carry much of the standard accessibility behavior with them. Flutter builds its own accessibility information for the screen reader, which works but deserves explicit testing. In every case, accessibility has to be designed and tested. It does not arrive automatically.

Backend and API needs

Almost every business app is a front end to a server. The mobile framework does not change what the backend must do:

• A documented API (REST or GraphQL) with versioning, because old app versions stay installed on phones long after you release a new one.
• Authentication with short-lived tokens, refresh handling and, where relevant, sign-in with Apple or Google.
• Push notifications through Apple Push Notification service and Firebase Cloud Messaging.
• File and image handling, background sync and a clear rule for what happens offline.
• An admin panel, analytics and crash reporting.

Because all three approaches consume the same API, a well-designed backend also protects you. If you later move from one mobile framework to another, or add a web app, the server and data stay as they are.

Security considerations

None of the three approaches is inherently secure or insecure. The security of a mobile app depends mainly on how it stores data, how it talks to the server and what the server allows. The OWASP Mobile Application Security Verification Standard (MASVS) is a useful, framework-neutral checklist covering storage, cryptography, authentication, network communication, platform interaction, code quality, resilience and privacy.

Points worth raising with any developer:

• Secrets do not belong in the app. API keys and business rules shipped inside an app can be extracted, whether the app is native, Flutter or React Native. Sensitive logic and authorization checks belong on the server.
• Use the platform's secure storage. Tokens should live in the iOS Keychain and Android Keystore-backed storage. Both cross-platform frameworks reach these through plugins.
• Dependencies are part of your attack surface. Cross-platform apps rely on package ecosystems (pub.dev for Flutter, npm for React Native) in addition to native libraries. Ask how dependencies are reviewed, pinned and updated.
• Regulated data. For payments, health or financial data, involve compliance early. The framework rarely decides the outcome, but SDK choices and data flows do.

Decision table: which approach fits your situation

Two short examples. A Texas home-services company that wants customers to book visits, pay and track a technician needs both platforms, standard features and a solid backend. Flutter or React Native fits. A UK health-tech firm building an app that pairs with its own Bluetooth sensor and processes readings on the device has hardware and performance risk at its core. Native is the safer starting point, possibly with shared Kotlin logic later.

Common mistakes to avoid

• Choosing on benchmarks. Framework speed tests rarely reflect a business app's real bottlenecks.
• Assuming cross-platform means zero native work. Store configuration, push notifications, widgets and some SDKs still need Swift and Kotlin.
• Ignoring the upgrade budget. Store deadlines for SDK and API levels arrive every year in every approach.
• Rewriting without a reason. Moving a working app to a different framework costs money and adds risk. Do it only to solve a specific problem.
• Deciding before the feature list is clear. One hardware integration or offline requirement can change the right answer.

For technical readers

• React Native. The New Architecture consists of the Fabric renderer (C++ core shared across platforms), Turbo Native Modules and JSI for direct JavaScript-to-native calls. Since 0.82 there is no opt-out, and Legacy Architecture code has been removed progressively from 0.84 onward while the interop layer remains. Hermes V1 is the default engine from 0.84. In 0.87 the Strict TypeScript API is the default, with an opt-out the release notes say is available through 0.88, and Swift Package Manager support is experimental and not yet recommended for production. Audit third-party libraries for New Architecture support before upgrading an older app.
• Flutter. Release builds are compiled ahead of time to machine code. Native interop uses platform channels, with the Pigeon package for type-safe generated bindings. On Android, Impeller is the default on API level 29 and above. On the web, Flutter still renders with Skia. In 3.47, Material and Cupertino are available as opt-in standalone packages (material_ui and cupertino_ui, both at 1.0), Impeller became the default renderer on desktop, and iOS dependency management continues to move from CocoaPods to Swift Package Manager. The supported platforms page lists iOS 15 and Android API level 24 as the minimum supported versions.
• Native. SwiftUI and Jetpack Compose are both declarative and both interoperate with their older counterparts (UIKit and Android Views), so existing apps can adopt them screen by screen.
• Kotlin Multiplatform. Core KMP is Stable for Android and iOS. Compose Multiplatform is Stable on Android, iOS and desktop, and Beta for web on Kotlin/Wasm. A common pattern is shared data and domain layers with SwiftUI and Compose interfaces.
• Brownfield options. Both Flutter and React Native can be embedded in an existing native app, which allows gradual adoption instead of a full rewrite.

Frequently asked questions

Is Flutter or React Native better in 2026?

Neither is better in general. Both are stable, actively maintained and used in production. Flutter suits teams that want full control of a custom interface from one codebase. React Native suits teams with React and TypeScript skills or a React web app. For a typical business app, team fit matters more than framework differences.

Can users tell whether an app is native or cross-platform?

Usually not, if the app is built well. Users notice slow loading, awkward navigation and crashes, which come from design and engineering quality. Differences become noticeable mainly in graphics-heavy or hardware-heavy apps, or when a Flutter interface deliberately differs from platform conventions.

Is cross-platform development always cheaper than native?

No. It usually reduces mobile UI and logic effort when you need both iOS and Android, but backend, integrations, design, testing and maintenance cost the same or nearly the same. If you need only one platform, or the app relies heavily on platform-specific features, native can be the more economical choice.

Is React Native still slow because of the bridge?

That description is outdated. The bridge-based Legacy Architecture is no longer the way React Native runs. The New Architecture has been the default since version 0.76 and the only architecture since 0.82. Older apps and libraries that have not been migrated need work before they can use current versions.

Can we start cross-platform and move to native later?

Yes, but treat it as a partial rebuild of the mobile app rather than a conversion. Your backend, API, design and product knowledge carry over. The mobile code mostly does not. A gradual path is to add native screens or modules inside the existing app where needed.

Do Apple and Google treat Flutter and React Native apps differently in review?

No. The store guidelines apply to the app's behavior, content and privacy practices, not to the framework. Apps built with either framework must meet the same SDK, target API, privacy and account deletion requirements as native apps.

How long does it take to build a mobile app with each approach?

It depends on scope far more than on framework. The number of screens, integrations, user roles, offline needs and the state of your backend drive the schedule. A shared codebase generally shortens the mobile part when two platforms are required. Ask for an estimate broken down by feature rather than a single figure.

Conclusion: choose for your product, team and next five years

In 2026, native, Flutter and React Native are all mature ways to build a mobile app. Native gives the most control and the earliest access to platform features at the cost of two codebases. Flutter gives one codebase and a consistent custom interface. React Native gives one codebase, real platform controls and access to the large React talent pool. Kotlin Multiplatform is worth a look if you already have a native Android team.

The reliable way to decide is to write down your must-have features, the platforms you need at launch, the skills you have or can hire, and what you expect to change over the next few years. Then test the riskiest feature with a small prototype before committing the full budget.

If you would like a second opinion on that list, Entrant Technologies builds native iPhone and Android apps as well as Flutter and React Native apps, and we are happy to talk through which approach fits your requirements before any code is written. You can request a quote to start that conversation.