Progresszív Webalkalmazások: Mikor Veri a PWA a Natívot

A progresszív webalkalmazás fejlesztése az a lehetőség, amelyet a brit megrendelők egy projekt első tíz percében elvetnek, majd tizennyolc hónappal később fedeznek fel újra, amikor a második natív kódbázis csendben már felemésztette a keretet. Azért vetik el, mert szinte minden, amit róla írnak, két táborba esik: olyan lelkesedés, amely kihagyja azt, amit az iOS nem hajlandó megtenni, vagy 2019-ből örökölt szkepszis, amikor a platform tényleg nem tudta ezeket.

Ma mindkettő téved, méghozzá úgy, hogy az számokban is látszik. A Safari az iOS 16.4 óta támogatja a push értesítéseket a kezdőképernyőre tett webalkalmazásokban. A Chrome elhagyta a service workerre vonatkozó követelményt a telepítéshez. A brit szabályozó 2025 októberében stratégiai piaci státuszúnak minősítette az Apple-t és a Google-t a mobilböngészőik és böngészőmotorjaik felett. Ezzel együtt az iOS továbbra is megtagadja a háttérben futást, a saját szabályai szerint lakoltatja ki a tárolt adatokat, és soha nem fog webalkalmazást felvenni az App Store-ba.

Az alábbi az a változat, amit egy olyan ügyfélnek adnék, aki egy és három kódbázis között választ. Minden itt idézett képességet a gyártó saját dokumentációjában ellenőriztem 2026 szeptemberében, mert ebben a témában a közvélekedés megbízhatóan két évvel jár hátrébb.

Mikor veri a PWA a natív alkalmazást? Amikor a felhasználói ugyanannyira vannak Androidon és asztali gépen, mint iPhone-on, amikor az alkalmazás egy szerver, és nem az eszköz előlapja, és amikor keresésből találják meg Önt, nem áruházból. A PWA veszít, ha háttérbeli helymeghatározás, kezdőképernyős widget, iPhone-os Bluetooth vagy áruházi számlázás kell. A megtakarítás egy kódbázis három helyett, ami brit viszonylatban nagyjából £40 000-tól £120 000-ig terjedő építés, utána pedig évről évre jóval kisebb számla.

Mi is valójában egy progresszív webalkalmazás

A fogalmat elég lazán használják ahhoz, hogy két ember ugyanazon a megbeszélésen mást értsen alatta. A műszaki meghatározás szűk, és érdemes ragaszkodni hozzá.

Az MDN úgy írja le a progresszív webalkalmazást, mint webplatform-technológiákkal épített alkalmazást, amely a platformspecifikus alkalmazásokéhoz hasonló élményt ad. Egyetlen kódbázisból több platformon fut, telepíthető, offline is működik, és beépül az operációs rendszerbe.

A gyakorlatban ez három elemet jelent, és az a webhely, amelyikből bármelyik hiányzik, ambiciózus webhely, nem PWA.

A webalkalmazás-manifeszt

A manifeszt egy JSON-fájl, amely megmondja az operációs rendszernek az alkalmazás nevét, a használandó ikonokat, az indításkor megnyitandó URL-t, és azt, hogy böngészőkeretben vagy önállóan fusson-e. Nélküle a böngészőnek nincs mit telepítenie. Kicsi, statikus, és az egész gyakorlat legolcsóbb része.

A service worker

A service worker olyan szkript, amely az oldaltól elkülönülten fut, az alkalmazás és a hálózat közé áll, és gyorsítótárból is válaszolhat a kérésekre. Ez teszi lehetővé az offline viselkedést, és ez fogadja a push üzeneteket. Ez az a rész is, ami félremegy, mert egy rosszul lehatárolt gyorsítótár hetekig avult kódot szolgál ki a felhasználóknak.

A HTTPS

A service workerek, a push, a helymeghatározás és a kamerahozzáférés mind biztonságos kontextushoz kötöttek. Modern tárhelyen ez ingyenes és automatikus, tehát megkötés, nem költség.

Mit jelent a telepítve, platformonként

A megrendelők azt feltételezik, hogy a telepítés egyetlen viselkedés. Három, és a különbségek üzletileg számítanak.

Android

Az Android Chrome adja a paritáshoz legközelebb álló élményt. Az alkalmazás ikont kap a kezdőképernyőn, saját bejegyzést az alkalmazásváltóban, saját tárhelyet, és burkolón keresztül felvehető a Play Áruházba. A telepítési felkérések a saját felületéről indíthatók, miután a böngésző kiváltotta a megfelelő eseményt, tehát Ön szabja meg a kérdezés pillanatát.

iOS és iPadOS

