Everyone starting a mobile app project sooner or later faces the same question: native or cross-platform? This is not just a technology choice; it is a business decision that shapes the budget, the timeline, the team and the next five years of the app.
Until a few years ago the answer was simpler: native if you wanted performance, cross-platform if you wanted fast and cheap. Today Flutter and React Native have matured, and Kotlin Multiplatform has reached a stable release on iOS as well. In this article we explain the approaches in plain language, compare Flutter and React Native, and show with examples which one makes sense for which project.
What do native and cross-platform apps mean?
A native app is written separately for each operating system using that platform’s own language and tools: Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. The result is two separate codebases and often two separate teams.
A cross-platform app, on the other hand, produces both iOS and Android versions from a single codebase. Today’s leading options are:
- Flutter: A framework developed by Google that uses the Dart language. It renders the interface with its own drawing engine, giving a pixel-identical look on every device.
- React Native: A framework developed by Meta that uses JavaScript / TypeScript and React. It uses the platform’s native UI components. With version 0.76 the “New Architecture” became the default, largely removing the bottlenecks of the old bridge between JavaScript and native code.
- Kotlin Multiplatform: JetBrains’ solution. It lets you share business logic in Kotlin and write the interface either natively or with Compose Multiplatform. Compose Multiplatform’s iOS support reached a stable release in May 2025.
There is also the PWA (progressive web app) option: a web app that runs in the browser and can be added to the home screen. It can be a good start for simple needs that don’t require an app store, but it has limitations with notifications and device features, especially on iOS.
Native vs cross-platform: compared on 7 criteria
To make the decision easier, we put the two approaches side by side on the criteria that matter most for business:
| Criterion | Native (Swift + Kotlin) | Cross-platform (Flutter / React Native) |
|---|---|---|
| Development cost | High; two separate codebases | Lower; most code is shared across both platforms |
| Time to market | Longer | Shorter; both platforms launch at the same time |
| Performance | Best; especially for graphics- and hardware-intensive work | Imperceptible for the vast majority of business apps |
| Access to new platform features | Day one | Usually via a plugin or native code bridge, sometimes with a delay |
| Look and feel | The platform’s native design language | Consistent brand look in Flutter; native components in React Native |
| Maintenance | Every feature is updated twice | Updated in one place; framework versions need to be tracked |
| Team | Separate iOS and Android specialists | One team; you still need someone who knows the native side |
As the table shows, cross-platform has the business advantage on most criteria; native pulls ahead in projects where performance and platform-specific features are at the heart of the product.
Flutter or React Native? Differences and selection criteria
Once you have decided on cross-platform, the second question arrives. Both frameworks are mature, have large communities and are used in production apps by major companies. The real deciding factors are:
Flutter stands out if…
- You want a brand-specific, animated interface that looks exactly the same on every device.
- You are also considering web and desktop (Windows, macOS, Linux) targets alongside mobile with the same code.
- Smooth, predictable performance on low-end Android devices matters.
React Native stands out if…
- Your team or existing web project already uses React and TypeScript; sharing knowledge and code becomes easier.
- You want the app to look like it uses each platform’s own components.
- You want to tap into the huge library pool of the JavaScript ecosystem and make hiring developers easier.
Which projects really need native development?
Can cross-platform do everything? No. In the following cases you need native development, or at least a significant native layer:
- Heavy graphics and real-time processing: games, augmented reality, advanced camera and video editing.
- Deep hardware integration: custom Bluetooth devices, medical sensors, low-level audio processing, continuous background work.
- Day-one access to platform features: if widgets, watch apps or APIs newly announced by Apple or Google are at the core of your product.
- Very large scale: products with millions of users where every millisecond and the app size matter.
Outside these cases, the vast majority of projects such as e-commerce, booking, field teams, customer loyalty, internal corporate apps and admin panels can comfortably be built cross-platform. What’s more, in cross-platform apps you can write a specific screen or feature in native code when needed; the choice is not black and white.
The right technology is not the most popular one; it is the one that delivers your product’s most critical feature with the least risk.
Cost, maintenance and long-term risks
The technology decision affects the total cost of ownership more than the initial investment. In native, every new feature is written twice and tested twice; so are bug fixes. In cross-platform, this burden shrinks as the share of shared code grows.
On the other hand, cross-platform has its own risks:
- Framework updates: Major version upgrades of Flutter or React Native, and keeping third-party plugins compatible with them, require regular effort.
- Plugin dependency: An abandoned plugin can block a critical feature. When choosing plugins, look at how often they are updated and at their community.
- App size: Because cross-platform apps also bundle the framework engine, they can be somewhat larger than their native counterparts.
If you want the budget side in detail, in our article on mobile app development costs we break down the items that determine the price one by one.
Four example projects: which technology and why?
Thinking in concrete examples rather than abstract criteria makes the decision easier. Below are four project types we often encounter and our assessment of each:
Restaurant ordering and loyalty app
Menu, basket, online payment, campaign notifications and a points system. There is almost no hardware requirement; launching on both platforms at once and having a brand-specific look matter. Here a single codebase with Flutter or React Native is by far the most efficient choice.
Field team app
Technicians view work orders, take photos, scan barcodes and sometimes work in basements with no internet. Offline data storage and syncing are critical. Cross-platform meets this need; but getting the offline architecture right from the start matters more than the technology choice.
Health app that talks to a custom Bluetooth device
The heart of the app is continuous, reliable data exchange with the device, and it also needs to run in the background. Here native development, or at least a hybrid structure with device communication written in native modules, is the safer choice. Because health data is processed, the KVKK rules on special categories of personal data must also be planned for.
Internal corporate app
An app where employees track leave requests, approval flows and announcements. The number of users is known and store visibility is irrelevant. If the budget is tight, it can make sense to start with a PWA and move to a cross-platform app as needs grow. In such cases desktop or web application also becomes a question.
The right mobile technology decision in 5 questions
To make the decision for your own project, answer the following questions in order:
- Question 1 — Is there heavy graphics, real-time media or custom hardware at the heart of the app? If yes, take native seriously.
- Question 2 — Do you need to launch on both platforms at once with a limited budget? If yes, cross-platform pulls ahead.
- Question 3 — What technology does your current team or web project use? If it is React-based, React Native; if you are starting from scratch, Flutter is a strong candidate.
- Question 4 — Will you also offer the same product on web and desktop? Flutter covers more targets with one codebase; a shared backend is essential in any case.
- Question 5 — Who will maintain the app for at least three years? Will you be able to find developers for the chosen technology?
We asked these questions for our own products too. For example, the web panel, iOS / Android apps and Windows app of KATSİS, our apartment and residential complex management software, are all connected to the same infrastructure. Designing the interface around the needs of users on each platform while keeping the data in one central place significantly reduced the maintenance burden. For details, see our projects.
- Has the app’s most critical feature been defined in writing?
- Are the hardware and performance requirements clear?
- Will both platforms be released at the same time?
- What technology do the current team and web infrastructure use?
- Will developers for the chosen technology be available in the long term?
- Has the maintenance status of the plugins to be used been checked?
Frequently asked questions
Are cross-platform apps as fast as native?
In the vast majority of business apps, users won’t notice a difference. Flutter delivers a smooth experience with its own rendering engine, and React Native with its new architecture. For heavy graphics, games or real-time media processing, native still has the edge.
Which is better, Flutter or React Native?
There is no single right answer. Flutter usually makes more sense for a brand-specific interface that looks the same on every device and for desktop targets alongside mobile; React Native if you have a team that knows React and TypeScript or an existing React web project.
Can an app built cross-platform be published on the App Store and Google Play?
Yes. Apps built with Flutter and React Native are compiled like native apps and published on both stores under the same rules. Users cannot tell which technology the app was written in.
Is it possible to start cross-platform and switch to native later?
It is possible, but it usually means rewriting the app. Instead, writing specific screens or modules in native code within the cross-platform app is often the more economical route.
Can a mobile app and a website use the same infrastructure?
Yes, and in most cases they should. Whatever mobile technology you choose, the app and the website or admin panel can connect to the same API and database. If React Native is used, part of the business logic can also be shared with a React-based web project. This approach lowers maintenance costs and keeps data consistent in one central place.
What is Kotlin Multiplatform and when should you choose it?
Kotlin Multiplatform is an approach that shares business logic between iOS and Android while letting you write the interface natively or with Compose Multiplatform. It suits projects with a strong Android team that want to share code without losing the native feel.
Final word
There is no universal answer to native vs cross-platform, but when you ask the right questions the answer usually becomes clear. For most business apps, a single codebase with Flutter or React Native is the most efficient path in terms of both budget and timeline; in projects where performance and hardware are at the heart of the product, a native investment pays off. If you’d like to assess together which approach suits your project, you can browse our mobile app services or get in touch with us.