Cross-platform mobile is no longer a moonshot. Banks, insurers and similar product organisations ship multi-platform apps as a standing requirement, not a laboratory experiment. The expensive mistake is choosing the stack that fitted a conference talk rather than your customer mix, country footprint and existing engineering gravity. Flutter and Kotlin Multiplatform both ship real products in 2026. They answer different questions. Treat them as alternatives only after you have named whether Android, iOS and web are peers, or whether Android is the centre with a meaningful but smaller iOS cohort.
The decision is organisational before it is technical. A greenfield consumer wallet that must look identical on phone and browser is a different problem from a large retail book that already runs Kotlin on Android and must extend logic to iOS without inventing a Dart estate. Geography matters too. Much of Asia and many large retail banking bases are Android-dominant. Parts of Hong Kong, Singapore, the UK and the US skew toward more balanced iOS and Android mix, with web often a serious acquisition and servicing channel. Use your books, not global averages.
What each option actually is in 2026
Flutter is a single-UI cross-platform toolkit. You write Dart, ship one interaction model and let Flutter’s engine paint the pixels. Impeller is the default rendering engine on iOS and on Android API 29 and above, with shaders compiled ahead of time to cut the old shader-jank path. The same product surface can target Android, iOS, web and desktop from one codebase. That is the honest pitch: one team, one design system, many targets.
Kotlin Multiplatform (KMP) is not “Flutter but Kotlin”. JetBrains declared the KMP core stable and production-ready with Kotlin 1.9.20 in November 2023. Google documents KMP as supported for sharing business logic between Android and iOS. You share domain models, networking, policy and persistence; UI can stay native (Jetpack Compose on Android, SwiftUI on iOS) or move toward Compose Multiplatform (CMP). CMP is the optional UI-sharing layer on top of KMP, not a synonym for KMP. Compose Multiplatform 1.8.0 in May 2025 marked Compose for iOS as stable and production-ready. That changes how much UI you can share if you choose to. It does not force you to share UI. It also does not make KMP/CMP web a peer of Flutter’s web story by default.
Clear the confusion early in any steering committee. KMP without CMP is shared logic plus platform-owned UI. KMP with CMP is shared logic plus a shared Compose UI where you elect to use it. Flutter is shared UI and shared logic under one Dart stack. Those are three postures, not two logos.
Flutter: what is good
Flutter’s strength is a single UI and interaction model across targets. Brand journeys, onboarding funnels and design-system components travel together. Hot reload, mature tooling and a large hiring pool for greenfield product teams make it attractive when you cannot staff parallel native UI squads. For organisations that need Android, iOS and an app-like web surface to feel like one product, Flutter is still the shortest path to a consistent brand experience.
That consistency matters most when the design system is custom rather than “pixel-perfect OS native”. Wallets, marketing-heavy acquisition flows and visually distinctive consumer products often want identical pixels everywhere. Flutter was built for that doctrine. Desktop targets exist when you need them; for banks and insurers the practical win is usually mobile plus web parity from one squad.
Flutter: what is bad or costly
Flutter is not truly native UI. Accessibility, typography and platform idioms need deliberate work. Screen readers and OS conventions improve year by year, but they remain an engineering programme rather than a free property of shipping Dart widgets. Deep platform SDK work (OEM banking SDKs, proprietary crypto modules, niche payment or attestation libraries) goes through platform channels or FFI. That friction shows up in enterprise estates with heavy device and vendor integration.
Dart is a skill island if the organisation is already a Kotlin and Java shop. App size and channel complexity grow with every awkward native bridge. None of these are fatal. All of them are real cost centres that conference demos omit. If your compliance story depends on direct, native control of biometrics, keystore and OS security surfaces, count the bridge tax before you celebrate the shared widget tree.
KMP and Compose Multiplatform: what is good
KMP reuses Kotlin domain, networking and policy logic without forcing you to abandon native UI where it matters. That is a natural fit for Android-heavy teams and existing Kotlin codebases. Netflix has described sharing platform-agnostic business logic for its Android and iOS studio apps via KMP while keeping appetite for Jetpack Compose and SwiftUI on the UI side. Cash App has run KMP in production for years as a long-running financial-app case study in JetBrains’ materials. Treat vendor case studies as existence proofs, not as a guarantee that your estate will share the same percentage of code.
Native iOS and Android feel remains available when UI stays platform-owned. CMP’s stable iOS path from mid-2025 lets teams share more UI when they choose, including gradual adoption screen by screen, without an all-or-nothing rewrite. Regulated shops that want native control of biometrics, keystore and OS security APIs often find the KMP-plus-native-UI posture easier to explain to security reviewers than a full custom-rendered stack. Google’s Jetpack multiplatform support for libraries such as DataStore, Room and ViewModel further reduces the “shared module feels second-class” objection on the Android side.
KMP and CMP: what is bad or costly
Without CMP you still pay for two UI teams or two UI codebases. Shared logic cuts duplication in the domain layer; it does not delete SwiftUI and Compose staffing. With CMP, iOS and especially web maturity, plus hiring for Compose beyond Android, still lag Flutter’s single-stack developer experience for some teams. JetBrains’ own CMP 1.8 notes frame web as evolving rather than finished: navigation and polish improved, but Compose Multiplatform for the web is not Flutter’s peer for a first-class product channel.
Many banks keep web as a separate React or Angular estate anyway. That is often the right call. Do not pretend KMP replaces a web product strategy by default. Coordination overhead remains: shared modules, API contracts and release trains across platform specialists. KMP rewards organisations that already have Android and iOS specialists who can agree contracts. It punishes organisations that hoped one junior squad would erase platform differences.
Good use cases for Flutter
Lean Flutter for greenfield consumer apps where brand UI must match on Android, iOS and web. Small or mid product teams that cannot staff parallel native UI squads get disproportionate value from one interaction model. Markets where both mobile operating systems and often mobile web are first-class acquisition channels favour the single-surface bet. Design-led products (wallets, onboarding, marketing-heavy journeys) over deep OEM integration are the sweet spot.
If you are throwing away an old Android app anyway and web parity is on the critical path for the next twelve months, Flutter is a coherent choice even in an otherwise Kotlin-heavy firm. The cost is starting a Dart estate. The benefit is not pretending three channels are one while staffing them as three.
Good use cases for KMP and CMP
Lean KMP for Android-first organisations extending to iOS without a Dart rewrite. Core banking and high-assurance mobile, where native UI and platform security APIs are non-negotiable, fit the shared-logic model. Large Kotlin backends and Android apps already in production can share the domain layer incrementally. Footprints that are mainly Android with a meaningful but smaller iOS cohort match the economics: protect Android velocity, extend logic, keep iOS UI native or selectively CMP.
Gradual adoption is a feature, not a hedge. Share networking and policy first. Add CMP later for selected screens if the design system and team skill justify it. That sequencing is harder to fake with Flutter once you have committed to Dart for the whole surface.
Strategy fork A: Android, iOS and web as first-class
When the customer base spans both mobile operating systems and treats mobile or desktop web as a real channel, the fork is blunt. Countries and segments with balanced iOS and Android mix (common in parts of Hong Kong, Singapore, the UK and the US) plus web-heavy onboarding push toward one product surface. Lean Flutter when one design system must ship everywhere and you will not fund a separate web product stack for the same journeys.
Lean KMP only if web stays a separate stack and you accept native or CMP UI on mobile only. That can still be right: many institutions will keep React or Angular for public web and use KMP for the authenticated mobile apps. Do not sell that posture as “one cross-platform strategy”. Sell it as mobile logic sharing with an honest web estate beside it. The failure mode is promising Flutter-like web parity from KMP/CMP because the slide said multiplatform.
Strategy fork B: mainly Android, some iOS
When the customer base and countries are Android-dominant (much of Asia, many large retail banking bases) with a smaller but important iOS cohort, existing Android and Kotlin gravity inside the firm usually wins. Lean KMP: protect Android velocity, share logic to iOS, keep iOS UI native or selectively CMP. Security and platform teams stay on familiar APIs. Hiring stays inside the Kotlin talent market you already pay for.
Flutter remains viable here if web parity matters more than Android heritage, or if you are replacing the old Android app rather than extending it. The tell is whether the next major release is “extend what we have” or “new consumer surface with browser parity”. Heritage without web pressure points to KMP. Greenfield brand surface with web as a peer points back to Flutter.
Deciding points for the CTO
Score the portfolio per product, not per slogan. Start with customers and countries: OS share in your real books, not vendor global charts. Ask whether web is a peer app or a brochure plus responsive site. Name the estate: greenfield versus a large Kotlin or Android codebase you intend to keep. Name the team shape: one cross-platform squad versus Android and iOS specialists who will not become Dart engineers overnight.
Compliance and device-security depth matter next. If platform channels versus native APIs will dominate every release train, price that friction honestly. State your UI doctrine: identical pixels everywhere versus native platform idioms. Set the time horizon: a twelve-month launch favours the stack your team can staff now; a five-year platform favours the language and hiring market you can sustain. Write explicit non-goals: what you will not share (web, desktop, OEM SDKs, accessibility-critical screens). Ambiguous non-goals are how Flutter programmes quietly drop web and how KMP programmes quietly invent a third UI framework.
Immediate next steps
Score each product on that checklist in a single working session with product, mobile and security leads present. Pilot one journey both ways only if the decision is genuinely close; otherwise pick and staff. Dual pilots that nobody intends to kill are how roadmaps stall. Freeze “we might add web later” as an explicit assumption in the architecture decision record. That single sentence often decides Flutter versus KMP more cleanly than any feature matrix.
Clinging to framework fashion while your customer mix, country footprint and Kotlin or Dart gravity sit unused on the whiteboard is how institutions buy the wrong five years. Flutter still wins when one UI must span Android, iOS and web. KMP, with optional Compose Multiplatform, wins when Android is the centre, native control matters and web stays secondary or separate. Pick for the estate you have.