Tussen 2017 en 2020 ging PWA door een echte tech-hype. Conferenties, blogposts, officiële ondersteuning van Google en Microsoft. Toen kwam de teleurstelling: iOS hield cruciale API's gesloten, installatieprompts bleken verwarrend, de marketing van native apps was nog altijd sterker. De community trok verder naar Flutter, React Native en Capacitor.
Maar in stilte gebeurde er nog iets. De PWA-stack werd steeds volwassener. Apple heeft de afgelopen jaren de ontbrekende API's toegevoegd, browsers hebben de installatieflow verbeterd en de service-workerspecificatie is uitgekristalliseerd. En voor productteams zonder een groot budget is PWA een verrassend sterke optie geworden.
Dit artikel is een eerlijke casestudy van trefa.app — een voorspelpool voor bedrijven, gebouwd als PWA — na een jaar in productie. Wat werkte, wat niet, en aan wie ik PWA tegenwoordig zou aanraden.
Context: wat trefa.app is
Trefa.app is een webapp voor voorspelpools binnen bedrijven. De gebruiker logt in met Google, maakt een competitie aan voor zijn bedrijf, nodigt collega's uit via een link of een QR-code en samen voorspellen ze wedstrijduitslagen. De app synchroniseert gegevens van sport-API's (NHL, Premier League, wereldkampioenschappen) en herberekent de punten in realtime.
De frontend is Next.js 16 + React 19 + Tailwind, gehost op Vercel. De backend is Django 5 + DRF + Channels op Hetzner. Daartussen draaien PostgreSQL op Supabase en Redis voor realtime communicatie.
Een leuk detail: er is geen native iOS- of Android-app. De PWA is de enige client. Gebruikers op iPhone, Android, Windows en macOS gebruiken precies hetzelfde.
Waarom we voor PWA kozen in plaats van native
De beslissing was vooral economisch. Een native app zou het volgende hebben betekend:
- Twee parallelle clients ontwikkelen (iOS Swift + Android Kotlin), of een cross-platformframework (Flutter, React Native).
- Het indieningsproces bij de App Store + Google Play — indieningskosten, vertraging door reviews, periodiek opnieuw publiceren bij wijzigingen in de backend-API.
- Pushmeldingen via APNs en FCM, twee aparte infrastructuren, twee certificeringsprocessen.
- Updateproces via de stores — de gebruiker moet actief updaten, een deel van de gebruikers blijft maandenlang op een oudere versie hangen.
Voor een product met een relatief kleine doelgroep (bedrijfsteams, geen massamarkt) waren de kosten van native ontwikkeling aanzienlijk hoger dan de meerwaarde. PWA nam dit alles in één klap weg.
Technische voordelen die gebruikers nooit zullen merken
Dit is het onderdeel dat ik vóór de productiegang had onderschat. Vanuit het oogpunt van ontwikkeling brengt PWA een aantal concrete voordelen die per jaar weken werk besparen:
Deployen gaat direct. Push naar main → Vercel bouwt → binnen 2 minuten staat de nieuwe versie bij alle gebruikers. Geen indiening, geen wachten, geen gegoochel met compatibiliteit tussen client- en backendversies. Maak ik een breaking API-wijziging, dan kan ik de volgende dag een fix uitrollen en heeft iedereen die meteen.
Eén codebase voor alles. iOS, Android, Windows, macOS, Linux — overal dezelfde app. Geen platformspecifieke bugs ("dit gaat alleen kapot op de iPhone 13 in dark mode"), geen dubbele implementatie.
Korte weg naar de gebruiker. Stuur een link, klik, je zit in de app. Geen "download onze app uit de App Store, registreer je en log dan in". Voor B2B-producten die je weinig gebruikt (een voorspelpool draait alleen tijdens een sporttoernooi) is dit een enorm conversievoordeel.
Pushmeldingen werken ook zonder installatie. De service worker registreert de pushabonnementen. Zodra de gebruiker op "Meldingen toestaan" klikt, ontvangt hij voor de wedstrijden alerts, ongeacht of hij de app aan zijn beginscherm heeft toegevoegd of hem slechts af en toe in Safari opent.
Wat PWA niet kan (het eerlijke verhaal)
Eerlijkheid telt hier zwaarder dan marketing. PWA kent echte beperkingen waar we in productie tegenaan zijn gelopen.
iOS-pushmeldingen hebben een addertje onder het gras. Apple Web Push bestaat sinds iOS 16.4, maar werkt alleen als de gebruiker de PWA aan zijn beginscherm heeft toegevoegd. Gebruikt hij de app via Safari-tabbladen, dan blijft het pushabonnement niet behouden. Dat is wrijving die native apps niet kennen.
Aanwezigheid in de App Store ontbreekt. Voor sommige koperspersona's (HR-afdelingen, enterprise-IT-managers) staat "niet in de App Store" gelijk aan "niet serieus". Subjectief, maar reëel.
Sommige OS-API's zijn niet beschikbaar. Bluetooth Low Energy, NFC, volledige toegang tot het bestandssysteem — voor een doorsnee-app is dat prima, maar heb je deze functies nodig, dan beperkt PWA je.
Offlinemodus is mogelijk, maar niet automatisch. De service worker moet handmatig worden ingericht, cachestrategieën moeten worden ontworpen, synchronisatiewachtrijen geïmplementeerd. Voor een volledig offline-first app is dit meer werk dan ontwikkelaars verwachten.
Performancebenchmark vs. native: PWA is bij de eerste keer laden ~15–25 % trager (het parsen van de JS-bundel) en ~5–10 % bij alledaagse interacties. Voor de meeste apps onmerkbaar, voor hardcore gaming of videobewerking een dealbreaker.
Resultaten na een jaar in productie
Concrete cijfers van trefa.app na een jaar draaien:
- Cross-platformstabiliteit — een ontwikkelteam van één persoon onderhoudt de app op alle besturingssystemen zonder platformspecifieke bugs. Dezelfde testcyclus voor allemaal.
- Deployfrequentie — gemiddeld 3 tot 5 deploys per week via Vercel. Geen ervan kreeg te maken met vertragingen door App Store-indieningen.
- Pushmeldingen — ~70 % van de gebruikers actief, een afleverpercentage van ~95 % op Android en ~85 % op iOS (vanwege de eis om hem op het beginscherm te installeren).
- Geen App Store-kosten — bespaarde ruwweg 70 USD per jaar aan developeraccounts, plus ruwweg 30 % commissie op transacties (die anders bij in-app-aankopen zou gelden).
Het belangrijkste zakelijke voordeel was echter niet technisch. Het was iteratiesnelheid. Als een klant schreef "deze functie zou me helpen", begon ik er meestal diezelfde dag aan en rolde ik hem binnen de week uit. Dat is met een native app gewoonweg niet mogelijk.
Aan wie ik PWA tegenwoordig zou aanraden
PWA past als minstens twee van de volgende punten gelden:
- Je hebt beperkte middelen en kunt geen twee native apps plus een webversie betalen.
- Je gebruikers gebruiken de app af en toe (niet elke dag), waardoor lage drempels bij de eerste keer openen belangrijk zijn.
- Je app heeft geen hardcore OS-API's nodig (Bluetooth, NFC, volledig bestandssysteem).
- Je wilt deployen zonder dat appstores in de weg zitten.
- Je publiek is gemengd — iOS plus Android, mobiel plus desktop.
PWA is waarschijnlijk niet de juiste keuze als:
- Je app dagelijks draait, meerdere uren per dag, en gebruikers hem intensief gebruiken (social media, messaging).
- Je geavanceerde OS-integraties nodig hebt.
- Je kopers aanwezigheid in de App Store verwachten.
- Performance cruciaal is (gaming, video, AR).
Conclusie
De PWA-hype mag dan voorbij zijn, de technologie is stilletjes uitgegroeid tot een punt waarop ze voor veel producten een betere keuze is dan native gaan. Trefa.app draait al een jaar op PWA en ik zie geen reden om dat te veranderen. Integendeel — als ik vandaag opnieuw zou beginnen, zou ik er sneller voor gaan.
Sta je voor de afweging tussen PWA en een native app voor je eigen project, houd dan naast de technische argumenten één ding in gedachten: met PWA bereik je sneller productie. En in de beginfase is iteratiesnelheid waardevoller dan wat dan ook.
Je kunt trouwens trefa.app zelf uitproberen — geen installatie, gewoon één klik en je voorspelt al.