We krijgen deze vraag in bijna elk discovery-gesprek: “Waarom Flutter en niet React Native?”
Soms komt het van een CTO die oprecht zijn huiswerk doet. Soms komt het van een managementteam dat ervan uitgaat dat React Native hetzelfde is als React, en dat hun webteam “ook even mobile kan doen.” Dat zijn heel andere gesprekken.
Dit is wat we geleerd hebben door jarenlang Flutter-apps in productie te brengen, en waarom we nog nooit een project hadden waar React Native de betere keuze zou zijn geweest.
Naast Elkaar
| Flutter | React Native | |
|---|---|---|
| Taal | Dart | JavaScript / TypeScript |
| Gemaakt door | Google (2017) | Meta (2015) |
| Compilatie | Native ARM-code | JavaScript-runtime (Hermes) |
| UI-rendering | Eigen engine (Skia / Impeller) | Native platformcomponenten |
| Platformen | iOS, Android, Web, Windows, macOS, Linux | iOS, Android, Web (community), Windows/macOS (Microsoft) |
| Desktop-ondersteuning | Ingebouwd, productierijp | Via Microsoft, minder volwassen |
| BLE / hardware | Volwassen ecosysteem | Beschikbaar, gefragmenteerd |
| Leercurve | Nieuwe taal (Dart), maar eenvoudig | Vertrouwd als je React kent |
| GitHub-sterren | 170k+ | 121k+ |
| Gebruikt door | Toyota, BMW, Google Pay, eBay | Meta, Shopify, Discord, Coinbase |
Tabellen zijn handig, maar ze vertellen niet hoe het echt is om met elk framework te bouwen. Dit is wat we geleerd hebben uit echte projecten.
Flutter voor Bluetooth Low Energy (BLE) Apps
Toen Classified Cycling bij ons kwam, hadden ze al hun research gedaan. Ze hadden een companion-app nodig die via Bluetooth Low Energy zou koppelen met draadloze aandrijflijnhardware, firmware-updates over the air zou pushen, en meerdere apparaattypes zou beheren op zowel iOS als Android.
Ze kozen Flutter nog voor wij betrokken waren, specifiek vanwege het BLE-ecosysteem. Na jaren van ontwikkeling over meerdere grote releases heen beheert de app nu verbindingen met vier verschillende hardwaretypes, integreert met twee partnerecosystemen (Shimano DI2 en TRP CMD), en verzorgt firmware-updates voor ze allemaal. De keuze heeft standgehouden.
De BLE-laag in Flutter beheert de volledige levenscyclus: scannen, verbinden, authenticeren met challenge-response over versleutelde characteristics, batterijniveaus uitlezen, firmware pushen via Nordic DFU, en bondingverschillen beheren tussen apparaattypes. Het werkt betrouwbaar in buitenomstandigheden waar Bluetooth op z’n onvoorspelbaarst is.
Had dit in React Native gebouwd kunnen worden? Technisch gezien ja. Maar het Flutter-ecosysteem voor BLE is meer geconsolideerd. Eén goed onderhouden bibliotheek dekt de volledige verbindingslevenscyclus. In React Native plak je meerdere bibliotheken aan elkaar met verschillende beheerders en verschillende aannames over hoe BLE-state beheerd moet worden.
Flutter Prestaties: 60fps op Low-End Hardware
Voor het Lava-veilingplatform bouwden we een realtime klok waarbij de prijs elke 50 milliseconden daalt en honderden kopers tegelijk bieden. Een visuele vertraging van 100ms betekent dat een koper op de verkeerde prijs biedt.
Flutter’s rendering engine liet ons de klok opsplitsen in twee onafhankelijke verflagen: het zware werk (100 prijspunten en labels hertekenen) draait op het tikritme van de klok, terwijl het lichte werk (de actieve prijsindicator animeren) draait op de verversingssnelheid van het scherm. Deze architecturale opsplitsing is alleen mogelijk omdat Flutter je directe controle geeft over de renderingpipeline. Je werkt niet via een bridge en wacht niet op een JavaScript-runtime om je frame te verwerken.
Het resultaat: 60fps op het web, zelfs op low-end apparaten. We schreven hier in detail over in onze auction clock deep dive.
In React Native heeft de New Architecture een groot deel van het prestatieverschil gedicht voor typische apps. Maar wanneer je controle op frameniveau nodig hebt over wat hertekend wordt en wanneer, geeft Flutter’s renderingmodel je tools die React Native’s architectuur niet blootstelt.
Flutter Desktop vs React Native
De Lava-veilingclient draait op Windows-desktop en webbrowsers vanuit dezelfde Flutter-codebase. Dezelfde rendering, dezelfde WebSocket-verbindingsafhandeling, hetzelfde state management. De desktopondersteuning was geen bijgedachte die we er later op schroefden. Het was een eersteklas doelplatform vanaf dag één.
Ubuntu’s installatie-wizard is gebouwd met Flutter. Google’s eigen interne tooling gebruikt het voor desktop. Als we klanten vertellen “Flutter draait op desktop,” hebben we het niet over een experimentele feature. Het is productie-infrastructuur.
React Native’s desktopverhaal verbetert dankzij bijdragen van Microsoft, maar het is nog steeds een apart traject met eigen beperkingen. Als multiplatformondersteuning een kernvereiste is (niet een leuk extraatje), is Flutter vandaag de veiligere keuze.
Flutter Hybride Apps: Bestaande Webinfrastructuur Inpakken
Niet elke app begint vanaf nul. Hubo, een Belgische doe-het-zelfretailer met meer dan 160 winkels, had al een volledige e-commercewebsite. Een native app bouwen die al die functionaliteit dupliceert zou verspilling zijn geweest. In plaats daarvan bouwden we een Flutter-shell die hun bestaande webplatform inpakt in een native app, met geselecteerde features die native zijn geïmplementeerd: pushmeldingen, klantenkaart, winkelzoeker.
Zowel Flutter als React Native ondersteunen embedded web views. Maar Flutter’s voordeel hier is controle. De native shell beheert de app-levenscyclus, deep linking en platformspecifieke features, terwijl de web views het productbrowsen en afrekenen afhandelen. De grens tussen native en web is onzichtbaar voor de gebruiker.
Dit hybride patroon is gangbaar voor bedrijven die al webinfrastructuur hebben en een mobiele aanwezigheid willen zonder alles opnieuw te bouwen. Flutter laat de native onderdelen native aanvoelen terwijl het benut wat er al bestaat.
Kan Je React-Team een React Native App Bouwen?
We hebben nog nooit een project gehad waar we React Native boven Flutter aanbevolen. Maar we hebben wel gesprekken gehad waar het management ervan uitging dat React Native de voor de hand liggende keuze was omdat “we al een React-webteam hebben.”
React Native en React delen het componentmodel en de JSX-syntax. Maar mobiele ontwikkeling is een ander vakgebied. BLE-verbindingen, pushmeldingen, achtergrondverwerking, app store-deployment, platformspecifieke permissies, offline opslag. Een React-webdeveloper wordt niet vanzelf productief op deze problemen alleen omdat de syntax er vertrouwd uitziet.
De leercurve voor Dart is reëel maar kort. De meeste developers zijn binnen een week comfortabel. En wat ze erbij krijgen is een framework waar mobile, desktop en web echt gelijkwaardige burgers zijn, geen bijgedachten die op een mobile-first architectuur zijn geschroefd.
Uit Onze Projecten
Deze cijfers komen uit productie Flutter-apps die we bouwen en onderhouden.
Migreren van React Native naar Flutter
Als je een bestaande React Native-app hebt en je loopt tegen prestatielimieten aan, worstelt met platforminconsistenties, of wilt uitbreiden naar desktop en web, dan is migreren naar Flutter het overwegen waard. We helpen teams beoordelen of een migratie zinvol is en plannen de transitie zonder te verstoren wat al werkt.
Een migratie is niet altijd de juiste keuze. Maar wanneer de eisen van je app zijn uitgegroeid boven wat React Native goed aankan, geeft Flutter je ruimte om te groeien.
Wanneer We Flutter Aanbevelen
- Prestaties zijn belangrijk (realtime UI’s, animaties, hardware-integratie)
- Je hebt pixelperfecte consistentie nodig over platformen heen
- Je bouwt voor meer dan alleen mobile (web, desktop, embedded)
- Bluetooth of IoT is betrokken
- Je begint vanaf nul zonder bestaande mobiele codebase
Onze Visie
De slechtste keuze is een framework kiezen op basis van hype in plaats van je werkelijke eisen. Wij kozen Flutter omdat onze projecten custom rendering, hardwareconnectiviteit en cross-platform bereik verder dan iOS en Android vereisen. Voor die use cases geeft Flutter ons een voorsprong die we niet zouden inruilen. Meer weten over hoe we werken? Bekijk onze Flutter development services.