Kort samengevat. Flutter en zijn geen twee implementaties van hetzelfde idee. Flutter is de ene weddenschap: één renderengine, één UI, elk platform. KMP is een andere weddenschap: deel de logica, houd de native UI van elk platform — tenzij je er Compose Multiplatform bovenop zet, waarna het een weddenschap in de vorm van Flutter wordt, met een jonger ecosysteem. Welke de juiste is hangt veel meer af van de bestaande vaardigheden van je team en de UI-ambities van je product dan van welke benchmark dan ook. Wij bouwen in Flutter, en we vertellen je hieronder precies wanneer we je juist naar KMP zouden wijzen.

Wil je alleen het antwoord: spring naar het beslismodel.

Vergelijk je Flutter liever met React Native? Dat is een eigen stuk. Met volledig native Swift en Kotlin? Ook een eigen stuk.

Waar we staan, vooraf gezegd

We zijn een Flutter-eerst bureau; het werk is openbaar. We hebben KMP voor klanten beoordeeld — de oprichter die dit schrijft heeft jarenlang productie-Kotlin opgeleverd en houdt zijn KMP en SwiftUI bij — maar we hebben geen KMP-app in productie opgeleverd, en het zou oneerlijk zijn om te doen alsof dat anders ligt. Dit stuk doet daarom twee dingen zorgvuldig: waar we ontwikkelervaring vergelijken, zeggen we wat onze evaluatieprojecten lieten zien in plaats van productie-ervaring te suggereren; en waar KMP werkelijk het betere antwoord is, zeggen we dat ronduit, want een vergelijking die geschreven is om altijd op "huur ons in" uit te komen is voor jou waardeloos.

Wat er tegen 2026 werkelijk veranderde

KMP is al een tijd niet meer de experimentele optie, en een vergelijking die het zo behandelt is achterhaald.

  • KMP zelf is stabiel en wordt van beide kanten omarmd. JetBrains verklaarde Kotlin Multiplatform eind 2023 stabiel, en Google maakte het op I/O 2024 tot een volwaardige aanbeveling voor het delen van bedrijfslogica op Android. Netflix, McDonald's en Cash App draaien met KMP gedeelde code in productie op serieuze schaal.
  • Compose Multiplatform bereikte in 2025 stabiliteit op iOS. De gedeelde UI-laag van JetBrains is nu stabiel op Android, iOS en desktop, met het webdoel nog in bèta. Dat doet ertoe omdat het verandert wat "KMP" kan betekenen: niet alleen gedeelde logica onder native UI's, maar ook gedeelde UI.
  • De Swift-kant is het actieve front. Kotlins directe Swift-export — zonder Objective-C-bridgingheaders ertussen — verscheen experimenteel en staat op JetBrains' pad naar stabiel. Tot die overal landt, blijft er op de grens tussen Kotlin en iOS wrijving zitten die native Swift-developers opvalt: geëxporteerde API's die vertaald aanvoelen in plaats van ontworpen.
  • Flutter stond ondertussen niet stil. -rendering is de gevestigde standaard, en het decennium aan ecosysteem van het framework — pub.dev, gereedschap, wervingsvijver — is precies datgene waartegen een jongere stack moet opboksen.

De vergelijking die de meeste stukken verkeerd aanpakken

"Flutter tegenover KMP" is in werkelijkheid twee verschillende vergelijkingen, en door ze op één hoop te gooien raken teams misleid.

Vergelijking A: Flutter tegenover KMP met native UI's. Je deelt bedrijfslogica — netwerkverkeer, opslag, domeinregels, viewmodels — in Kotlin, en bouwt de interface twee keer: SwiftUI op iOS, Jetpack Compose op Android. Doorgaans landt het delen op 40–70% van de codebase. In ruil daarvoor is elke app niet te onderscheiden van volledig native, want de UI is volledig native.

