FajarFive years ago the Flutter debate was whether it was ready for production. That argument is over. As of September 2026 the current stable release is Flutter 3.47, published in August 2026 on the same day as Dart 3.13 (the Flutter release notes list every version). Dart 3 brought sound null safety, records and pattern matching, and the language is now pleasant to work in. The useful question has changed from “can Flutter do it?” to “is Flutter the right call for this product, this team and this roadmap?” We build with Flutter, Swift and Kotlin, and we recommend against Flutter about as readily as we recommend it. This is the reasoning we use.
What Changed Under the Hood
Early Flutter had a reputation for stutter the first time an animation ran, caused by shaders compiling at runtime. Impeller, the rendering engine that replaces Skia, compiles shaders at build time to avoid that. According to the Impeller documentation, it is the only renderer on iOS, it is the default on Android from API level 29, and it became the default on Windows, macOS and Linux in Flutter 3.47. Two caveats matter. Older Android devices, and devices without Vulkan support, fall back to the legacy OpenGL renderer. Flutter on the web still renders with Skia. So first-run jank is much less common than it was, but “gone on every device” would overstate it. Profile on the cheapest phone your users own.
On the web, Flutter can now compile to WebAssembly, which helps runtime performance. It does not change the basic trade-off: the app draws to a canvas, the initial download is heavy compared with an HTML page, and search engines get little to index.
Where Flutter Is the Strong Choice
Products Where the Brand Is the Interface
Flutter draws every pixel itself, so the distance between the design file and the shipped app is short. If the product stands out through a distinctive, animated interface (fintech onboarding, fitness, consumer subscriptions), Flutter renders that design the same way on a three-year-old Android phone and a new iPhone. A motion spec has a better chance of reaching production intact when there is one rendering layer to argue with instead of two.
Small Teams Shipping to Many Surfaces
A team of three can realistically maintain iOS, Android and a desktop companion from one codebase. Windows, macOS and Linux are stable targets. Suppose a warehouse app has to run on Android handheld scanners and on Windows terminals at the packing desk: most of the screens, state and business logic can be shared, and the platform-specific part shrinks to scanner and printer integration. If the roadmap includes kiosk, desktop or embedded targets, breadth of coverage is Flutter’s best argument.
Mid-Range Android as the Main Market
Because Flutter owns its rendering pipeline, frame times depend less on the manufacturer’s version of the platform’s UI toolkit. Long lists, image-heavy feeds and several animations at once tend to behave consistently across devices. That is a tendency, so test it: build the heaviest screen first and run it on a budget handset before committing.
Long-Lived Internal and B2B Apps
Field-service tools, clinical workflow apps and delivery-driver apps value consistent UI, offline-first data and low upkeep more than platform-native feel. Since Flutter does not depend on the operating system’s widgets, an OS update is less likely to break the layout. You still have to keep up with SDK upgrades, store policy changes and new permission rules.
Where Native Still Wins
Deep Platform Integration Is the Product
Home-screen widgets, watch complications, App Intents, Live Activities, CarPlay and Android Auto, advanced camera pipelines, Bluetooth peripherals, background work at the edge of what the OS allows: Flutter reaches all of these through platform channels, and every channel is code you write and maintain in Swift or Kotlin anyway. Our rule of thumb is that once more than about a quarter of the feature list needs platform-specific code, the savings of a shared codebase have mostly been spent.
An Audience That Notices
Flutter’s Cupertino widgets imitate iOS well, and they are still an imitation. Scroll physics, context menus, text selection and keyboard behavior are close, and a design-literate iPhone audience can feel the difference. For a premium consumer product aimed at that audience, SwiftUI first is often the safer brand decision.
Tiny Binaries and Instant Start
A Flutter app ships its engine, so the download is several megabytes larger than a comparable native app, and cold start is fine without being the fastest available. For most products this does not matter. For a utility that must open instantly, or an app competing for storage on low-end phones, it can decide the question.
The Other Cross-Platform Options
Flutter is not competing with native alone, and the alternatives deserve a fair description.
React Native renders real platform views and lets you write the app in TypeScript. Its New Architecture, the default since version 0.76, removed the old asynchronous bridge that caused most of its historic performance complaints. If your team already writes React for the web, React Native gives you shared language, shared tooling, a very large package ecosystem and a wide hiring pool. It is a sensible default for many product apps. Its weaker spots are custom-drawn, animation-heavy interfaces and desktop targets.
Kotlin Multiplatform takes a different approach: share the business logic (networking, storage, validation, domain rules) in Kotlin, and keep the UI native in SwiftUI and Jetpack Compose. Google supports it for sharing logic between Android and iOS, and Compose Multiplatform can share UI as well where that suits. It fits teams that already have native developers and want a fully native feel without writing every rule twice. It saves less than a single UI codebase does, because you still build two front ends.
In short: choose React Native for a TypeScript team, Kotlin Multiplatform for a native team, and Flutter when control over the pixels or the number of target platforms is the deciding factor.
The Ecosystem in 2026
- Packages. pub.dev covers the mainstream well: payments, maps, analytics and authentication are solid. The gaps are at the edges. Niche enterprise SDKs, some regional payment providers and brand-new OS features often get Flutter support later than native support, or not at all. List your integrations and check each one before committing. It takes about a day.
- AI coding tools. Assistants have seen far more TypeScript, Swift and Kotlin than Dart, so suggestions in Dart can be a little weaker. It is a small factor and it is narrowing.
- Flutter web. We would use it for logged-in dashboards and internal tools that pair with a Flutter mobile app, and not for public, content-led pages that need search traffic. Those belong on an HTML framework.
Governance and Platform Risk
Flutter is an open-source project that depends heavily on Google’s continued investment. Google’s 2024 layoffs touched the Flutter and Dart teams, and that unsettled some CTOs. Releases have continued on a steady quarterly rhythm since, and the framework is widely deployed, so we consider abandonment unlikely. If your board needs a ten-year horizon with the least possible platform risk, native is the conservative answer, and we will say so.
What a Flutter Project Costs and Takes
The one-codebase pitch implies half the cost of two native apps. It does not work out that way, and the reason is structural. Screens, state management and business logic are written once. Platform-channel work, release engineering for each store, and testing across a matrix of devices are not halved, and some of that work exists only because there is a framework between you and the platform. Expect a real saving on the first version, smaller than the pitch suggests. The size depends on how much of the app is shared UI and how much is platform work.
The economics improve after launch. Every feature, fix and experiment ships to both platforms from one change, reviewed once and tested once. If you are judging by the v1 budget alone, Flutter’s advantage is modest. Over three years of iteration it compounds. For how scope drives budgets more generally, see what a custom web app really costs. The same decisions apply to mobile.
One budgeting caution: keep a reserve for last-mile platform work such as store review, notification permission flows and platform-specific payment rules. Cross-platform frameworks compress the middle of a project and leave both ends the same length. If you are still deciding what goes into the first release, our guide to scoping an MVP covers that step.
The Team Question
Benchmarks get the attention. Team composition decides the outcome. Three questions we ask before recommending Flutter:
- Who maintains this in year two? If the long-term owner is an in-house team of web developers, Dart is a retraining cost. It is a modest one, since Dart is easy to pick up for anyone who knows TypeScript, Java or Kotlin, but the hiring pool is smaller than for JavaScript or native.
- Do you have any native capability? Every serious Flutter app eventually needs someone who can read Swift and Kotlin for platform channels, build tooling and store rejections. Budget for at least occasional native expertise.
- Is there an existing app? Adding Flutter to an existing native app is supported and is the least comfortable part of the ecosystem. If the native app is healthy, carrying on natively usually wins. Flutter suits new builds best.
The Decision in Brief
Choose Flutter when the project is new, targets two or more surfaces with a small team, needs pixel-level control over the design, uses mainstream integrations, and has to run well on mid-range Android. Choose native when platform depth is the product, when the audience is iOS-first and design-sensitive, when more than about a quarter of the features need platform code, or when long-term platform risk is a board-level concern. Look hard at React Native or Kotlin Multiplatform when your existing team’s skills point that way.
If you are torn, spend a week building the riskiest screen in Flutter. Platform-channel pain shows up almost immediately, and a one-week spike is cheap insurance. A shared design system and design tokens also make a mixed portfolio workable: a design-heavy consumer app in Flutter and a hardware-integrated field tool in native code can share a back end and a visual language. Choose per product, not per company.
Our mobile development team works in Flutter, Swift and Kotlin, and will tell you which one your project needs. Request a call and bring your feature list and target devices.