A Safari a megosztási lapon és a kezdőképernyőhöz adás menüponton át telepít. Nincs olyan oldalon belüli telepítési felkérés, amelyet elindíthatna, nincs olyan sáv, amelyet az Apple megjelenítene Ön helyett, és nincs megbízható módja annak, hogy észlelje, ha egy felhasználó megtette. Ez az egyetlen interakciós rés a legnagyobb gyakorlati különbség a platformok között, és inkább tervezési, mint mérnöki feladat: meg kell tanítani a felhasználónak egy mozdulatot.

Asztali gépek

A Chrome, az Edge és a macOS-en a Safari mind a dokkba vagy a tálcára telepíti a webalkalmazásokat, saját ablakkal. Az asztali gép az a hely, ahol a PWA-k a legkevésbé vitatottak és a legkevésbé kihasználtak, különösen belső eszközöknél, ahol az alternatíva egy Electron-build, amit senki sem akar karbantartani.

A Chrome megváltoztatta a telepíthetőség szabályait, és a legtöbb útmutató nem vette észre

Éveken át minden cikk ugyanazt a listát ismételte: manifeszt, ikonok, HTTPS, és egy fetch kezelővel ellátott service worker. Ez az utolsó pont a menüből indított telepítésre már nem igaz.

A Google eltávolította a fetch-et megvalósító service worker követelményét a menüből indított telepítéshez, mobilon a 108-as, asztali gépen a 112-es verzióban, és mostantól alapértelmezett offline oldalt biztosít azoknak a webhelyeknek, amelyek nem hoznak sajátot. A telepítési felkérés algoritmusa továbbra is fetch kezelőt szeretne, de maga a telepíthetőség már nem függ tőle.

A hatás elért az eszközökig. A Lighthouse a 12.0.0 verzióban, amely 2024 áprilisában jelent meg, teljesen megszüntette a PWA kategóriát, mert azok az auditok már nem érvényes feltételeket teszteltek. Ha a build-folyamata még mindig elhasal egy hiányzó PWA-pontszámon, olyasmit tesztel, amit a Google visszavont.

A gyakorlati olvasat az, hogy a telepítés és az offline képesség szétvált. Kiadhat telepíthető alkalmazást bármiféle offline történet nélkül, ami gyakran a helyes első kiadás, és akkor tesz hozzá gyorsítótárazást, amikor már tudja, melyik képernyőket használják az emberek térerő nélkül.

Az offline működés tervezői döntés, aminek ára van

Az offline szó óriási hatókör-tartományt takar. Egy gyorsítótárazott váz, amely a legutóbb ismert adatokat mutatja, egy hét munka. Egy valóban offline first alkalmazás, amely sorba állítja az írásokat, feloldja az ütközéseket és újracsatlakozáskor egyeztet, másik termék.

Gyorsítótárazási stratégiák

A service worker gyorsítótárazása négy mintára és erőforrástípusonként egy döntésre egyszerűsödik. A cache first a tárolt másolatot adja vissza és soha nem ellenőriz, ami betűtípusoknál és hasított build-fájloknál helyes. A network first a szervert próbálja és visszalép, ami olyan adatokhoz illik, amelyeknek naprakésznek kell lenniük. A stale while revalidate azonnal a gyorsítótárból szolgál ki és a háttérben frissít, ez a szokásos választás tartalomhoz. A network only mindenre való, amit nem szabad avult másolatból kiszolgálni, például a fizetésekre.

Ezt elrontani a leggyakoribb PWA-kudarc, amit látok. Az alkalmazásvázra alkalmazott cache first szabály a múlt havi JavaScriptet adja a visszatérő felhasználóknak, amíg valami ki nem kényszeríti a frissítést, és a hibajelentések olyan tüneteket írnak le, amelyek a jelenlegi kódban nem léteznek.

Háttérszinkronizálás

Az írások offline sorba állítása és a sor ürítése a kapcsolat visszatértekor a Background Synchronization API dolga. Az MDN korlátozott elérhetőségűként és kifejezetten nem Baseline-ként sorolja fel, ami azt jelenti, hogy a legszélesebb körben használt böngészők egy részében nem működik.

iOS-en tehát Ön írja meg a tartalékmegoldást: a sort IndexedDB-ben őrzi, és az alkalmazás következő megnyitásakor üríti. Ez működik, a felhasználók elfogadják, és talán három-öt nap fejlesztés az API által kért délután helyett.

A push értesítések több projektet döntenek el, mint bármi más

Ha egyetlen képesség elsüllyeszt egy PWA-javaslatot, akkor ez az, rendszerint olyan tények alapján, amelyek 2022-ben voltak igazak.

Android és asztali gép

