Written by:
Last Published:
6 augusti 2026
•
En progressiv webbapplikation (PWA) är en webbapplikation som använder modern webbläsarfunktionalitet, främst service workers och ett webbapp-manifest, för att fungera som en installerad inbyggd app. Du klickar på en länk, och det som öppnas ser ut som en app, fungerar offline och hamnar på din hemskärm efteråt, utan att du någonsin har besökt en appbutik eller godkänt en installation. Se en inbyggd app som en butik som kräver att du fyller i ett medlemsformulär vid dörren. En PWA är samma butik med dörren redan öppen.
Men det är inte alltid rätt val. Apples stöd för installerade webbappar ligger efter Googles, hårdvaruåtkomsten är mer begränsad än för inbyggda appar, och ingen av appbutikerna listar PWA:er som standard. Frågan är alltså inte om PWA:er fungerar, utan när en sådan är rätt för din verksamhet, vilket är vad resten av detta går igenom: vad en PWA gör, vad den kostar, var begränsningarna går och hur du fattar beslutet.
Webbplattformens syn på vad en PWA är, och standarderna bakom den, dokumenteras av MDN Web Docs och Googles web.dev PWA learning path.
Mobilappar är viktiga eftersom de gör det möjligt att skapa något som är smidigare och mer personligt än vad en webbsida vanligtvis kan erbjuda. Det finns tre huvudsakliga sätt att bygga en app på.
Inbyggda appar (native apps) är byggda för en specifik plattform. De körs i plattformens eget språk, iOS i Swift och Android i Kotlin, och de har tillgång till alla funktioner på plattformen. Två plattformar innebär två kodbaser.
Hybridappar kombinerar inbyggd kod med webbkod, så en kodbas levereras till flera plattformar inuti ett inbyggt skal. Beroende på ramverk och tillgängliga insticksprogram kan hybridappar ibland inte nå alla plattformsspecifika funktioner, så kontrollera att push-notiser och hårdvaruåtkomst som GPS eller kamera stämmer överens med dina krav innan du bestämmer dig.
Progressiva webbappar (PWA) är webbplatser byggda med modern webbteknik som användare kan installera på hemskärmen och använda offline. De är inte lika kraftfulla som inbyggda appar. De erbjuder dock många av samma fördelar från en och samma kodbas och distributionskedja.
Läs mer om Inbyggd app vs hybridapp vs PWA: för- och nackdelar. Om du vill ha en bredare överblick först, så täcker vår ultimata guide till utveckling av webbappar grunderna som den här artikeln bygger vidare på.
En webbapplikation är mjukvara som du når via en webbläsare som Chrome, Safari eller Firefox. Webbapplikationer tar allt mer mark från traditionell skrivbordsprogramvara av tre enkla skäl: de kräver ingen installation, de uppdateras centralt och de fungerar överallt där det finns en webbläsare.
En progressiv webbapplikation tar detta ett steg längre. Den använder webbläsar-API:er för att bibehålla en fungerande användarupplevelse även när anslutningen är långsam eller helt borta, och den anpassar sig efter enheten den körs på istället för att förutsätta en snabb telefon på ett snabbt nätverk. En enda version fungerar på alla plattformar, så du behöver inte underhålla olika kodbaser för olika operativsystem.
PWA:er lånar även funktioner från mobilappar: push-notiser där plattformen tillåter det, offline-funktionalitet och möjligheten att installera appen på hemskärmen. Och eftersom appen levereras via webben istället för att laddas ner, får användarna alltid den senaste versionen så fort de öppnar den. Inga uppdateringar i appbutiker att godkänna, och ingen utdragen process där användare kör gamla versioner.
I grunden består en PWA av HTML, CSS och JavaScript, vilket innebär att den drar nytta av hela webbens ekosystem: bibliotek, verktyg, kompetensförsörjning och en driftsättningsprocess som ditt team redan använder. Det är den praktiska anledningen till att en PWA kommer ut snabbare än motsvarande inbyggda appar. Det är ingen magi. Det är infrastruktur du redan har.
Ribban sätts dock av inbyggda appar. Så vad krävs egentligen för att skapa en bra PWA?
Det är sex saker som skiljer en PWA från en mobilanpassad webbplats, och var och en av dem är ett aktivt val snarare än en inställning.
Minimikraven för installerbarhet, ett HTTPS-ursprung och ett giltigt manifest, beskrivs i MDN:s Göra PWA:er installerbara guide. Stöd för service workers i olika webbläsare följs upp på caniuse.
Mindre än du tror. Tre av kraven är tekniska, två handlar om bedömning.
HTTPS, eftersom serviceworkers kräver det. Din webbplats måste köras över HTTPS. Det skyddar användardata under överföring, och webbläsare registrerar inte en serviceworker på en osäker källa, så utan det finns ingen PWA. Det är inte förhandlingsbart.
En serviceworker, för offline-läge och cachning. En serviceworker är ett bakgrundsskript som webbläsaren kör separat från din sida. Den möjliggör användning offline, cachar resurser och data, hanterar bakgrundsaktiviteter och kan slutföra arbete även när din PWA inte är öppen, vilket är det som gör push-notiser och bakgrundssynkronisering möjliga.
Ett webbapp-manifest. Denna JSON-fil talar om för webbläsaren hur din PWA ska se ut och bete sig när den är installerad: namn, kortnamn, beskrivning, ikoner, tema- och bakgrundsfärger, visningsläge och start-URL. Det är det som förvandlar en flik till en app. MDN har en fullständig referens för manifestmedlemmar, och web.dev har en praktisk genomgång av webbapp-manifest.
Ramverk och verktyg. Alla moderna JavaScript-ramverk fungerar, och de flesta har nu en dokumenterad väg för PWA: React, Angular, Vue, Svelte och ramverk som Next.js, Nuxt och SvelteKit. För själva serviceworkern väljer de flesta team Workbox istället för att skriva cachningsstrategier för hand. Äldre vägledning som nämner AngularJS eller Polymer är föråldrad och båda är pensionerade, så se alla guider som fortfarande rekommenderar dem som en varningsflagga för resten av innehållet.
En första laddning värd namnet. Den första skärmen är vad användarna bedömer dig utifrån, så mät den istället för att gissa. Lighthouse, Googles granskningsverktyg med öppen källkod, rapporterar om prestanda, tillgänglighet, SEO och installerbarhet, och det körs i Chrome DevTools mot valfri URL.
En brasklapp innan vi går in på siffrorna, eftersom den påverkar hur mycket de väger. Varje resultat nedan kommer från företagens egna tekniska rapporter, samlade i web.devs bibliotek för fallstudier, och de flesta publicerades omkring 2016 och 2017.
Det var en period då PWA-tekniken var ny och de mobilsajter de ersatte ofta var bristfälliga. Se dem därför som bevis på att metoden kan löna sig, inte som en prognos för din egen utveckling. Googles sammanfattning av vad användare förväntar sig av en mobil upplevelse kommer från samma samling: FIRE-akronymen – fast (snabb), installable (installerbar), reliable (pålitlig) och engaging (engagerande).
Affärsframgång ser olika ut beroende på vad du säljer, så välj det mätetal som passar din affärsmodell. Tid på webbplatsen, avvisningsfrekvens, konverteringsgrad eller återkommande besökare. Och eftersom en PWA kan levereras stegvis kan du lansera de funktioner som ger mest värde först och lägga till resten efter hand.
Pinterest byggde om sin mobila webbupplevelse till en PWA för att stödja sin internationella tillväxt. Endast 1 % av mobilanvändarna konverterade till registreringar, inloggningar eller appinstallationer, och dålig mobilprestanda var orsaken, så teamet började om från början.
Ombyggnaden gav tre resultat, enligt Pinterests egna tekniska rapport: tiden på den mobila webben ökade med 40 % jämfört med den tidigare versionen, kärninteraktioner ökade med 60 % och intäkterna från annonser som visas i användargenererat innehåll – vilket är hur Pinterest tjänar pengar på flödet – steg med 44 %.
Med över 80 % av sina användare på mobilen ville Twitter ha en mobil webbupplevelse som var snabbare, mer pålitlig och datasnål. Twitter Lite blev standardupplevelsen för alla användare globalt, byggd kring omedelbar laddning, engagemang och datareducering.
Twitters tekniska team rapporterade 65 % fler sidvisningar per session, 75 % fler skickade tweets och 20 % färre avvisningar. Twitter Lite laddades på under tre sekunder, även vid långsamma anslutningar.
Uber byggde om sin webbapp som en PWA för att erbjuda en bokningsupplevelse i klass med den inbyggda appen när företaget expanderade till nya marknader. PWA-lösningen gör att bokningar fungerar på 2G-nätverk och körs i alla moderna webbläsare, vilket når användare med enklare enheter som inte kan köra Ubers inbyggda app alls.
Enligt Ubers tekniska rapport blev resultatet en lättviktig webbapp som laddas på tre sekunder via 2G, oavsett plats, nätverkshastighet eller enhet.
Starbucks byggde en PWA av sitt beställningssystem för att matcha upplevelsen i sin inbyggda app. Kunderna kan bläddra i menyn, anpassa beställningar och lägga till varor i varukorgen utan en stabil anslutning, för att sedan se platsspecifika priser och slutföra beställningen när de är online igen.
Eftersom så mycket fungerar offline passar den kunder som rör sig in och ut ur täckning under dagen. Appen är under 0,15 MB, och Starbucks rapporterade att de sedan lanseringen har fördubblat antalet dagliga aktiva användare, där beställningar från datorer närmar sig samma nivå som från mobila webbläsare.
Trivago, en av de största hotellsökmotorerna, investerade i en PWA för en stabilare mobil upplevelse. Teamet prioriterade offlineåtkomst, push-notiser och möjligheten att lägga till på hemskärmen, då de bedömde att detta var mest värdefullt för deras användare.
Trivagos rapporterade siffror: antalet gånger användare lagt till appen på hemskärmen ökade med 150 %, och de såg en ökning på 97 % i klick utåt – de klick som skickar användaren vidare till ett hotells eget erbjudande och genererar intäkter för Trivago. Användare som tappar anslutningen kan fortsätta surfa, och 67 % gör precis det när de är online igen.
De ursprungliga siffrorna för dessa fem fall kommer från respektive företags tekniska rapporter, samlade i Googles web.devs fallstudiebibliotek. Betrakta dem som historiska dokument snarare än aktuella riktmärken.
Om vi skalar bort marknadsföringspratet återstår tre fördelar som gör grovjobbet.
En kodbas, flera plattformar. En PWA körs på alla webbenheter och webbläsare, vilket innebär att du bygger och underhåller en enda lösning istället för en webbapp, en iOS-app och en Android-app. Det är här besparingen ligger, och den växer över tid: varje funktion, varje rättning och varje säkerhetsuppdatering behöver bara skickas ut en gång.
App-funktionalitet utan hinder. Offlineåtkomst, push-notiser där plattformen har stöd för det, låg dataförbrukning och installation på hemskärmen är numera tillgängligt för webbappar. Twitter Lites 20-procentiga minskning av avvisningsfrekvensen och Trivagos 150-procentiga ökning av installationer är samma fördel mätt på två olika sätt. Personer som aldrig skulle ha fyllt i ett medlemsformulär väljer ändå att lägga till butiken på sin hemskärm.
Snabbare att lansera, billigare att drifta. Webb-API:er och befintliga verktyg gör att ett team kan lansera en kundtjänst utan att behöva bygga separata mobil- och skrivbordsapplikationer, och det finns bara en distributionsväg istället för två olika granskningsköer i appbutiker. Underhållet blir enklare av samma anledning: färre kodbaser, färre pipelines och ingen versionsfragmentering bland användare som aldrig uppdaterat sin app.
Ett förbehåll gäller för alla tre punkter. En PWA passar när dina krav ryms inom vad webbläsaren kan hantera, och när de inte gör det kan inget av ovanstående rädda situationen.
Engagemangssiffrorna ovan är den enkla delen av affärsnyttan. De kommande fyra frågorna utgör resten, och det är dessa som är värda att ta med i beslutsunderlaget.
Utvecklingskostnad. Det ärligt svar är ett intervall, inte en fast summa, och det beror mer på omfattningen än på tekniken. Den strukturella poängen är enkel: en PWA består av en kodbas medan inbyggda appar kräver två. Du jämför alltså ett bygge mot två, utöver det design- och backend-arbete som tillkommer oavsett val. Ta fram en omfattningsbaserad uppskattning innan du planerar utifrån en siffra.
Tid till första lansering. En PWA blir tillgänglig så fort du driftsätter den. Ingen inlämning till appbutiker, ingen granskningskö – vilket eliminerar både väntetiden före lansering och fördröjningen vid varje efterföljande uppdatering. För ett team som levererar uppdateringar varje vecka är detta ofta det avgörande argumentet.
Underhåll. En kodbas, en pipeline, en version ute hos användarna. Inbyggda appar innebär två kodbaser som följer två olika operativsystem med egna lanseringscykler, plus en lång svans av användare med gamla versioner som du fortfarande måste stödja. En PWA är dock inte underhållsfri: webbläsarstöd förändras och cachningslogik behöver ses över i takt med att appen utvecklas.
Risk, först gällande plattformen. Apples stöd för installerade webbappar har historiskt legat efter Googles och har tidigare varit instabilt: i början av 2024 tog Apple kortvarigt bort webbappar på hemskärmen för EU-användare för att följa Digital Markets Act, men backade inom några veckor efter stark kritik. Den episoden är utagerad nu, och utvecklingen har sedan dess gått stadigt framåt. Push-notiser har fungerat på installerade PWA:er sedan iOS 16.4, och från och med iOS 26 öppnas alla webbplatser som läggs till på hemskärmen som webbappar som standard, vilket tar bort ett steg som användare tidigare behövde känna till. Det som inte har förändrats är de mer avancerade funktionerna. Tillgång till hårdvara och operativsystem är fortfarande mer begränsad än för inbyggda appar, så Bluetooth, bakgrundssynkronisering, djup OS-integrering och vissa sensorer kan helt enkelt vara utom räckhåll, och iOS kan rensa en PWA:s cachade data efter lång tids inaktivitet. Om en stor del av dina användare använder iOS bör du testa dina kritiska funktioner i den aktuella versionen av Safari innan du fattar ett beslut.
Risk, sedan gällande distribution och exit. Ingen av appbutikerna listar en PWA som standard, så om närvaro i butik är en del av din förvärvsstrategi behöver du en separat väg dit. Och om du senare upptäcker att du trots allt behöver en inbyggd app, finansierar du ett andra bygge istället för att bygga vidare på det första.
Apple dokumenterar den nuvarande statusen för webbappar på hemskärmen i EU i sin DMA och appar i EU frågor och svar för utvecklare, och introduktionen av webb-push för iOS beskrivs på WebKit-bloggen.
Vi ställer samma fyra frågor i alla projekt där en PWA är aktuell. De löser de flesta av dessa beslut under ett enda samtal.
Varifrån kommer dina användare? Om det är via sökningar, annonser eller en delad länk håller en PWA hela resan på webben utan att något behöver installeras. Om de kommer via appbutikerna försvinner det argumentet.
Vad behöver appen från enheten? Lista de hårdvaru- och OS-funktioner du inte kan vara utan, och kontrollera sedan var och en mot webbläsarstödet på de plattformar dina användare faktiskt använder. En enda oundviklig brist avgör saken direkt.
Vad måste fungera offline? "Fungerar offline" täcker allt från att visa cachat innehåll till att köa transaktioner för senare utförande. Ju mer avancerade kraven är, desto mer av utvecklingen går åt till service workern.
Vad händer om 18 månader? Om din roadmap pekar mot funktioner som bara kan levereras via native, kan det fortfarande vara rätt att bygga en PWA först, så länge du är medveten om att du väljer att betala för båda istället för att upptäcka det senare. Ibland är native helt enkelt det ärliga svaret från dag ett. När vi byggde Jinga Life, en digital plattform för familjehälsa, pekade kraven mot iOS från start, så det var vad vi byggde istället för att tvinga en webbapp att utföra ett jobb den inte var lämpad för. Syftet med de fyra frågorna är inte att övertala dig till en PWA. Det är att visa dig vilken av de två du faktiskt behöver.
Besvara de fyra frågorna så brukar valet ge sig självt. I de fall det verkligen inte gör det är den delade vägen legitim: lansera en PWA, lär dig av den faktiska användningen och gå över till native senare för de delar som kräver det.
Det är tre saker som skiljer en PWA som håller måttet från en som bara fungerar vid skrivbordet.
Ja, och bättre än vad ryktet gör gällande. Safari har stöd för service workers, offline-cachelagring och ”lägg till på hemskärmen”, så kärnan i en PWA fungerar på iPhone och iPad. Push-notiser har funnits tillgängliga för installerade PWA:er sedan iOS 16.4, och från och med iOS 17 öppnas en webbplats som sparats på hemskärmen som en egen app som standard, istället för som en webbläsargenväg.
Begränsningarna handlar om djup, inte om huruvida de körs eller ej. Det finns fortfarande ingen automatisk installationsfråga på iOS på samma sätt som på Android, så användaren måste trycka på Dela och sedan på Lägg till på hemskärmen. Det är värt att designa en uppmaning för detta istället för att anta att folk hittar funktionen själva. Push-notiser aktiveras bara när appen är installerad och tillstånd har getts, så de kan inte återaktivera någon som aldrig installerat appen. Dessutom saknas eller är bakgrundssynkronisering, det mesta inom Bluetooth och sensorer samt persistent storskalig lagring opålitliga. Om en betydande del av dina användare använder iOS bör du testa dina specifika måste-funktioner i den aktuella versionen av Safari innan du planerar utifrån dem. Apples utvecklar-Q&A om EU-appar är rätt ställe att bekräfta den senaste statusen på.
Skillnaden ligger i antalet kodbaser, inte i tekniken. En PWA är ett bygge som betjänar alla plattformar, medan motsvarigheten för inbyggda appar innebär en iOS-app och en Android-app, var och en med sin egen lanseringscykel och sitt eget underhåll. Design och backend-arbete kostar ungefär lika mycket oavsett vilket. Be om en avgränsad uppskattning baserad på din egen funktionslista istället för att utgå från ett publicerat genomsnitt.
Inte som standard. En PWA distribueras via webben, så användare hittar den genom sökningar, länkar eller annonser snarare än genom att bläddra i en butik. Om närvaro i butik är viktigt för dig kan du paketera appen för publicering: på Android via en Trusted Web Activity, Googles mekanism för att leverera en PWA inuti ett tunt inbyggt paket, och på iOS via en inbyggd wrapper – en minimal inbyggd app vars enda uppgift är att visa din webbapp. Båda vägarna innebär en bygg- och granskningsprocess som du annars inte hade haft.
Ja. Teknikerna bakom dem – service workers, webbapp-manifestet och installationsfrågan – är nu standarddelar av plattformen snarare än ett experiment, och de ramverk som de flesta team redan använder har direktstöd för dem. Det som har förändrats är inramningen. En PWA är inte längre en separat produktkategori, utan en uppsättning funktioner som du aktiverar för en webbapp när de tillför ett faktiskt värde.
Allt som kräver djup åtkomst till enheten eller operativsystemet. Bakgrundsplatstjänster, det mesta inom Bluetooth och sensorer, tät integrering med systemfunktioner och allt som kräver en bakgrundsprocess som alltid körs är antingen otillgängligt eller har ojämnt stöd. Tillgängligheten varierar mellan webbläsare och plattformar, så fatta beslut utifrån din egen kravlista och kontrollera varje punkt mot MDN:s referens för PWA, snarare än ett generellt svar.
Det beror på omfattningen, men två saker gör att det går betydligt snabbare än för inbyggda appar: en enda kodbas att bygga, och ingen granskning i appbutiker före lansering. Om du redan har en välbyggd webbapp är det ett fokuserat arbete att lägga till en service worker, ett manifest och en offline-strategi, snarare än att bygga om allt från grunden. Om det är den befintliga appen som är problemet, som i fallet med Pinterest, står du inför en total ombyggnad och tidsplanen styrs då av det arbetet.
Här är hela resonemanget i korthet. En progressiv webbapp är rätt val när dina krav matchar vad webbläsaren kan göra, dina användare kommer från webben och du hellre underhåller en kodbas än två. Det är fel val när en funktion du absolut behöver finns i operativsystemet, eller när appbutikerna är din huvudsakliga distributionskanal. Håll dörren öppen när du kan. Anpassa dig efter plattformen när du måste.
Vi har byggt båda delarna, från webbappar som kan installeras på hemskärmen till inbyggda produkter som Jinga Life, så rekommendationen du får är den som ditt projekt faktiskt behöver. Ta en titt på hur vi närmar oss webbutveckling och mobilutveckling, eller hör av dig så går vi igenom dina krav utifrån de fyra frågorna ovan.
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
Inês Silva är projektledare med över fyra års erfarenhet av att skriva om mjukvaruleveranser, agila metoder och tekniskt ledarskap. Eftersom hon inledde sin karriär som utvecklare har Inês en genuin och djup teknisk förståelse för ledningsarbetet. Hon brinner för att överbrygga klyftan mellan övergripande affärsstrategi och det dagliga ingenjörsarbetet, och hon delar gärna med sig av praktiska tips som hjälper team att samarbeta bättre och leverera fantastiska produkter.
People who read this post, also found these interesting:
