Cross-platform app development is the practice of writing one app, in one codebase, and shipping it to both the App Store and Google Play. For most business apps, such as ordering, booking, marketplaces, content and internal tools, it is the sensible default: each screen and rule is written once instead of twice. It does not halve everything, though: design for two platforms, two store releases and testing on both kinds of phone stay on your list.
I have worked in software development for 18 years. My company, 26 Lines of Code, has 70+ specialists and 150+ projects behind it since 2017, and we build mobile apps both ways: one codebase in Flutter or React Native, or two native apps in Swift and Kotlin.
What "cross-platform" and "hybrid" mean now
Both words promise one codebase for two platforms. They cover two different technologies, though, and the difference shows in how the app feels.
- One codebase that becomes a native app. Flutter draws its own screens with its own engine and compiles to machine code. React Native describes the screens in JavaScript and turns them into real iOS and Android views. Kotlin Multiplatform shares the logic and keeps the screens native, unless you share those too with Compose Multiplatform.
- A web app inside a native shell. Ionic with Capacitor packages a web app as a store app. Its screens are web pages in the phone's web view (WKWebView on an iPhone), and plugins reach the camera and other device features.
The second kind is the original "hybrid": PhoneGap, one of the old hybrid app frameworks, worked this way until Adobe ended it in 2020. The word has since stretched, and on our own site hybrid app development means Flutter and React Native. So ask which kind a quote means before you compare prices.
Cross-platform app development frameworks compared
The table compares five cross-platform mobile app development frameworks that their makers support today. The last column is the one sales pitches tend to skip.
| Framework | Made by | You write in | Screens | Fits best | Watch for |
|---|---|---|---|---|---|
| Flutter | Dart | Drawn by its own engine | One custom design on both phones | Platform habits are your design decision | |
| React Native | Meta | JavaScript or TypeScript, with React | Real iOS and Android views | Teams that know React | Platform differences are handled in code |
| Kotlin Multiplatform | JetBrains, supported by Google | Kotlin | Native, or shared via Compose Multiplatform | An Android app that needs an iOS sibling | Native screens are still built twice |
| Ionic with Capacitor | Ionic | HTML, CSS and JavaScript | Web pages in a web view | A mobile web app that needs a store listing | Apple wants more than a repackaged website |
| .NET MAUI | Microsoft | C# and XAML | Native controls | Teams already on .NET | The successor to Xamarin.Forms, which lost support on May 1, 2024 |
Mobile app development frameworks age faster than the guides about them. In October 2026 I read five guides on cross-platform app development from the top of Google's results: all five still list at least one framework its maker no longer supports, four name Xamarin and two name Adobe's PhoneGap. Only one mentions Kotlin Multiplatform, and none mentions Capacitor. Five pages are a small sample, but the check costs one question on any quote: which framework, and does its maker still support it?
Flutter vs React Native: a verdict by team and product
Choose by who will maintain the code and how the app should look, not by speed. Both ship real apps to both stores, and in a typical business app your users will feel no difference.
- Flutter, when the design is the product. It draws every screen itself, so a custom brand look stays identical on an iPhone and an Android phone. The language is Dart, so whoever maintains the app after launch needs Flutter developers.
- React Native, when a React team will own the app. Meta has maintained it since 2015, and its standard controls are each platform's own views, so they behave the way users expect. Its documentation recommends starting a new app with a framework such as Expo.
- Either, when nobody on your side writes code. Then pick the team, not the framework: ask to install an app they have shipped to both stores.
On Flutter vs React Native performance, much of what you read is out of date. One of the five guides I measured still marks React Native down for its "JavaScript bridge", yet the New Architecture, React Native's default since October 2024, removed that bridge. Flutter compiles to machine code, and both are fast enough for ordering, booking and content apps.
Both hybrid apps in our portfolio are built in Flutter. Mutualz, a restaurant app from Oldenburg, Germany, is one codebase, published in both stores in German and English; the hard part was tracking every order and loyalty point from the table to the restaurant's admin panel and back. Tarot Fans, a Flutter app on a Django backend with live video, calls billed by the minute and a wallet, is live on Google Play: a shared codebase does not oblige you to open both stores at once.
Hybrid vs native app: when native still wins
Native wins when the core of the app depends on the phone itself rather than on its screens. That comes down to three cases:
- Heavy graphics and live camera work: AR, 3D, effects applied while the camera records. A shared codebase reaches these through plugins, and where a plugin falls short, that part is written natively anyway.
- Deep device features: a Bluetooth device at the heart of the product, long background work, home screen widgets, watch apps. Google's own Flutter guide says a home screen widget cannot be drawn with Flutter: it is built with a platform framework such as SwiftUI or Jetpack Compose. Flutter's supported platforms do not include Apple Watch either.
- The newest OS features first. A native app can adopt a new iOS or Android capability as soon as Apple or Google releases it; a shared codebase waits for its framework or a plugin to catch up.
If such a feature is an extra, keep one codebase and write that piece natively. If it is the core, two native apps earn their higher price. Our portfolio has native work too: the SaneBox Android app we designed and built is Kotlin with Jetpack Compose.
Cross-platform is not for you at all in two cases. If most of your users are on one platform, start with a native iOS app or Android app; the guide on Android vs iOS development helps pick the first. If people will open the app once or twice rather than every week, skip the stores: a progressive web app installs straight from the browser.
What one codebase saves, and what it does not
One codebase saves the second build of every screen and rule: a feature is written once, fixed once and released to both stores together. It does not save the work around the code, because a cross-platform application still runs on two systems and sells in two stores.
- Design for two platforms. Flutter adapts scrolling, page transitions and fonts by itself, but its documentation leaves design choices such as tab bars and dialogs to you.
- Two store releases. Two developer accounts (Apple charges $99 a year, Google Play $25 once), two listings, two reviews and two privacy forms: App Privacy details for Apple, the Data safety form for Google.
- Testing on both. Real iPhones through TestFlight and real Android phones through a Google Play testing track, before every release.
- Rising store minimums. Both stores keep raising the bar: in 2026 Apple began accepting only builds made with Xcode 26 or later (from April 28), and Google Play began requiring new apps and updates to target Android 16 (from August 31). One upgrade of the shared code often covers both, but two apps still get rebuilt, retested and resubmitted, which is part of mobile app maintenance.
The backend and the admin panel are built once either way, so cross-platform development saves nothing there. That is why a cross-platform quote is not half of a native one; with us, a first version for both stores starts at $5,000.
Choosing for your first release: a table to forward
Each row is a yes-or-no question about your product or your team. Send the table to whoever decides with you, then bring the answers to any vendor, us included.
| If this is true | It points to |
|---|---|
| A core feature needs a Bluetooth device, AR or long background work | Two native apps, or native code for that feature |
| Most of your users are on one platform | A native app for that platform first |
| A custom brand design must look the same on both phones | Flutter |
| Your own React developers will maintain the app | React Native |
| You already have a native Android app in Kotlin | Kotlin Multiplatform |
| A web app of yours already works well on phones | Ionic with Capacitor, if the app will do more than the site |
| People will open it once or twice, not weekly | A progressive web app or a website |
| None of the above | One codebase: Flutter or React Native |
Mistakes few avoid
- The framework before the feature list. A Bluetooth scale or a home screen widget that turns up mid-build can change the whole plan.
- Testing on the team's own phones only. If everyone on the project carries an iPhone, your Android users find the bugs.
- Store accounts in the developer's name. Whoever holds an account controls every update, so register both in your company's name. On Google Play, a personal account opened after November 13, 2023 must also run a closed test with at least 12 testers for 14 days before an app goes live.
If you are weighing cross-platform app development against two native apps, start from the feature list, not the framework. Our hybrid app development page shows how we build Flutter and React Native apps and what a first version includes.
Questions
Is a cross-platform app slower than a native one?
For ordering, booking, content and most business apps, users notice no difference. The gap shows with heavy graphics, AR and long background work.
What is the difference between a hybrid app and a cross-platform app?
Strictly, a hybrid app is a web app in a native shell (Ionic with Capacitor), while cross-platform means one codebase that turns into a native app (Flutter, React Native). In everyday speech both mean one codebase for two stores.
Will Apple accept our website wrapped as an app?
Only if the app does more than the site. Apple's review rules expect more than a repackaged website, so plan accounts, notifications, offline use or something else app-like.
Can we start cross-platform and switch to native later?
Yes. The backend, the design and the store listings carry over; only the app itself is rewritten in Swift and Kotlin.
Can the same code give us a web version too?
Flutter also builds for the web and desktop, which suits dashboards. A marketing site that must rank in Google is better built as a website: Flutter's own documentation says its web output is not made for search engines.