Flutter vs Native (Kotlin and Swift): Which Fits Your Mobile App?

Most companies planning a mobile app ask the same question early: build once with Flutter, or build separately for Android with Kotlin and for iOS with Swift? Both approaches produce good apps, and both have teams that regret choosing them. The right answer depends less on which technology is better in general and more on what the app needs to do, how the team is set up, and how long the app is expected to live.

How Flutter and Native Development Differ

Flutter is a framework from Google that uses the Dart language. It draws its own interface with its own rendering engine, so the same code produces the same screens on Android and iOS. Access to device features such as the camera, location, or payments goes through plugins, and when a plugin does not exist, the team writes a small piece of Kotlin or Swift and connects it through a platform channel.

Native development means two separate apps: Kotlin with Jetpack Compose for Android, and Swift with SwiftUI for iOS. Each app uses the platform's own interface components and has direct access to every API the operating system offers. The cost is two codebases, usually two sets of developers, and features that have to be built and tested twice.

When Flutter Is the Better Choice

• The app is mostly screens, forms, lists, and data from an API, which describes most business, e-commerce, booking, and internal apps.
• The design should look the same on Android and iOS, for example to follow a strong brand identity.
• Budget or team size only allows one team, and both platforms need to launch at the same time.
• The goal is an MVP to test the market quickly, with the option to invest more once the product is proven.

When Native Is Worth the Extra Cost

• The app depends heavily on hardware or OS integration, such as advanced camera processing, augmented reality, Bluetooth devices, background location, home screen widgets, or smartwatch apps.
• Every frame matters, for example in apps with complex animations, real-time audio or video, or games that are not built with a game engine.
• The app must adopt new Android or iOS features as soon as they are released, without waiting for a plugin to support them.
• The company already has experienced Android and iOS teams, and switching to a new stack would cost more than it saves.

There is also a middle path. Kotlin Multiplatform lets a team share business logic such as networking, data models, and validation between Android and iOS while keeping a native interface on each platform. It suits teams with strong Kotlin skills who want native UI without writing the same logic twice.

The Real Cost Difference

Flutter rarely halves the cost of a mobile project. One codebase removes most of the duplicated UI and logic work, but some work stays per platform: store setup and review, push notification configuration, permissions, testing on both platforms, and native code for features without a good plugin. Design, backend, and project management cost the same either way. A realistic expectation is a meaningful saving on the app itself, not on the whole project.

Before committing to Flutter, list every device feature the app needs and check that each one has a well-maintained plugin. A single missing plugin for a core feature can turn into weeks of native work.

Check Plugins Before You Commit

Flutter's productivity depends on its plugin ecosystem. For common needs such as maps, camera, push notifications, and local storage, mature plugins exist. For less common hardware, local payment SDKs, or vendor-specific devices, check carefully. On pub.dev, look at the publisher, the date of the last release, which platforms are supported, and the open issues on its repository. A plugin abandoned two years ago is a maintenance liability, even if it works today.

Test on the Devices Your Users Actually Have

In markets like Indonesia, a large share of users run Android phones with limited memory and storage, often on mobile data. Whichever approach you choose, test regularly on a low-end Android device, not only on the developers' flagship phones. Watch startup time, scrolling smoothness on long lists, memory usage, and download size. These matter more to most users than the theoretical performance difference between Flutter and native.

How to Decide in Practice

1. 1List the app's core features and mark the ones that depend on device hardware, background processing, or very recent OS features.
2. 2For each of those features, check whether a well-maintained Flutter plugin exists, or estimate the native work needed.
3. 3Look at your team: who will build the app, and who will maintain it in two or three years.
4. 4Decide whether a consistent custom design or platform-native behaviour matters more to your users.
5. 5If the answer is still unclear, build a small prototype of the riskiest feature in Flutter before committing the whole project.