A webes push az Android Chrome-on, az asztali Chrome-on, az Edge-en és a Firefoxon évek óta működik a Push API, a Notifications API és egy service worker együttes munkájával. A kézbesítést a böngészőgyártó push szolgáltatása végzi, az engedélykérés szokványos, és nincs érdemi hátrány a natív alkalmazáshoz képest abban a gyakori esetben, amikor egy szerver üzenetet küld egy feliratkozott felhasználónak.

iOS és iPadOS

Az Apple az iOS és iPadOS 16.4 verzióban adta hozzá a webes pusht. A hozzá kötött feltétel az a rész, ami elsikkad: a WebKit kimondja, hogy a webalkalmazást hozzá kell adni a kezdőképernyőhöz, és az engedélyt közvetlen felhasználói interakcióra válaszul kell kérni, például egy feliratkozó gomb megérintésekor. A webes push nem működik olyan webhelynél, amely Safari-lapon ül.

A manifesztnek a display értékét standalone vagy fullscreen értékre kell állítania, és az értesítések ezután úgy viselkednek, mint bármely más alkalmazásé: zárolási képernyő, értesítési központ, párosított Apple Watch, és alkalmazásonkénti szabályozás a Beállításokban. A jelvények is működnek.

Az Apple később egyszerűbb utat adott hozzá. A Declarative Web Push a Safari 18.4 verzióban érkezett, iOS és iPadOS 18.4 rendszeren érhető el a kezdőképernyőhöz adott webalkalmazásokhoz, és szabványos JSON-adatból jelenít meg értesítést anélkül, hogy futnia kellene egy service workernek. Munkát vesz le. A kezdőképernyős feltételt nem veszi le.

Az iOS-hiányosság, pontosan megfogalmazva

A hiányosság valós, és kisebb, mint a híre. Pontosan megfogalmazni hasznosabb, mint panaszkodni rá vagy úgy tenni, mintha bezárult volna.

A tárolt adatok kilakoltatása

A WebKit a legrégebben használt elv szerint lakoltatja ki a webhelyadatokat, ahol az utolsó használatot az utolsó felhasználói interakciótól vagy tárolási művelettől számítja. A tárolási szabályzat dokumentációja forrásonként a lemez legfeljebb 60 %-át engedi böngészőalkalmazásoknak és legfeljebb 15 %-át más alkalmazásoknak, összesített kvótaként pedig 80 %-ot, illetve 20 %-ot, és megerősíti, hogy a kezdőképernyőn önállóan futó webalkalmazás ugyanazokat a kvótákat kapja, mint a böngésző.

Ebből két dolog következik. A tárhely nem az a korlát, aminek képzelik, a kilakoltatás pedig ütemezési, nem kapacitáskockázat. Kezelje az eszközt gyorsítótárként és a szervert nyilvántartásként, és a kilakoltatás megszűnik terméktulajdonságnak lenni.

Háttérben futás

iOS-en nincs megfelelője a natív háttérfeladatnak. Nincs időzített lekérés, nincs háttérbeli helymeghatározás, nincs csendes feldolgozás zárt alkalmazás mellett. Bárminek, aminek ütemezetten kell megtörténnie, a szerverén kell megtörténnie, és push üzeneten át jut el az eszközre, amit a felhasználó lát.

Nincs jelenlét az App Store-ban

PWA nem vehető fel az App Store-ba. Ha ügyfeleinek érdemi része arra számít, hogy az áruházban rákeres a márkájára és ott megtalálja, az nem olyan mérnöki gond, amit a weben egyáltalán megoldhatna.

Böngészőmotorok, a DMA és a CMA

Ez az a rész, ahol a beszámolók megelőzik az elsődleges forrásokat, tehát érdemes szűken tartani magunkat ahhoz, ami valóban dokumentált.

Az Apple ma már engedélyez alternatív böngészőmotorokat, és kifejezetten kimondja, hogy ez kizárólag az Európai Unióban érvényes, iOS 17.4 vagy újabb és iPadOS 18 vagy újabb rendszeren, két olyan jogosultságon keresztül, amelyet a közzétett biztonsági, adatvédelmi és tesztkészlet-feltételeknek megfelelő fejlesztők kapnak meg. Az Apple megköveteli a Web Platform Tests 90 %-ának és a Test262 80 %-ának teljesítését, a JIT nélküli működést, és a sebezhetőségek többségének 30 napon belüli javítását.

Egy brit vállalkozás számára ebből ma semmi nem változtat semmin. A jogosultságok joghatósághoz kötöttek, és egy brit szolgáltatónál lévő brit felhasználó WebKitet futtat, bármelyik böngészőikonra koppintott is.

A brit helyzet külön mozog. 2025. október 22-én a CMA stratégiai piaci státuszúnak minősítette az Apple-t és a Google-t a mobilplatformjaikon, lefedve az operációs rendszereket, az alkalmazásterjesztést, a böngészőket és a böngészőmotorokat, öt éves időszakra. A minősítés a magatartási előírások kiszabásának hatásköre, nem maguk az előírások. Tervezzen a platformmal úgy, ahogy ma viselkedik, és minden lazítást tekintsen ráadásnak.

