Een Progressive Web App (PWA) is een webapp die je via een URL gebruikt en, op ondersteunde apparaten, als app kunt installeren. Offline taken en pushmeldingen zijn mogelijke functies die apart moeten worden ingericht. Het label PWA zegt dus nog niet wat jouw gebruikers ermee kunnen. In deze gids lees je welke afspraken en proeven nodig zijn. De maatwerkwebsitegids geeft de bredere context; app laten maken vergelijkt de ontwikkelroutes.

Wat maakt een webapp een Progressive Web App?

Een PWA blijft een webtoepassing, ook wanneer je hem via een eigen icoon opent. De installatie maakt er geen native app van. Volgens MDN over installeerbaarheid legt een webappmanifest onder meer vast hoe de app wordt gepresenteerd. Een service worker is niet voor iedere installatie vereist.

Dat laatste onderscheid is praktisch. Een klant kan een icoon op zijn telefoon hebben, terwijl de toepassing nog steeds verbinding nodig heeft om een bestelling op te halen. Beoordeel daarom de handeling zelf. Openen zonder internet is iets anders dan gegevens bekijken, veranderen en later correct verzenden.

Wat is het verschil met een website en een native app?

Een responsive website past haar weergave aan het scherm aan. Dat zegt niets over installatie, opslag of meldingen. Die mogelijkheden kunnen aan webtoepassingen worden toegevoegd; de grens tussen een website en PWA is geen harde lijst met verboden en toegestane functies.

Onderwerp Webapp of PWA App voor iOS of Android
Bereiken Via een URL; installatie hangt af van browser en inrichting Via een gekozen distributieroute, bijvoorbeeld een appstore
Zonder verbinding Alleen de taken waarvoor opslag en herstel zijn gebouwd Ook hier moet offline gedrag worden gebouwd
Apparaatfuncties Afhankelijk van web-API’s, browser en toestemming Afhankelijk van platform-API’s, rechten en implementatie
Nieuwe versie Webuitrol, met aandacht voor caches en open sessies Nieuwe uitgave en het bijbehorende updateproces
Toetsing De gebruikte browsers én toestellen De ondersteunde platformen en toestellen

Kies dus niet alleen op “één codebase”. Ook cross-platform apps kunnen code delen. Een platformkeuze moet passen bij distributie, gebruik en onderhoud. Het onderscheid tussen webapp, SaaS en custom platform helpt als die begrippen in offertes door elkaar lopen.

Hoe werken installatie en pushmeldingen op de iPhone?

Sinds iOS en iPadOS 16.4 kunnen ondersteunde browsers van andere makers ook toevoegen aan het beginscherm aanbieden. De oude uitspraak “alleen Safari” klopt dus niet. WebKit beschrijft bovendien webpush voor apps op het beginscherm, waarbij de gebruiker toestemming geeft na een eigen handeling in de app. Zie de uitleg van WebKit.

Maak meldingen daarom geen stille voorwaarde voor een belangrijke taak. Als iemand ze weigert, moet duidelijk blijven waar hij een aanvraag of bericht kan terugvinden. En laat een installatieproef uitvoeren op de toestellen die je doelgroep gebruikt. Een demonstratie in de browser van de ontwikkelaar is daarvoor onvoldoende.

De installatie-ervaring verschilt per browser en besturingssysteem. Google beschrijft die verschillen in zijn PWA-documentatie. Geef gebruikers instructies voor hun eigen apparaat, in plaats van overal dezelfde installatieknop te beloven.

Wat betekent offline werken in de praktijk?

Offline is geen enkele functie. Het kan betekenen dat iemand eerder geladen informatie terugziet, een concept opslaat of een wijziging klaarzet om later te verzenden. Dat zijn verschillende opdrachten met verschillende foutmogelijkheden.

Een service worker kan netwerkverzoeken afhandelen en eerder bewaarde bestanden gebruiken. Maar een cache bevat alleen wat erin is opgeslagen, en een gekozen cachingstrategie bepaalt wanneer oudere of nieuwe gegevens worden getoond. Een formulier openen zegt nog niet dat een server de ingevulde gegevens heeft ontvangen.

Stel je, als hypothetisch voorbeeld, een medewerker voor die op locatie een werkbon invult. Er is tijdelijk geen bereik. De app zou de bon als concept kunnen bewaren en later aanbieden voor verzending. De opdrachtgever moet dan antwoord krijgen op vragen als:

  • Welke bonnen en bijlagen zijn vooraf beschikbaar?
  • Hoe ziet de gebruiker het verschil tussen lokaal opgeslagen en ontvangen?
  • Wat gebeurt er als dezelfde bon op kantoor wordt aangepast?
  • Hoe wordt voorkomen dat opnieuw verzenden een dubbele opdracht maakt?
  • Welke gegevens verdwijnen bij uitloggen op een gedeeld toestel?