Vergelijking B: Flutter tegenover Compose Multiplatform. Je deelt ook de UI. CMP op iOS tekent zijn eigen pixels via rendering uit de Skia-familie, precies de architectuurweddenschap die Flutter in 2017 aanging — en dan kies je tussen twee implementaties van hetzelfde idee: de voordelen van Flutter zijn volwassenheid, diepte van het ecosysteem en platformbreedte; het voordeel van CMP is dat de taal en de helft van je toolchain die zijn waarin je Android-team al leeft.

Blijf je afvragen in welke vergelijking je werkelijk zit. Dat beslist vrijwel alles hieronder.

Zes dimensies die er werkelijk toe doen

1. UI-strategie — de echte tweesprong

  • KMP met native UI's levert iets wat Flutter architectonisch niet kan: elk scherm gebouwd uit de eigen componenten van het platform, met platformperfect gedrag in elk detail van scrollfysica, contextmenu's en toegankelijkheidssemantiek. Is "niet te onderscheiden van native" een harde eis — en in zakelijke verkooptrajecten in het bankwezen of de zorg is dat soms contractueel zo — dan is dit de eerlijke manier om die te halen terwijl je de logica eronder toch deelt.
  • Flutter levert de omgekeerde garantie: overal dezelfde pixels, een designsysteem dat volledig van jou is, en één implementatie van elk scherm. Voor merkzware, animatiezware, eigen UI — het Arcana-uiteinde van het spectrum — verslaat één keer bouwen twee keer bouwen op zowel kosten als consistentie.
  • CMP zit op deze as bij Flutter, niet bij native.

Eerlijke conclusie: dit is de dimensie om als eerste over te beslissen. Al het andere is verfijning.

2. Teamvorm — waar de meeste besluiten werkelijk vallen

KMP met native UI's vraagt nog steeds mensen die SwiftUI schrijven en mensen die Compose schrijven. Je hebt de gedupliceerde logica weggenomen, niet de behoefte aan twee platformvaardigheden. Dat is de juiste ruil voor organisaties die al native teams in dienst hebben — en dat zijn precies de organisaties die vandaag KMP op schaal uitleveren.

Flutter draait het om: één team, één taal, beide platforms — en daarom kan een zeskoppig bureau zoals het onze zeven productie-apps dragen. Werf je vanaf nul en bezit je nog geen Kotlin-expertise, dan is Flutter de kleinere organisatie om op te bouwen.

Eerlijke conclusie: bestaand Android/Kotlin-team → KMP verdient het je standaardhypothese te zijn. Nog geen mobiel team → met Flutter bouw je de kleinere organisatie.

3. Ecosysteem en de iOS-naad

Het ecosysteem van Flutter heeft een decennium aan diepte: pub.dev-pakketten voor de meeste SDK's die ertoe doen, volwassen gereedschap, en een enorme hoeveelheid oorlogsverhalen uit productie (we hebben ons deel geschreven). Het bibliotheekecosysteem van KMP is echt en groeit — kotlinx, Ktor, SQLDelight en Koin zijn degelijk — maar dunner in de lange staart, en de iOS-naad is waar evaluatieprojecten het voelen: tot directe Swift-export overal stabiel is, kunnen gedeelde API's die vanuit Swift worden gebruikt aanvoelen als vertaald Kotlin in plaats van native Swift, en je iOS-engineers zullen daar een mening over hebben.

Eerlijke conclusie: Flutter, duidelijk, vandaag — met de eerlijke voetnoot dat dit het snelst bewegende front van KMP is.

4. Stapsgewijze adoptie — de stille superkracht van KMP

Je kunt Flutter in een bestaande native app niet zinvol 10% per keer adopteren; add-to-app bestaat en werkt (we draaien er migraties op), maar het is een route naar het vervangen van de UI, niet naar eeuwig naast elkaar bestaan. KMP is voor het tegenovergestelde ontworpen: haal één module los — netwerkverkeer, synchronisatie, prijsregels — deel hem, lever uit, herhaal. Geen herbouw, geen groot besluit, bij elke stap omkeerbaar.

