Native app vs cross-platform: hoe maak je de juiste keuze?

Native app vs cross-platform: hoe maak je de juiste keuze?

Wat is het verschil tussen native en cross-platform?

Native app-ontwikkeling betekent dat je per platform een aparte codebase bouwt. Voor iOS gebruik je Swift (en tegenwoordig vaak SwiftUI), voor Android Kotlin (met Jetpack Compose). Elk platform heeft zijn eigen ontwikkelomgeving, eigen testproces en eigen release-ritme.

Native app-ontwikkeling betekent dat je per platform een aparte codebase bouwt.

Cross-platform betekent dat je een codebase schrijft die op beide platforms draait. De drie grote namen in 2026 zijn Flutter (Dart, achter Google), React Native (JavaScript, achter Meta) en Kotlin Multiplatform (Kotlin, achter JetBrains). Ze compileren naar native code, dus het zijn geen webpagina’s in een jasje.

Let op: “hybride” is een term die veel rondzweeft, maar strikt genomen bedoelt men daarmee een webview-gebaseerde oplossing zoals Ionic of Cordova. Flutter en React Native zijn technisch gezien geen hybride apps, ze renderen native UI. Er bestaat ook nog een derde optie: een progressive web app, waarover zo meer.

Wanneer een native app de juiste keuze is

Wij kiezen native als de app diep op hardware, sensoren of real-time functionaliteit leunt. Dat klinkt abstract, dus een paar concrete voorbeelden uit onze eigen projecten.

Voor een klant in professionele LED-verlichting bouwden we de LumiTaG-app, waarmee technici armaturen in theaters en op events configureren via een NFC-tap. NFC-afhandeling zit diep in het Android SDK en werkt op iOS weer anders. Offline werken in een theaterzaal zonder netwerk was een harde eis. Native was hier geen voorkeur, het was de voorwaarde.

Voor Vetts bouwden we een veterinair telehealth platform met videoconsulten, push notificaties en drie betaalmethoden. Real-time video op twee platforms met reactive programming (RxSwift en RxJava) is precies het type werk waar native glanst. Resultaat: 4.9 sterren in de App Store.

Voor FOCUS draaien we sinds 2019 een gamification-platform met HLS adaptive video streaming, push notificaties met deeplinks en minigames die op 60fps moeten lopen. Voor innerkidz bouwden we real-time chat via SignalR, waarbij kinderen in therapie veilig met hun behandelaar kunnen praten. Voor Met WA Beveiliging draait een native app die honderden beveiligers dagelijks in het veld gebruiken, gedistribueerd via Apple Business Manager voor device-management. MegaPrep combineerde QR-scanning met videocaptatie in minder dan 30 seconden per testregistratie.

Allemaal situaties waarin de native-laag het verschil maakt. Widgets op het lockscreen, App Intents voor Siri, directe adoptie van nieuwe iOS- of Android-features zodra Apple of Google ze uitrolt, dat is het soort detail waar native apps altijd voorlopen.

Wanneer cross-platform de slimste keuze is

Als de app draait om informatie, bestellingen, content of eenvoudige interactie, en er is geen zware sensor- of video-integratie nodig, dan wint cross-platform vrijwel altijd. Minder code, minder onderhoud, sneller op beide stores.

Een typisch voorbeeld is een B2B-bestelapp: product kiezen, hoeveelheid aangeven, bestelling versturen. Geen real-time video, geen sensor-afhankelijkheid, geen device-management. Daar bouwen we Flutter, één codebase voor iOS en Android, lager onderhoud. Native zou voor dit type app een verdubbeling van inspanning opleveren zonder dat de eindgebruiker er iets van merkt.

Over de frameworks zelf: Flutter en React Native zijn in 2026 allebei volwassen. Flutter heeft met de Impeller-renderer een performance-inhaalslag gemaakt en haalt op moderne devices stabiel 120fps. React Native heeft met de nieuwe architectuur (JSI, zonder bridge) ook een grote sprong gemaakt. Kotlin Multiplatform groeit hard in enterprises die al native iOS- en Android-teams hebben en business logic willen delen zonder hun UI-stack op te geven: de adoptie ging volgens JetBrains van 7% in 2024 naar 23% in 2025.

