Add-to-app is het officiële mechanisme van Flutter om een Flutter-module in te bedden in een bestaande native iOS- of Android-applicatie. De gastapp blijft precies wat hij is — jouw Swift- of Kotlin-codebase, jouw releaseproces, jouw gebruikers — en Flutter komt daarachter te staan als één gecompileerde module, die de schermen rendert die jij hem toevertrouwt. Elk van die schermen wordt één keer geschreven en draait op beide platforms.

Deze pagina is voor teams die Flutter binnen de app willen die ze al hebben: een native product dat niemand gaat herbouwen, maar waarvan elke volgende functie het dubbele blijft kosten omdat die apart voor iOS en Android moet worden gebouwd. Is je werkelijke doel om volledig op Flutter uit te komen, dan is dat een andere opdracht met dezelfde mechaniek — lees dan migratie van React Native en native, die eerlijk is over het feit dat het een herbouw is. Hier wordt niets herbouwd: de native app blijft het product, en Flutter verdient zijn plek functie voor functie.

De opdrachten die we uitvoeren

  • Een pilotfunctie — één afgebakende functie, gebouwd in Flutter en uitgebracht binnen je beide native apps, waarbij de integratiekosten en de opbrengst worden gemeten in plaats van bediscussieerd
  • Functiepariteit inhalen — het scherm dat je iOS-app wel heeft en je Android-app niet (of andersom), één keer gebouwd voor beide in plaats van een tweede keer voor één
  • Het nieuwe oppervlak — een loyaliteitsprogramma, een boekingsstroom, een chat: een op zichzelf staande toevoeging aan een volwassen native product, die beide platforms bereikt op één budget
  • Fundament voor adoptie — de modulescaffolding, de routerkoppeling, de CI-opzet en de platform-channel-contracten netjes ingericht, zodat je eigen engineers de functies opleveren

Voor wie dit is — en wie beter kan migreren

Add-to-app verdient zichzelf terug onder specifieke voorwaarden, en we benoemen die liever dan een integratie te verkopen aan een team dat iets anders nodig heeft.

Tekenen dat add-to-app past

  • Elke roadmapfunctie wordt twee keer gebouwd, en de iOS- en Android-versies van je app zijn in mogelijkheden uit elkaar gaan lopen
  • De app is te groot of te bewezen om te herbouwen, dus "gewoon Flutter gebruiken" is nooit een beschikbaar antwoord geweest
  • Je wilt Flutter beoordelen op echt productiewerk — één functie, echte gebruikers, gemeten — voordat je een grotere verbintenis aangaat
  • Twee platformteams zijn moeilijk gelijkmatig te bemensen, en nieuwe oppervlakken lopen vast op het platform dat dit kwartaal toevallig onderbezet is

Wanneer het NIET de juiste keuze is

  • De app is klein genoeg dat een verse Flutter-bouw of een migratie scherm voor scherm minder kost dan het onderhouden van een naad tussen native en Flutter — integratie heeft overhead, en een kleine gastapp kan die niet terugverdienen
  • Het besluit om op 100% Flutter uit te komen is al genomen — voer het dan vanaf dag één uit als een migratie, met een migratiekaart, in plaats van er langzaam in af te glijden
  • De app is al React Native — een tweede cross-platformruntime naast de eerste inbedden verergert het probleem; de realistische opties voor dat team zijn blijven zitten of migreren
  • De functie die je wilt is een diepe platformmogelijkheid — een ervaring die om widgets draait, functionaliteit die op de Watch begint — waar Flutter het verkeerde gereedschap is, en dat zeggen we dan ook

De eerlijke lezing: een hybride app is een permanente naad — twee toolchains, twee sets idiomen, en een grens die elke engineer in het team moet begrijpen. Add-to-app is die kosten waard wanneer de gastapp te groot is om te herbouwen en de roadmap de belasting van twee platforms blijft betalen. Is geen van beide waar voor jouw app, dan is een van de naburige pagina's het betere antwoord — en in het eerste gesprek zeggen we welke.

Hoe stapsgewijze adoptie verloopt

De add-to-app-stroom

Stap 1

Native app blijft het product

Je iOS- en Android-apps blijven ongewijzigd uitkomen — geen bevriezing, geen parallelle herbouw, geen omschakeling aan de horizon

Stap 2

Flutter-module ingebed

Eén Flutter-module wordt in beide gastapps ingebouwd en deelt hun navigatie, authenticatie en analytics via vastgelegde contracten

Stap 3

Pilotfunctie komt uit

Een afgebakende functie wordt één keer in Flutter gebouwd en binnen beide apps uitgebracht, met de omvang- en opstartkosten vooraf en achteraf gemeten

Stap 4

Adoptie groeit functie voor functie

Elk nieuw oppervlak dat in de module landt is er één dat je niet twee keer hebt gebouwd — en elk is een besluit, geen verplichting

