Most teams weighing cross-platform development end up choosing between two frameworks. In Stack Overflow’s 2024 Developer Survey, Flutter came in at 9.4% and React Native at 8.4% of respondents.
The webview-based tools trail them, with Ionic at 2.5%, Cordova at 2.2% and Capacitor at 1.8%.
All of them aim at the same goal. One shared codebase runs on iOS, Android, web and desktop, so a team can ship to the Apple App Store and Google Play from a single project instead of keeping separate native apps in Swift and Kotlin.
What Is Cross-Platform App Development?
One shared codebase, several operating systems (iOS, Android, web and desktop), and no separate native codebase for each. Flutter’s documentation notes that the operating system packages a Flutter app like any other native application.
The point is code reuse. How much gets shared depends on the framework. Some share the whole app, interface included, while others share only business logic.
Flutter’s documentation lists iOS, Android, web and desktop as targets. .NET MAUI reaches Android, iOS, macOS and Windows (Microsoft Learn), and Expo, the React-based platform used with React Native, covers Android, iOS and the web (Expo repository).
Neighboring terms overlap, so the boundaries need drawing.
Hybrid apps get mixed up with all of this. A hybrid app wraps a web interface in a native shell, so it’s one approach inside cross-platform development and not another word for it.
Flutter and React Native never load a webview for their interface. Flutter paints it with its own engine, and React Native renders through native components.
A progressive web app delivers one web codebase through the browser, with no separate build per operating system. It shares the single-codebase idea but runs through the browser rather than as a compiled app package.
“Multiplatform” is the same idea under a different brand. Microsoft calls its framework Multi-platform App UI, and JetBrains went with Kotlin Multiplatform.
What actually matters is where the sharing stops.
How Cross-Platform Apps Run on Several Platforms
A framework takes the shared code and produces a native app package for each operating system. Some draw the interface themselves. Others map it to native components, host it in a webview, or share only the business logic and leave the interface native.
Own rendering engine
Flutter compiles Dart to machine code (Intel x64 or ARM) for release builds and paints every widget with its own engine instead of the system’s controls, according to its architecture documentation.
Because the engine ships inside the app, a switch looks and behaves the same on every OS version.
The cost is a larger install, since the engine travels with every app.
Native component mapping
React Native used to have JavaScript talk to native code over an asynchronous bridge. That’s gone now. JSI, Fabric and TurboModules let JavaScript call native code directly, and native modules load lazily.
React Native 0.76 made this the default on October 23, 2024, per the React Native blog.
.NET MAUI maps its controls to platform controls from C# and XAML, with one project targeting Android, iOS, macOS and Windows. On Android, iOS and macOS it runs on Mono, and Windows apps use WinUI 3 (Microsoft Learn).
Webview wrapper
Webview apps run a website inside a native shell.
Ionic’s documentation describes the stack as a web app hosted in a Web View. Capacitor acts as the native runtime, and plugins expose device APIs to the web layer.
Apache Cordova uses the same webview model, and Ionic names Capacitor as the official native runtime for its stack. Interface speed depends on how the webview renders the web layer.
Shared business logic
Some teams share only the logic and keep the interface native.
Kotlin Multiplatform reached stable status on November 1, 2023 (DevClass, reporting JetBrains’ announcement), covering iOS, Android, desktop, web and server.
Compose Multiplatform adds a shared interface on top. At that 2023 launch it was stable only for Android and desktop, and JetBrains declared the iOS target stable with version 1.8.0 in May 2025.
Cross-Platform Frameworks and the Languages They Use
Flutter uses Dart and React Native uses JavaScript and TypeScript. Kotlin Multiplatform runs on Kotlin, .NET MAUI on C#, and Ionic with Capacitor on HTML, CSS and JavaScript. Of the lot, Flutter and React Native lead on usage.
| Framework | Language | Interface rendering | Targets |
|---|---|---|---|
| Flutter | Dart | Own engine (Impeller; Skia on web) | iOS, Android, web, desktop |
| React Native | JavaScript, TypeScript | Native components | iOS, Android (web via Expo) |
| Kotlin Multiplatform | Kotlin | Native UI or Compose Multiplatform | Android, iOS, desktop, web, server |
| .NET MAUI | C# and XAML | Native controls | Android, iOS, macOS, Windows |
| Ionic with Capacitor | HTML, CSS, JavaScript | Webview | iOS, Android, web |
Google builds Flutter and Dart, Meta created React Native, JetBrains maintains Kotlin Multiplatform, Microsoft builds .NET MAUI, and the Ionic team maintains Capacitor. Expo adds hosted build services (EAS) around React Native projects.
Electron sits outside the mobile set. It covers desktop only (Windows, macOS and Linux) and wraps web technologies in a native window.
Microsoft ended support for all Xamarin SDKs, Xamarin.Forms included, on May 1, 2024, and recommends .NET MAUI as the successor.
Stack Overflow’s 2024 Developer Survey puts Flutter at 9.4% of all respondents and React Native at 8.4%. Among professional developers the gap narrows to 9.4% against 9.0%.
Xamarin (2.9%) still sat close to .NET MAUI (3.1%) in that survey, even with support ending. Stack Overflow’s 2025 survey has no comparable framework question, so the 2024 figures are the latest of their kind.
Popularity depends on what gets counted. The Pragmatic Engineer reports that around 11% of apps released in 2024 used Flutter against 7% for React Native, yet the same piece finds React Native apps earn more revenue.
The sources don’t agree. Professionals are nearly tied, and Flutter leads in new releases while React Native leads in revenue. No single ranking fits all of that.
Flutter and React Native differ mostly in rendering and language, a trade-off covered in this comparison of Flutter and React Native.
Smaller options and build tooling get a wider rundown in this roundup of cross-platform development tools.
How Does Cross-Platform Performance Compare With Native?
Both leading frameworks have removed their best-known bottleneck. React Native replaced its asynchronous bridge with the New Architecture, and Flutter’s Impeller precompiles shaders at engine-build time so they do not compile at runtime.
Third-party posts give conflicting release numbers for these milestones, so the official changelogs decide. React Native 0.74 made Bridgeless the default under the New Architecture, and 0.76 enabled the New Architecture by default.
The official sources give these versions and dates.
- React Native 0.76 turned the New Architecture on by default and was released October 23, 2024 (React Native blog).
- On iOS, Impeller has been Flutter’s default since Flutter 3.10 (May 2023), and Flutter 3.29 removed Skia from the iOS backend, so there is no way to switch back (Flutter documentation and release notes).
- Android got Impeller by default on API 29 and above with Flutter 3.27 (Flutter documentation).
- Compose Multiplatform adds about 9 MB on iOS compared with a native SwiftUI app (JetBrains, May 2025).
The baseline for every comparison is a pair of native apps, one in Swift and one in Kotlin.
Against that baseline, the remaining costs are structural. Flutter ships Impeller inside every app, so install size grows, and JetBrains puts its own equivalent at roughly 9 MB.
JetBrains also reports that over 96% of teams using Compose Multiplatform on iOS see no major performance concerns. That figure comes from a vendor-run survey, so weigh it accordingly.
Embedding native views inside a Flutter screen, Google Maps for example, adds synchronization overhead, according to Flutter’s architecture documentation.
Webview apps are the weakest case. Their interface is a web page, so slow web code stays slow on a phone.
Cross-Platform vs Native: Cost, Speed and Team Size
One team on one stack replaces two platform teams, and that is where the savings come from. Platform-specific code, plugin upkeep and framework upgrades take part of them back.
Published savings percentages vary widely and rarely state a method, so the structural drivers matter more than any single number. Budgets also depend on scope and team rates, which is why a breakdown of mobile app development costs is worth reading before any estimate.
Coinbase moved its iOS and Android apps to React Native in January 2021. Its engineering blog says that over the preceding year the company could hire only half as many mobile engineers as web engineers.
The same post records the price of the transition. While native and shared code coexisted, iterating on shared code could require knowledge of three platforms and take longer than fully native work.
Where cross-platform helps
You get one team and one release pipeline, and features reach iOS and Android together. Hiring gets easier too, because you can draw from web talent pools, which is what Coinbase did with React Native in 2021.
Where it costs you
Platform-specific code and plugins still need native skills, and no framework changes that. Framework lifecycles also become a dependency (Xamarin support ended May 1, 2024).
Where a framework draws its own controls, the native look is reproduced, not inherited. And in Flutter, embedded native views carry synchronization overhead.
What native offers
Native gives direct use of platform SDKs and first-party tooling such as Xcode and Android Studio, with no framework layer between the app and the operating system.
The price is two codebases in two languages, usually Swift and Kotlin. That means two teams and two release pipelines, with every feature built twice, plus hiring pressure on specialist mobile engineers, the problem Coinbase reported in 2021.
Hybrid sits apart from both. A comparison of native, hybrid and cross-platform apps shows where each one fits.
The savings are real when most screens share code. They shrink fast when most features need platform-specific work.
Native Features and UI Fidelity in Cross-Platform Apps
Cross-platform apps reach device features through plugins first and custom native code second. Every major framework documents that second route, and each one asks the team to know the underlying platform.
| Framework | Escape hatch | Native side |
|---|---|---|
| Flutter | Platform channels, plus FFI for C-based APIs | Kotlin or Swift |
| React Native | TurboModules with a typed JavaScript spec | Kotlin or Java, Objective-C++ |
| Kotlin Multiplatform | expect and actual declarations | Platform source sets |
| .NET MAUI | Conditional compilation, partial classes | C# against platform APIs |
React Native’s documentation says to write a Turbo Native Module when the app needs platform APIs that neither the core nor an existing library provides. The module starts as a typed JavaScript spec, and Codegen turns it into native interfaces.
Microsoft Learn is blunt about the price for .NET MAUI. Platform code requires knowledge of Apple’s, Google’s and Windows App SDK APIs.
JetBrains’ documentation steers Kotlin Multiplatform teams away from overusing expect and actual declarations. Standard language constructs such as interfaces come first, and expected and actual classes were still labeled Beta on the page updated May 13, 2026.
React Native and .NET MAUI hand rendering to platform controls, so screens pick up each OS’s look and behavior.
Flutter paints its own widgets and ships Material and Cupertino control sets for the Android and iOS design languages. The app keeps its look when the OS changes its controls, until Flutter’s own controls change.
Capacitor supplies only the runtime, and Ionic’s documentation points to a UI framework such as Ionic Framework for mobile-style components.
iOS users judge apps against Apple’s Human Interface Guidelines, so any framework that draws its own controls has to reproduce them.
On Android the reference is Material Design principles, which a native-component framework inherits and a drawing framework copies.
Keep the native edge small and written down, with one module per platform feature and an owner who knows that platform.
Maintenance, Testing and Device Fragmentation
A shared codebase gives one release plan but not one deadline. Apple and Google each enforce their own annual toolchain requirement, and the framework has to support both before a team can ship.
| Platform | Store requirement | Flutter 3.47 support window |
|---|---|---|
| iOS | Xcode 26 and iOS 26 SDK for uploads from April 28, 2026 | iOS 15 to 27 |
| Android | Target API 36 for new apps and updates, deadline every August 31 | API 24 to 37 |
The iOS row comes from Apple’s upcoming-requirements page. The Android row comes from Google Play’s target API policy and its 2023 developer update, and the support windows from Flutter’s supported-platforms page.
Apple’s rule applies to the uploaded binary, so Flutter, React Native and Capacitor builds all pass through it. MacTech, reporting Apple’s announcement, says the next step is the iOS 27 SDK from April 2027.
Lag behind new OS releases is short for the leading frameworks. Apple scheduled iOS 27 for September 14, 2026 (MacTech), and Flutter’s support page, last updated eight days later, already lists iOS 15 to 27.
That page covers the framework itself, not every third-party plugin.
A framework’s support window sets the test matrix a team inherits. Flutter 3.47 spans 14 Android API levels (24 to 37) and 13 iOS major versions (15 to 27).
Flutter’s documentation ranks unit tests lowest on confidence and lowest on maintenance cost, and they run quickly. Integration tests sit at the other end. They give the most confidence, cost the most to maintain, run slowly, and usually need a real device or an emulator.
Native code is the blind spot. React Native’s documentation warns that component tests run in Node.js and cannot catch bugs in iOS or Android code, and Flutter’s integration_test package cannot drive permission dialogs, notifications or platform views.
For those gaps, React Native’s documentation names Detox, Appium and Maestro for end-to-end runs. Flutter’s documentation points to the open-source Patrol package for native interactions.
Because every release passes two stores, a regression testing pass on real devices belongs in each cycle, not only in releases that touch native code.
Budget for post-deployment maintenance as seriously as for launch, since the two deadlines recur every year.
When Cross-Platform App Development Does Not Fit
It fits poorly when the product is a thin wrapper around a website, when it needs high-end graphics, when it targets a platform the framework does not list, or when the whole audience sits on one platform. Each case has a documented cause.
Conditions that break the case
Apple’s App Store Review Guidelines (section 4.2, Minimum Functionality) reject apps that amount to a repackaged website.
A webview shell with no native features is the clearest candidate. For that product, a comparison of a mobile app or web app is the better starting point.
Heavy graphics are a different problem. Flutter documents a games toolkit for casual titles, including a tutorial on the Flame engine, while teams building 3D games use dedicated engines such as Unity instead.
Then there are platforms the framework simply doesn’t cover. Flutter’s supported-platforms page lists Android, iOS, Windows, macOS, Debian and Ubuntu Linux, and four web browsers. watchOS and Wear OS do not appear on it.
With a single-platform audience, there is nothing to share. The framework adds a dependency between the app and the platform SDK without a second platform to pay it back.
Documented reversals
Facebook’s 2012 reversal is the oldest case. Mark Zuckerberg called betting too much on HTML5 over native the company’s biggest mistake, and said people consumed twice as many feed stories after the native iOS app shipped (TechCrunch Disrupt, reported by InfoQ).
Critics quoted by The Register blamed execution, not the web stack. The 2012 app was an HTML5 web app bundled into a native shell, per Motley Fool, which is a different technology from React Native or Flutter.
Airbnb
The engineering team announced in June 2018 that it was sunsetting React Native after two years, citing technical and organizational issues, among them initialization and the async first render.
Surveyed engineers still leaned positive. 63% would have chosen React Native again and 74% would consider it for a new project.
The decision came more than six years before React Native 0.76, so it describes the older runtime.
Coinbase again
In early October 2026, Coinbase manager Adam Wolf announced that the consumer trading app is moving off React Native to Swift and Kotlin. Job listings dated September 29, 2026 describe a greenfield rewrite that uses AI-assisted code generation.
The reasons given were startup speed, stability, day-one access to new OS features, and AI agents lowering the cost of building each feature twice.
Coinbase had not published an engineering blog post on the change when this article was checked, so the details rest on press coverage and the company’s job listings.
The 2012 and 2018 reversals trace to a mismatch between product and approach, not to code sharing itself. Coinbase’s 2026 reasons are different, since they concern the speed and stability of one product and the falling cost of writing native code twice.
How to Decide Whether Cross-Platform Fits a Project
Start with how many screens need platform-specific code. Then look at which language the team already writes, and last, whether the riskiest native feature survives a prototype on real devices.
One hardware integration, a Bluetooth peripheral for example, is a module. Native needs on every screen make a native project.
Run the decision as a feasibility study and answer the audit questions on paper before any code exists.
Team skill breaks the tie between frameworks. A JavaScript or TypeScript team should pick React Native, and a web team with an existing web app can go with Ionic with Capacitor. Kotlin or Android teams fit Kotlin Multiplatform, and C# teams fit .NET MAUI.
With no strong stack yet, Flutter gives one toolkit across mobile, desktop and web, though Dart is a new language to learn.
Skip cross-platform entirely when the audience sits on one platform.
Before committing budget, prototype the riskiest native feature end to end. Most teams skip this step, and it’s usually the one they regret skipping. A feature that fails on a real device in week one is cheaper than the same failure in month six.
- List the target platforms and the audience share on each. One dominant platform ends the analysis.
- Audit native feature needs screen by screen: camera, Bluetooth, background tasks, wearables, payments.
- Check each shortlisted framework’s supported-platforms page for the OS versions and device types you need.
- Match the framework to the language the team already writes.
- Prototype the riskiest native feature on real devices.
- Reserve release-calendar time for both store toolchain deadlines.
- Write down the exit condition, meaning the measured problem that would trigger a native rewrite.
Cross-Platform App Development FAQ
Which language is best for cross-platform app development?
No language wins outright, because each framework brings its own. The practical test is the language the team already writes.
Stack Overflow’s 2024 Developer Survey shows JavaScript used by 62.3% of respondents and Dart by 6%, a gap that shapes hiring.
Can iOS apps be built on a Windows machine?
Not the final build, no. Apple requires uploads built with Xcode, and Microsoft Learn states that building .NET MAUI apps for iOS and macOS requires a Mac.
Developers on Windows add a Mac build step through a remote Mac or a hosted CI service.
Do cross-platform apps pass App Store and Google Play review the same way as native apps?
Yes. Both stores review the submitted package against one policy set and do not assess the framework behind it.
The exposure is thin content, since Apple’s section 4.2 rejects apps that add little beyond a website.
Can the same codebase also produce a web or desktop version?
Depending on the framework, yes. Flutter compiles its Dart code to JavaScript or WebAssembly for browsers and builds for Windows, macOS and Linux.
React Native alone targets iOS and Android, so a web build needs Expo.
What are well-known examples of cross-platform apps?
Meta built the Facebook and Instagram apps for Quest devices with React Native, according to Meta’s engineering blog (October 2024). JetBrains lists Netflix and VMware among Kotlin Multiplatform users, and cites the Respawn app as a Compose Multiplatform build.
Adopting Cross-Platform Code in an Existing Native App
A full rewrite isn’t required. Kotlin Multiplatform shares business logic with an existing Swift or Kotlin app, while Flutter and React Native embed single screens into one.
Order matters here, because risk rises with how visible the code is to users. Start with shared business logic, since users never see it. Then move one low-traffic screen to test rendering and navigation, and leave core flows such as login or checkout until that first screen has passed store review.
The trade-off is two build pipelines and two test suites running side by side until the migration finishes.
This position was verified in October 2026. It changes if a framework falls behind a new iOS or Android SDK requirement, because store deadlines do not move for it.
- Notepad++ Android Options: Apps That Come Close - October 21, 2026
- Data Management Services: A Practical Guide for Growing Companies - October 21, 2026
- MongoDB Cheat Sheet - October 20, 2026
