The Alchemist CodeOne of the first decisions in any mobile project is whether to build in Flutter or go native: Swift for iPhone and Kotlin for Android. There is no universal answer, but there are clear criteria. This guide explains how we make the call, using apps we publish and run ourselves.
The difference in one sentence
- Flutter: one codebase, written in Dart, compiled into a native app for iOS and another for Android. Google created it and it’s open source.
- Native: two separate apps, one in Swift for iOS and one in Kotlin for Android, each built with Apple’s and Google’s official tools.
When Flutter is the right call
You need iOS and Android at the same time, with one team. Every feature is built once and ships the same day in both stores. Maintenance doesn’t double either: one fix reaches both platforms.
Your app is mostly screens, data and business logic. Catalogs, orders, inventory, bookings, live scores and dashboards fit Flutter very well. Most of our 17 apps are built this way, including Soccer24 (75,685 Google Play installs), Komodo VPN and Inventra.
Design matters and must look the same everywhere. Flutter draws its own interface, so your brand looks identical on an iPhone and on a mid-range Android phone.
You need phones, tablets and foldables. The same app can rearrange itself for the screen size. PeakPlay, our NFL app, goes from two to four columns when a Pixel 9 Pro Fold opens, without reloading.
When native is the right call
The app depends on features tied closely to the OS. Examples: keyboard extensions, Apple Watch features, deep HealthKit or CarPlay integration, or real-time audio and video processing.
You already have an experienced native team. If your company has iOS and Android engineers, switching technology has a learning cost to weigh.
You only need one platform. If your market is almost entirely on iPhone, a Swift app can be simpler than a Flutter one.
The option few people mention: both
It doesn’t have to be all or nothing. Flutter lets you write parts of the app in native code and connect them.
In Soccer24, the app is built in Flutter and the home-screen widgets are written in Swift (iOS) and Kotlin (Android), because the platforms require it. The result is one codebase for almost everything, and native only where it’s needed.
Quick comparison
| Criterion | Flutter | Native (Swift + Kotlin) |
|---|---|---|
| Platforms from one codebase | iOS, Android, web and desktop | One per project |
| Cost to build for iOS and Android | Lower: one codebase | Higher: two apps |
| Maintenance | One fix for both stores | Every fix done twice |
| Access to OS features | Nearly all, the rest through native code | Full |
| Performance | Compiles to native code; enough for the vast majority of apps | The maximum possible |
| Widgets and extensions | Need a native part | Direct |
Questions to decide
- Do you need iOS and Android from day one?
- Does any feature depend on a very specific Apple or Google API?
- Who will maintain the app two years from now?
- What matters more right now: budget and time to market, or full access to the platform?
If you answered “yes” to the first and “no” to the second, Flutter is usually the most efficient choice.
What doesn’t change, whatever you choose
- Store rules. Apple reviews every release, and both Apple and Google raise their requirements for updates every year. For example, Google Play requires apps targeting Android 15 or later to support 16 KB memory pages.
- The backend. Notifications, sync and payments depend on the server as much as on the app.
- Maintenance. An app without updates stops working well on new phones.
Want help deciding?
On the first call we review what your app needs and recommend Flutter, native or a mix, with the reasons in writing. We’re a nearshore studio in Puebla, Mexico, on US Central hours. See our Flutter development and mobile app development services.