Stap 5

Jij bepaalt het eindspel

Blijf onbeperkt hybride, draag de module over aan je eigen team, of zet het momentum om in een volledige migratie — elke grens is een stoppunt

Deze aanpak gebruikt bewust dezelfde machinerie als onze migratiedienst — een Flutter-module achter een gedeelde router, schermen die één voor één verhuizen. Het verschil is de bestemming: een migratie faseert de native gastapp aan het einde uit, en adoptie hoeft dat nooit. Dat betekent ook dat adoptie later netjes omgezet kan worden in een migratie als de module dat verdient, zonder dat er iets wordt weggegooid.

Wat add-to-app werkelijk vraagt

Eén engine, met een beheerde levenscyclus

Een Flutter-module brengt de Flutter-engine mee, en die engine is een hulpbron die de gastapp bewust moet beheren: voorverwarmd zodat het eerste Flutter-scherm opent zonder zichtbare opstarttijd, gedeeld over toegangspunten in plaats van per scherm geïnstantieerd, en vrijgegeven wanneer het platform geheugen terugvraagt. Dit verkeerd doen is onzichtbaar in een demo en overduidelijk in productie. Het is het eerste wat we bouwen, niet het laatste wat we bijstellen.

Navigatie over de grens

Gebruikers maakt het niet uit welk framework het scherm rendert waar ze op staan, en de navigatie moet zich daar ook naar gedragen: teruggebaren die de conventie van elk platform volgen, deeplinks die net zo betrouwbaar op Flutter-schermen landen als op native schermen, en state die de oversteek in beide richtingen overleeft. Het routercontract tussen gastapp en module is het stuk add-to-app-architectuur dat bepaalt of de naad onzichtbaar is of een permanente bron van bugs.

Gedeelde diensten, geleend in plaats van gedupliceerd

Je app heeft al authenticatie, analytics, een netwerklaag en feature flags. De Flutter-module moet die lenen via — niet zijn eigen kopieën laten groeien, want zo eindigt een hybride app met twee sessies, twee eventschema's en metrieken die niemand vertrouwt. Die channelcontracten precies vastleggen is het grootste deel van de fundamentopdracht, en het is werk dat zich uitbetaalt bij elke functie die volgt.

Twee toolchains in één pijplijn

Na de integratie bouwt je de Flutter-module én beide native gastapps, en wordt de module geversioneerd tegen twee releasetreinen die niet altijd samen zullen bewegen. We nemen de modulebuild op in je bestaande pipeline — gecachet, reproduceerbaar, en eigendom van je repo in plaats van van een laptop — want een integratie die je CI niet kan bouwen, is niet geïntegreerd.

Een naad waar je designers mee kunnen leven

Flutter tekent zijn eigen pixels, en dat heeft twee kanten: het erft je native componenten niet, maar het reproduceert je designsysteem exact — zodra je tokens, typografie en spacing zijn overgezet naar het thema van de module. Dat overzetten doen we als onderdeel van het fundament, zodat een gebruiker die van een native scherm een Flutter-scherm in scrollt op geen enkele manier kan zien waar de grens lag.

De kosten, gemeten in plaats van beweerd

Flutter inbedden voegt echt gewicht toe: in de orde van enkele megabytes aan een Android-release en iets meer op iOS, plus de opstart van de engine bij de eerste lancering van een Flutter-scherm. De exacte getallen hangen af van jouw app, en daarom horen bij de oplevering van de pilot de voor- en nametingen van binaire omvang en opstarttijd — jij beslist of je verder gaat op basis van data uit je eigen product, niet uit een benchmarkblog.

Precedent in productie

Add-to-app is al jaren een ondersteund integratiemodel van Flutter, en de bekendste gebruiker is Google Pay, dat Flutter adopteerde binnen een bestaande native app met honderden miljoenen gebruikers voordat het de inzet vergrootte. Het patroon is wat deze pagina beschrijft: inbedden, één oppervlak uitbrengen, meten, dan beslissen. Onze eigen staat van dienst ermee komt uit migratiewerk, waar dezelfde machinerie van een module achter een router hele apps overzet; adoptie gebruikt die machinerie met een lichtere verbintenis.

Hoe we werken

Fundament en pilot met vaste scope. We integreren de module in beide gastapps, zetten de designtokens over, leggen de channelcontracten vast en brengen de eerste functie uit — een afgebakende opdracht met de metingen als onderdeel van de oplevering. Ons ontwikkelproces beschrijft hoe we afgebakend werk week na week uitvoeren.

Ingebedde engineers. Onze Flutter-engineers sluiten aan bij je native team, in jouw repo en jouw sprints, en bouwen de module uit naast de mensen die de gastapp bezitten — zie teamuitbreiding. Dit is de natuurlijke vorm zodra de pilot zich heeft bewezen en de module een plek wordt waar je roadmap regelmatig landt.