Wij hebben geen vaste framework-default. Flutter pakken we wanneer we snelheid op één codebase willen halen en de UI relatief uniform mag zijn over beide platforms. React Native overwegen we wanneer er web-componenten of bestaande JavaScript-expertise hergebruikt kunnen worden, of wanneer een klant al een React-stack op de backend heeft staan. Kotlin Multiplatform houden we actief in de gaten, juist omdat wij al Swift- en Kotlin-mensen in huis hebben en KMP de mogelijkheid biedt om alleen de business logic te delen zonder de native UI op te geven. We zetten het nog niet productief in voor klantprojecten. De iOS-toolchain is nog niet stabiel genoeg voor de garanties die we onze klanten geven, maar voor het juiste volgende project staat het op de kaart.

Eerlijke trade-offs bij native app vs cross-platform

Om het concreet te maken: dit is hoe de twee aanpakken zich naast elkaar verhouden op de factoren die meestal doorslaggevend zijn.

Een paar nuances bij deze tabel. De performance-gap tussen Flutter en native is in 2026 voor een normale business-app verwaarloosbaar. Onafhankelijke benchmarks laten zien dat Flutter met Impeller en Dart’s ahead-of-time compilatie ruim onder de 16ms per frame blijft, wat neerkomt op consistent 60fps of meer (Foresight Mobile benchmarks). Waar native nog duidelijk wint is bij intensief GPU-werk, AR, on-device machine learning en OS-features die net uit zijn.

Wij zien in onze eigen projecten doorgaans 25 tot 30% tijdwinst op de bouw zelf, lager dan de 30 tot 40% die in vakbladen genoemd wordt. Dat verschil zit in QA-tijd: platform-eigenaardigheden lekken altijd door het framework heen en je verliest tijd aan het bijslijpen van iOS-specifieke gestures, Android-back-stack-gedrag en verschillen in toetsenbord-handling. Wie die uren niet meeneemt, claimt een te rooskleurig getal.

Op kosten is het plaatje als volgt: als je voor beide platforms native bouwt, zit je op ongeveer 200% van de inspanning van een platform. Bij cross-platform zit je typisch rond 125%. Dat is geen magie: de eerste 100% gaat in de shared code, de extra 25% gaat in platform-specifieke edge cases, app store-processen en testen op echte devices. Nederlandse collega’s bij AppSpecialisten verwoordden het goed: je bespaart alleen als je het goed aanpakt. Als je de platform-specifieke uitzonderingen uit de hand laat lopen, verdampt je besparing snel.

Onze aanpak: hoe wij samen met de klant kiezen

Wij hebben geen framework-religie. Wij hebben een beslismatrix. Vier vragen die wij in elke intake langsgaan.

Vraag 1: leunt je app op hardware, sensoren of real-time video? Als het antwoord ja is (NFC, BLE, LiDAR, AR, real-time videoconsult, zware camera-verwerking), dan neigen we naar native. Dit is waar we voor Vetts en CLS LED landden.

Vraag 2: is time-to-market kritiek en is de functionaliteit vooral UI en API-gedreven? Als het antwoord ja is, is cross-platform vrijwel altijd de slimste keuze. Voor B2B-bestel-apps en informatie-apps landen we hier vaak.

Vraag 3: heb je al een iOS- of Android-team intern? Als je bestaand native talent hebt, is Kotlin Multiplatform een interessante middenweg: je deelt business logic maar houdt je native UI-teams productief.

Vraag 4: hoe strak is het performance-budget? Bij twijfel testen we een kernscenario op beide aanpakken. Het scheelt misschien een week vooraf, maar voorkomt een jaar later tandengeknars.

Bij Vetts hebben we vanaf het begin native gebouwd. Dagelijks videoconsult door dierenartsen, stabiele camera- en betaalflows over meerdere jaren, dat krijg je niet betrouwbaar voor elkaar zonder de native laag. Twee jaar later staat de app op 4.9 in de App Store. Andersom hebben we klanten weggepraat van native toen het gebruiksprofiel formulieren-en-API-werk was. Dan is Flutter even goed en voelt 30% goedkoper.

Wat wij niet doen: een offerte maken voor het framework dat ons het beste uitkomt. We kiezen met je mee, ook als dat betekent dat we zeggen “dit kan slimmer”. Dat klinkt als een dooddoener, maar het is de reden dat we sinds 2019 met FOCUS werken, sinds 2021 met Met WA en sinds 2016 met Berkleba.

Wat het kost om te bouwen en te onderhouden

Kosten is het onderwerp waar mensen het meeste omfloerste antwoorden op krijgen, dus we zijn hier concreet. Ruwweg:

• Native app voor beide platforms: ongeveer 200% effort vergeleken met een app voor een platform. Je hebt twee codebases, twee test-cycli, twee release-processen.
• Cross-platform (Flutter of React Native): ongeveer 125% effort. De eerste 100% in shared code, de overige 25% in platform-specifieke afwerking.
• Onderhoud: native kost per platform apart onderhoud. Cross-platform heeft een onderhoudsstroom, wel met een extra risico: als het framework een grote update uitrolt (Flutter 3 naar 4, React Native architectuur-migratie), heb je een migratie-traject.

Voor een typische B2B-bestelapp in Flutter bespaar je tegenover een twee-platform native opzet ongeveer 30 tot 40% bouwtijd, vooral omdat de bestelflow op beide platforms identiek mag zijn en het type app geen native-only features vraagt. Onderhoud erbij gerekend wordt het verschil over de jaren nog groter.

Op de totale kostenlevenscyclus (TCO) bespaar je met cross-platform tussen de 30 en 40% volgens branche-cijfers. Bij ons komt dat in grote lijnen uit, met kanttekening: zodra een klant platform-specifieke edge cases erin wil (bijvoorbeeld een Android-only widget), verdampt de besparing sneller dan je denkt. Wees dus scherp op scope.

Wil je een vollediger beeld van wat een app laten maken kost? Wij hebben een uitgebreide pagina met prijsindicaties en een kostencalculator waarmee je een eerste inschatting krijgt.

Een derde optie: progressive web apps

Voor sommige projecten is het antwoord geen van beide. Een progressive web app (PWA) is een webapp die zich gedraagt als een app, installeerbaar op het startscherm, werkt offline, geen app store nodig. Voor Pixowall, een fotocollage-ontwerp-app, was dit de juiste keuze. Geen sensor-afhankelijkheid, wel een flow die op elk device moet draaien zonder dat gebruikers iets hoeven te installeren.

PWA’s passen niet bij alles. Push notificaties op iOS zijn beperkt, diep hardware-gebruik is onmogelijk en app store-aanwezigheid ontbreekt. Maar voor bepaalde e-commerce en content-apps is het een uitstekende derde weg.

Veelgestelde vragen over native app vs cross-platform

Is een native app altijd sneller dan een cross-platform app?

Nee. In 2026 is de performance-gap tussen native en Flutter of React Native voor een normale business-app verwaarloosbaar. Native is nog altijd sneller bij zware GPU-workloads, AR, 3D-gaming en on-device machine learning. Voor een portaal-app, bestelapp of dashboard-app merkt een gebruiker geen verschil.

Wat kost een native app meer dan een Flutter-app?

Voor een app die op iOS en Android moet draaien, kost native bouwen ongeveer 30 tot 40% meer dan een cross-platform-aanpak. Onderhoud is ook duurder, omdat je twee codebases moet bijhouden. Dit geldt over de hele levenscyclus van de app, niet alleen de eerste release.

Kan ik later overstappen van cross-platform naar native?

Ja, maar het is een her-bouw, geen migratie. Als je begonnen bent met Flutter en je wil later naar native iOS plus Android, schrijf je in praktijk opnieuw. Begin dus met de vraag: hoe ziet deze app er over drie jaar uit? Als je ziet aankomen dat je diep native functionaliteit gaat nodig hebben, is het slimmer om daar vanaf dag een op te bouwen.

Welke keuze maken jullie het vaakst?

Dat wisselt per klanttype. Voor apps met zware real-time functionaliteit of diepe sensor-integratie kiezen we meestal native. Voor apps waar het draait om informatie, bestellingen of content kiezen we vaker cross-platform. Onze portfolio is ongeveer 50/50 verdeeld over de twee, en die verhouding hangt sterk af van het type project dat dat jaar binnenkomt. Wij hebben geen voorkeur, we hebben een afweging per project.

Wat is het verschil tussen hybride en cross-platform?

Strikt genomen is hybride een oude term voor apps die in een webview draaien (Ionic, Cordova). Cross-platform verwijst meestal naar moderne frameworks als Flutter en React Native, die native renderen. Mensen gebruiken de termen door elkaar, maar technisch zijn ze niet hetzelfde. Flutter is geen hybride app, maar wel een cross-platform app. Wil je meer weten over de derde optie PWA, kijk dan op onze pagina over progressive web apps.

Twijfel je welke kant jouw maatwerk app op moet? We denken graag mee, liefst met een kop koffie erbij. Stuur een bericht via onze contactpagina en we plannen vrijblijvend een gesprek. Geen framework-evangelie, wel een eerlijk advies op basis van wat jouw gebruikers echt nodig hebben.