Vraag de bouwer deze situaties te demonstreren. Zo toets je bedrijfslogica en herstel, in plaats van alleen het verschijnen van een offline-icoon.

Kan een PWA altijd op de achtergrond synchroniseren?

Nee. Achtergrondtaken worden door de browser beheerd en kunnen aan voorwaarden en tijdslimieten gebonden zijn. MDN over offline en achtergrondtaken beschrijft hoe een synchronisatiepoging opnieuw kan worden gestart en waarom langlopende taken niet zomaar blijven draaien.

Ontwerp een zichtbare uitweg. Als automatische verzending niet lukt, kan de app bijvoorbeeld na opnieuw openen laten zien welke wijzigingen nog wachten. Dat is een ontwerpkeuze die je moet afspreken, geen standaardgarantie van een PWA.

Voor een proces dat continu moet meten of op een exact moment moet reageren, is een haalbaarheidsproef nodig voordat je de webroute kiest. Kijk naar het specifieke toestel en de benodigde functie. Het algemene oordeel “PWA’s kunnen geen hardware gebruiken” is net zo weinig bruikbaar als “native kan alles”.

Krijgt iedereen direct de nieuwste versie?

Een nieuwe webversie uitrollen betekent niet dat iedere geopende app meteen overschakelt. Een nieuwe service worker kan wachten totdat de oude geen vensters meer bedient. Dat updategedrag staat uitgelegd in de documentatie over service workers.

Bespreek daarom wat een gebruiker merkt tijdens een update. Kan hij een lopend formulier afmaken? Hoe worden oude lokale gegevens gelezen door een nieuwe versie? Wie helpt als een toestel een oude weergave blijft tonen?

Snelheid vraagt een eigen controle. Het woord PWA maakt een zware pagina niet licht en is geen voorspelling van conversie. Meet de route die gebruikers werkelijk afleggen; onze uitleg over Core Web Vitals en websitesnelheid geeft daar handvatten voor.

Hoe test je of een PWA geschikt is?

Begin met de risicovolste taak op een representatief apparaat. Je hebt daarvoor geen volledig product nodig, maar wel een proef die het echte gedrag laat zien. Bij een portaal kan het ophalen en wijzigen van gegevens belangrijker zijn dan een fraaie installatieanimatie.

Proef Wat je wilt kunnen beoordelen
Eerste bezoek zonder installatie Kan iemand de kerntaak vinden en starten?
Gebruik na installatie Werken aanmelden, links en terugkeren naar de app?
Verbinding valt weg Blijven invoer en verzendstatus begrijpelijk?
Verbinding komt terug Worden wijzigingen verwerkt zonder onduidelijke dubbelen?
Toestemming geweigerd Is er een bruikbare route zonder meldingen of cameratoegang?
Nieuwe versie tijdens gebruik Blijft onafgemaakt werk behouden?

Leg vast op welke toestellen en browserversies dit is aangetoond. Voeg ook toetsenbordbediening, leesbaarheid en foutmeldingen toe aan de beoordeling. Een geslaagde technische verbinding is nog geen goed bruikbare app.

Wat bepaalt de kosten van een PWA?

De prijs hangt vooral af van de toepassing: accounts, rollen, gegevensverwerking, koppelingen en de taken die je wilt ondersteunen. Installeerbaarheid toevoegen is iets anders dan een bestaand product geschikt maken voor offline wijzigingen met conflictoplossing.

Vraag daarom aparte posten voor de basisapp, offline gedrag, meldingen, compatibiliteitstests en beheer. Vermijd de aanname dat “een PWA-laag” altijd slechts enkele dagen werk is. Laat de leverancier eerst de bestaande applicatie en de gevraagde situaties beoordelen.

Voor een eenvoudige informatiesite is installatie mogelijk geen nuttige toevoeging. Voor terugkerend werk in een portaal kan ze juist prettig zijn. De keuze moet een gebruikersprobleem oplossen, niet alleen een technisch vinkje toevoegen.

Hoe begin je concreet?

Schrijf op wie de app gebruikt, op welke apparaten en wat zonder verbinding beschikbaar moet blijven. Maak onderscheid tussen bekijken, bewerken en verzenden. Kies daarna het scenario dat bij falen de meeste hinder geeft en laat dat eerst toetsen.

Bekijk onze aanpak voor maatwerk websites of plan een gesprek. We helpen bepalen welke webfuncties nuttig zijn en wanneer je een andere ontwikkelroute moet onderzoeken.