I många år var svaret enkelt: vill du ha en riktig app bygger du native. År 2026 ser kartan annorlunda ut. Webbplattformen har fått WebGPU, on-device AI, gigabyte-stor lokal lagring och push-notiser på både Android och iOS. Samtidigt finns det fortfarande hårda gränser, framför allt på Apples plattform, som gör att native ibland är enda vägen. Den här guiden går igenom skillnaderna som faktiskt avgör valet, utan hype och utan att låtsas att den ena tekniken alltid vinner.

Vad är skillnaden, egentligen?

En native app byggs specifikt för en plattform (Swift/SwiftUI för iOS, Kotlin för Android) eller med ett cross-platform-ramverk som React Native eller Flutter. Den distribueras via App Store och Google Play och installeras som ett vanligt program.

En progressive web app (PWA) är en webbplats byggd med moderna webbtekniker som beter sig som en app: den kan installeras på hemskärmen, köra offline via en service worker, skicka push-notiser och nå hårdvara som kamera och GPS. Användaren behöver inte gå via en app-butik utan kan installera direkt från webbläsaren.

Den viktiga skillnaden 2026 är att de tekniska klyftorna har krympt rejält, men distributions- och plattformspolitik skapar fortfarande verkliga begränsningar, särskilt på iOS.

App Store-närvaro: här går den största skiljelinjen

Vill du synas i app-butikerna ser läget olika ut beroende på plattform.

  • Google Play: En PWA kan paketeras och publiceras via en Trusted Web Activity (TWA), exempelvis med Microsofts gratisverktyg PWABuilder som genererar en Android App Bundle. Din PWA hamnar alltså i Play-butiken med relativt lite extra arbete.
  • Microsoft Store: PWA:er kan skickas in direkt och med minimala anpassningar.
  • Apple App Store: Här är dörren stängd. Apples granskningsregler avvisar uttryckligen appar som bara är "ompaketerade webbplatser", och en ren PWA faller under den kategorin. Det har gällt i flera år och gäller fortfarande 2026.

Behöver du alltså finnas i Apples App Store, vara sökbar där och kunna ta betalt via Apples köpflöde, då behöver du i praktiken en native eller hybrid-app. Behöver du inte det, försvinner ett av de starkaste historiska argumenten för native: distributionen kan ske direkt via webben utan butiksgranskning och utan uppdateringskö.

Offline och lokal kraft: webben har vuxit ifatt

Offline var länge native-territorium. Idag använder PWA:er service workers med Cache API och IndexedDB för att fungera utan nät, och bakgrundssynk för att skicka data när uppkopplingen är tillbaka. Det räcker långt för det stora flertalet affärsappar: läsa cachat innehåll, fylla i formulär offline, jobba i ett dashboard.

2026 har webbplattformen dessutom fått tunga verktyg:

  • WebGPU för högpresterande grafik och lokal AI-inferens direkt i webbläsaren.
  • Origin Private File System (OPFS) som låter en PWA hantera gigabyte av data med nära native disk-prestanda, vilket gör det realistiskt att köra videoredigerare eller stora datamängder helt i webbappen.
  • WebAssembly och on-device-AI-API:er som kör modeller utan serveranrop.

Gränsen går vid det riktigt tunga: omfattande offline-kartor, stora mediabibliotek, avancerad bakgrundsbearbetning eller maximalt utpressad grafik- och sensorprestanda hanteras fortfarande smidigare native. För en typisk webbtjänst, e-handel eller internt verktyg är webbens offline-stöd däremot fullt tillräckligt.

Push-notiser: möjligt på båda, men med ett iOS-förbehåll

Push fungerar idag på både Android och iOS för PWA:er, vilket länge var en av native-lägrets trumfkort.

På iOS finns dock ett viktigt villkor: Push API är bara tillgängligt för webbappar som lagts till på hemskärmen (via Dela → Lägg till på hemskärmen). En öppen flik i Safari har ingen tillgång till push. Stödet kom med iOS 16.4 (2023), och med iOS 26 öppnas varje sida som lagts till på hemskärmen som standard som en webbapp. Safari 18.4 introducerade dessutom Declarative Web Push, ett enklare upplägg som inte ens kräver en service worker.

