Progressive Web App (PWA) vs native app: wat is het verschil?

Wat is een Progressive Web App?

Een Progressive Web App, kortweg PWA, is een webapplicatie die zich gedraagt als een native app. Onder de motorkap is het gewoon HTML, CSS en JavaScript — dezelfde technologieën waarmee elke moderne website wordt gebouwd. Wat een PWA onderscheidt zijn een paar extra lagen waarmee hij dingen kan die voorheen voorbehouden waren aan apps uit de App Store of Play Store: installeerbaar op het beginscherm, werken zonder internet, push-notificaties versturen, full-screen draaien zonder browserbalk eromheen.

De term werd rond 2015 door Google geïntroduceerd om aan te geven dat het web technisch volwassen genoeg was om met native te concurreren — niet op elk vlak, maar voor een groot deel van wat doorsnee apps doen. Een typisch voorbeeld: u opent een webwinkel in Chrome of Safari op uw telefoon. In het menu verschijnt een optie "Aan beginscherm toevoegen". Tikt u die aan, dan komt er een icoon op uw home-screen dat opent in een full-screen venster — geen browserbalk, geen adresregel. Voor de gebruiker voelt het exact zoals een gewone app, terwijl u technisch nog steeds een website draait.

De drie technische pijlers

Een PWA staat op drie pilaren. De Service Worker is een stukje JavaScript dat los van de pagina in de achtergrond meedraait. Hij vangt netwerk-verzoeken op, bewaart pagina's en assets in een lokale cache, en levert ze later opnieuw uit — ook zonder verbinding. Hij is ook het kanaal voor binnenkomende push-notificaties. Het manifest is een JSON-bestandje dat de naam, het icoon, de kleuren en het startscherm van de app beschrijft; het besturingssysteem behandelt de PWA na installatie als een gewone applicatie. En HTTPS is een harde eis: service workers werken simpelweg niet over plain HTTP — een terechte beveiligingsmaatregel gezien de toegang die ze krijgen tot het netwerk-verkeer.

Wat is een native app?

Een native app is een applicatie die specifiek voor één besturingssysteem is gebouwd, in de programmeertaal en met de tools die de fabrikant van dat systeem voorschrijft. Voor iOS betekent dat in de praktijk Swift (of het oudere Objective-C), gebouwd met Xcode en uitgerold via de App Store. Voor Android betekent dat Kotlin (of het oudere Java), gebouwd met Android Studio en uitgerold via de Play Store.

Native apps draaien rechtstreeks op het besturingssysteem, zonder browser ertussen. Ze hebben volledige toegang tot wat het toestel kan: camera, microfoon, GPS, NFC, Bluetooth, biometrische authenticatie (Face ID, Touch ID), de gezondheidsgegevens van HealthKit, betalingen via Apple Pay of Google Pay, contactenlijsten, agenda's. Alles waarvan een gebruiker via systeem-dialogen toestemming moet geven, kan een native app aanroepen zodra die toestemming verleend is.

De distributie verloopt via de officiële stores. Apple keurt elke iOS-app handmatig voordat hij verschijnt; Google doet hetzelfde voor Android, hoewel iets soepeler. Een gebruiker zoekt in de store, leest reviews, ziet sterren en downloadt vervolgens de app. Voor merken met een breed publiek is die App Store-aanwezigheid op zichzelf al een kanaal — een vindbaarheid en vertrouwen-route die op het web anders ligt.

De prijs van die diepte

Tegenover die diepte staat een prijskaartje in ontwikkelinspanning. Een echte native app voor zowel iOS als Android betekent in beginsel twee aparte codebases, in twee aparte talen, gebouwd door specialisten in elk platform. Een feature die u in beide apps wilt aanbieden, moet twee keer worden gebouwd, twee keer getest, twee keer onderhouden. Daarbovenop komt de overhead van het App Store-proces: review-tijden, regelmatige updates om bij te blijven met SDK-eisen, en jaarlijkse developer-account-kosten.

Voor uitgebreidere strategie rond app-ontwikkeling — wanneer een eigen mobiele applicatie loont, hoe het traject loopt en wat er bij komt kijken — verwijzen we naar onze app-ontwikkeling-dienstpagina.

Cross-platform als tussenvorm

Tussen "pure PWA" en "twee aparte native apps" in zit een derde categorie: cross-platform native. Met frameworks als React Native, Flutter of .NET MAUI schrijft u één codebase die compileert naar zowel een iOS- als een Android-app — en die op het toestel zelf gewoon draait als native code, niet als webpagina.

