Progressive web apps vs. native apps: hoe maak je de juiste keuze voor jouw product?

Elke keer als we met een opdrachtgever praten over mobile app development, komt de vraag: "Moeten we een native app bouwen of is een progressive web app voldoende?" Het antwoord dat de meeste bureaus geven is een technische verhandeling over rendering engines en API-ondersteuning. Dat is zelden wat je nodig hebt.

Bij Livewall stellen we de vraag anders: wat wil je dat gebruikers doen, hoe vaak doen ze dat, en wat is je budget voor de komende twee jaar? Die drie vragen bepalen de keuze vaker dan welke technische specificatie dan ook.

In dit artikel leggen we uit wat PWAs vandaag wel en niet kunnen, wanneer native echt beter is, en wanneer je geld verspilt door voor native te kiezen terwijl een PWA prima werkt.

Wat een PWA vandaag kan en niet kan

Een progressive web app is een website die zich gedraagt als een app. Je kunt hem toevoegen aan je startscherm, hij werkt offline dankzij service workers, en hij kan pushberichten sturen. Op Android werkt dat inmiddels uitstekend. Op iOS is het verhaal genuanceerder.

Apple heeft PWA-ondersteuning jarenlang bewust beperkt gehouden. Pushberichten via het web werken pas sinds iOS 16.4, en alleen als de gebruiker de PWA aan zijn startscherm heeft toegevoegd. Achtergrondtaken, Bluetooth-toegang en NFC zijn op iOS via een PWA nog steeds niet mogelijk. Cameratogang werkt, maar met beperkingen ten opzichte van native.

Dat betekent niet dat PWAs zwak zijn. Voor de meeste digitale producten, van portalen en ledenplatforms tot interne tools en lichtere consumentenapps, biedt een goed gebouwde PWA alles wat nodig is. De beperkingen zijn relevant als je hardware-integratie nodig hebt of als je doelgroep primair iOS-gebruikers zijn die pushberichten cruciaal vinden voor je retentiemodel.

Wanneer native echt beter is

Er zijn situaties waarbij native de juiste keuze is, zonder discussie.

Hardware-toegang is de grootste. Als je app Bluetooth-verbindingen nodig heeft, diep in cameracontroles duikt, NFC gebruikt of met wearables communiceert, dan heb je native nodig. Een PWA komt daar gewoon niet bij.

App store distributie speelt ook een rol. Als je doelgroep apps ontdekt via de App Store of Google Play, en als jouw categorie sterk leunt op reviews en rankings, dan geeft een vermelding in de store je een bereikvoordeel dat een PWA niet biedt.

Performance-intensieve toepassingen zoals realtime videobewerking, augmented reality of complexe animaties draaien op native aanzienlijk soepeler. De gap wordt kleiner, maar is er nog.

Een goed voorbeeld uit ons eigen werk is Dumpert. Dumpert serveert meer dan 150 miljoen videoweergaven per maand. Een platform op die schaal, met die intensiteit aan mediastreaming, community-interacties en het belang van een snelle, vloeiende videoafspeelervaring, vroeg om een native oplossing. De keuze voor native was geen voorkeur maar een productvereiste.

Wanneer een PWA de betere keuze is

Een PWA wint op een aantal punten die de meeste opdrachtgevers onderschatten.

Budget en snelheid. Eén codebase voor alle platforms. Geen dubbele ontwikkeling voor iOS en Android, geen twee aparte review-processen in de app stores, geen twee afzonderlijke technische schulden om te onderhouden. In onze ervaring scheelt dit bij een gemiddeld product al snel 30 tot 40 procent in initiële bouwkosten.

Snelle iteratie. Bij een PWA deploy je direct naar gebruikers. Geen wachttijd voor app store review. Als je in een vroeg stadium bent en je wil je product snel testen met echte gebruikers, is dit een significant voordeel. Dat sluit ook direct aan op onze werkwijze van rapid prototyping: begin klein, valideer snel, bouw door op wat werkt.

Cross-platform bereik zonder wrijving. Gebruikers hoeven niets te installeren. Ze openen een link en zijn direct in je product. Voor campagne-gerelateerde digitale producten, kortstondige activaties of B2B-tools waar installatie een drempel is, is dat een groot voordeel.

Geen app store-afhankelijkheid. Apple en Google bepalen niet wanneer je update live gaat of of je app aan hun richtlijnen voldoet. Dat geeft vrijheid, zeker als je product regelmatig verandert.

Het AvroTros-voorbeeld: wanneer native echt nodig is

Voor de AvroTros Eurovision voting app was native de juiste keuze, maar om andere redenen dan technische beperkingen. De app moest realtime stemmen verwerken voor 141.000 gebruikers tijdens één van de meest bekeken tv-evenementen van het jaar. App store-aanwezigheid was essentieel: mensen zochten actief naar de app in de store, de rankings werden beïnvloed door mediaberichten, en de geloofwaardigheid van een officiële app store-vermelding paste bij het schaalniveau van het evenement. De app bereikte de #1-positie in de Nederlandse App Store.

Dat is een heel ander scenario dan een B2B-platform of een ledenomgeving. Context bepaalt de keuze, niet de technologie zelf.

Het middengebied: React Native en cross-platform

Tussen een pure PWA en volledig native ligt nog een derde weg: frameworks zoals React Native of Flutter. Je schrijft grotendeels één codebase, maar het resultaat is een echte native app die je in de app stores kunt plaatsen en die toegang heeft tot hardware-API's.

Dit is geen magische oplossing. De performance van React Native zit voor de meeste producten dicht bij native, maar niet bij complexe animaties of zware media. De tooling is volwassen, maar je hebt ontwikkelaars nodig die het framework echt kennen. En je hebt nog steeds twee app store-accounts, twee review-processen en platform-specifieke eigenaardigheid om mee om te gaan.

Voor een MVP die je wil valideren op zowel iOS als Android, zonder het budget van twee native teams, is cross-platform vaak de juiste tussenoplossing. Als het product groeit en de prestaties of de hardware-integratie echt knelt, kun je dan alsnog migreren naar native.

De keuze is nooit definitief. Technologie verandert. PWA-ondersteuning op iOS verbetert. De juiste vraag is: wat heeft dit product nu nodig, en wat heeft het over twee jaar nodig?