Om de zoveel maanden neemt een CTO contact op met een variant van dezelfde vraag. Hun team heeft een React Native app. Die draait al twee of drie jaar. En nu is er iets veranderd: ze hebben betere performantie nodig, ze willen naar desktop, ze voegen hardware-integraties toe die de JS-bridge lastig maakt. De vraag op tafel is of ze naar Flutter moeten migreren.
Deze post gaat over die beslissing. Niet over “welk framework kies ik voor een nieuw project” (dat behandelen we in onze vergelijking van Flutter en React Native). Dit is de moeilijkere vraag: je hebt al een React Native codebase, je team kent ze, en je weegt af of de kost van een migratie opweegt tegen wat je er aan de andere kant voor terugkrijgt.
We zijn eerlijk: Unlock’d heeft nog nooit een volledige migratie van React Native naar Flutter gedaan als klantopdracht. Wat we wel deden, is de haalbaarheid van migraties inschatten tijdens discovery-gesprekken, React Native codebases auditen om te ramen wat een herbouw in Flutter zou kosten, en Flutter apps bouwen in domeinen waar React Native teams vaak tegen plafonds aanlopen. Deze post put uit die opgebouwde ervaring, niet uit één project.
Signalen dat je React Native app tegen limieten aanloopt
React Native werkt prima voor veel apps. Valt die van jou in een categorie waar het begint te knellen, dan herken je deze patronen.
Performantie van animaties en rendering. Door de bridge-architectuur van React Native passeren UI-updates langs een JavaScript-runtime. Voor de meeste apps merk je daar niets van. Maar zodra je controle op frameniveau nodig hebt, denk aan animaties op 60 fps, realtime visualisaties of interfaces die bij elk WebSocket-bericht updaten, wordt de bridge de flessenhals. Flutter rendert rechtstreeks, zonder runtime in de lus. Voor het veilingplatform van Lava woog dat door: de aflopende prijsklok moest aan 60 fps animeren, zelfs op Windows-hardware uit het lagere segment, met 100 prijsstippen die 20 keer per seconde hertekenen. Dat is precies het soort eis waar het renderingmodel van Flutter je gereedschap geeft dat React Native niet blootlegt.
Performantie van grote lijsten. React Native is hierop vooruitgegaan met de New Architecture, maar teams melden nog altijd wisselvallige scrollprestaties bij complexe lijsten, zeker met custom item renderers of geneste views.
BLE en hardware-integratie. Het BLE-ecosysteem van React Native is versnipperd. Je knoopt vaak meerdere packages aan elkaar van verschillende maintainers met verschillende aannames. De BLE-library van Flutter is meer geconsolideerd: één goed onderhouden package die de volledige levenscyclus van een verbinding dekt. Voeg je hardwareconnectiviteit toe aan je app, of waren hardware-integraties überhaupt de aanleiding om naar Flutter te kijken, dan is dat een reële overweging. De companion app van Classified Cycling beheert BLE-verbindingen met vier toesteltypes in buitenomstandigheden. Ze werd van meet af aan in Flutter gebouwd, precies daarom.
Uitbreiding naar web en desktop. De ondersteuning voor web en desktop van React Native is verbeterd, maar blijft een secundair doel. Heb je één codebase nodig die betrouwbaar draait op iOS, Android, web en Windows desktop, dan is de multi-platformondersteuning van Flutter over die doelen heen echt gelijkwaardig. Het veilingplatform van Lava draait op Windows desktop en op het web vanuit dezelfde Flutter codebase, met dezelfde rendering engine en hetzelfde state management.
Wrijving bij de migratie naar de New Architecture. De New Architecture van React Native (Fabric + TurboModules) is een flinke verbetering, maar bestaande apps migreren kan pijnlijk zijn. Sta je toch voor een grote infrastructuurupgrade in React Native, dan vinden sommige teams de totale kost daarvan vergelijkbaar met die van een herbouw in Flutter, en dan wordt de vraag waar je liever mee eindigt.
Wanneer migreren NIET zinvol is
Dit is de sectie die je zelden ziet in marketingmateriaal over Flutter. Migreren is niet altijd de juiste keuze.
Je app werkt prima. Zijn gebruikers tevreden, zijn crashes zeldzaam en zijn er geen klachten over performantie, dan is de business case voor een migratie zwak. Een migratie is een grote investering die een resultaat oplevert dat er voor gebruikers identiek uitziet. De technische verbeteringen moeten zich vertalen naar echte zakelijke uitkomsten.
Je React Native team is productief en tevreden. Het React Native ecosysteem is volwassen. Is je team snel, zelfzeker en loopt het nergens tegen muren, dan betekent van framework wisselen een periode van lagere snelheid terwijl ze Dart en de Flutter-patronen leren. Dat is een reële kost.
Geen uitbreiding naar meerdere platformen gepland. De kracht van Flutter stapelt op zodra je vanuit één codebase naar meerdere platformen uitlevert. Is mobiel je blijvende doel en heb je geen plannen voor desktop of web, dan geldt dat voordeel niet voor jou.
Krap budget zonder duidelijke ROI. Migraties kosten geld. Kan je geen specifieke zakelijke uitkomst benoemen die eruit volgt (sneller features leveren, ondersteuning voor een nieuw platform, minder crashes, een hardware-integratie die vandaag onmogelijk is), dan houdt de business case geen stand. Technologie omdat ze nieuw is, is geen business case.
Kosten- en tijdslijnmarges voor een migratie
Dit zijn eerlijke schattingen op basis van wat we tijdens discovery-opdrachten zagen. Het zijn geen garanties. Echte projecten zijn rommeliger.
| Complexiteit van de app | Voorbeelden | Tijdslijn | Relatieve kost |
|---|---|---|---|
| Eenvoudig (5-15 schermen, standaard UI) | Contentapps, dashboards | 2-3 maanden | 40-60% van de originele bouw |
| Middelmatig (15-40 schermen, custom UI, integraties) | E-commerce, boekingsapps | 4-6 maanden | 50-70% van de originele bouw |
| Complex (40+ schermen, native modules, offline, hardware) | Fintech, IoT-companion, healthcare | 6-12 maanden | 60-80% van de originele bouw |
Een paar dingen jagen de kost sneller op dan het aantal schermen doet vermoeden:
Equivalenten voor native modules. Elke native module in React Native heeft een Flutter-equivalent nodig. Sommige hebben een kant-en-klare vervanger. Andere vragen custom platform channels of, soms, FFI-bindings naar native code. Inventariseer je native modules vroeg. Dat is meestal de grootste bron van variatie in de schatting.
Herschrijven van state management. Patronen uit Redux en MobX mappen niet 1:1 op Riverpod of Bloc. De logica is overdraagbaar, de code niet. Een grote app met een volgroeide Redux-store vraagt een bewuste herontwerp van de architectuur, geen vertaling.
Verschillen in platformspecifiek gedrag. Randgevallen in het gedrag van iOS en Android die je team via productie-ervaring leerde kennen, moeten in een Flutter-context opnieuw geleerd worden. Zaken als het ontwijken van het toetsenbord, omgaan met safe areas, permissieflows per platform en routing van deep links hebben allemaal net andere idiomen.
Herbouw van de testinfrastructuur. Je bestaande widget tests en integratietests gaan niet mee. Je bouwt de testsuite van nul opnieuw op in het testframework van Flutter.
Veelvoorkomende valkuilen bij migratie
Teams die migraties onderschatten, struikelen bijna altijd over dezelfde reeks problemen.
Migratiestrategieën
Niet elke migratie volgt hetzelfde patroon. Er zijn drie hoofdaanpakken, elk met een ander risicoprofiel.
| Strategie | Hoe het werkt | Best wanneer |
|---|---|---|
| Volledige herbouw | Bouw de Flutter app van nul naast de bestaande RN-app en schakel over als ze klaar is | De app klein tot middelgroot is, of de bestaande codebase genoeg technische schuld draagt om achter te laten |
| Strangler-patroon | Embed Flutter-modules in de bestaande React Native app met flutter_boost of iets vergelijkbaars en vervang schermen stap voor stap | De app groot en complex is en teams beide versies in productie moeten houden tijdens de overgang |
| Schermen stapsgewijs vervangen | Bouw nieuwe features alleen in Flutter, migreer eerst de drukste schermen en stel schermen met lage prioriteit uit | De organisatie een hybride codebase langere tijd kan verdragen |
Voor de meeste teams waarmee we praten, is de volledige herbouw de praktischste keuze bij kleine tot middelgrote apps. Het strangler-patroon klinkt aantrekkelijk omdat het minder riskant aanvoelt, maar een hybride codebase met RN en Flutter draaien is echt complex. Je onderhoudt twee systemen voor state management, twee navigatiestacks en een brug ertussen. Die operationele last stapelt snel op. Het strangler-patroon is zinvoller bij grote apps met veel verkeer, waar in één keer overschakelen commercieel riskant is.
Overweeg je een migratie vanwege hardware-integratie, lees dan onze post over BLE app-ontwikkeling met Flutter voor wat dat werk echt inhoudt. Heeft je app e-commercefunctionaliteit en weeg je een herbouw af tegen een hybride aanpak, dan behandelt onze post over Flutter-Magento-integratie beide patronen.
Hoe een discovery-opdracht eruitziet
Komen teams bij ons met migratievragen, dan pakken we de beoordeling zo aan.
Audit van de codebase. We nemen de bestaande React Native codebase door: aantal schermen, complexiteit van componenten, inventaris van native modules, architectuur van het state management, testdekking en CI/CD-configuratie. Het doel is een feitelijke inventaris, geen oordeel over kwaliteit.
Inventaris van native modules. We mappen elke native module op zijn Flutter-equivalent, of markeren hem als custom werk. Dat is veruit de belangrijkste input voor de kostenraming. Een codebase met vijf native modules die goed onderhouden Flutter-equivalenten hebben, verschilt sterk van een codebase met vijf modules die maatwerk vragen.
Complexiteitsscore. We geven elk groot gebied een complexiteitsniveau: complexiteit van de UI, diepte van het state management, native integraties, offline-eisen en platformspecifiek gedrag. Dat levert een gewogen schatting op in plaats van een schatting op basis van schermen.
Raming van tijdslijn en budget. Op basis van de audit maken we een schatting in marges, met eerlijke betrouwbaarheidsintervallen. We benoemen welke aannames de schatting sturen en wat ze zou doen uitlopen.
Go/no-go-advies. We geven onze eerlijke kijk op de vraag of migreren de moeite waard is voor deze specifieke app en zakelijke context. Is het antwoord nee, dan zeggen we dat. Een correcte beoordeling is nuttiger dan een project dat om de verkeerde redenen start.
Belangrijkste inzichten
Migratiebeslissingen verdienen meer rigueur dan de meeste teams eraan besteden. Zorg dat je deze vragen kunt beantwoorden voor je je vastlegt.
Kan je het specifieke probleem benoemen dat de migratie oplost? Performantie op een bepaald scherm, uitbreiding naar desktop, een hardware-integratie die je vandaag niet kunt bouwen, een architectuur die je team afremt. Is het antwoord vaag, dan is de ROI dat ook.
Heb je je native modules geïnventariseerd? Die ene factor verklaart het grootste deel van de spreiding in kostenramingen voor migraties. Doe dit voor je aan andere scoping begint.
Klopt de business case op de tijdshorizon van de migratie? Een migratie van 4 tot 6 maanden die 18 maanden sneller features opleveren oplevert, is verdedigbaar. Een migratie van 6 maanden voor een app met stabiele, weinig frequente releases is moeilijker te rechtvaardigen.
Heb je het strangler-alternatief overwogen? Bij grote apps kan stapsgewijs Flutter-modules inbedden het commerciële risico verlagen, ook al verhoogt het de technische complexiteit. Het juiste antwoord hangt af van je teamgrootte, commerciële druk en risicobereidheid.
De teams met de beste migraties zijn de teams die met correcte data begonnen. De teams die worstelen, zijn de teams die de complexiteit van hun native modules onderschatten en aannamen dat de codebase sneller zou overzetten dan ze deed.
Overweeg je een migratie?