Een PWA, of progressive web app, is een webapplicatie die zich gedraagt als een app op je gsm. Je opent ze in de browser, maar je kan ze ook op je startscherm zetten, en ze werkt zelfs zonder verbinding. Een native app daarentegen bouw je specifiek voor iOS of Android en verdeel je via de App Store en Google Play. Welke van de twee past, hangt af van wat je app moet doen en wie ze gebruikt. In dit artikel zetten we de verschillen naast elkaar.
Wat een PWA precies is
Technisch is een PWA een website met twee extra onderdelen. Een manifest vertelt het toestel hoe de app heet, welk icoon ze krijgt en hoe ze opent. Een service worker is een stukje code dat bestanden en gegevens bewaart, zodat de app ook offline werkt. Meer technische uitleg vind je in de documentatie van MDN.
Voor de gebruiker voelt het als een gewone app. Ze staat met een eigen icoon op het startscherm, opent zonder adresbalk en kan meldingen sturen. Sinds iOS 16.4 kan dat ook op een iPhone, op voorwaarde dat de gebruiker de webapp eerst aan het startscherm toevoegt.
Installeren gaat bij een PWA wel anders dan bij een gewone app. Op Android stelt de browser het vaak zelf voor, terwijl je op een iPhone via het deelmenu kiest voor Zet op beginscherm. Leg dat dus kort uit aan je gebruikers, bijvoorbeeld met een instructie bij de eerste keer openen.
Waarom een webapp vaak volstaat
- Eén codebasis: dezelfde app werkt op iPhone, Android en de computer.
- Geen app store nodig: je deelt een link, en een update staat meteen bij iedereen klaar.
- Vindbaar: de inhoud kan in Google verschijnen, net als een website.
- Lagere drempel: gebruikers hoeven niets te installeren om te starten.
Daardoor is een PWA vaak de logische keuze voor interne tools, klantenportalen en apps die vooral gegevens tonen of formulieren verwerken. Denk aan een app waarmee technici werkbonnen invullen, of een klantenportaal waar klanten hun bestellingen opvolgen. Ook de kosten blijven zo beperkter, omdat je maar één versie onderhoudt.
Wanneer een native app beter past
Een native app heeft volledige toegang tot het toestel. Sommige functies, zoals Bluetooth, NFC of taken die lang op de achtergrond lopen, zijn in de browser beperkt of op een iPhone niet beschikbaar. Ook zware grafische toepassingen, zoals spelletjes of uitgebreide fotobewerking, lopen meestal vlotter als native app. Bovendien verwachten sommige doelgroepen je app gewoon in de App Store of Google Play terug te vinden.
Daartegenover staan wel extra stappen. Elke versie moet langs de controle van Apple en Google, en die regels veranderen geregeld. Ook de kosten liggen meestal hoger, omdat je twee platformen bouwt en test, tenzij je met een gedeelde codebasis werkt. De richtlijnen van Apple lees je in de App Store Review Guidelines. Verder installeert niet elke gebruiker een update meteen, dus moet je server soms oudere versies blijven ondersteunen.
Native app of PWA: zo maak je de keuze
Stel jezelf eerst deze vragen:
- Welke toestelfuncties heeft de app echt nodig, zoals camera, locatie, Bluetooth of meldingen?
- Gebruiken vooral je eigen medewerkers de app, of ook het brede publiek?
- Moet de app werken waar geen bereik is, bijvoorbeeld op een werf of in een magazijn?
- Hoe vaak verandert de inhoud of de werking?
- Is een vermelding in de app stores belangrijk voor je merk?
Volstaan camera, locatie en meldingen, dan is een PWA meestal genoeg. Heb je diepe toegang tot de hardware nodig, of wil je per se in de stores staan, dan kies je beter native. Ook een tussenvorm bestaat: één codebasis die zowel als webapp als in de stores verschijnt. Zo kan een PWA later nog uitgroeien tot een app in de stores.
Offline werken vraagt in beide gevallen planning. Wat gebeurt er als een technicus een werkbon invult zonder bereik, en een collega dezelfde bon intussen aanpast? Een goede app bewaart de wijziging lokaal en synchroniseert zodra er weer verbinding is, met duidelijke regels voor conflicten. Dat ontwerpen we vooraf, samen met de mensen die de app dagelijks gebruiken.
Welke keuze je ook maakt: begin bij een stevige basis
Een goede app begint bij dezelfde basis als elke webapplicatie: een duidelijke structuur, een veilige API en een ontwerp dat op een klein scherm werkt. Bij in2sites bouwen we de achterkant vaak in Laravel, met een API die later ook een native app kan bedienen. Zo hoef je niet opnieuw te beginnen als je na een PWA toch voor een native app kiest.
Lees op de pagina over een app laten maken hoe we zo’n traject aanpakken, of bekijk onze werkwijze.