Een React Native-app verschijnt in de App Store, krijgt een eigen icoon en heeft toegang tot dezelfde hardware-API's als pure Swift of Kotlin. Het verschil zit erin dat logica en schermen in JavaScript zijn beschreven, en dat een bridge die instructies vertaalt naar native componenten op het toestel. Voor de meeste organisaties is dit de praktische middenweg: één team, één codebase, App Store-aanwezigheid en native gedrag. Wij behandelen die afweging dieper op onze pagina over React Native-app laten maken.

Vergelijking op zes dimensies

De keuze tussen PWA en native is zelden absoluut. Het ligt aan welke dimensies voor u zwaar wegen. Hieronder zes die in de praktijk doorslaggevend zijn.

1. Offline-mogelijkheden

Op papier kan een PWA prima offline werken: de service worker bewaart pagina's en data lokaal en levert die uit als er geen verbinding is. In de praktijk vraagt dat ontwerp-discipline — welke pagina's worden voorgecached, hoe worden mutaties tijdelijk opgeslagen, en wat toont u wanneer iets niet beschikbaar is.

Een native app heeft meer ingebouwde gereedschappen voor offline-scenario's: een lokale SQLite-database, bestandssysteem-toegang, achtergrond-synchronisatie via OS-services. Voor apps waar offline echt een eerste-klas-scenario is — buitendienst, scheepvaart, magazijnen zonder dekking — kan dat verschil bepalend zijn. Voor een doorsnee app waar offline een nice-to-have is, is de PWA-aanpak ruim voldoende.

2. Push-notificaties

Hier zit historisch het grootste verschil tussen de twee werelden, en het is een verschil dat lang in het nadeel van PWA's bleef. Native apps versturen push-notificaties via de centrale push-services van Apple en Google sinds het allereerste begin. Voor PWA's was dat op Android lange tijd ook al mogelijk, maar op iOS niet — totdat Apple in iOS 16.4 (begin 2023) ook web-push ondersteunde voor PWA's die op het beginscherm waren geïnstalleerd.

Sindsdien is web-push op iPhone en iPad mogelijk, maar wel onder voorwaarden: de PWA moet eerst geïnstalleerd zijn (gewone Safari-tabs krijgen geen push), de gebruiker moet expliciet toestemming geven, en de toegankelijke functionaliteit blijft beperkter dan op Android of in een native app. Voor wie push een centrale plek geeft in zijn product — chat-applicaties, real-time alerts, transactionele bevestigingen — is native vaak nog steeds voorspelbaarder.

3. App Store-distributie

Een native app of een cross-platform native build verschijnt in de App Store en de Play Store. Dat geeft toegang tot een vindbaarheidskanaal, sterren en reviews, en een installatie-flow die voor veel gebruikers vertrouwd voelt. Voor B2C-merken met massa-bereik is die aanwezigheid soms onmisbaar — een merk dat "geen app in de store" heeft, voelt voor sommige doelgroepen onaffer.

Een PWA distribueert u via uw eigen URL. Dat is sneller, vrijer en zonder review-proces, maar mist het sterren-systeem en de natuurlijke vindbaarheid in de stores. Sommige stores accepteren PWA's tegenwoordig wel als wrapper (Microsoft Store doet dit ruimhartig, Google Play via Trusted Web Activities, Apple App Store nog niet), maar dat blijft een aparte stap.

4. Hardware-toegang

Native apps hebben volledige toegang tot wat het toestel aanbiedt: camera met geavanceerde instellingen, biometrische sensors, HealthKit en Google Fit, NFC voor contactloze betalingen of toegangsbewijzen, Bluetooth Low Energy voor wearables en IoT, AR-frameworks voor uitgebreide werkelijkheid. PWA's hebben de afgelopen jaren via web-API's veel terrein gewonnen — Web Bluetooth, Web NFC, WebRTC voor camera-toegang, Web Share — maar de dekking is platform-afhankelijk en op iOS aanzienlijk beperkter dan op Android.

Voor een app die toegang moet hebben tot Apple Pay, HealthKit of een specifieke sensor die niet via web-API's beschikbaar is, valt de keuze automatisch op native of cross-platform native. Voor een app die alleen met de camera een foto wil maken en de locatie uitleest, is een PWA tegenwoordig prima.

5. Performance

