Native vs cross-platform apps.

De kern van de discussie

Je wilt een app bouwen. De eerste grote beslissing: bouw je apart voor iOS en Android (native), of gebruik je een framework dat beide platforms bedient vanuit een enkele codebase (cross-platform)? Het antwoord hangt af van je product, je budget, je tijdlijn en je ambities.

Er is geen universeel goed antwoord. Maar er zijn situaties waarin de ene keuze duidelijk beter is dan de andere. Laten we de opties ontleden.

Native development: Swift en Kotlin

Bij native development bouw je twee aparte apps: een in Swift (of SwiftUI) voor iOS en een in Kotlin voor Android. Elke app is geschreven in de programmeertaal en met de tools die Apple en Google specifiek voor hun platform aanbieden.

Voordelen van native

• Maximale performance: Native code draait direct op het apparaat zonder vertaallaag. Voor apps met zware animaties, realtime data-processing of complexe UI-interacties merk je het verschil.
• Volledige platform-integratie: Toegang tot alle platform-API's op dag één. Nieuwe features van iOS of Android kun je direct gebruiken, zonder te wachten tot een cross-platform framework ze ondersteunt.
• Platform-specifieke UX: iOS-gebruikers verwachten een andere ervaring dan Android-gebruikers. Navigatiepatronen, gestures, animaties — native apps voelen aan alsof ze bij het platform horen omdat ze dat ook doen.
• Stabiliteit: Geen afhankelijkheid van een derde partij. Je code praat direct met het OS. Geen bugs door een tussenlaag, geen breaking changes door framework-updates.

Nadelen van native

• Dubbele kosten: Je bouwt en onderhoudt twee aparte codebases. Twee teams (of een team met kennis van beide platforms), dubbele QA, dubbele tijd voor nieuwe features.
• Langere time-to-market: Twee apps bouwen duurt simpelweg langer dan een. Elke feature moet twee keer worden gebouwd, getest en gereleased.
• Schaarste aan developers: Goede Swift- en Kotlin-developers zijn schaars en duur. Het vinden en behouden van talent voor beide platforms is een uitdaging.

Cross-platform: Flutter en React Native

Cross-platform frameworks laten je vanuit een enkele codebase apps bouwen voor zowel iOS als Android. De twee dominante opties zijn Flutter (van Google) en React Native (van Meta).

Flutter

Flutter gebruikt Dart als programmeertaal en rendert alles zelf via de Skia graphics engine. Het tekent elke pixel op het scherm, onafhankelijk van de native UI-componenten van het platform.

Wat dat betekent in de praktijk:

• Consistente UI: Je app ziet er pixel-perfect hetzelfde uit op iOS en Android. Goed voor merkidentiteit, maar het kan ook betekenen dat je app er niet "native" aanvoelt op een van beide platforms.
• Snelle ontwikkeling: Hot reload, een rijke widget-library en een productief framework maken dat je snel kunt bouwen.
• Groeiend ecosysteem: Flutter wordt actief ontwikkeld door Google en heeft een snel groeiende community en package-bibliotheek.
• Beyond mobile: Flutter ondersteunt ook web en desktop, al zijn die platforms minder volwassen dan de mobiele ondersteuning.

React Native

React Native gebruikt JavaScript (of TypeScript) en React als basis. In tegenstelling tot Flutter maakt het gebruik van de native UI-componenten van het platform.

De praktijk:

• Native feel: Omdat React Native de native componenten van het platform gebruikt, voelen apps meer aan als echte iOS- of Android-apps.
• JavaScript-ecosysteem: Enorm pakket-ecosysteem, makkelijker om developers te vinden, en code-sharing mogelijk met een bestaande React-webapp.
• Bewezen op schaal: Gebruikt door Instagram, Shopify en Discord. Het kan dus wel.
• Bridge-overhead: De communicatie tussen JavaScript en native code gaat via een bridge (of de nieuwere JSI-architectuur), wat in sommige scenario's performance-overhead geeft.

De technologiekeuze is een middel, geen doel. Het doel is een app die je gebruikers graag gebruiken en die je bedrijf vooruit helpt.

De eerlijke vergelijking

Performance

Voor 90% van de apps is het verschil verwaarloosbaar. Scroll je door een lijst, vul je formulieren in, bekijk je data? Dan merk je geen verschil tussen native en cross-platform. Het verschil wordt relevant bij complexe animaties (60fps+ met veel overlapping elementen), zware berekeningen op het apparaat, AR/VR-toepassingen, en apps die directe hardware-aansturing nodig hebben (Bluetooth LE, NFC op laag niveau).