Eerlijke conclusie: voor een gezonde bestaande native app die wil stoppen met logica twee keer schrijven is KMP het juiste gereedschap en Flutter het verkeerde. We zeggen hetzelfde op onze migratiepagina: stabiele native apps met tevreden teams moeten nergens naartoe worden herschreven.

5. Prestaties

Saai antwoord, eerlijk gemeend: voor de overgrote meerderheid van apps zijn alle drie de configuraties snel genoeg dat architectuur en discipline rond widget-herbouw de prestaties bepalen, niet het framework. Impeller van Flutter en de native UI's van KMP renderen allebei op platformsnelheid; het canvasrenderen van CMP op iOS is dezelfde aanpak die Flutter jarenlang heeft gehard, uitgevoerd door een team dat zich op een eerder punt van die weg bevindt. Leeft je product op de rand van het renderen — streamende grafieken, zware animatie — dan is de volwassenheid van Flutter daar bewezen; dat was het ExtraETF-besluit.

6. Risico op de lange termijn

Het risico van Flutter is concentratie: het gedijt bij de gratie van Google, verzacht door open source en een enorme geïnstalleerde basis. Het risico van KMP is kleiner en anders van vorm: Kotlin is de officiële Android-taal, het hele bedrijf van JetBrains is developergereedschap, en Google onderschrijft het deelverhaal mede — maar specifiek CMP is jong, en gedeelde UI erop inzetten is wedden op zijn roadmap. Geen van beide risico's rechtvaardigt angst; beide rechtvaardigen bedrijfslogica achter schone modulegrenzen schrijven, wat de werkelijke verzekering is en frameworkonafhankelijk — hetzelfde argument als in de FAQ van onze pijlerpagina.

Kies Kotlin Multiplatform als…

  • Je een bestaande, gezonde native app hebt — zeker Android-eerst met een Kotlin-team — en de pijn zit in logica twee keer schrijven, niet in de UI.
  • Platformperfecte native UI een harde eis is en je SwiftUI plus Compose kunt bemensen.
  • Je stapsgewijze, omkeerbare adoptie wilt binnen apps die je al uitlevert.
  • Je organisatie al in Kotlin denkt: server-side Kotlin, senior Android-engineers, overal JetBrains-gereedschap.

Kies Flutter als…

  • Je nieuw bouwt en één team wilt dat naar beide winkels uitlevert — de economie waar ons hele portfolio op draait.
  • Je je designsysteem zelf bezit en het overal pixelidentiek wilt, inclusief web en desktop waar dat zijn plek verdient.
  • Je vandaag het diepere ecosysteem en de grotere vijver aan toegewijde framework-engineers wilt, niet pas na de volgende mijlpaal op de roadmap.
  • Het alternatief dat je werkelijk overweegt CMP is — dan kies je hoe dan ook de architectuur van Flutter, en volwassenheid pleit voor het origineel.

Het korte beslismodel

Bestaande native app, Kotlin-kennis in huis, UI blijft native: KMP — en daar heb je geen bureau als het onze voor nodig. Nieuw product, één team, eigen designsysteem, beide winkels op één budget: Flutter. In de verleiding om Compose Multiplatform te nemen voor een nieuw product: besef dat je de weddenschap van Flutter aangaat met een jongere stack, en maak de keuze op volwassenheid van het ecosysteem, niet op taalvoorkeur. Twijfel je dan nog, dan is de doorslag het team dat je over twee jaar werkelijk in dienst hebt.

Veelgestelde vragen