De prestatie-kloof tussen PWA's en native apps is sterk gekrompen. Voor de meeste apps — content tonen, formulieren invullen, lijsten doorbladeren, transacties bevestigen — is een goed gebouwde PWA niet of nauwelijks merkbaar trager. Voor zware grafische scenario's, intensieve animaties of complexe interactiepatronen blijven native (en cross-platform native) sneller, omdat ze rechtstreeks praten met de grafische laag van het toestel. Nuance: de eerste keer dat een gebruiker een PWA opent zonder dat de service worker iets heeft kunnen cachen, voelt hij hem als website. Pas na installatie ervaart de gebruiker de "app-feel".

6. Ontwikkelkosten en onderhoud

Hier ligt vaak de doorslag voor mkb en scale-ups. Een PWA is in beginsel één codebase die draait op alles met een moderne browser. Wijzigingen zijn direct voor iedereen beschikbaar — geen review, geen update die uitgerold moet worden, geen oude versies die rondhangen op toestellen. Een native app voor twee platformen vraagt twee builds, twee testbomen, twee release-trajecten. Cross-platform native drukt die kosten terug naar één codebase, maar voegt eigen complexiteit toe: bridging-laag, platform-specifieke uitzonderingen, framework-upgrades. Onderhoud is bij elke vorm doorlopend.

iOS-beperkingen op PWA's

De grootste asterisk in elk PWA-verhaal blijft Apple. Op Android werken PWA's al jarenlang nagenoeg volledig: web-push, achtergrond-sync, installatie-banners die de browser zelf aanbiedt, ruimhartige web-API's voor hardware. Op iOS heeft Apple zich altijd terughoudender opgesteld. Een paar concrete punten:

• Geen automatische install-prompt: waar Android-browsers een banner kunnen tonen, moet een iOS-gebruiker handmatig het deel-menu openen en "Aan beginscherm toevoegen" kiezen. Veel doelgroepen vinden die route nooit zonder hulp.
• Beperkte opslag: iOS legt strakkere quota op aan wat een PWA lokaal mag bewaren, en ruimt opslag van zelden gebruikte PWA's onaangekondigd op.
• Web-push pas vanaf iOS 16.4: push-notificaties op iPhone en iPad zijn er sinds maart 2023, voor PWA's die op het beginscherm geïnstalleerd zijn. Daarvoor was push op iOS jarenlang simpelweg niet mogelijk — een dealbreker voor veel use-cases.
• Geen toegang tot bepaalde sensors: NFC voor lezen, een aantal Bluetooth-profielen, Apple Pay buiten Safari — Apple houdt deze functionaliteit voor native apps gereserveerd.
• Safari als enige rendering-engine: op iOS draait elke browser onder de motorkap op WebKit. Een PWA in Chrome op iPhone is technisch nog steeds een Safari-PWA.

Apple's terughoudendheid is geen technisch ongeluk maar een commerciële afweging. Een goede PWA-ecosfeer maakt de App Store als kanaal minder essentieel, en daarmee de commissie die Apple op store-transacties vraagt. Dat spanningsveld bepaalt voor een groot deel hoe ver de iOS-PWA-ondersteuning gaat.

Wanneer kies je voor een PWA?

Niet elke app hoeft native te zijn. Een PWA komt sterk uit de bus zodra een van de volgende patronen herkenbaar is:

• Content-zware producten: nieuws, magazines, kennisbanken, documentatie-portals. De primaire taak is lezen, navigeren en zoeken — gebieden waar een goed gebouwde PWA niet voor een native app onderdoet.
• Web-first organisaties: u heeft al een sterke website met een team dat ervaring heeft met JavaScript en moderne web-stacks. Een PWA bovenop het bestaande platform is een natuurlijke uitbreiding zonder een tweede team te starten.
• Breed bereik, lage installatiebarrière: u wilt dat iedereen die uw link aanklikt direct iets bruikbaars heeft. Geen drempel naar de App Store, geen installatie verplicht, en als de gebruiker vaker terugkomt biedt u "Aan beginscherm toevoegen" aan.
• Snelle iteratie nodig: u wijzigt regelmatig de UI, voegt features toe en wilt geen weken kwijt zijn aan App Store-review. Een PWA rolt u dezelfde dag uit.
• App Store-restricties willen vermijden: als uw product niet past in de richtlijnen van Apple of Google (sommige categorieën rond financiën, kansspelen, content), of u wilt om commerciële redenen geen commissie afdragen, biedt een PWA een legitieme uitweg.
• Eenvoudige hardware-behoefte: uw product heeft genoeg aan camera, locatie en notificaties, en niet aan diepere hardware-koppelingen.