Hardver és eszköz-API-k, ellenőrizve és nem feltételezve

A web nem fér hozzá a hardverhez az az ellenvetés, amit a leggyakrabban hallok, és amelyik egy konkrét esetben a leggyakrabban téves.

Ami gyakorlatilag mindenhol működik

A kamera- és mikrofonhozzáférés a getUserMedia felületen keresztül Baseline az MDN szerint, és 2017 óta böngészőkön át működik. A helymeghatározás, az eszköztájolás, a fájlfeltöltés a mobilos kamerarögzítéssel együtt, a vágólap-hozzáférés, a Web Share API mobilon és a WebAuthn szerinti passkey Face ID-vel vagy ujjlenyomattal mint hitelesítővel mind működik a mai mobilböngészőkben. A vonalkód- és QR-olvasás a kamerafolyamból rutin.

Az üzleti alkalmazások túlnyomó többségénél ez a lista a teljes hardverigény.

Ami csak Chromium, mobilon pedig gyakorlatilag csak Android

A Web Bluetooth a Google dokumentációja szerint ChromeOS-en, Android 6.0-tól Chrome-ban, macOS-en Chrome 56-tól és Windows 10-en Chrome 70-től érhető el, iOS-támogatás felsorolása nélkül, az MDN pedig korlátozott elérhetőségűnek, nem Baseline-nak jelöli. A Web NFC ennél is szűkebb: a Google szerint Androidon a Chrome 89 verziójától érhető el.

A felhasználó által választott fájlok olvasására és írására szolgáló File System Access API szintén Chromium-terület, jóllehet az origin private file system a böngészőkön átívelően lefedi az alkalmazáson belüli tárolási igények nagy részét.

Az áruházi terjesztés üzleti kérdés, nem műszaki

A csapatok úgy vitatkoznak az áruházi terjesztésről, mintha képességről szólna. Négy üzleti változóról szól, és ezek közül csak egy szól egyértelműen az áruház mellett.

A felfedezhetőség az őszinte előny. A fogyasztók valóban keresnek az App Store-ban és a Play-en márka és kategória szerint, és az áruházi jelenlét nélküli vállalkozás lemond erről a csatornáról. Óriásit számít egy felismerhető nevű fogyasztói terméknél, és nagyon keveset egy olyan eszköznél, amelyet egyetlen cég 200 alkalmazottja használ.

A bizalom valós, és közönségtől függően aszimmetrikus. Az idősebb és kevésbé műszaki felhasználók biztonsági jelzésként olvassák az áruházi adatlapot. A fiatalabbak egyre kevésbé, és ugyanaz a felhasználó szívesen használja egy bank webhelyét ugyanazon a telefonon.

Ezzel szemben az áruház ellenőrzési sort iktat Ön és a felhasználói közé, elutasítási kockázatot jelent változó szabályok mentén, és jutalékot von le mindenből, amit az alkalmazásban elad. A PWA-nál ezek egyike sincs. Akkor élesít, amikor eldönti, és egy kritikus javítás a következő betöltéskor jut el minden felhasználóhoz, nem egy ellenőrzés után.

Mennyit vonnak le valójában az áruházak

A jutalékszámok elég gyakran mozognak ahhoz, hogy fejből idézni őket meggondolatlanság legyen. Ezek a gyártók saját közzétett feltételei, 2026 szeptemberében ellenőrizve.

Az Apple 30 %-ot számít fel szabványos jutalékként digitális termékekre és szolgáltatásokra. Az App Store Small Business Program ezt 15 %-ra csökkenti azoknál a fejlesztőknél, akiknek az előző naptári évben legfeljebb 1 000 000 USD bevételük volt, az új fejlesztők jogosultak, és a szabványos kulcs a jövőbeli eladásokra tér vissza, ha egy éven belül átlépi a küszöböt.

A Google sávos szolgáltatási díjat tesz közzé a Google Play-hez: 15 % az évi első egymillió USD fejlesztői bevételre, 30 % efölött, és 15 % az automatikusan megújuló előfizetésekre a bevételtől függetlenül. Ugyanaz az oldal ismertet egy eltérő szerkezetet, amely 2026. június 30-án lép hatályba az EGT, az Egyesült Királyság és az Egyesült Államok területén, és 10 %-on vagy 20 %-on alapul, plusz 5 % számlázási díj, aszerint hogy a telepítés új vagy meglévő.