Ja, zonder voorbehoud voor gedeelde bedrijfslogica: KMP is stabiel sinds eind 2023, Google beveelt het aan voor het delen van logica op Android, en bedrijven als Netflix, McDonald's en Cash App draaien het op schaal in productie. Gedeelde UI is de genuanceerdere helft: Compose Multiplatform is sinds 2025 stabiel op Android, iOS en desktop, maar het iOS-ecosysteem ervan is jong vergeleken met dat van Flutter, en het webdoel zit nog in bèta. Productieklaar en in de strijd gehard zijn verschillende claims, en voor gedeelde UI op iOS moet de tweede nog worden verdiend.
Nee — in zijn klassieke vorm beantwoordt het een andere vraag. KMP deelt bedrijfslogica terwijl elk platform zijn native UI houdt, dus je bouwt nog steeds twee interfaces en bemenst twee UI-vaardigheden; Flutter deelt alles inclusief de pixels, dus één team levert naar beide winkels uit. De configuraties komen alleen samen als je Compose Multiplatform adopteert voor gedeelde UI, en dan heb je de architectuurweddenschap van Flutter gekozen — canvasrenderen, één widgetboom — geïmplementeerd door een jongere stack. Verschillende weddenschappen passen bij verschillende teams; geen van beide vervangt de andere.
Ja, via Compose Multiplatform, dat stabiel is op Android, iOS en desktop, met web nog in bèta. Op iOS tekent het zijn eigen pixels via rendering uit de Skia-familie in plaats van de UI-componenten van Apple te gebruiken — dezelfde architectuur als die van Flutter, en daarom zou een team dat CMP kiest voor een nieuwe app het rechtstreeks tegen Flutter moeten afwegen: de ruil is vertrouwdheid met Kotlin en hergebruik van Android-Compose-vaardigheden tegenover het decennium van Flutter aan ecosysteem, gereedschap en productieharding op precies die renderaanpak.
Vrijwel zeker KMP, en een Flutter-bureau dat je iets anders vertelt is aan het verkopen, niet aan het adviseren. Je Kotlin-code, de vaardigheden van je team en je bestaande architectuur gaan rechtstreeks mee: haal gedeelde modules stapsgewijs los, voeg een iOS-app toe die de logica hergebruikt, en houd elke stap omkeerbaar. Flutter zou betekenen dat je werkende code herschrijft en een werkend team omschoolt — een kostenpost die zich alleen terugbetaalt als je ook wilt wat Flutter als enige biedt, zoals één eigen designsysteem over elk platform of een consolidatie die volledig van platformteams af beweegt.
Voor de meeste nieuwe producten in 2026 blijft Flutter de veiligere versie van dezelfde weddenschap. Beide tekenen hun eigen UI op elk platform; Flutter draait die architectuur sinds 2018 in productie, met het pakketecosysteem, de devtools en de wervingsvijver als bewijs, terwijl CMP in 2025 stabiliteit op iOS bereikte en die diepte nog aan het opbouwen is. Het pleidooi voor CMP boven Flutter is organisatorisch, en het is reëel: een sterk Kotlin-team dat dagelijks Jetpack Compose schrijft houdt zijn taal, IDE en spiergeheugen. Weeg teamcontinuïteit tegen volwassenheid van het ecosysteem — dat is het werkelijke besluit.
Niet in productie, en dat zeggen we liever dan bluffen: ons opgeleverde werk is Flutter, plus native en backend-engineering eromheen. We hebben KMP serieus beoordeeld — ook voor klanten wier situatie die kant op wees — en wanneer de evaluatie zegt dat KMP jouw antwoord is, vertellen we je dat en helpen we je afbakenen wat je als eerste deelt, want een eerlijk nee bouwt meer vertrouwen op dan een opgerekt ja. Wil je de vergelijking uitgevoerd zien op jouw specifieke product en team, dan is dat gesprek precies waar ons verkennende gesprek voor is.

Aan het kiezen tussen Flutter en KMP voor een echt product? Plan een gesprek van 30 minuten — we geven een eerlijke aanbeveling, inclusief "gebruik KMP, en je hebt ons niet nodig."