Mellan 2017 och 2020 var PWA en teknologisk hype-cykel. Konferenser, blogginlägg, officiellt stöd från både Google och Microsoft. Sedan kom besvikelsen — iOS höll viktiga API:er stängda, installationsuppmaningar visade sig vara förvirrande och marknadsföringen för nativa appar var fortfarande starkare. Communityt rörde sig mot Flutter, React Native och Capacitor.
Men i tystnad hände något annat. PWA-teknologin fortsatte att mogna. Apple har under de senaste åren lagt till de API:er som saknades, webbläsare har förbättrat sitt installationsflöde och specifikationen för service workers har stabiliserats. Och för produktteam utan stor budget har PWA blivit en överraskande stark lösning.
Den här artikeln är en ärlig fallstudie av Trefa.app — en app för företags-tipstävlingar byggd som en PWA — efter ett år i produktion. Vad som fungerade, vad som inte fungerade och vem jag skulle rekommendera PWA till idag.
Kontext: vad är Trefa.app
Trefa.app är en webbapplikation för företags-tipstävlingar. Användaren loggar in via Google, skapar en liga för sitt företag, bjuder in kollegor via en länk eller QR-kod, och alla tippar matchresultat tillsammans. Applikationen synkroniserar data från sport-API:er (NHL, Premier League, världsmästerskapet) och räknar om poäng i realtid.
Frontenden är Next.js 16 + React 19 + Tailwind, hostad på Vercel. Backenden är Django 5 + DRF + Channels på Hetzner. Däremellan PostgreSQL på Supabase och Redis för realtidskommunikation.
En trevlig detalj: det finns ingen nativ iOS- eller Android-app. PWA är den enda klienten. Användare på iPhone, Android, Windows och macOS använder exakt samma sak.
Varför vi valde PWA istället för nativa appar
Beslutet var till stor del ekonomiskt. En nativ app skulle innebära:
- Utveckling av två parallella klienter (iOS Swift + Android Kotlin), eller ett plattformsoberoende ramverk (Flutter, React Native).
- Godkännandeprocessen för App Store + Google Play — registreringsavgifter, fördröjningar i granskningen, periodiska återpubliceringar vid ändringar i backend-API:et.
- Pushnotiser via APNs och FCM, två olika infrastrukturer, två olika certifieringsprocesser.
- Uppdateringsflöde via appbutiker — användaren måste uppdatera aktivt, och en del blir kvar på äldre versioner i månader.
För en produkt med en relativt liten målgrupp (företags-team, inte massmarknad) var kostnaderna för nativ utveckling betydligt högre än fördelarna. PWA tog bort alla dessa punkter på en gång.
Tekniska fördelar som användarna inte märker
Det här är en del som jag skulle ha underskattat före produktionssättningen. Ur ett utvecklingsperspektiv har PWA en rad specifika fördelar som sparar veckor av arbete varje år:
Driftsättningen är omedelbar. Push till main → Vercel bygger → på 2 minuter är den nya versionen ute hos alla användare. Inget godkännande, ingen väntan, inga problem med kompatibla versioner av klient vs. backend. Om jag gör en breaking change i API:et fixar jag det nästa dag och alla får rättelsen direkt.
En kodbas för allt. iOS, Android, Windows, macOS, Linux — samma applikation överallt. Inga plattformsspecifika buggar ("det här kraschar bara på iPhone 13 i mörkt läge"), ingen dubbelimplementering.
Kort väg till användaren. Skicka en länk, de klickar, och de är i applikationen. Inget "ladda ner vår app från App Store, registrera dig och logga sedan in". För B2B-produkter med låg användningsfrekvens (en tipstävling fungerar bara under en sportturnering) är detta en enorm konverteringsfördel.
Pushnotiser fungerar även utan installation. Service workern registrerar en push-subscription. När användaren klickar på "Tillåt notiser" börjar de få påminnelser inför matcher, oavsett om de har lagt till applikationen på hemskärmen eller bara öppnar den då och då i Safari.
Vad PWA inte kan (ärlig sektion)
Här är ärlighet viktigare än marknadsföring. PWA har reella begränsningar som vi stötte på i produktionen.
iOS-pushnotiser har sina särdrag. Apple Web Push finns sedan iOS 16.4, men det fungerar bara om användaren lägger till sin PWA på hemskärmen. Om de använder applikationen via flikar i Safari sparas inte push-subscriptionen. Detta är en friktion som en nativ applikation inte har.
App Store är inte tillgängligt. För vissa köparprofiler (HR-avdelningar, IT-chefer i storföretag) är "den finns inte i App Store" detsamma som "den är inte seriös". Subjektivt, men reellt.
Vissa OS-API:er är otillgängliga. Bluetooth Low Energy, NFC, djup filsystemsåtkomst — för en vanlig applikation spelar det ingen roll, men om du behöver dessa funktioner begränsar PWA dig.
Offline-läge är möjligt, men inte automatiskt. Du måste konfigurera service workern manuellt, tänka ut cache-strategier och implementera synkroniseringsköer. För en helt offline-first-applikation är det mer jobb än vad utvecklare föreställer sig.
Prestandatest vs. nativ: PWA är ca 15–25 % långsammare vid första laddningen (på grund av parsning av JS-bundle) och ca 5–10 % i vanlig interaktion. För de flesta applikationer är skillnaden omärklig, men för hardcore gaming eller videoredigering är det en dealbreaker.
Resultat efter ett år i produktion
Konkreta data från Trefa.app efter ett års drift:
- Plattformsoberoende stabilitet — ett utvecklingsteam på 1 person underhåller applikationen på alla operativsystem utan specifika buggar. Samma testcykel för alla.
- Driftsättningsfrekvens — i genomsnitt 3–5 driftsättningar i veckan via Vercel. Ingen av dem påverkas av fördröjningar i App Store-godkännanden.
- Pushnotiser — aktiva hos ca 70 % av användarna, leveransgrad för pushnotiser ca 95 % på Android, ca 85 % på iOS (tack vare kravet på installation på hemskärmen).
- Inga App Store-avgifter — sparat ca 70 USD per år för utvecklarkonton + ca 30 % i transaktionskommission (som annars skulle riskeras vid köp i appen).
Den största affärsnyttan var i slutändan inte teknisk. Det var iterationshastigheten. Om en kund skrev "den här funktionen skulle vara användbar för mig", påbörjade jag den vanligtvis samma dag och inom en vecka var den i produktion. Det är helt enkelt inte möjligt med en nativ applikation.
Vem jag skulle rekommendera PWA till idag
PWA passar bra om minst två av följande punkter stämmer:
- Du har begränsade resurser och har inte råd med två nativa applikationer plus en webbversion.
- Dina användare använder applikationen då och då (inte varje dag), så låg friktion vid första öppningen är viktigt.
- Din applikation behöver inte avancerade OS-API:er (Bluetooth, NFC, fullt filsystem).
- Du vill driftsätta utan appbutikernas grindvakter.
- Din målgrupp är blandad — iOS och Android, mobil och desktop.
Å andra sidan är PWA troligen inte rätt val om:
- Din applikation körs dagligen, flera timmar om dagen, och användarna använder den intensivt (sociala medier, meddelandeappar).
- Du behöver avancerade OS-integrationer.
- Dina köpare förväntar sig närvaro i App Store.
- Prestanda är kritisk (gaming, video, AR).
Slutsats
PWA-hypen kanske är över, men teknologin har i tystnad vuxit till en punkt där den för många produkter är ett bättre val än nativ utveckling. Trefa.app har körts på PWA i ett år nu och jag ser ingen anledning att ändra på det. Tvärtom — om jag skulle börja om idag, skulle jag göra det ännu snabbare.
Om du överväger mellan PWA och en nativ applikation för ditt projekt, ta en sak i beaktande utöver de tekniska argumenten: PWA tar dig snabbare till produktion. Och i ett tidigt skede är iterationshastigheten mer värdefull än något annat.
Förresten, du kan själv testa trefa.app — ingen installation, bara ett klick och du tippar.