Mindkét gyártó USD-ben tesz közzé. Egy £9,99-es havi előfizetés áruházon át történő értékesítése 15 %-nál előfizetőnként évi nagyjából £18-ba, 30 %-nál nagyjából £36-ba kerül. Szorozza meg az előfizetői számával, mielőtt ingyenesnek tekintené az áruházat.

PWA-t továbbra is kiadhat a Google Play-en

Az Android egyszerre adja mindkét lehetőséget, ami valódi aszimmetria a platformok összevetésében, és ritkán említik.

A Trusted Web Activity olyan Android-alkalmazás, amely a saját PWA-ját nyitja meg teljes képernyőn, böngészőkeret nélkül, Digital Asset Links segítségével az Önéként hitelesítve. Android 72-es vagy újabb Chrome-ot igényel, a gazdaalkalmazás pedig nem fér hozzá a webes tartalom sütijeihez vagy tárhelyéhez. A gyakorlatban vékony burkoló, amelyet a manifesztjéből generálnak és bármely más alkalmazáshoz hasonlóan küldenek be a Play-re.

Androidon tehát a választás nem áruház vagy web. Kiadja a PWA-t, becsomagolja, és ugyanabból a kódbázisból megkapja az áruházi adatlapot is, néhány nap csomagolási munkáért és az éves fejlesztői fiókdíjért.

iOS-en nincs megfelelője. Az Apple ellenőrzési irányelvei régóta önmagában elégtelennek tekintik a webhely köré vont burkolót, tehát az iOS-áruházi út azt jelenti, hogy valami valóban natívat kell építeni. Ez az aszimmetria formálja az alábbi költségtáblát, jobban, mint bármelyik API-hiányosság.

A progresszív webalkalmazás fejlesztésének költsége két natív kódbázissal szemben

Az összevetés, amit az emberek elvégeznek, az építési költség, és ez a kisebbik fele. Az összevetés, amely eldönti a kimenetet, a hároméves teljes költség, mert a natív kiadása ismétlődik.

Ezeket brit ügynökségi sávokként olvassa egy közepes bonyolultságú üzleti alkalmazásra, nem árajánlatként. Egy ilyen alakú PWA jellemzően két-három mérnökből álló csapat három-öt hónapon át. Két natív kódbázis plusz webes jelenlét három csapat, három kiadási folyamat és évente három adag platformfrissítés.

Az első és a harmadik sor közötti különbség, nagyjából £75 000-tól £175 000-ig építésben és utána évi £27 000-tól £60 000-ig, az, amit a natívval megvásárol. Néha jól elköltött pénz. Döntésnek kellene lennie, nem alapbeállításnak. A webfejlesztés és a szoftverfejlesztés oldalunk bemutatja, hogyan méretezzük fel mindkét utat.

Hová megy valójában a karbantartási pénz

Az építési költségről alkudnak. A karbantartási költséget felfedezik, és a több kódbázisos projektek itt buknak el csendben, nem hangosan.

A natív platformok minden évben munkát kényszerítenek Önre. Az új rendszerverziók API-kat avultatnak el, az aláírás és a kiépítés változik, a minimális SDK-szintek emelkednek, az áruházi szabályzatok pedig olyan követelményeket adnak hozzá, mint az adatvédelmi manifesztek és az adatbiztonsági nyilatkozatok. Ezek egyike sem szállít funkciót. Két platformon kétszer fizeti meg, olyan ütemben, amit valaki más szab meg.

Aztán ott az elcsúszás. Két kódbázis, amely ugyanazt a funkciót valósítja meg, széttart, és a széttartás olyan támogatási jegyekben jelentkezik, amelyek csak az egyik platformon reprodukálhatók. Minden termékdöntést kétszer kell meghozni és egyeztetni, és az egyeztetés költsége egyetlen számlán sem látszik.

A PWA mindezt a böngészők fejlődésére cseréli, ami folyamatos, visszafelé kompatibilis, és szinte soha nem tör el működő kódot. Az ismétlődő munka a saját függőségfrissítése, a biztonsági javítás és a tárhely, vagyis ugyanaz a karbantartás, amire minden egyedi webalkalmazásnak amúgy is szüksége van.

A lényeges összevetés nem két szám egy ajánlaton. Egy csapat három ellen, minden évben, ameddig a termék él.

Teljesítmény és Core Web Vitals egy PWA-nál

A telepített alkalmazást a natívhoz mérik, tehát a teljesítménymérce magasabb, mint egy webhelynél, nem alacsonyabb. A jó hír az, hogy a mérőszámok nyilvánosak, a küszöbök pedig rögzítettek.

A Core Web Vitals jelenleg három mérőszámból áll, mindegyiket az oldalbetöltések 75. percentilisén értékelik, mobilra és asztali gépre bontva. A Largest Contentful Paint 2,5 másodpercnél vagy annál kevesebbnél jó, és 4,0 felett gyenge. Az Interaction to Next Paint, amely a First Input Delayt váltotta fel, amikor 2024-ben stabillá vált, 200 ezredmásodpercnél vagy annál kevesebbnél jó, és 500 felett gyenge. A Cumulative Layout Shift 0,1-nél vagy annál kevesebbnél jó, és 0,25 felett gyenge.