Hoe dan ook sturen we, zodra we de eisen scherp hebben, binnen twee werkdagen een offerte met duidelijke scope.

Wat een add-to-app-integratie kost

De opdracht van fundament plus pilot wordt geoffreerd nadat we de app hebben gezien: de integratiekosten worden bepaald door de gastapp — zijn navigatiearchitectuur, zijn buildsysteem, hoe zijn gedeelde diensten worden ontsloten — veel meer dan door de pilotfunctie zelf, dus een getal dat vóór het bekijken van de codebase wordt genoemd zou fictie zijn. Als ankerpunt: een afgebakende pilot blijft ruim onder wat een losstaande app kost — de gepubliceerde niveaus op de pagina Flutter-appontwikkeling beginnen bij € 12-24K voor een volledige MVP, en een pilotfunctie binnen een bestaande gastapp is een fractie van die scope.

Voor het ingebedde model geldt het gepubliceerde tarief van teamuitbreiding: € 8-11,2K per senior engineer per maand. En is het eerlijke eindspel van de roadmap een app die volledig Flutter is, prijs het dan als wat het is — een migratie, die op die pagina wordt geankerd tegen een volledige herbouw, niet als een adoptie die haar naam is ontgroeid.

Veelgestelde vragen

Veelgestelde vragen van teams die Flutter binnen een bestaande native app overwegen.

Ja — daar bestaat het add-to-app-integratiemodel van Flutter precies voor. Een Flutter-module wordt ingebed in je bestaande Swift- of Kotlin-app, aangesloten op zijn navigatie, authenticatie en analytics via platform channels, en rendert de schermen die jij erin laat bouwen. Je app blijft de hele tijd ongewijzigd uitkomen; de module wordt toegevoegd naast de code die je hebt, niet in plaats daarvan. Elk Flutter-scherm wordt één keer geschreven en draait binnen zowel je iOS- als je Android-app.
Nee. Adoptie en migratie delen dezelfde mechaniek — een Flutter-module achter een gedeelde router — maar een migratie verbindt zich eraan de native app aan het einde uit te faseren, en adoptie hoeft dat nooit. Elke functiegrens is een legitiem stoppunt: sommige producten blijven onbeperkt hybride met Flutter als eigenaar van een handvol oppervlakken, sommige dragen de module over aan hun eigen team, en sommige zetten het momentum om in een volledige migratie zodra de module dat heeft verdiend. Niets wat tijdens de adoptie is gebouwd wordt weggegooid als je later verder gaat.
De Flutter-engine en de module voegen echt gewicht toe — in de orde van enkele megabytes aan een Android-releasebuild en iets meer op iOS. Het precieze getal hangt af van je app en van wat de module bevat, en daarom omvat onze pilotopdracht voor- en nametingen van binaire omvang en opstarttijd op je werkelijke product. Je neemt het adoptiebesluit op basis van je eigen getallen, niet van een generieke benchmark.
Mechanisch werkt het — Flutter kan op dezelfde manier in een React Native-gastapp worden ingebed als in een volledig native app. Strategisch is het zelden zinnig: je zou twee cross-platformruntimes, twee bruggen en drie UI-idiomen in één binary draaien, wat het onderhoudsprobleem verergert in plaats van oplost. Voor een React Native-team dat ontevreden is met de status quo zijn de realistische opties blijven zitten of scherm voor scherm naar Flutter migreren — en onze migratiepagina opent met wie geen van beide zou moeten doen.
Ja. Add-to-app is al jaren een ondersteund integratiemodel van Flutter, en de bekendste gebruiker is Google Pay, dat Flutter inbedde in een native app met honderden miljoenen gebruikers voordat het de inzet vergrootte. Het patroon van een module inbedden, één oppervlak uitbrengen, meten en dan beslissen is bekend terrein. De engineeringrisico's die overblijven zijn de integratiedetails — de levenscyclus van de engine, navigatie over de grens, gedupliceerde diensten — en dat is precies het werk dat een gestructureerde fundamentopdracht naar voren haalt.
Niet voor de pilot — die bouwen wij, en jouw team beoordeelt de modulegrens in plaats van de Dart erbinnen. Groeit de Flutter-adoptie, dan zullen sommige van je engineers in de module willen werken, en Dart is een kleine stap vanaf Swift of Kotlin: sterk getypeerd, met garbage collection, en dichter bij wat ze al schrijven dan JavaScript zou zijn. Het model met ingebedde engineers bestaat precies voor deze overgang — onze mensen bouwen naast de jouwe totdat de module een codebase is die je team bezit in plaats van alleen huisvest.

Lees de migratiepagina als de bestemming volledig Flutter is, teamuitbreiding voor het ingebedde model, of begin bij de pijler Flutter-appontwikkeling.