Ik heb production apps geshipt in Swift, in Kotlin, in Flutter, en genoeg in React Native overgenomen. Dit is dus geen benchmark post. Het is het antwoord dat ik founders geef die deze week moeten beslissen en het niet twee jaar opnieuw willen zien.
De korte versie
- Flutter als je twee platforms, één team en zware custom UI nodig hebt. Beste cost-to-quality ratio voor meeste products in 2026.
- Native als de app het business is, of je afhankelijk bent van platform features de dag ze shipped.
- React Native als je al een sterk React team hebt en een web app om logica mee te delen. Anders is het geval zwakker dan het was.
Alles hieronder is waarom.
Native (Swift / Kotlin)
Twee codebases, twee skillsets, twee release cycli. Ruwweg 1,6–1,9× de buildkosten van een cross-platform equivalent — niet de 2× die mensen aannemen, omdat gedeeld werk (design, backend, product thinking) niet verdubbelt.
Wat je krijgt: elk platform capability dag één. Widgets, App Clips, Live Activities, CarPlay, Wear, diepe OS integraties, nieuwste camera en ML APIs. Geen abstractielaag tussen jou en het platform, wat betekent niet wachten tot iemand het ding dat je nodig hebt wrapper.
Kies het wanneer: de app is het product en zijn kwaliteit is de differentiator; je zit in een categorie waar platform features retention drijven; je hebt absolute beste performance en memory behaviour nodig; of je bent groot genoeg dat twee specialist teams normaal zijn.
Flutter
Eén codebase, één team, eigen rendering engine. Dat laatste is wat mensen verkeerd begrijpen: Flutter wrapi native componenten niet, het tekent zijn eigen. Dat is precies waarom zware custom UI goedkoop is in Flutter en precies waarom het subtiel un-native kan voelen als je tegen conventies van het platform vecht.
Wat je krijgt: echt dezelfde app op beide platforms, één team in te huren, één bug om te fixen. Uitstekend voor design-led products waar het interface toch al maatwerk is.
Wat het kost: je bent één laag verwijderd van nieuwe OS features, en grotere binaries. Alles diep platform-specifiek betekent een platform channel schrijven — wat prima is, en ook native code die je nu onderhoudt.
Kies het wanneer: twee platforms tellen, het budget is reëel maar eindig, de UI is custom, en je hebt liever één sterk team dan twee dunne.
React Native
De zaak is enger geworden. De nieuwe architecture fixte de oude bridge performance issues en als je React engineers hebt, zijn ze dag één productief — dat is een echt, groot voordeel.
Wat het kost: de dependency surface. Een React Native app is jij plus een lange staart community packages, en hun maintenance is niet jouw keuze. Upgrades zijn de meest voorkomende bron van ongepland werk die ik in overgenomen RN codebases zie.
Kies het wanneer: je hebt een React team en een web product om logica mee te delen. Als je vers zou inhuren, Flutter is meestal de beter bet in 2026.
De kostenvergelijking, concreet
Voor een mid-size consumer app — auth, core loop, payments, push, offline handling, beide platforms — ziet de vorm ruwweg zo uit:
- Flutter: één team, één codebase. Baseline. Zeg € X.
- React Native: ~1,0–1,15× baseline als je al React mensen hebt; ~1,2× als je vers inhuurt, want ecosystem kennis duurt langer dan syntax.
- Native beide platforms: ~1,6–1,9× baseline. Niet 2×, omdat design, backend en product thinking niet verdubbelen — alleen het client werk doet.
- Native één platform eerst: ~0,75× baseline, en dan heb je het tweede-platform gesprek in zes maanden met minder geld dan je nu hebt. Populair, en meestal betreurd.
Maintenance is waar de divergence compound wordt. Twee native codebases betekenen elke verandering word eenmaal gemaakt en tweemaal gebouwd, voor altijd. Over drie jaar is die kloof meestal groter dan het initiële buildverschil.
De inhuurrealiteit die niemand inprijst
In Barcelona, Madrid, Lissabon en het meeste van Centraal-Europa duurt het inhuren van een sterke Flutter engineer in 2026 weken. Inhuren van een sterke senior iOS engineer duurt maanden, en kost 20–30% meer als je een vind. In Londen, Amsterdam of Stockholm zijn beide lastiger en duurder.
Dit is een echte input voor de beslissing en het verschijnt bijna nooit in de technische vergelijking. De beste architectuur die je niet kunt bemannen is slechter dan de goeie architectuur die je kan.
Als je al op een bent en afvraagt of je moet switchelen
Kort antwoord: meestal niet, en hier is de test. Herschrijven kost 60–80% van een fresh build en levert nul nieuwe user value op de dag het shipped. Het is alleen gerechtvaardigd wanneer:
- Je kunt fysiek niet inhuren voor de huidige stack tegen enige redelijke prijs.
- Een platform requirement zal het werk forceren toch binnen twaalf maanden.
- De bestaande codebase faalt de basics — zie de audit checklist — in welk geval je niet herschrijft door het framework.
- Je onderhoudt twee native codebases met een team te klein voor een.
"Onze engineers zouden X liever hebben" staat niet op die lijst, en het is waarom meeste rewrites echt starten.
De vragen die het eigenlijk bepalen
Niet "wat is snelste". Deze:
- Wie onderhoudt dit in twee jaar? Kies de stack waarop je kunt inhuren in je stad of je budget. Een perfecte technische keuze met geen beschikbare engineers is een slechte keuze.
- Hoe custom is het interface? Zware custom favoriseert Flutter. Platform-conventioneel favoriseert native.
- Heb je een platform feature op launchdag nodig? Zo ja, native. Alles ander wacht op een wrapper.
- Is er een bestaande web app? Als het React is en de logica is echt shareable, wordt React Native's case veel sterker.
- Wat is het echte budget? Native voor beide platforms op een € 40.000 budget betekent één platform, slecht. Wees eerder eerlijk dan later.
Wat niet zoveel speelt als je denkt
- Raw performance. Voor de overgrote meerderheid apps zijn alle drie ver voorbij de drempel waar gebruikers het zien. Je network layer en image handling spelen meer mee dan je framework.
- "Het voelt niet native aan." Meestal waar van slechte apps in elk framework. Het is vaker een design en attention issue dan een technologie issue.
- Framework longevity argumenten. Alle drie overleven je huidige roadmap. Zet in op je team, niet op een foundation's persberichten.
Als je een bestaande app overneemt in plaats van een nieuwe te starten, is de framework vraag secundair — start met wat een audit eigenlijk moet kijken.