A PWA-nak itt van egy szerkezeti előnye. A vázat gyorsítótárból kiszolgáló service worker miatt az ismételt látogatások közel azonnaliak, és pontosan ezt a mintát adja egy telepített alkalmazás, így a telepített PWA valós felhasználói adatai rendszerint jobban festenek, mint ugyanaz a kód hidegen, böngészőben meglátogatva.

Van egy szerkezeti kockázata is. Az egyoldalas keretrendszerek a kliensre tolják a munkát, és az INP az a mérőszám, amely ezt bünteti. Ha már küzd ezekkel a számokkal, a Core Web Vitals teljesítéséről szóló útmutatónk mélyebben tárgyalja a diagnózist, mint ez a bejegyzés.

A SEO az az előny, amit senki nem áraz be

Ez az az érv, amit a legtöbb üzleti esetben elsőként hoznék elő, és szinte mindig teljesen kimarad az összevetésből.

A PWA webhely. Minden képernyőnek van URL-je, minden URL bejárható, indexelhető, hivatkozható és megosztható, és mindegyik rangsorolható. A natív alkalmazásnak ebből semmije sincs. Az áruházi adatlapokat felszínesen indexelik, és egy elkerített kerten belül, teljesen más jelzések alapján rangsorolják, az alkalmazáson belüli tartalom pedig láthatatlan a kereső számára.

A következmény halmozódik. A natív alkalmazásra fordított marketingköltés telepítéseket vesz, és azon a napon leáll, amikor a költés leáll. Ugyanaz a költés egy PWA tartalmára és műszaki minőségére olyan oldalt vesz, amely tovább rangsorol. Három év alatt ez a különbség gyakran meghaladja bármelyik út teljes építési költségét.

Csak akkor térül meg, ha a megvalósítás bejárható, és itt hibáznak a kliensoldalon renderelt alkalmazások: mindent JavaScriptben renderelni egyetlen URL-lel és szerveroldali HTML nélkül teljesen eljátssza az előnyt. A szerveroldali renderelés vagy az indexelhető útvonalak előrenderelése a megoldás, és egy technikai SEO audit indulás előtt jóval olcsóbb, mint fél év múlva rájönni, hogy semmi nem indexelődött.

A kizáró követelmények

A döntés vétólistaként könnyebb, mint előnylistaként, mert a vétók tárgyilagosak.

Natívra van szüksége, ha az alábbiak bármelyike valódi követelmény és nem óhaj. Háttérbeli helykövetés zárt alkalmazás mellett. Kezdőképernyős widgetek, óraalkalmazások, vagy CarPlay és Android Auto integráció. Bluetooth vagy NFC iPhone-on. HealthKit, alkalmazáson belüli Apple Pay, vagy bármilyen mély rendszerintegráció, amelyet az Apple nem nyitott meg a web felé. Áruházi számlázás digitális termékekre, ahol az áruházi szabályzat megköveteli. Tartósan nehéz számítás, például valós idejű videofeldolgozás vagy natív képkockasebességű 3D renderelés. App Store-jelenlét mint marketingkövetelmény, amelytől a vállalkozása valóban függ.

Ha ezek egyike sem áll fenn, a PWA nagyon valószínűen a helyes válasz, és a bizonyítási teher azé, aki három kódbázist akar.

Két további megfontolás tovább billenti. Ha a felhasználói túlnyomórészt asztali gépen vagy Androidon vannak, az iOS-hiányosságok a közönség kisebbségét érintik. És ha az alkalmazás a saját szerverének, nem az eszköznek az előlapja, ami az üzleti szoftverek többségére igaz, az eszköz képességei alig számítanak.

Első forgatókönyv: helyszíni szerviz egy létesítménykezelőnél

Kétszáz technikus, munkalapok, fényképek az elvégzett munkáról, aláírásrögzítés, foltos térerő gépházakban és pincékben. Ez az az eset, amelyről mindenki azt hiszi, hogy natívot kíván, és ez az, ahol a PWA a legtisztábban nyer.

Minden követelmény lefedett. A kamera a getUserMedia felületen működik. Az aláírás egy canvas elem. A munkaadatok IndexedDB-ben tárolódnak, és az írási sor újracsatlakozáskor ürül, kézzel megírva, mert a Background Sync böngészőkön át nem megbízható. A diszpécserriasztások webes pushként mennek ki, ami Androidon működik, iOS-en pedig azoknál a technikusoknál, akik felvették az alkalmazást a kezdőképernyőre, és a telepítés egy ötperces pont a betanításban, nem felhasználószerzési feladat.