Een veelvoorkomend grensgeval is het klantportaal. Een geauthenticeerde omgeving waarin een klant zijn dossier inziet, een factuur betaalt of een afspraak verzet, kan vrijwel altijd uitstekend als PWA — installeerbaar voor wie hem dagelijks gebruikt, gewoon bereikbaar via de browser voor wie hem zelden opent. Die specifieke keuze tussen klantportaal-als-app of als responsive-site behandelen we apart in onze gids over klantportaal-app versus responsive website.

Wanneer kies je voor native?

Aan de andere kant zijn er patronen waar native (al dan niet cross-platform) verreweg de sterkste keuze is:

• Dagelijks gebruik met sterke retentie-ambitie: uw app komt op het beginscherm en wordt regelmatig geopend. Het icoon, de push-notificaties en de aanwezigheid in app-switchers zijn op zichzelf marketing-instrumenten.
• Hardware-zware features: AR, geavanceerde camera-controls, HealthKit, NFC-betalingen, biometrische authenticatie als kernfunctionaliteit, intensieve Bluetooth-koppelingen met wearables. Dit zijn gebieden waar native de enige route is, zeker op iOS.
• App Store-aanwezigheid als marketing-kanaal: u verwacht installs uit organische store-zoekopdrachten of investeert in App Store-advertenties. Voor sommige doelgroepen is "niet in de store staan" gelijk aan "niet bestaan".
• Performance-kritisch: games, real-time grafische apps, video-bewerking, audio-productie. Niet de doorsnee bedrijfs-app, maar wel het scenario waar elk frame telt.
• Branding en gevoel: u wilt een merkbeleving die zich onderscheidt van het web. Animaties, gestures, eigen typografie — alles wat het web ook kan, maar in native vaak een tikje verfijnder uitkomt zonder afsluiting.
• Distributie via app-stores als trust-signaal: in zorg, finance of bepaalde B2B-segmenten geeft "we staan in de App Store" een formeel signaal dat een willekeurige URL niet biedt.

Voor wie aan de native kant uitkomt zonder direct twee aparte codebases te willen onderhouden, is React Native vaak het startpunt. Eén JavaScript-codebase, twee platformbuilds, en wanneer een specifieke feature dieper moet kan dat met een platform-stukje aangevuld worden. Voor minder app-zware producten met een sterke web-oorsprong is een PWA opbouwen vanuit een bestaande Single Page Application vaak een logische evolutie — die SPA-architectuur leent zich uitstekend voor het toevoegen van een service worker en een manifest.

Hybride strategieën

De keuze hoeft niet binair te zijn. Een veelvoorkomend patroon: het hele product is bereikbaar via een PWA voor incidentele gebruikers en zoekverkeer, terwijl een native app verschijnt voor de zware dagelijkse gebruiker met features die alleen native werken. Op Android kunt u een PWA bovendien via een Trusted Web Activity in een dunne wrapper publiceren naar de Play Store — onder de motorkap blijft het de PWA, maar de gebruiker downloadt hem als gewone app.

Kosten en onderhoud

Bij een PWA betaalt u in beginsel voor één codebase die op alle moderne browsers en besturingssystemen draait. Het werk zit in feature-bouw, het ontwerpen van offline-gedrag en het opzetten van service worker en manifest. Onderhoud beperkt zich grotendeels tot wat u voor een hoogwaardige website ook doet — moderne JavaScript bijhouden, browser-quirks volgen, af en toe een service-worker-bug debuggen.

Bij twee aparte native apps verdubbelt het bouwwerk vrijwel evenredig: elke feature twee keer, testen op twee platformen, opleveren op twee stores. Cross-platform native zit qua kosten ergens tussen PWA en pure native — één codebase, maar wel platform-specifieke aandacht voor delen die per OS afwijken, plus de App Store-overhead.

Onderhoud is bij elke vorm doorlopend. Apple en Google passen hun platformen jaarlijks aan; oude API's verlopen; iOS- en Android-versies dwingen periodieke upgrades af. Vraag bij elke offerte expliciet naar de overdracht: hoe ziet de codebase eruit, hoe is hij gedocumenteerd, en wat is er nodig om hem in een ander team verder te brengen.

App Store-economie en commissies