Praktiken är att din faktiska push-räckvidd på iPhone begränsas till de användare som faktiskt installerat din PWA på hemskärmen, vilket i regel är en mindre andel av besökarna. Behöver du nå alla användare med notiser med hög tillförlitlighet är native fortfarande starkare på just iOS.

EU-faktorn: ett rörligt mål

Här finns en regulatorisk komplikation värd att känna till. Under DMA-processen försökte Apple först ta bort hemskärms-webbappar i EU, men backade efter kraftiga protester. Resultatet 2026 är att PWA:er på iOS fortsatt körs på WebKit, och de tekniska begränsningar som fanns innan DMA finns i praktiken kvar.

iOS tillåter formellt tredjeparts webbläsarmotorer i EU sedan iOS 18.2, men Apples implementation via BrowserEngineKit har skapat så mycket friktion att ingen webbläsare hade tagit upp den i början av 2026. Brittiska CMA gav i oktober 2025 Apple "Strategic Market Status" och pekade ut just motorkraven som konkurrensskadliga. Slutsatsen: regelutvecklingen kan på sikt gynna webbappar, men du ska inte planera arkitektur utifrån löften om framtida lättnader.

Kostnad i tid och komplexitet

Här menar vi inte kronor utan ingenjörstid, antal kodbaser och underhållsbörda.

PWA

  • En kodbas för alla plattformar och webben. Samma kod, samma deploy.
  • Snabbare iteration: du publicerar uppdateringar direkt, utan butiksgranskning och utan att vänta på att användare uppdaterar.
  • Lägre tröskel: teamet kan ofta bygga vidare på befintlig webbkompetens.

Native

  • En eller två kodbaser till (iOS och Android), eller ett cross-platform-ramverk som ändå kräver plattformsspecifik finputs.
  • Butiksprocess: granskning, release-cykler, certifikat och provisioning som löpande underhåll.
  • Mer specialiserad kompetens per plattform.

Tumregeln 2026 för de flesta affärsappar: PWA är förvalet, och du behöver konkreta skäl för att gå native, snarare än konkreta skäl för att gå PWA. De skälen är reella när de finns, men de bör vara just specifika, inte vanans makt.

Underhåll över tid

En PWA underhålls som vilken modern webbapp som helst: en pipeline, en miljö, ett ställe att fixa buggar. En native- eller hybridapp innebär parallellt underhåll av plattformsversioner, OS-uppdateringar som kan bryta API:er, samt återkommande butiksinlämningar. Över en produkts livstid är detta en betydande, ofta underskattad, post. Samtidigt får du med native en stabilare grund för djup hårdvaruintegration och prestanda som inte är beroende av webbläsarleverantörernas tempo.

Så väljer du: en kort beslutsguide

Välj PWA när:

  • Räckvidd via webben, snabb iteration och en kodbas väger tyngst.
  • Offline-behoven är måttliga (cachat innehåll, formulär, dashboards).
  • Du inte är beroende av att synas i Apples App Store.
  • Det handlar om e-handel, innehåll, interna verktyg eller SaaS.

Välj native (eller hybrid) när:

  • App Store-närvaro på iOS är affärskritisk.
  • Du behöver maximal prestanda, avancerad sensor- eller hårdvaruintegration eller tunga offline-scenarier.
  • Pålitlig push till samtliga iOS-användare är ett måste.
  • Du bygger spel eller grafikintensiva upplevelser där varje millisekund räknas.

Många hamnar dessutom rätt i en mellanväg: bygg kärnan som en stark PWA och paketera den för Google Play via TWA, och addera native bara där det verkligen behövs.

Hur ZORC tänker

Vi börjar alltid i affärsmålet, inte i tekniken. Vilka enheter använder dina kunder? Hur viktig är App Store? Hur ofta behöver ni släppa nytt? Svaret avgör om en PWA tar er hela vägen eller om native är värt den extra komplexiteten. Vad ett projekt kräver i tid och underhåll beror på just dessa val, omfattning och integrationer, snarare än på en standardmall. Vill du ha en uppskattning för just ditt case får du fram en snabbt i vår offertkalkylator, eller så tar vi det direkt via kontakt.