Ontwikkelsnelheid

Cross-platform wint hier overtuigend. Een codebase in plaats van twee betekent:

• 30-50% minder ontwikkeltijd voor de initiële build
• Nieuwe features hoeven maar een keer te worden gebouwd
• Bugfixes zijn automatisch op beide platforms gefixt
• Een kleiner team kan hetzelfde bereiken

De kanttekening: zodra je veel platform-specifieke functionaliteit nodig hebt, verdampt dat voordeel. Als je voor elke feature native bridges moet schrijven, had je net zo goed native kunnen bouwen.

Onderhoudskosten

Op lange termijn is dit vaak de doorslaggevende factor. Native apps vereisen dubbel onderhoud: twee codebases updaten bij OS-releases, twee sets dependencies bijhouden, twee CI/CD-pipelines onderhouden. Cross-platform halveert die operationele last grotendeels.

Maar cross-platform heeft eigen onderhoudsrisico's: framework-updates kunnen breaking changes bevatten, en je bent afhankelijk van de roadmap van Google (Flutter) of Meta (React Native). Als zij besluiten het framework niet meer actief te onderhouden, heb je een probleem.

Talent en teamsamenstelling

JavaScript-developers (React Native) zijn makkelijker te vinden dan Swift- of Kotlin-specialisten. Dart-developers (Flutter) zitten daar tussenin — Dart is makkelijk te leren, maar de pool is kleiner. Native development vereist ofwel twee gespecialiseerde developers, ofwel een dure unicorn die beide platforms beheerst.

Wanneer kies je native?

Native is de juiste keuze wanneer:

• Performance kritisch is: Games, AR/VR, realtime audio/video-processing, complexe animaties.
• Je zware platform-integratie nodig hebt: HealthKit, ARKit, Siri Shortcuts, Android Auto, Wear OS.
• Je app het kernproduct is: Als de app-ervaring je belangrijkste differentiator is (denk aan Snapchat, TikTok), investeer dan in de best mogelijke ervaring per platform.
• Je een groot team en budget hebt: Twee dedicated teams die parallel werken kunnen sneller features leveren dan een enkel cross-platform team.
• Langetermijnvisie: Je bouwt een product dat 5-10 jaar mee moet en je wilt geen afhankelijkheid van een third-party framework.

Twee aparte codebases bouwen en onderhouden is niet twee keer zo goed; het is twee keer zo duur. Voor de meeste zakelijke apps is dat onnodig.

Wanneer kies je cross-platform?

Cross-platform is de juiste keuze wanneer:

• Je snel de markt wilt bereiken: Een MVP dat op beide platforms werkt in de helft van de tijd.
• Budget beperkt is: Een codebase is goedkoper dan twee. Periode.
• Je app data-gedreven is: CRUD-apps, dashboards, e-commerce, content-apps — de standaard UI-patronen werken prima in cross-platform.
• Je team al JavaScript/React kent: React Native laat je bestaande kennis hergebruiken.
• Je ook een webapp hebt: Met React Native kun je componenten delen met je React-webapp. Flutter web is ook een optie, al is die minder volwassen.

Flutter vs React Native: welke kiezen?

Als je hebt besloten voor cross-platform, is de volgende vraag: welk framework?

Kies Flutter als je een consistente, pixel-perfect UI wilt, als je team geen JavaScript-achtergrond heeft, of als je ook desktop/web vanuit dezelfde codebase wilt bedienen.

Kies React Native als je team al React kent, als je code wilt delen met een bestaande webapp, of als een native look-and-feel per platform belangrijk is.

Beide zijn volwassen, bewezen en actief onderhouden. Je kunt met beide een uitstekende app bouwen.

Voor 90% van de apps merk je geen verschil in snelheid tussen native en cross-platform. Het verschil zit in je budget en je time-to-market.

Onze aanpak

Wij adviseren op basis van jouw situatie, niet op basis van onze voorkeur. In de praktijk betekent dat: voor de meeste zakelijke apps adviseren we cross-platform (Flutter of React Native) vanwege de lagere kosten en snellere time-to-market. Voor apps waar de gebruikerservaring het product is, of waar zware platform-integratie nodig is, adviseren we native.

De technologie-keuze is belangrijk, maar het is een middel, geen doel. Het doel is een app bouwen die je gebruikers graag gebruiken en die je bedrijf vooruit helpt. De rest zijn implementatiedetails.