Een onderdeel dat in technische vergelijkingen vaak onderbelicht blijft, is het commerciële model van Apple en Google. Beide stores rekenen een commissie op transacties die via in-app-aankopen of abonnementen lopen — historisch 30 procent, voor kleinere ontwikkelaars en jaar-twee-abonnementen verlaagd naar 15 procent. Voor producten die volledig op store-transacties draaien, is dat geen marginale kostenpost maar een structureel deel van het verdienmodel.

Een PWA omzeilt die commissies, omdat transacties via uw eigen web-betalingen lopen — Mollie, Stripe, Adyen of een eigen merchant. Dat is een van de redenen waarom sommige content-, gaming- en nieuwsplatformen actief op PWA inzetten. Daar staat tegenover dat App Store-aanwezigheid op zichzelf een marketing-asset is: het signaal van "geverifieerde uitgever", reviews en zichtbaarheid in zoekopdrachten. Voor B2C-merken met massa-bereik is dat zelden te negeren.

Veelgemaakte fouten in de keuze

• Native kiezen omdat het serieuzer voelt: een content-zware app waar niemand offline iets mee doet, in twee native builds gegoten — dubbele kosten zonder dubbele waarde.
• PWA kiezen en vergeten hem te ontwerpen als app: een mobiele website met "Aan beginscherm toevoegen" eraan geplakt voelt nooit als app. Een echte PWA vraagt app-niveau-aandacht voor navigatie, gebaren, offline-states en notificaties.
• iOS niet vooraf testen: een PWA bouwen die op Android prachtig werkt, en pas bij oplevering ontdekken dat een kritieke functie op iPhone ontbreekt. Toets eerder, niet later.
• App Store-aanwezigheid overschatten: een app in de store zetten betekent niet dat iemand hem vindt. Zonder serieuze App Store Optimization en kanaal-investeringen blijft het icoon onzichtbaar.
• Onderhoud niet meebegroten: de bouw is een eenmalige investering, het onderhoud is doorlopend. Wie alleen de bouw begroot, ontdekt later dat de app niet meer in de winkel staat omdat een SDK verlopen is.
• App en website laten divergeren: data-modellen die uit elkaar lopen, features die op het web wel maar in de app niet bestaan (of omgekeerd). De kanalen horen op dezelfde architectuur te draaien.

Geen van deze fouten is exotisch en ze zijn allemaal vermijdbaar door bij de start de juiste vragen te stellen — over doelgroep, gebruiksfrequentie, hardware-behoefte, distributie-strategie en onderhoudscapaciteit. Voor wie de bredere achtergrond rondom moderne web-technologie wil verkennen, is onze pagina over web-ontwikkeling als dienst een logisch vervolg.

Veelgestelde vragen

Wat is het verschil tussen een PWA en een gewone website?

Een gewone website draait in een browser en stopt zodra u het tabblad sluit. Een PWA is een website met een service worker en een manifest erbij, waardoor hij installeerbaar wordt op het beginscherm, offline kan werken en push-notificaties kan versturen.

Kan een PWA dezelfde dingen als een native app?

Bijna, maar niet helemaal. Op Android nadert de overlap, zeker voor content- en transactie-georiënteerde apps. Op iOS blijven er belangrijke beperkingen — bepaalde hardware-API's, push-scenario's en opslag-quota. Voor functionaliteit die diepe hardware-toegang of expliciete App Store-distributie vraagt, is native nog steeds nodig.

Werkt een PWA op iPhone?

Ja. Safari ondersteunt de bouwstenen al jaren en sinds iOS 16.4 ook web-push (mits de PWA op het beginscherm is geïnstalleerd). De installatie verloopt wel handmatig via het deel-menu, en sommige web-API's die op Android werken blijven op iOS gereserveerd voor native apps.

Kan een PWA in de App Store?

Op Microsoft Store en op Google Play wel, doorgaans via een wrapper-formaat. Op de Apple App Store niet rechtstreeks — daar moet u een (cross-platform) native app uitbrengen om aanwezigheid te realiseren.

Is React Native een PWA?

Nee. React Native bouwt een echte native app die in de App Store en Play Store verschijnt en native UI-componenten gebruikt, geschreven in JavaScript. Een PWA is een website met service worker en manifest. Beide gebruiken JavaScript, maar het zijn andere uitrol-modellen.

Welke vorm kiest u bij twijfel?

Start met een PWA als de doelgroep breed is en de hardware-behoefte beperkt; plan een native of cross-platform-uitbreiding zodra de gebruiksfrequentie dat rechtvaardigt. Andersom werkt minder goed.