Nincs áruházi felfedezhetőségi igény, mert a felhasználók alkalmazottak. Nincs számlázás, tehát a jutalék lényegtelen. Az eszközpark vegyes Android és iOS, pontosan az az eset, amely a legkeményebben bünteti a két natív kódbázist.

Építsen egy PWA-t talán £45 000-tól £70 000-ig ahelyett, hogy két natív alkalmazást építene £120 000-tól £200 000-ig, adja ki a javításokat még aznap délután ellenőrzés helyett, és a különbözetet költse a diszpécser-háttérrendszerre, ami valójában eldönti, hogy működik-e a dolog.

Második forgatókönyv: szalonlánc, amely foglalást és emlékeztetőket akar

Tizennégy fiók, fogyasztói piac, időpontfoglalás, emlékeztetők, hűségprogram, a pénztárnál és nem az alkalmazásban beszedett fizetés. Az ösztön natív alkalmazást mond, mert a versenytársaknak van.

A követelménylista semmitmondó: foglalási űrlapok, naptár, emlékeztetők, fiókfelület. Az emlékeztető az egyetlen érdekes pont, és ezen a piacon SMS és e-mail jobban szolgálja, mint a push, mert az az ügyfél, aki évente kétszer foglal, nem fog telepíteni semmit.

A felfedezhetőség a döntő tényező, és egyértelműen a webnek kedvez. Az emberek keresésből és térképről találnak szalont, nem alkalmazásáruházban böngészve, tehát a szolgáltatásokat leíró és foglalást felvevő oldalaknak rangsorolniuk kell. A natív alkalmazás ehhez teljesen láthatatlan. Magának a webhelynek a költsége az igazi költségvetési sor, az alkalmazásréteg pedig telepíthetőségként rakódik rá.

Építse meg rendesen a foglalási webhelyet, tegye telepíthetővé, hogy a törzsvendégek a kezdőképernyőn tarthassák, és tegyen hozzá webes pusht annak a kisebbségnek, amely kéri. Egy natív fejlesztés itt £80 000-t vagy többet költ el, hogy kevesebb ügyfelet érjen el, mint amennyit a webhely már most elér.

Harmadik forgatókönyv: előfizetéses fitnesztermék

Vezetett edzések, videótartalom, viselhető eszköz integrációja, £12,99 havonta, közvetlenül a fogyasztónak, fizetett ügyfélszerzésből finanszírozott növekedés. Ez a forgatókönyv a másik irányba megy, és érdemes megmutatni, miért.

Az áruházi felfedezhetőség itt számít, mert a fitnesz böngészős kategória, és az adatlap valódi ügyfélszerzési csatorna. A viselhető eszköz integrációja HealthKitet jelent, amit a web nem ér el. A háttérhang és a képernyő viselkedése edzés közben natívon jobb. A videók offline használatra letöltése nagy léptékben a weben megoldható, de nem kényelmes.

A számlázás az érdekes rész. Az áruházi jutalék £12,99 havi díjon 15 %-nál előfizetőnként évi nagyjából £23, 30 %-nál £47, ami 20 000 előfizetőnél évi £460 000-tól £940 000-ig terjed. Ez erős érv amellett, hogy a fizetést a weben vegye fel, az alkalmazást pedig kliensként kezelje, amit több nagy előfizetéses termék ma már így csinál.

A válasz natív alkalmazás a termékhez, és PWA vagy hagyományos webalkalmazás a regisztrációhoz, a számlázáshoz és a tartalommarketinghez. Mindkettő létezik, és a szétválasztás szándékos, nem véletlen.

Hogyan döntsön egy délután alatt

A döntéshez nem kell felfedezési szakasz. Négy válasz kell hozzá, leírva.

Először sorolja fel azokat az eszközképességeket, amelyekre valóban szüksége van, majd mindegyiket a gyártó saját dokumentációjában ellenőrizze, ne egy összefoglalóban. A legtöbb lista drámaian megrövidül ennél a lépésnél. Másodszor állapítsa meg, honnan érkeznek a felhasználói: ha a válasz a keresés, a web már előnyben van, ha az áruházi böngészés, akkor nincs.

Harmadszor árazza be mind a három utat három évre, ne egyre, a fenti karbantartási számokkal együtt, és számolja bele az áruházi jutalékot mindenre, amit el akar adni. Negyedszer legyen őszinte a csapatával kapcsolatban. Egy három mérnök által karbantartott kódbázis többet szállít, mint három mérnök által karbantartott három kódbázis, minden alkalommal.

