De toekomst van app-ontwikkeling draait in 2026 minder om “welk framework is hip” en meer om architectuurkeuzes die snelheid, kwaliteit en kosten structureel beïnvloeden. De discussie “native versus hybride” is opnieuw actueel door hogere gebruikersverwachtingen, strengere privacy-eisen en een arbeidsmarkt waarin mobiele expertise schaars is. Wie nu de verkeerde koers kiest, betaalt later met performanceproblemen, technische schuld of vertraagde releases.
Tegelijk is de keuze niet binair: moderne productteams combineren steeds vaker native, cross-platform en zelfs low-code componenten binnen één portfolio. De kernvraag is: welke aanpak levert voor uw use-cases de beste balans tussen time-to-market, UX en beheersbaarheid? In dit artikel krijgt u een praktisch, beslisbaar kader—zonder mythes, mét realistische trade-offs.
Key Takeaways
- Kies native wanneer topperformance, platformfeatures en premium UX doorslaggevend zijn; kies hybride/cross-platform wanneer snelheid en één codebase prioriteit hebben—een afweging die Gartner expliciet benoemt voor mobiele frameworks.
- Flutter en React Native blijven in 2026 de dominante cross-platform opties; in 2023 gebruikte 46% van ontwikkelaars Flutter en 35% React Native volgens Statista.
- De beste keuze hangt minder af van “techniek” en meer van productrisico, teamvaardigheden, releasefrequentie, integraties en lifecycle-kosten (onderhoud, QA, security).
- Een toekomstbestendige aanpak begint met een architectuur-beslismodel (capabilities, constraints, governance) en eindigt met meetbare KPI’s voor performance, stabiliteit en developer productivity.
Wat is het verschil tussen native en hybride app-ontwikkeling (en waarom is de definitie belangrijk)?
Native apps worden per platform gebouwd (iOS/Android) met platform-ecosystemen, terwijl hybride/cross-platform apps één codebase delen voor meerdere platforms. Dit verschil bepaalt direct uw toegang tot platformfeatures, performance, teststrategie en teamopbouw. Heldere definities voorkomen dat u een “hybride” oplossing kiest die eigenlijk een webview is, met bijbehorende beperkingen.
In de praktijk vallen onder “hybride” meerdere smaken: (1) webview-hybride (bijv. Cordova-achtig), (2) cross-platform native rendering (bijv. Flutter), en (3) JS-bridge benaderingen (bijv. React Native). Elk model heeft een andere performancecurve, andere integratiecomplexiteit en andere eisen aan CI/CD en QA.
Voor beslissers is het nuttig om te praten in termen van “deliverable”: levert u een app die voelt als een volledig native product, of is het vooral een container rond webfunctionaliteit? Uw keuze beïnvloedt ook compliance: denk aan keychain/keystore, biometrie, attestation, en platform-specifieke privacyflows. Deze details bepalen vaak of een app ‘enterprise-grade’ is.
Waarom is ‘native versus hybride’ in 2026 opnieuw een strategische keuze?
In 2026 is de keuze strategisch omdat mobiele apps steeds vaker het primaire kanaal zijn voor omzet, service en dataverzameling. Tegelijk willen organisaties sneller leveren met kleinere teams, wat cross-platform aantrekkelijk maakt. Gartner beschrijft dat cross-platform ontwikkeling ontwikkeltijd en -kosten kan verminderen door één codebase te hergebruiken, terwijl native superieure prestaties en toegang tot platformfeatures biedt.
Daarnaast groeit de druk op releasekwaliteit: app stores, OS-updates en security-eisen veranderen continu. Een “snelle” keuze die later leidt tot instabiliteit of hoge onderhoudslast is duurder dan een initieel zwaardere native investering. Daarom is een portfolio-aanpak (per app of module de juiste techniek) vaker verstandig dan één uniforme standaard.
Ook het platformlandschap verandert: mobiele apps zijn niet meer alleen UI’s, maar clients in een bredere architectuur met API’s, eventing, analytics en feature flags. Uw keuze moet passen bij software governance, security reviews, observability en teamstructuren. Wie dit negeert, krijgt “framework-discussies” in plaats van productresultaten.
Wanneer kiest u voor native app-ontwikkeling?
Kies native wanneer u maximale performance, diepgaande platformintegratie en de beste UX nodig hebt, of wanneer uw app afhankelijk is van geavanceerde device-capabilities. Native is vaak de veiligste route voor complexe animaties, intensieve realtime interacties en strikte security-eisen. U betaalt doorgaans met hogere ontwikkelinspanning door twee codebases en specialistische skills.
Native is sterk in performance, UX en platformfeatures
Native biedt directe toegang tot iOS- en Android-API’s zonder extra abstraherende lagen. Dat maakt het eenvoudiger om nieuwe OS-features snel te adopteren en edge-cases goed af te handelen. Voor apps waarin micro-latency, vloeiende animaties of intensieve graphics belangrijk zijn, geeft native u meer voorspelbaarheid in tuning en profiling.
Native past bij strengere security- en compliance-eisen
Wanneer u werkt met gevoelige data (financieel, zorg, identity) is het voordeel van native dat u securitypatronen en platform-hardening direct kunt toepassen. Denk aan secure storage, certificaatpinnen, device binding en biometrische flows. Hybride kan dit ook, maar u moet vaker bruggen, plugins en extra supply-chain controles beheren.
- U heeft platform-specifieke features nodig die snel veranderen (bijv. nieuwe privacy-API’s, achtergrondtaken, deep OS-integraties).
- Uw UX is een concurrentievoordeel en moet “pixel-perfect” aanvoelen op elk platform.
- U wilt maximale controle over performance, batterijverbruik en memory-profielen.
- U accepteert hogere initiële kosten in ruil voor lagere productrisico’s bij complexe use-cases.
Praktische tip: als u native kiest, voorkom dan dat iOS- en Android-teams divergeren in functionaliteit. Gebruik gedeelde domeinmodellen, API-contracten, design tokens en een gezamenlijke releasekalender. Zo behoudt u consistentie zonder de voordelen van native op te offeren.
Wanneer is hybride/cross-platform app-ontwikkeling de beste keuze?
Kies hybride/cross-platform wanneer time-to-market, feature-pariteit en efficiënt onderhoud prioriteit hebben. Eén codebase kan de ontwikkelinspanning verlagen en teams kleiner houden, wat Gartner ook als kernvoordeel van cross-platform frameworks benoemt. Het werkt vooral goed voor productervaringen die grotendeels uit standaard UI-patronen bestaan en sterk API-gedreven zijn.
Eén codebase: sneller itereren en consistentie bewaren
Voor veel B2B-apps—denk aan portals, field service, interne tools—zijn de meeste schermen formulieren, lijsten, workflows en notificaties. Daar levert cross-platform vaak de meeste winst: één implementatie, één QA-stroom en één set componenten. Dat maakt het makkelijker om productbeslissingen snel in de markt te testen.
De marktadoptie van Flutter en React Native blijft hoog
Adoptie is relevant omdat het iets zegt over beschikbaar talent, tooling en community-ecosystemen. Volgens Statista gebruikte in 2023 46% van de softwareontwikkelaars wereldwijd Flutter als cross-platform framework en 35% React Native. Zie: Statista (cross-platform frameworks 2019–2023).
- U wilt snel een MVP en daarna gecontroleerd opschalen met dezelfde codebase.
- U heeft beperkte capaciteit en wilt de afhankelijkheid van zeldzame native specialisten verminderen.
- Uw app is vooral API-gedreven en gebruikt voornamelijk standaard UI-componenten.
- U wilt één release-ritme en één productteam dat end-to-end verantwoordelijk is.
Let op: “hybride” is geen vrijbrief om performance te negeren. U moet alsnog investeren in profiling, caching, offline strategie en render-optimalisaties. Cross-platform is het meest succesvol wanneer u het behandelt als volwaardige software engineering—niet als een shortcut.
Flutter vs React Native vs ‘echte’ hybride webview: wat zijn de trade-offs?
Flutter en React Native zijn toonaangevend voor cross-platform, maar ze verschillen in renderingmodel, integratie en teamskills. Gartner positioneert beide als leidende opties en adviseert engineering leaders om factoren af te wegen bij evaluatie. Webview-hybride kan geschikt zijn voor eenvoudige apps, maar loopt sneller tegen UX- en performancegrenzen aan.
Flutter: eigen rendering, consistente UI
Flutter rendert UI met een eigen engine, wat consistente visuals over platforms mogelijk maakt. Dat kan helpen wanneer u één design system exact wilt doorvoeren. Keerzijde: u beheert een extra laag in uw stack en moet scherp zijn op pluginkwaliteit en OS-compatibiliteit, zeker bij snelle platformwijzigingen.
React Native: native UI met een bridge, sterke web-synergie
React Native gebruikt doorgaans native UI-componenten en integreert via een bridge-achtige architectuur. Dat kan prettig zijn voor teams met veel JavaScript/TypeScript-ervaring en een bestaande React-ecosysteem. U moet wel actief sturen op dependency management, native module kwaliteit en regressietests bij OS-upgrades.
Webview-hybride: snel, maar beperkt voor ‘premium’ apps
Een webview-hybride aanpak kan aantrekkelijk zijn als u al een sterke webapp heeft en vooral “container + offline + push” nodig hebt. Maar voor complexe gestures, high-end animaties en diepe OS-integraties ontstaat vaak frictie. Behandel dit als een bewuste keuze voor een web-first product, niet als een vervanger van native.
Voor een gestructureerde vergelijking van Flutter en React Native is Gartner’s analyse nuttig: How to Decide Between React Native and Flutter for Mobile Apps. Gebruik dit soort bronnen vooral om evaluatiecriteria te formuleren, niet om blind “de winnaar” te kiezen.
Hoe beïnvloedt app-architectuur uw skills, effort en gebruikerservaring?
Uw app-architectuur bepaalt welke vaardigheden u nodig heeft, hoeveel ontwikkelinspanning realistisch is en hoe consistent de gebruikerservaring wordt. Gartner benadrukt dat de keuze voor een mobiele app-architectuur direct impact heeft op skills, effort en UX. Daarom moet u architectuur niet als technische bijzaak zien, maar als productstrategie.
Architectuurkeuzes die vaak onderschat worden
Frameworkkeuze is slechts één laag. Minstens zo belangrijk zijn: state management, offline-first synchronisatie, caching, error-handling en observability. Als die fundamenten ontbreken, voelt zelfs een native app instabiel; en een cross-platform app kan juist uitstekend presteren wanneer deze principes goed zijn uitgewerkt.
Een praktisch beslismodel: capabilities, constraints, governance
- Capabilities: welke device-functies zijn essentieel (camera, BLE, biometrie, achtergrondservices, AR)?
- Constraints: welke eisen gelden (compliance, latency, offline, store policies, integraties, data residency)?
- Governance: hoe organiseert u releases, QA, security reviews, dependency management en incidentrespons?
Koppel dit model aan meetbare doelen: crash-free sessions, opstarttijd, API-latency, releasefrequentie en defect leakage. Zo voorkomt u dat de keuze emotioneel wordt (“team X wil Y”), en maakt u het een herhaalbaar besluit. Bron voor het belang van architectuurkeuze: Gartner – Decision Point for Choosing a Mobile App Architecture.
Kosten, snelheid en TCO: waar zit het echte verschil?
Het grootste verschil zit zelden in de eerste release, maar in TCO (total cost of ownership): onderhoud, QA, OS-upgrades, security patches en doorontwikkeling. Cross-platform kan tijd en kosten verminderen door hergebruik van één codebase, zoals Gartner aangeeft. Native kan echter goedkoper uitpakken bij complexe platformfeatures doordat u minder omwegen en plugins hoeft te beheren.
TCO-onderdelen die u expliciet moet begroten
- QA-matrix: devices, OS-versies, schermformaten, netwerkcondities, accessibility.
- Release-operations: store submissions, feature flags, staged rollouts, hotfix-proces.
- Dependency & plugin management: updates, security advisories, compatibility.
- Observability: crash reporting, performance monitoring, logging, tracing.
- Security: pentests, secure storage, secrets management, code signing, supply-chain controles.
Sneller bouwen vs sneller veranderen
Cross-platform is vaak sneller voor brede functionaliteit, maar native kan sneller zijn bij platform-specifieke iteraties. Vraag dus niet alleen “hoe snel kunnen we v1 bouwen?”, maar ook “hoe snel kunnen we 24 maanden lang veilig blijven releasen?”. In B2B-omgevingen met veel integraties is die tweede vraag meestal bepalender.
Als u een businesscase maakt, vermijd schijnprecisie met niet-onderbouwde percentages. Werk liever met scenario’s: best case, expected, worst case—en benoem de drivers (teamgrootte, plugin-risico, OS-gevoeligheid, testinspanning). Gartner’s market guide geeft de richtinggevende trade-off tussen cross-platform efficiëntie en native performance: Market Guide for Mobile Development Frameworks.
Performance en gebruikerservaring: waar winnen native apps (en wanneer niet)?
Native apps winnen meestal bij extreme performance-eisen, complexe animaties en diepe OS-integraties. Toch is het verschil in 2026 vaak kleiner voor ‘standaard’ enterprise flows, mits cross-platform correct is geoptimaliseerd. De sleutel is om performance als requirement te behandelen: meet, profile en stel budgets op, ongeacht de techniek.
Performance-budgets die u vooraf kunt afspreken
- Opstarttijd (cold start) en time-to-interactive per deviceklasse.
- Scroll- en animatievloeiendheid (stutter/jank) in kernschermen.
- Netwerkbudget: aantal calls en payload per user journey.
- Offline gedrag: maximale wachttijd bij sync en conflictresolutie.
- Crash- en ANR-drempels als release gate in CI/CD.
UX-consistentie: design systems en platformconventies
Een valkuil is dat teams ‘consistentie’ verwarren met ‘identiek’. Gebruikers verwachten platformconventies: navigatiepatronen, back-behavior, permissions en share sheets. Cross-platform kan dit goed ondersteunen, maar u moet bewust kiezen waar u platform-specifiek afwijkt en waar u uniform blijft via een design system met tokens.
Praktisch: maak een UX-decision log met regels zoals “native patterns tenzij merkidentiteit in het geding is”. Zo voorkomt u eindeloze discussies in design reviews. Combineer dit met accessibility-by-default, omdat toegankelijkheid vaak eerder faalt door proces dan door framework.
Team en organisatie: welke skills en operating model passen bij uw keuze?
De beste technische keuze faalt als uw teamstructuur er niet bij past. Architectuur beïnvloedt vaardigheden en inspanning, zoals Gartner benadrukt, en dat vertaalt zich naar hiring, onboarding en ownership. Native vraagt meestal om twee platformteams of sterke platformspecialisten; cross-platform vraagt om een team dat end-to-end verantwoordelijk is voor één codebase én voor native extensies.
Organisatiemodellen die in de praktijk werken
- Platformteams (native): iOS en Android met gedeelde product-owner, gedeelde API-contracten en gezamenlijke QA.
- Feature teams (cross-platform): één team levert features voor beide platforms, met een kleine native enablement-groep voor plugins en platform-upgrades.
- Hybrid portfolio: kernervaring native, ondersteunende modules cross-platform (of omgekeerd), met duidelijke grenzen en interface-contracten.
Hiring en marktinformatie: maak skills zichtbaar
Maak uw skill-gap concreet: hoeveel iOS/Android engineers heeft u nodig, hoeveel cross-platform generalisten, en hoeveel QA/DevOps ondersteuning? Gebruik arbeidsmarktdata om verwachtingen te managen en salarissen realistisch te budgetteren. Een nuttige interne stap is om uw rolprofielen te spiegelen aan data zoals IT salary data by city and role.
Voor organisaties die partners overwegen, helpt een objectieve longlist van leveranciers met relevante track record. U kunt bijvoorbeeld oriënteren via de Verified IT company catalog en vervolgens uw selectie toetsen op referenties, security posture en delivery maturity. Dit reduceert het risico dat u vooral op ‘mooie demo’s’ selecteert.
Praktische scenario’s: welke aanpak past bij welk type app?
De meest betrouwbare manier om te kiezen is via scenario’s: wat moet de app doen, onder welke omstandigheden, en hoe vaak verandert het product? Hieronder staan zes mini-cases (illustratief, deels hypothetisch) die laten zien hoe native en hybride in de praktijk uitpakken. Gebruik ze als patroon, niet als blauwdruk.
Scenario 1 (illustratief): B2B field service app met offline-first
Een field service app moet werken in kelders, industrieterreinen en onderweg, met grote formulieren en foto’s. Cross-platform kan hier uitstekend werken als u offline sync, conflictresolutie en lokale opslag solide ontwerpt. Native wordt aantrekkelijk als u zware camera-workflows, achtergrondverwerking of device-integraties (bijv. scanners) intensief gebruikt.
Scenario 2 (illustratief): consumentenbankieren met biometrie en attestation
Bij bankieren zijn security, betrouwbaarheid en platformintegratie doorslaggevend. Native ligt voor de hand vanwege directe toegang tot secure enclaves, biometrische flows en fijnmazige controle over hardening. Cross-platform kan werken, maar vereist strakke governance rondom plugins, native modules en security reviews om supply-chain risico’s te beheersen.
Scenario 3 (illustratief): interne HR/self-service app met snelle iteraties
Een interne HR-app draait vaak om workflows: verlof, declaraties, approvals, notificaties en documenten. Cross-platform is hier meestal efficiënt: één team kan snel features uitrollen en consistentie borgen. Combineer dit met sterke API-contracten en role-based access control; de bottleneck is vaak backend-integratie, niet de UI.
Scenario 4 (illustratief): retail app met loyalty, wallet en store-ervaring
Retail apps hebben vaak piekbelasting, veel tracking/analytics en integraties met betalingen en loyalty. Een hybride aanpak is reëel: cross-platform voor catalogus en account, native voor performance-kritische flows (bijv. wallet, scanning, in-store features). Als betalingen centraal staan, stem dan uw mobiele keuze af op uw payment-architectuur en gateway-integraties.
Voor teams die e-commerce en payments combineren met mobile is het zinvol om ook uw webfundamenten te versterken. Zie bijvoorbeeld Best practices voor het integreren van betalingsgateways voor integratiepatronen die ook mobiele flows beïnvloeden.
Governance, kwaliteit en security: hoe voorkomt u technische schuld?
Technische schuld ontstaat meestal niet door de keuze native of hybride, maar door ontbrekende governance: onduidelijke ownership, geen quality gates en zwak dependency management. Uw frameworkkeuze bepaalt wél waar de risico’s zitten: bij native vooral in dubbele implementatie en releasecoördinatie; bij cross-platform vooral in plugins, bridges en platformcompatibiliteit.
Quality gates die u in elke mobiele pipeline wilt
- Automated tests op drie niveaus: unit, integration, en end-to-end smoke op echte devices.
- Static analysis en dependency scanning (incl. licenties) als merge-requirement.
- Performance checks (startup, scroll, memory) op representatieve toestellen.
- Security checks: secrets scanning, certificate pinning regressie, jailbreak/root detectie waar relevant.
- Release governance: staged rollout, crash monitoring, rollback-procedures en incident playbooks.
Supply-chain en plugin-risico’s beheersen (extra belangrijk bij cross-platform)
Cross-platform stacks leunen vaak op een plugin-ecosysteem. Maak daarom een pluginbeleid: welke bronnen zijn toegestaan, hoe vaak update u, en wie is eigenaar van kritieke plugins? Voor kritieke device-functies is het soms verstandig om eigen native modules te bouwen en die intern te onderhouden, zodat u niet afhankelijk bent van community-onderhoud.
Koppel governance aan uw bredere softwarepraktijk. Als uw organisatie ook webapplicaties beheert, harmoniseer dan observability, CI/CD en security controls waar mogelijk. Dit sluit aan op de bredere discipline van Softwareontwikkeling, waar consistente engineeringstandaarden vaak meer waarde leveren dan nóg een frameworkwissel.
Hoe passen low-code, cloud-native en SaaS in de toekomst van app-ontwikkeling?
Low-code, cloud-native en SaaS veranderen de discussie doordat ze ontwikkeling versnellen, maar ook nieuwe grenzen introduceren rond extensibility en governance. Gartner waarschuwt dat legacy applicatieplatforms de prestaties van teams beperken en dat leiders proactief het optimale platform moeten selecteren om ontwikkeling te versnellen. Dit betekent: kijk verder dan mobile-only en ontwerp uw totale delivery platform.
Wanneer low-code logisch is (en wanneer niet)
Low-code is sterk voor interne apps, snelle procesdigitalisering en standaard workflows. Het wordt risicovol wanneer u unieke UX, zware offline eisen of complexe device-integraties nodig hebt. Een praktische aanpak is ‘low-code voor admin en backoffice, native/cross-platform voor customer-facing mobiele journeys’—met gedeelde API’s en identity.
Cloud-native backend als ‘force multiplier’ voor elke mobiele keuze
De meeste mobiele vertraging zit niet in UI, maar in backend- en integratiewerk: identity, API’s, data, events en observability. Door uw backend cloud-native te organiseren (API gateway, rate limiting, tracing, feature flags) verbetert u zowel native als cross-platform delivery. Zie Gartner’s perspectief op platformkeuze: How to Choose Between Low Code, Cloud Native and SaaS Application Platforms.
Voor organisaties die ook webkanalen moderniseren, loont het om mobile en web als één productecosysteem te behandelen: gedeelde design tokens, gedeelde content-modellen en herbruikbare API’s. Een nuttige parallel is hoe teams webplatforms schaalbaar maken; zie bijvoorbeeld Bestaande platforms optimaliseren met responsive design.
Wat betekent AI voor native versus hybride apps in 2026?
AI beïnvloedt app-ontwikkeling vooral via nieuwe productfeatures (assistants, personalisatie) en via engineering (snellere prototyping, testgeneratie). Voor de keuze native versus hybride geldt: AI-features zijn meestal API-gedreven, waardoor cross-platform vaak prima werkt. Native wordt belangrijker wanneer u on-device AI, camera/vision pipelines of strikte latency- en privacy-eisen heeft.
AI-features zijn vaak backend-first: focus op integratie en governance
Veel AI-ervaringen bestaan uit UI + API-calls + observability. Dan is uw mobiele framework minder bepalend dan uw API-architectuur, logging, evaluatie en guardrails. Als u AI-roadmaps heeft, borg dan dat mobile teams vroeg betrokken zijn bij token/latency budgets, caching en fallback UX.
On-device AI en privacy: waar native vaker voordeel heeft
On-device verwerking kan aantrekkelijk zijn voor privacy en latency, maar vraagt om diepe integratie met platform-capabilities, modeldistributie en performanceprofiling. In zulke gevallen is native (of een hybride aanpak met native modules) vaak pragmatischer. Wilt u breder oriënteren op AI-initiatieven die mobile raken, dan past een verwijzing naar AI-ontwikkeling als kapstok voor use-cases en governance.
Belangrijk: vermijd dat AI “extra complexiteit” wordt bovenop een al fragiele mobiele basis. Eerst betrouwbaarheid, performance en security; daarna AI-innovatie. Zo voorkomt u dat u een nieuw kanaal bouwt dat niet schaalbaar te beheren is.
Implementatiechecklist: zo kiest en levert u de juiste aanpak
De beste volgende stap is een gestructureerde evaluatie die eindigt in een besluit dat u kunt uitvoeren én verdedigen. Gebruik onderstaande checklist om requirements te concretiseren, risico’s te reduceren en een pilot meetbaar te maken. Dit is geen theorie: teams die dit doen, vermijden de klassieke valkuil van “framework first” en bouwen een roadmap die standhoudt.
- Definieer uw top-10 user journeys en label ze op complexiteit (offline, device features, performance-kritisch, compliance).
- Maak een beslismatrix met weging: UX, performance, platformfeatures, time-to-market, TCO, hiring, risico’s (plugins/supply chain).
- Kies een ‘reference architecture’ (auth, API-layer, caching, offline sync, observability) vóórdat u UI-componenten uitwerkt.
- Plan een 4–8 weken pilot: bouw 2 kernschermen + 1 device-feature + 1 offline flow, inclusief CI/CD en monitoring.
- Stel quality gates in: testdekking, performance-budgets, dependency scanning, releaseproces met staged rollout.
- Borg ownership: wie beheert plugins, wie doet OS-upgrade readiness, wie beheert incident response en security patches?
- Maak een talentplan: hiring/opleiding, rolprofielen, en budget; gebruik marktdata en partneropties waar nodig.
- Leg het besluit vast in een ‘architecture decision record’ met meetpunten die u na 90 dagen evalueert.
Als u externe capaciteit nodig heeft, maak uw selectie concreet: vraag om voorbeelden van vergelijkbare apps, hun releaseproces, en hoe ze platform-upgrades en pluginrisico’s managen. Start klein met een pilotcontract met duidelijke deliverables en exit-criteria. Voor teams die vooral mobiel als kerncompetentie willen versterken, is het logisch om ook te verkennen wat er speelt binnen Mobiele app ontwikkeling.
