kort antwoord
Voor veel zakelijke tools is een webapp die je als PWA op het beginscherm zet genoeg. Kies een app in de App Store en Google Play als je gebruikers vaak terugkomen, meldingen de kern zijn of je diepe telefoonfuncties nodig hebt.
Je hebt een webapp, of je laat er een bouwen, en de vraag komt vanzelf: moet dit ook in de App Store en Google Play? Vaak niet. Een goed gebouwde webapp kun je als PWA op het beginscherm zetten, en voor veel zakelijke tools is dat genoeg. Een echte app in de stores loont pas als je gebruikers dagelijks terugkomen, je betrouwbaar meldingen wilt sturen of je telefoonfuncties diep nodig hebt.
Wat is een PWA eigenlijk?
Een PWA (progressive web app) is een webapp die zich gedraagt als een app. MDN, de documentatie van Mozilla voor webontwikkelaars, omschrijft het als een app die gebouwd is met webtechniek, maar die een gebruikerservaring biedt zoals die van een app voor een specifiek platform. Je gebruiker opent hem in de browser en kan hem daarna op het beginscherm zetten. Vanaf dat moment start hij met een eigen icoon, zonder adresbalk.
Volgens MDN draait een PWA net als een website op verschillende apparaten vanuit één codebase. Codebase is de verzameling broncode waaruit de app bestaat. Eén codebase betekent: je laat één product bouwen en onderhouden, niet drie. Een PWA kan ook offline of op de achtergrond werken en samenwerken met het apparaat, zo schrijft MDN.
Een app in de App Store of Google Play heet een native app. Die installeer je via de store en die is gebouwd voor iPhone en Android. Tegenwoordig hoef je daarvoor niet altijd twee aparte apps te laten bouwen: met frameworks als React Native schrijf je één app die op beide platforms draait.
Weet je nog niet precies wat het verschil is tussen een website en een webapp? Lees dan eerst wat een webapplicatie is en wanneer je er een nodig hebt.
Wanneer is een PWA genoeg?
Een PWA is meestal de verstandige keuze als je webapp vooral achter een bureau of af en toe op de telefoon wordt gebruikt. Denk aan:
- Interne tools voor je eigen team, zoals een planning, een urenregistratie of een voorraadoverzicht.
- Klantportalen waar klanten een paar keer per maand inloggen voor facturen, orders of documenten.
- Dashboards met cijfers en rapporten die je vooral op een groot scherm bekijkt.
- Formulieren en aanvragen die mensen onderweg invullen, zoals een werkbon of een schademelding.
Het grote voordeel: je hoeft niet langs de keuring van Apple en Google. Een verbetering staat live zodra je hem publiceert, voor iedereen tegelijk. Je gebruikers hoeven niets te downloaden en een link in een mail is genoeg om te beginnen. En omdat het gewoon een webadres is, kun je pagina’s delen en kan Google ze vinden als je dat wilt.
Ook meldingen zijn geen harde reden meer om een store-app te kiezen. Apple voegde in iOS en iPadOS 16.4 pushmeldingen toe voor webapps die op het beginscherm staan, schrijft het WebKit-team. Er zitten wel voorwaarden aan: de gebruiker moet de webapp eerst zelf op het beginscherm zetten, en de vraag om toestemming moet volgen op een actie van de gebruiker, zoals een tik op een knop.
Wanneer heb je toch een app in de stores nodig?
Die voorwaarde is in de praktijk precies het probleem. Veel mensen weten niet hoe je een website aan het beginscherm toevoegt, en zonder die stap krijgen ze op een iPhone geen meldingen. Draait je product om meldingen, dan is dat een serieuze drempel.
Een native app is de betere keuze als een of meer van deze punten op jou van toepassing zijn:
- Je gebruikers komen dagelijks of wekelijks terug. Een icoon in de lijst met apps en meldingen houden je product in beeld.
- Meldingen zijn de kern. Bijvoorbeeld: er is een plek vrijgekomen, je bestelling is onderweg, je afspraak is morgen.
- Je doelgroep zoekt in de store. Consumenten zoeken een app vaak eerst in de App Store of Google Play, niet in Google.
- Je hebt telefoonfuncties nodig die op het web beperkt zijn. Denk aan werken op de achtergrond, Bluetooth-apparaten of uitgebreid gebruik van locatie. Wat een browser wel en niet ondersteunt, verschilt per platform en browser. Laat dit per functie checken voordat je kiest.
- Vertrouwen telt. Een app in de store voelt voor veel mensen officiëler dan een webadres.
Daar staat tegenover dat een native app meer vraagt. Apple en Google beoordelen elke nieuwe versie voordat die in de store komt. Je hebt ontwikkelaarsaccounts nodig, je moet voldoen aan de regels van beide stores en je app moet mee met nieuwe versies van iOS en Android. Dat is geen reden om het niet te doen, wel een reden om het bewust te doen.
De verschillen op een rij
| Webapp of PWA | App in de stores | |
|---|---|---|
| Installeren | Niet nodig; optioneel op beginscherm | Via App Store of Google Play |
| Updates | Direct live voor iedereen | Na beoordeling door Apple en Google |
| Meldingen op iPhone | Alleen als de webapp op het beginscherm staat | Ja, na toestemming |
| Vindbaar via Google | Ja, als je dat wilt | Vooral via de store |
| Telefoonfuncties | Veel, maar verschilt per browser | Volledig |
| Onderhoud | Eén product | App plus de webapp of server erachter |
Waarom het vaak allebei wordt
De vraag is in veel gevallen niet of, maar voor wie. Vaak heb je twee soorten gebruikers: mensen die beheren en mensen die gebruiken. De beheerder werkt achter een laptop en wil een groot scherm met overzichten. De eindgebruiker pakt zijn telefoon en wil in twee tikken iets regelen.
Dan werkt een combinatie het best: een webapp voor kantoor en een app voor onderweg, die allebei met dezelfde server en dezelfde gegevens praten. Zo hebben we het ook gedaan bij Rijschema, onze eigen software voor rijscholen. De rijschool plant lessen in een webdashboard, leerlingen boeken zelf in een gratis app voor iPhone en Android. Het dashboard is gebouwd in Next.js, de apps in React Native met Expo. De app staat sinds februari 2026 in de App Store en Google Play, en in oktober 2026 zaten er 624 actieve leerlingen in, met 5.189 boekingen door leerlingen.
Voor leerlingen was een app logisch: ze boeken vaak, ook ’s avonds, en willen een melding krijgen. Voor de rijschool was een app juist niet nodig, want plannen doe je liever op een groot scherm.
Belangrijk bij deze aanpak: bouw de server en de gegevens zo dat er later makkelijk een app bij kan. Dan kun je beginnen met een webapp en de app toevoegen zodra blijkt dat je gebruikers erom vragen. Leg ook vooraf vast van wie de code is, zeker als er meerdere onderdelen zijn. Daarover lees je meer in van wie de broncode is als je een webapp laat bouwen.
Vijf vragen om zelf te beantwoorden
Twijfel je nog? Beantwoord deze vragen eerlijk, voordat je met een bureau om tafel gaat:
- Hoe vaak gebruikt één persoon je product? Dagelijks pleit voor een app, een paar keer per maand voor een webapp.
- Waar gebruiken ze het? Achter een bureau, onderweg of allebei?
- Hoe belangrijk zijn meldingen? Is het leuk om te hebben of draait het product erom?
- Welke telefoonfuncties heb je echt nodig? Maak een lijst en laat per functie checken of het in de browser kan.
- Wie houdt het bij? Een app vraagt releases, store-regels en updates voor nieuwe besturingssystemen. Reken dat mee in je planning en budget.
Komt er bij vraag 1 en 3 een duidelijk ja uit voor een app, dan is de keuze snel gemaakt. Is het overal twijfel, begin dan met een webapp die je later kunt uitbreiden. Wil je sparren over jouw situatie, kijk dan hoe we webapps en apps voor iPhone en Android bouwen.
Veelgestelde vragen
Niet zomaar. Een PWA installeer je meestal vanuit de browser. Wil je echt in de App Store staan, dan heb je in de praktijk een native app nodig, of een app die je webapp verpakt en aan de regels van Apple voldoet.
Ja, sinds iOS 16.4, maar alleen als de gebruiker de webapp eerst aan het beginscherm toevoegt en daarna toestemming geeft. Zonder die stap krijgt een iPhone-gebruiker geen meldingen van je webapp.
Meestal niet meer. Met een framework als React Native bouw je één app die op beide platforms draait. Je publiceert hem wel apart in de App Store en in Google Play.
Ja, als de webapp zo gebouwd is dat andere programma’s met de gegevens kunnen praten. Vraag daar vooraf naar bij je bureau, dan hoef je later niets opnieuw te bouwen.
Meestal wel, omdat er een extra product bij komt dat je moet bouwen, testen, publiceren en bijhouden. Hoeveel duurder hangt af van de functies, dus vraag een offerte waarin web en app los staan.