# Native or Flutter / React Native: which one fits your app > Whether to go native or Flutter depends on what the app does. For most business apps, a shared Flutter or React Native codebase is enough and ships iOS and Android with less work. Native is the better choice when the app leans heavily on deep device features or needs a platform-specific experience. - URL: https://radkod.com/en/blog/native-or-flutter - Publisher: RadKod - Published: 2026-08-28 ## In short - Native means writing iOS and Android separately, in Swift and Kotlin, with two codebases. - Flutter and React Native ship both platforms from one shared codebase. - For most business apps a shared codebase is enough and makes maintenance simpler. - Pick the approach from what the app must do, not from which technology is fashionable. ## Native or Flutter: which should you choose? If your app does not depend heavily on deep device features, Flutter or React Native is usually enough. If the camera, sensors or platform-only features sit at the centre of the app, native tends to give a better result. That is the short answer. The rest of this post explains why. We build with all four: Swift, Kotlin, Flutter and React Native. So this is not a post defending one camp. It is the list of questions we ask a client before we recommend anything, written down so you can ask them yourself. ## What is a native app? A native app is written separately for each platform, in that platform's own language. iOS apps are written in Swift and Android apps in Kotlin. You end up with two codebases. Every new feature is written twice and tested twice. In return, you get everything the platform offers, from day one, with nothing in between. When Apple or Google announces a new capability, you can use it right away. You do not wait for a framework or a plugin to catch up. ## How do Flutter and React Native work? Both produce an iOS and an Android app from one codebase, but they get there in different ways. This approach is called [cross-platform](/en/glossary/cross-platform) development. Flutter is developed by Google and uses the Dart language. It draws the interface with its own rendering engine. That is why a Flutter app looks almost identical on both platforms, and why it suits brand-specific designs well. React Native is developed by Meta and uses JavaScript or TypeScript. It renders the platform's own interface components. Buttons, lists and navigation therefore stay closer to what users expect on each platform. Both can talk to native code when needed. Even in a shared codebase, a small part sometimes has to be written in Swift or Kotlin. That is normal. A good team spots it in advance and puts it in the quote. ![Native, Flutter and React Native compared on language, codebase, UI, device access, new features and maintenance.](https://radkod.com/images/content/native-cross-platform.svg) *Native needs two codebases; Flutter and React Native ship both platforms from one.* **Native, Flutter and React Native compared** | | Native (Swift / Kotlin) | Flutter | React Native | | --- | --- | --- | --- | | Language | Swift and Kotlin | Dart | JavaScript / TypeScript | | Codebase | One per platform | One shared | One shared | | Interface | Platform components | Own rendering engine, same look on both | Platform components | | Device access | Direct and complete | Through plugins, native code if needed | Through modules, native code if needed | | New features | Written twice | Written once | Written once | | Maintenance | Two codebases to update | One codebase plus plugins | One codebase plus modules | | Best fit | Heavy device use, platform-specific experience | Business and consumer apps with a custom look | Business and consumer apps with a platform-native feel | ## Is the performance difference noticeable? In most business apps, users do not notice any performance difference. Showing lists, filling in forms, placing orders and receiving notifications all run smoothly on all three. When an app feels slow, the cause is usually badly written screens or a slow server, not the framework. The difference shows up in heavy work. Intensive graphics, real-time image processing, augmented reality and low-level hardware control are more comfortable in native code. App size and start-up time come up too. Cross-platform apps bundle their own runtime, so they are usually a little larger. Most users never notice. If your audience relies on low-storage devices, factor it in. ## When is native the right choice? Native is the right choice when the device itself is the heart of the app. We lean native when: - The app works intensively with the camera, Bluetooth or sensors at a low level. - Platform-only pieces, such as watch apps or home screen widgets, are central. - The app only needs to run on one platform. - Using new platform features on release day is critical to the business. - Your company already has a team that knows Swift or Kotlin. ## When is Flutter or React Native enough? When the app moves a business process onto the phone, a shared codebase is usually enough. Online shops, bookings, loyalty programmes, field team tools, appointments and content apps all fall into this group. Most of them talk to a server through an [API](/en/glossary/api), a defined door that lets two pieces of software exchange data, and show that data on screen. Here a shared codebase gives you two things. First, both platforms go live with less work, which feeds straight into the budget. We cover the cost side in [what mobile app cost depends on](/en/blog/mobile-app-cost). Second, maintenance gets simpler. A bug is fixed once and a feature is added once. ## Flutter or React Native? The choice between the two is mostly about the interface and your team. If you want a brand-specific interface that looks the same on both platforms, Flutter is a comfortable pick. If you want the app to feel like a standard iOS app on iPhone and a standard Android app on Android, React Native can fit better. Then there is the long view. Who will develop the app over the next few years? If you plan to build your own team, think about which developers are easier for you to hire. A company with web developers who already write JavaScript may find React Native easier to own. ## Can you switch later? You can, but switching from cross-platform to native means rewriting the app. The backend and the API can stay as they are. That is one reason we spend time on the choice up front. The other direction is gentler: Flutter can be added to an existing native app screen by screen, so new features can move to a shared codebase without a big rewrite. ## Which questions do we ask before deciding? We choose the technology once it is clear what the app must do, not in the first meeting. These are the questions: 1. Which device features will the app use, and how deeply? 2. One platform or two? 3. Should the interface be brand-specific or close to platform standards? 4. When does the first version need to be live? 5. Who will develop the app later on? Based on the answers, we write a recommendation and explain the reasons. The choice appears plainly in the quote and in the definition of done. Whichever route we take, the code repository and store accounts are in your name from day one. Publishing is its own step, covered in [publishing an app to the stores](/en/blog/publish-app-to-stores). If you want to keep the first version small, read [how to build an MVP](/en/blog/how-to-build-an-mvp). How we work on apps is on our [mobile app development](/en/services/mobile-app-development) page. ## Frequently asked questions ### Will the App Store accept a Flutter app? Yes. Apps built with Flutter or React Native are submitted to the App Store and Google Play like any native app. They go through the same review under the same rules. ### Can we move to native later? Yes, but it means rewriting the app itself. The backend and API can stay the same. That is why it pays to make the choice carefully at the start. ### Is everything written only once in a shared codebase? Most of it is. Some device features may need small native pieces in Swift or Kotlin. We point these out at the quote stage so they do not surprise you later. ### Which is cheaper, native or Flutter? If you need both iOS and Android, a shared codebase usually means less work and a lower cost. For a single platform the gap gets smaller. The exact answer depends on the scope of the app. ### Is Flutter better than React Native? Neither is better across the board. Flutter suits a custom interface that looks the same on both platforms, while React Native suits a platform-native feel and teams that already know JavaScript. We choose based on the app and on who will maintain it. ### Are Flutter apps slow? No, Flutter apps run smoothly for typical business use and users rarely notice a difference. Slowness usually comes from inefficient screens or a slow server. Heavy graphics and low-level hardware work are still more comfortable in native code. ### Can a cross-platform app use push notifications, the camera and location? Yes. Push notifications, camera, location, biometric login and payments are available through well-maintained plugins in both Flutter and React Native. If a plugin is missing something, that part is written in Swift or Kotlin and connected to the shared code. ### Is Kotlin Multiplatform an option too? It can be. Kotlin Multiplatform shares business logic between iOS and Android while each platform keeps its own native interface. It suits teams that want native screens but less duplicated logic. We discuss it when the app calls for that balance. ## Sources - [Flutter documentation](https://docs.flutter.dev/), Flutter - [Introduction](https://reactnative.dev/docs/getting-started), React Native - [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/), Apple **Let's pick the right approach for your app** [Get a quote](https://radkod.com/en/get-a-quote)