Mellom 2017 og 2020 var PWA i en teknologisk hype-syklus. Konferanser, blogginnlegg, offisiell støtte fra både Google og Microsoft. Så kom skuffelsen — iOS holdt viktige API-er lukket, installasjonsforespørsler viste seg å være forvirrende, og markedsføringen av native apper var fortsatt sterkere. Fellesskapet flyttet seg til Flutter, React Native og Capacitor.
Men i det stille skjedde det noe mer. PWA-teknologien fortsatte å modnes. Apple har de siste årene lagt til de manglende API-ene, nettleserne har forbedret installasjonsflyten, og service worker-spesifikasjonen har stabilisert seg. Og for produktteam uten store budsjetter har PWA blitt en overraskende sterk løsning.
Denne artikkelen er en ærlig case study av Trefa.app — en bedrifts-tippekonkurranse bygget som en PWA — etter ett år i produksjon. Hva som fungerte, hva som ikke fungerte, og hvem jeg ville anbefalt PWA til i dag.
Kontekst: hva er Trefa.app
Trefa.app er en nettapplikasjon for en bedrifts-tippekonkurranse. Brukeren logger inn med Google, oppretter en liga for bedriften sin, inviterer kolleger via en lenke eller QR-kode, og alle tipper kampresultater sammen. Applikasjonen synkroniserer data fra sports-API-er (NHL, Premier League, verdensmesterskapet) og beregner poeng i sanntid.
Frontend er Next.js 16 + React 19 + Tailwind, hostet på Vercel. Backend er Django 5 + DRF + Channels på Hetzner. I mellomtiden PostgreSQL på Supabase og Redis for sanntidskommunikasjon.
En fin detalj: Det finnes ingen native iOS- eller Android-app. PWA-en er den eneste klienten. Brukere på iPhone, Android, Windows og macOS bruker nøyaktig samme løsning.
Hvorfor vi valgte PWA i stedet for native apper
Beslutningen var i stor grad økonomisk. En native app ville betydd:
- Utvikling av to parallelle klienter (iOS Swift + Android Kotlin), eller et rammeverk for flere plattformer (Flutter, React Native).
- Godkjenningsprosess i App Store + Google Play — registreringsavgift, forsinkelser i vurderingen, periodisk ny publisering ved endringer i backend-API-en.
- Push-varsler via APNs og FCM, to ulike infrastrukturer, to ulike sertifiseringsprosesser.
- Oppdateringsflyt via appbutikkene — brukeren må oppdatere aktivt, og en del blir værende på en eldre versjon i flere måneder.
For et produkt med en relativt liten målgruppe (bedriftsteam, ikke massemarked) var kostnadene for native utvikling betydelig høyere enn fordelene. PWA fjernet alle de nevnte punktene på én gang.
Tekniske fordeler som brukerne ikke legger merke til
Dette er en del jeg ville ha undervurdert før produksjonssetting. Fra et utviklingsperspektiv har PWA en rekke konkrete fordeler som sparer uker med arbeid i året:
Distribusjon skjer umiddelbart. Push til main → Vercel bygger → på 2 minutter er den nye versjonen ute hos alle brukere. Ingen godkjenningsprosess, ingen ventetid, ingen kompatibilitetsproblemer mellom klient og backend. Hvis jeg gjør en ødeleggende endring (breaking change) i API-en, fikser jeg den neste dag, og alle får feilrettingen umiddelbart.
Én kodebase for alt. iOS, Android, Windows, macOS, Linux — samme applikasjon overalt. Ingen plattformspesifikke feil («dette krasjer bare på iPhone 13 i mørk modus»), ingen duplisert implementering.
Kort vei til brukeren. Du sender en lenke, de klikker, og de er inne i applikasjonen. Ingen «last ned appen vår fra App Store, registrer deg og logg deretter inn». For B2B-produkter med lav bruksfrekvens (en tippekonkurranse fungerer bare under en sportsturnering) er dette en enorm konverteringsfordel.
Push-varsler fungerer selv uten installasjon. En service worker registrerer push-abonnementet. Når brukeren klikker på «Tillat varsler», begynner de å motta varsler før kampene, uavhengig av om de har lagt til appen på hjemskjermen eller bare åpner den av og til i Safari.
Hva PWA ikke kan gjøre (en ærlig vurdering)
Her er ærlighet viktigere enn markedsføring. PWA har reelle begrensninger som vi har støtt på i produksjon.
iOS push-varsler har sine særegenheter. Apple Web Push har eksistert siden iOS 16.4, men fungerer bare hvis brukeren legger til PWA-en på hjemskjermen. Hvis de bruker applikasjonen via Safari-faner, blir ikke push-abonnementet lagret. Dette er en friksjon som en native app ikke har.
App Store er ikke tilgjengelig. For noen kjøperprofiler (HR-avdelinger, IT-ledere i selskaper) er «vi har den ikke i App Store» det samme som «dette er ikke seriøst». Subjektivt, men reelt.
Enkelte OS-API-er er utilgjengelige. Bluetooth Low Energy, NFC, dyp tilgang til filsystemet — for en vanlig applikasjon spiller ikke dette noen rolle, men hvis du trenger disse funksjonene, vil en PWA begrense deg.
Frakoblet modus (offline) er mulig, men ikke automatisk. Du må konfigurere en service worker manuelt, utforme hurtigbufferstrategier og implementere synkroniseringskøer. For en applikasjon som skal være helt «offline-first», er det mer arbeid enn utviklere ser for seg.
Ytelsestest vs. native: En PWA er omtrent 15–25 % tregere ved første innlasting (på grunn av parsing av JS-pakker) og 5–10 % tregere ved vanlig interaksjon. For de fleste applikasjoner er dette en umerkelig forskjell, men for hardcore spilling eller videoredigering er det en dealbreaker.
Resultater etter ett år i produksjon
Konkrete data fra Trefa.app etter ett års drift:
- Stabilitet på tvers av plattformer — et utviklingsteam på 1 person vedlikeholder applikasjonen på alle operativsystemer uten spesifikke feil. Samme testsyklus for alle.
- Distribusjonsfrekvens — i gjennomsnitt 3–5 distribusjoner i uken via Vercel. Ingen av dem påvirkes av forsinkelser med godkjenning i App Store.
- Push-varsler — rundt 70 % aktive brukere, leveringsgrad for push på ~95 % på Android, ~85 % på iOS (takket være kravet om installasjon på hjemskjermen).
- Ingen gebyrer til App Store — spart rundt 70 USD årlig på utviklerkontoer + ca. 30 % provisjon på transaksjoner (som ellers ville vært en risiko ved kjøp i appen).
Den største forretningsfordelen var til syvende og sist ikke teknisk. Det var iterasjonshastigheten. Hvis en kunde skrev «jeg skulle gjerne hatt denne funksjonen», startet jeg vanligvis på den samme dag, og innen en uke var den i produksjon. Det er rett og slett ikke mulig med en native app.
Hvem jeg ville anbefalt PWA til i dag
PWA passer godt hvis minst to av følgende punkter stemmer:
- Du har begrensede ressurser og har ikke råd til to native apper i tillegg til en nettversjon.
- Brukerne dine bruker appen av og til (ikke hver dag), så lav friksjon ved første åpning er viktig.
- Applikasjonen din trenger ikke avanserte OS-API-er (Bluetooth, NFC, full tilgang til filsystemet).
- Du ønsker å distribuere uten å gå veien om appbutikker.
- Målgruppen din er blandet — både iOS og Android, mobil og desktop.
Motsatt vil PWA sannsynligvis ikke være det riktige valget hvis:
- Appen din kjører daglig, flere timer om dagen, og brukerne bruker den intensivt (sosiale medier, meldinger).
- Du trenger avanserte OS-integrasjoner.
- Kjøperne dine forventer tilstedeværelse i App Store.
- Ytelsen er kritisk (spill, video, AR).
Konklusjon
PWA-hypen er kanskje over, men teknologien har i det stille modnet til et punkt der den for mange produkter er et bedre valg enn native utvikling. Trefa.app har vært basert på PWA i et år nå, og jeg ser ingen grunn til å endre på det. Tvert imot — om jeg skulle startet på nytt i dag, ville jeg ha gått for det enda raskere.
Hvis du vurderer PWA eller en native app for prosjektet ditt, bør du ta én ting med i beregningen utover de tekniske argumentene: PWA sender deg raskere ut i produksjon. Og i en tidlig fase er iterasjonshastighet mer verdifullt enn noe annet.
Forresten kan du teste Trefa.app selv — ingen installasjon, bare klikk og tipp.