Ha a válasz ezután is kétértelmű, előbb a PWA-t építse meg. Ezt olcsóbb visszafordítani. PWA-ról később natívra váltani annyit tesz, hogy a natív klienseket egy már létező és bevált API-ra írja meg, a másik irányba menni pedig azt, hogy elölről kezdi. Ez az aszimmetria többet ér, mint a fenti funkcióösszevetések többsége.

Hol hagyja ez Önt

A progresszív webalkalmazás fejlesztése nem kompromisszum azoknak, akik nem engedhetik meg maguknak a natívot, és nem is egyetemes válasz. Ez a helyes architektúra a termékek egy meghatározott és nagy körére: üzleti szoftverekre, belső eszközökre, foglalási és fiókrendszerekre, tartalomtermékekre, és mindenre, aminek az ügyfelei keresésből érkeznek.

Az iOS-hiányosságok valósak, konkrétak, és többnyire megkerülhetők, nem végzetesek. A push működik, ha a felhasználó telepít. A tárhely bőséges, de kilakoltatható. A háttérben futás nem létezik, és amúgy is a szerverén a helye. A Bluetooth és az NFC nem működik iPhone-on, és ezen semennyi mérnöki munka nem változtat.

A Mecanik mindkét utat építi, és megmondja, mikor a natív a válasz. Ha az összevetést a valódi követelményeire szeretné lefuttatva látni, nem egy általános listára, a webfejlesztés és a szoftverfejlesztés oldal leírja, hogyan méretezzük fel, a webalkalmazás építéséről 2026-ban szóló útmutatónk pedig az ebből következő technológiai döntéseket tárgyalja.

Gyakran ismételt kérdések

Mi az a progresszív webalkalmazás? A progresszív webalkalmazás olyan, webes technológiákkal épített alkalmazás, amely úgy viselkedik, mint egy platformspecifikus alkalmazás. Műszakilag HTTPS-en kiszolgált webalkalmazás egy manifeszttel, amely leírja a nevét, ikonjait és indítási viselkedését, plusz egy service worker, amely gyorsítótárból szolgálhat ki kéréseket és fogadhat push üzeneteket. Az MDN olyan szoftverként határozza meg, amely egyetlen kódbázisból több platformon fut, miközben telepíthető marad és offline is működik.

Küldhet a PWA push értesítést iPhone-on? Igen, egy feltétellel. Az Apple az iOS és iPadOS 16.4 verzióban adta hozzá a webes pusht, de a WebKit megköveteli, hogy a webalkalmazást előbb hozzáadják a kezdőképernyőhöz, és hogy az engedélyt közvetlen felhasználói interakcióra válaszul kérjék, például egy feliratkozó gomb megérintésekor. Safari-lapon futó webhelynél a push nem működik. Az iOS és iPadOS 18.4 verzióban megjelent Declarative Web Push egyszerűsíti a megvalósítást, de ugyanazt a kezdőképernyős feltételt tartja fenn.

Mennyibe kerül a progresszív webalkalmazás fejlesztése az Egyesült Királyságban? Egy közepes bonyolultságú üzleti alkalmazásnál £35 000-tól £75 000-ig számoljon egyetlen PWA-kódbázis megépítésével és évi £8 000-tól £20 000-ig a karbantartásával. Az összehasonlítható natív út, külön iOS és Android alkalmazással plusz egy marketingoldallal, £110 000-tól £250 000-ig kerül megépíteni, utána pedig évi £35 000-tól £80 000-ig. Ezek brit ügynökségi sávok, nem árajánlatok, és az ismétlődő különbség rendszerint többet nyom a latban, mint az építési.

Fel lehet tenni egy PWA-t az App Store-ba vagy a Google Play-re? A Google Play-re igen, az App Store-ba nem. Androidon a Trusted Web Activity vékony natív burkolóba csomagolja a PWA-t, Digital Asset Links segítségével hitelesítve, így ugyanaz a kódbázis néhány nap csomagolási munkáért Play-adatlapot kap. Az Apple-nél nincs megfelelője, és az ellenőrzési irányelvei elégtelennek tekintik a webhely köré vont burkolót, tehát az App Store-jelenlét azt jelenti, hogy valami valóban natívat kell építeni.

Mikor érdemes natív alkalmazást választani a PWA helyett? Akkor válasszon natívot, ha zárt alkalmazás melletti háttérbeli helykövetésre, kezdőképernyős widgetekre, óra- vagy autóintegrációra, iPhone-os Bluetoothra vagy NFC-re, HealthKitre vagy alkalmazáson belüli Apple Payre, tartósan nehéz számításra, például valós idejű videofeldolgozásra, vagy valódi ügyfélszerzési csatornaként App Store-jelenlétre van szüksége. Ha ezek egyike sem áll fenn, a PWA nagyon valószínűen helyes, és a bizonyítási teher azé, aki három kódbázist akar karbantartani.