Progressive Web Apps: Când O PWA Bate Nativul

Dezvoltarea de progressive web app este opțiunea pe care cumpărătorii britanici o resping în primele zece minute ale unui proiect și o redescoperă optsprezece luni mai târziu, după ce a doua bază de cod nativă a mâncat discret bugetul. Este respinsă fiindcă aproape tot ce se scrie despre ea cade în două tabere, pledoaria care sare peste ce refuză iOS, sau scepticismul moștenit din 2019, când platforma chiar nu putea.

Ambele greșesc acum, în feluri care schimbă calculul. Safari acceptă notificări push în aplicațiile web de pe ecranul principal începând cu iOS 16.4. Chrome a renunțat la cerința unui service worker pentru instalare. În octombrie 2025 autoritatea britanică a stabilit că Apple și Google au statut de piață strategic pe browserele și motoarele lor mobile. Între timp iOS refuză în continuare execuția în fundal, evacuează datele stocate după reguli pe care nu le controlați și nu va lista niciodată o aplicație web în App Store.

Urmează versiunea pe care i-aș da-o unui client care alege între o bază de cod și trei. Fiecare capacitate citată aici a fost verificată în septembrie 2026 în documentația furnizorului, fiindcă aici ideile primite au constant doi ani vechime.

Când bate o PWA o aplicație nativă? Când utilizatorii dvs. sunt pe Android și desktop la fel de mult ca pe iPhone, când aplicația este o fațadă către un server, nu către dispozitiv, și când lumea vă găsește prin căutare, nu într-un magazin. O PWA pierde dacă aveți nevoie de localizare în fundal, widgeturi pe ecranul principal, Bluetooth pe iPhone sau facturare prin magazin. Economia este o bază de cod în loc de trei, în Regatul Unit aproximativ £40.000 până la £120.000 la construcție și apoi o factură mult mai mică în fiecare an.

Ce este de fapt o progressive web app

Termenul se folosește destul de lax încât două persoane din aceeași ședință să înțeleagă lucruri diferite. Definiția tehnică este îngustă și merită păstrată ca atare.

MDN descrie o progressive web app ca pe o aplicație construită cu tehnologii ale platformei web care oferă o experiență asemănătoare unei aplicații specifice platformei. Rulează pe mai multe platforme dintr-o singură bază de cod și poate fi instalată, folosită offline și integrată cu sistemul de operare.

În practică asta înseamnă trei artefacte, iar un site căruia îi lipsește unul dintre ele este un site cu ambiții, nu o PWA.

Manifestul aplicației web

Manifestul este un fișier JSON care îi spune sistemului de operare cum se numește aplicația, ce pictograme să folosească, ce URL să deschidă la lansare și dacă să ruleze într-un cadru de browser sau de sine stătător. Fără el, browserul nu are ce instala. Este mic, este static și este partea cea mai ieftină din tot exercițiul.

Service workerul

Un service worker este un script care rulează separat de pagină, stă între aplicație și rețea și poate răspunde cererilor dintr-un cache. El face posibil comportamentul offline și el primește mesajele push. Este și partea care o ia razna, fiindcă un cache prost delimitat servește utilizatorilor cod vechi săptămâni la rând.

HTTPS

Service workerele, push-ul, geolocalizarea și accesul la cameră sunt toate limitate la contexte securizate. Pe o găzduire modernă acest lucru este gratuit și automat, deci este o constrângere, nu un cost.

Ce înseamnă instalată, platformă cu platformă

Cumpărătorii presupun că instalarea este un singur comportament. Sunt trei, iar diferențele contează comercial.

Android

Chrome pe Android oferă cel mai apropiat lucru de paritate. Aplicația primește o pictogramă pe ecranul principal, o intrare proprie în comutatorul de aplicații, spațiu propriu de stocare și poate fi listată în Play Store printr-un înveliș. Solicitările de instalare pot fi declanșate din propria interfață după ce browserul a emis evenimentul relevant, deci controlați momentul în care întrebați.

iOS și iPadOS

Safari instalează prin meniul de partajare și prin opțiunea de adăugare pe ecranul principal. Nu există nicio solicitare de instalare în pagină pe care să o puteți declanșa, niciun banner pe care Apple să îl afișeze în locul dvs. și nicio modalitate sigură de a detecta că un utilizator a făcut-o. Acel singur decalaj de interacțiune este cea mai mare diferență practică între platforme și este o problemă de design, nu de inginerie: trebuie să învățați utilizatorul un gest.

Desktop

Chrome, Edge și Safari pe macOS instalează toate aplicațiile web în dock sau în bara de activități, cu fereastră proprie. Desktopul este locul unde PWA sunt cel mai puțin contestate și cel mai puțin folosite, mai ales pentru unelte interne unde alternativa este un build Electron pe care nimeni nu vrea să îl întrețină.

Chrome a schimbat regulile de instalabilitate și aproape niciun ghid nu a observat

Ani la rând fiecare articol repeta aceeași listă: manifest, pictograme, HTTPS și un service worker cu un handler fetch. Ultimul punct nu mai este adevărat pentru instalarea din meniu.

Google a eliminat cerința unui service worker care implementează fetch pentru instalarea din meniu, în versiunea 108 pe mobil și 112 pe desktop, și oferă acum o pagină offline implicită siturilor care nu au una proprie. Algoritmul solicitării de instalare vrea în continuare un handler fetch, dar instalabilitatea în sine nu mai depinde de el.

Efectul a ajuns până la unelte. Lighthouse și-a eliminat complet categoria PWA în versiunea 12.0.0, publicată în aprilie 2024, fiindcă acele audituri existau ca să testeze criterii care nu se mai aplicau. Dacă lanțul dvs. de build încă pică pe un scor PWA lipsă, testează ceva ce Google a retras.

Citirea practică este că instalarea și capacitatea offline au fost decuplate. Puteți livra o aplicație instalabilă fără nicio poveste offline, ceea ce este adesea prima versiune corectă, și adăugați cache după ce aflați ce ecrane folosesc oamenii cu adevărat fără semnal.

Offline este o decizie de proiectare care costă

Cuvântul offline ascunde o gamă enormă de anvergură. Un înveliș din cache care arată ultimele date cunoscute înseamnă o săptămână de lucru. O aplicație cu adevărat offline first, care pune scrierile la coadă, rezolvă conflicte și reconciliază la reconectare, este un alt produs.

Strategiile de cache

Cache-ul unui service worker se reduce la patru tipare și la o decizie pentru fiecare tip de resursă. Cache first servește copia stocată și nu verifică niciodată, ceea ce este corect pentru fonturi și pentru fișierele de build cu hash. Network first încearcă serverul și se retrage pe cache, ceea ce se potrivește datelor care trebuie să fie la zi. Stale while revalidate servește cache-ul instantaneu și împrospătează în fundal, alegerea obișnuită pentru conținut. Network only se folosește pentru orice nu trebuie servit dintr-o copie veche, cum ar fi plățile.

Greșeala aici este cel mai frecvent eșec de PWA pe care îl văd. O politică cache first aplicată învelișului aplicației va servi utilizatorilor care revin JavaScript de luna trecută până când ceva forțează o actualizare, iar rapoartele de eroare vor descrie simptome care nu există în codul dvs. actual.

Sincronizarea în fundal

Punerea scrierilor la coadă cât timp sunteți offline și golirea cozii când revine conectivitatea este scopul Background Synchronization API. MDN o listează ca având disponibilitate limitată și explicit în afara Baseline, ceea ce înseamnă că nu funcționează în unele dintre cele mai folosite browsere.

Pe iOS scrieți deci singuri soluția de rezervă: păstrați coada în IndexedDB și goliți-o la următoarea deschidere a aplicației. Funcționează, utilizatorii acceptă, iar asta înseamnă poate trei până la cinci zile de inginerie în loc de după-amiaza pe care ar fi costat-o API-ul.

Notificările push decid mai multe proiecte decât orice altceva

Dacă o singură capacitate scufundă o propunere de PWA, aceasta este, de obicei pe baza unor fapte adevărate în 2022.

Android și desktop

Push-ul web pe Chrome pentru Android, Chrome desktop, Edge și Firefox funcționează de ani buni prin Push API, Notifications API și un service worker care lucrează împreună. Livrarea este gestionată de serviciul push al producătorului de browser, permisiunea este o solicitare standard și nu există niciun decalaj notabil față de o aplicație nativă pentru cazul obișnuit în care un server trimite un mesaj unui utilizator abonat.

iOS și iPadOS

Apple a adăugat Web Push în iOS și iPadOS 16.4. Condiția atașată este partea care se pierde: WebKit precizează că aplicația web trebuie adăugată pe ecranul principal, iar permisiunea trebuie cerută ca răspuns la o interacțiune directă a utilizatorului, de exemplu o atingere pe un buton de abonare. Push-ul web nu funcționează pentru un sit aflat într-o filă Safari.

Manifestul trebuie să seteze display pe standalone sau fullscreen, iar notificările se comportă apoi ca ale oricărei alte aplicații: ecran blocat, centru de notificări, Apple Watch asociat și control per aplicație în Setări. Și insignele funcționează.

Apple a adăugat ulterior o cale mai simplă. Declarative Web Push a apărut în Safari 18.4, disponibil pe iOS și iPadOS 18.4 pentru aplicațiile web adăugate pe ecranul principal, și afișează o notificare dintr-un payload JSON standardizat fără să fie nevoie ca un service worker să ruleze. Elimină muncă. Nu elimină cerința ecranului principal.

Decalajul iOS, formulat precis

Decalajul este real și este mai mic decât reputația lui. Formularea lui exactă este mai utilă decât plângerea sau pretenția că s-a închis.

Evacuarea datelor stocate

WebKit evacuează datele siturilor pe baza celor mai puțin folosite recent, unde ultima folosire se măsoară de la ultima interacțiune a utilizatorului sau operațiune de stocare. Documentația lui despre politica de stocare fixează o cotă per origine de până la 60 % din disc pentru aplicațiile de navigare și de până la 15 % pentru celelalte aplicații, cu cote generale de 80 % și respectiv 20 %, și confirmă că o aplicație web de sine stătătoare de pe ecranul principal primește aceleași cote ca browserul.

Din asta decurg două lucruri. Stocarea nu este constrângerea pe care o imaginează lumea, iar evacuarea este un risc de programare, nu de capacitate. Tratați dispozitivul drept cache și serverul drept registru, iar evacuarea încetează să fie un defect de produs.

Execuția în fundal

Nu există echivalent al unei sarcini native de fundal pe iOS. Fără preluare periodică, fără localizare în fundal, fără procesare tăcută cât timp aplicația este închisă. Orice trebuie să se întâmple după un orar se întâmplă pe serverul dvs. și ajunge la dispozitiv printr-un mesaj push pe care utilizatorul îl vede.

Nicio prezență în App Store

O PWA nu poate fi listată în App Store. Dacă o parte semnificativă dintre clienții dvs. se așteaptă să caute marca în magazin și să vă găsească acolo, aceea nu este o problemă de inginerie pe care să o puteți rezolva pe web.

Motoarele de browser, DMA și CMA

Aceasta este partea în care relatările depășesc sursele primare, deci merită să rămânem strict la ce este documentat cu adevărat.

Apple permite acum motoare de browser alternative și este explicit că acest lucru se aplică doar în Uniunea Europeană, pe iOS 17.4 sau mai nou și iPadOS 18 sau mai nou, prin două drepturi acordate dezvoltatorilor care îndeplinesc criterii publicate de securitate, confidențialitate și suite de teste. Apple cere trecerea a 90 % din Web Platform Tests și a 80 % din Test262, funcționarea fără JIT și rezolvarea majorității vulnerabilităților în 30 de zile.

Pentru o firmă britanică nimic din toate acestea nu schimbă nimic astăzi. Drepturile sunt legate de jurisdicție, iar un utilizator britanic pe un operator britanic rulează WebKit indiferent ce pictogramă de browser a atins.

Poziția britanică se mișcă separat. Pe 22 octombrie 2025 CMA a stabilit că Apple și Google au statut de piață strategic pe platformele lor mobile, acoperind sistemele de operare, distribuția de aplicații, browserele și motoarele de browser, pentru o perioadă de cinci ani. Desemnarea este puterea de a impune cerințe de conduită, nu cerințele în sine. Planificați cu platforma așa cum se comportă azi și tratați orice relaxare drept câștig.

Hardware și API-uri de dispozitiv, verificate în loc de presupuse

Webul nu poate accesa hardware este obiecția pe care o aud cel mai des și cea care se dovedește cel mai des greșită într-un caz concret.

Ce funcționează practic peste tot

Accesul la cameră și microfon prin getUserMedia este Baseline pe MDN și funcționează în toate browserele din 2017. Geolocalizarea, orientarea dispozitivului, încărcarea de fișiere inclusiv captura cu camera pe mobil, accesul la clipboard, Web Share API pe mobil și passkey-urile prin WebAuthn cu Face ID sau o amprentă drept autentificator funcționează toate în browserele mobile actuale. Citirea codurilor de bare și a codurilor QR din fluxul camerei este rutină.

Pentru marea majoritate a aplicațiilor de business, acea listă este întreaga nevoie de hardware.

Ce ține doar de Chromium și, pe mobil, practic doar de Android

Web Bluetooth este documentat de Google ca disponibil pe ChromeOS, Chrome pentru Android 6.0, macOS de la Chrome 56 și Windows 10 de la Chrome 70, fără suport iOS listat, iar MDN îl marchează cu disponibilitate limitată în loc de Baseline. Web NFC este și mai îngust: Google îl documentează ca disponibil pe Android în Chrome 89.

File System Access API pentru citirea și scrierea fișierelor alese de utilizator este la fel teritoriu Chromium, deși origin private file system acoperă în toate browserele majoritatea nevoilor de stocare internă ale unei aplicații.

Distribuția prin magazine este o chestiune comercială, nu tehnică

Echipele se ceartă despre distribuția prin magazine ca și cum ar fi vorba de capacitate. Este vorba de patru variabile comerciale, iar una singură favorizează magazinul fără echivoc.

Descoperirea este avantajul onest. Consumatorii chiar caută în App Store și în Play după marcă și după categorie, iar o firmă fără prezență în magazin renunță la acel canal. Contează enorm pentru un produs de larg consum cu un nume recognoscibil și foarte puțin pentru o unealtă folosită de 200 de angajați ai unei singure companii.

Încrederea este reală și asimetrică în funcție de public. Utilizatorii mai în vârstă și mai puțin tehnici citesc o fișă din magazin drept semnal de siguranță. Cei mai tineri tot mai puțin, iar același utilizator va folosi bucuros situl unei bănci de pe același telefon.

În contrapartidă, un magazin adaugă o coadă de revizuire între dvs. și utilizatori, un risc de respingere pe reguli care se schimbă și un comision pe tot ce vindeți în aplicație. O PWA nu are nimic din toate astea. Livrați când decideți dvs., iar o corecție critică ajunge la fiecare utilizator la următoarea încărcare, nu după o revizuire.

Cât rețin de fapt magazinele

Cifrele de comision se mișcă suficient de des încât să fie neînțelept să le citați din memorie. Acestea sunt condițiile publicate chiar de furnizori, verificate în septembrie 2026.

Apple percepe 30 % drept comision standard pe bunuri și servicii digitale. App Store Small Business Program îl reduce la 15 % pentru dezvoltatorii cu venituri de până la 1.000.000 USD în anul calendaristic precedent, dezvoltatorii noi fiind eligibili, iar tariful standard revine pe vânzările viitoare odată ce depășiți pragul într-un an.

Google publică un comision de serviciu pentru Google Play pe trepte: 15 % pe primul milion de USD din venitul dezvoltatorului în fiecare an, 30 % peste, și 15 % pe abonamentele cu reînnoire automată indiferent de venit. Aceeași pagină prezintă o structură diferită care intră în vigoare pe 30 iunie 2026 pentru SEE, Regatul Unit și Statele Unite, bazată pe 10 % sau 20 % plus un comision de facturare de 5 %, după cum instalarea este nouă sau existentă.

Ambii furnizori publică în USD. Vânzarea unui abonament lunar de £9,99 printr-un magazin costă circa £18 pe an per abonat la 15 % și circa £36 la 30 %. Înmulțiți cu numărul dvs. de abonați înainte de a considera magazinul gratuit.

Puteți totuși publica o PWA prin Google Play

Android vă dă ambele opțiuni deodată, ceea ce este o asimetrie reală în comparația dintre platforme și este rar menționată.

O Trusted Web Activity este o aplicație Android care deschide propria dvs. PWA pe tot ecranul, fără cadrul browserului, verificată ca fiind a dvs. prin Digital Asset Links. Cere Chrome pe Android 72 sau mai nou, iar aplicația gazdă nu are acces la cookie-urile sau la stocarea conținutului web. În practică este un înveliș subțire generat din manifestul dvs. și trimis la Play ca orice altă aplicație.

Pe Android alegerea nu este deci magazin sau web. Publicați PWA, o împachetați și obțineți în plus fișa din magazin, din aceeași bază de cod, pentru câteva zile de împachetare și taxa anuală de cont de dezvoltator.

Pe iOS nu există echivalent. Ghidurile de revizuire ale Apple tratează de multă vreme un înveliș în jurul unui sit drept insuficient în sine, deci calea magazinului iOS înseamnă să construiți ceva cu adevărat nativ. Acea asimetrie, mai mult decât orice decalaj de API, dă forma tabelului de costuri de mai jos.

Costul dezvoltării de progressive web app față de două baze de cod native

Comparația pe care o face lumea este costul de construcție, care este jumătatea mai mică. Comparația care decide rezultatul este costul total pe trei ani, fiindcă cheltuiala pentru nativ se repetă.

Citiți-le ca intervale de agenție britanică pentru o aplicație de business de complexitate medie, nu ca o ofertă. O PWA de forma aceasta înseamnă de obicei o echipă de doi sau trei ingineri, timp de trei până la cinci luni. Două baze de cod native plus o prezență web înseamnă trei echipe, trei procese de lansare și trei seturi de actualizări de platformă în fiecare an.

Distanța dintre primul și al treilea rând, aproximativ £75.000 până la £175.000 la construcție și £27.000 până la £60.000 pe an după aceea, este ce cumpărați când cumpărați nativ. Uneori sunt bani bine cheltuiți. Ar trebui să fie o decizie, nu o setare implicită. Paginile noastre de dezvoltare de site-uri web și dezvoltare software arată cum încadrăm ambele căi.

Unde se duc de fapt banii de întreținere

Costul de construcție se negociază. Costul de întreținere se descoperă, iar acolo eșuează în tăcere, nu zgomotos, proiectele cu mai multe baze de cod.

Platformele native vă impun muncă în fiecare an. Versiunile majore noi de sistem depreciază API-uri, semnarea și provizionarea se schimbă, nivelurile minime de SDK cresc, iar politicile magazinelor adaugă cerințe precum manifestele de confidențialitate și declarațiile de siguranță a datelor. Nimic din toate acestea nu livrează o funcționalitate. Pe două platforme o plătiți de două ori, după un calendar stabilit de altcineva.

Apoi vine derapajul. Două baze de cod care implementează aceeași funcționalitate diverg, iar divergența iese la suprafață ca tichete de asistență care se reproduc pe o singură platformă. Fiecare decizie de produs trebuie luată de două ori și apoi reconciliată, iar costul de coordonare nu apare pe nicio factură.

O PWA înlocuiește toate acestea cu evoluția browserelor, care este continuă, retrocompatibilă și aproape niciodată nu strică un cod care funcționează. Munca recurentă înseamnă propriile dvs. actualizări de dependențe, corecții de securitate și găzduire, adică aceeași întreținere de care are deja nevoie orice aplicație web personalizată.

Comparația care contează nu este între două cifre dintr-o ofertă. Este o echipă contra trei, în fiecare an, cât timp trăiește produsul.

Performanță și Core Web Vitals pentru o PWA

O aplicație instalată este judecată față de nativ, deci ștacheta de performanță este mai sus decât pentru un sit, nu mai jos. Vestea bună este că metricile sunt publice, iar pragurile sunt fixe.

Core Web Vitals constă în prezent din trei metrici, fiecare evaluată la percentila 75 a încărcărilor de pagină și separată între mobil și desktop. Largest Contentful Paint este bun la 2,5 secunde sau mai puțin și slab peste 4,0. Interaction to Next Paint, care a înlocuit First Input Delay când a devenit stabil în 2024, este bun la 200 de milisecunde sau mai puțin și slab peste 500. Cumulative Layout Shift este bun la 0,1 sau mai puțin și slab peste 0,25.

O PWA are aici un avantaj structural. Un service worker care servește învelișul din cache face vizitele repetate aproape instantanee, ceea ce este exact tiparul pe care îl produce o aplicație instalată, așa că datele reale ale unei PWA instalate arată de obicei mai bine decât același cod vizitat la rece într-un browser.

Are și un risc structural. Framework-urile de tip single page împing munca spre client, iar INP este metrica ce pedepsește asta. Dacă vă luptați deja cu aceste cifre, ghidul nostru despre trecerea Core Web Vitals tratează diagnosticul mai în adâncime decât poate acest articol.

SEO este avantajul pe care nimeni nu îl pune în calcul

Acesta este argumentul pe care l-aș pune primul în majoritatea cazurilor comerciale și lipsește aproape întotdeauna cu totul din comparație.

O PWA este un sit web. Fiecare ecran are un URL, fiecare URL poate fi accesat cu crawlerul, indexat, legat și partajat, și fiecare poate să se claseze. O aplicație nativă nu are nimic din toate astea. Fișele din magazine sunt indexate superficial și se clasează într-o grădină îngrădită, pe semnale complet diferite, iar conținutul din aplicație este invizibil pentru căutare.

Consecința se acumulează. Bugetul de marketing pentru o aplicație nativă cumpără instalări și se oprește în ziua în care se oprește cheltuiala. Același buget pus în conținut și în calitate tehnică pentru o PWA cumpără o pagină care continuă să se claseze. Pe trei ani, acea diferență depășește frecvent întregul cost de construcție al oricăreia dintre căi.

Se plătește doar dacă implementarea poate fi parcursă de crawler, și aici greșesc aplicațiile randate pe client: a randa totul în JavaScript cu un singur URL și fără HTML generat pe server pierde avantajul complet. Randarea pe server sau prerandarea rutelor indexabile este soluția, iar un audit SEO tehnic înainte de lansare costă mult mai puțin decât să descoperiți după șase luni că nu s-a indexat nimic.

Cerințele care descalifică

Decizia este mai ușoară ca listă de veto decât ca listă de beneficii, fiindcă vetourile sunt obiective.

Aveți nevoie de nativ dacă vreunul dintre punctele următoare este o cerință reală și nu o dorință. Urmărirea locației în fundal cât timp aplicația este închisă. Widgeturi pe ecranul principal, aplicații de ceas sau integrarea cu CarPlay și Android Auto. Bluetooth sau NFC pe iPhone. HealthKit, Apple Pay în aplicație sau orice integrare adâncă cu sistemul pe care Apple nu a deschis-o webului. Facturarea prin magazin pentru bunuri digitale, acolo unde politica magazinului o cere. Calcul greu și susținut, precum prelucrarea video în timp real sau randarea 3D la cadre native. Prezența în App Store ca cerință de marketing de care afacerea dvs. chiar depinde.

Dacă niciunul dintre aceste puncte nu se aplică, o PWA este foarte probabil răspunsul corect, iar sarcina probei revine celui care vrea trei baze de cod.

Alte două considerații înclină și mai mult balanța. Dacă utilizatorii dvs. sunt preponderent pe desktop sau pe Android, decalajele iOS ating o minoritate a publicului. Iar dacă aplicația este o fațadă către propriul dvs. server, nu către dispozitiv, ceea ce descrie majoritatea software-ului de business, capacitățile dispozitivului contează abia.

Scenariul unu: servicii de teren pentru un contractor de facilități

Două sute de tehnicieni, fișe de lucrare, fotografii ale lucrărilor terminate, captură de semnătură, semnal slab în camere tehnice și subsoluri. Acesta este cazul despre care lumea presupune că cere nativ și este cazul în care o PWA câștigă cel mai limpede.

Fiecare cerință este acoperită. Camera funcționează prin getUserMedia. Semnăturile sunt un element canvas. Datele lucrărilor se pun în cache în IndexedDB, iar coada de scriere se golește la reconectare, scrisă de mână fiindcă Background Sync nu este de încredere în toate browserele. Alertele de dispecerat pleacă drept push web, care funcționează pe Android și pe iOS pentru tehnicienii care au adăugat aplicația pe ecranul principal, iar instalarea este un punct de cinci minute în instruirea de început, nu o problemă de achiziție de utilizatori.

Nu există cerință de descoperire în magazin, fiindcă utilizatorii sunt angajați. Nu există facturare, deci comisionul este irelevant. Dispozitivele sunt mixte, Android și iOS, exact cazul care pedepsește cel mai tare două baze de cod native.

Construiți o PWA pentru poate £45.000 până la £70.000 în loc de două aplicații native la £120.000 până la £200.000, livrați corecțiile în aceeași după-amiază în loc să treceți printr-o revizuire, și puneți diferența în backendul de dispecerat, care chiar decide dacă lucrul funcționează.

Scenariul doi: un lanț de saloane care vrea rezervări și memento-uri

Paisprezece filiale, adresat consumatorilor, programare de întâlniri, memento-uri, un program de fidelitate, plăți încasate la casă și nu în aplicație. Instinctul spune aplicație nativă fiindcă au concurenții una.

Lista de cerințe nu are nimic remarcabil: formulare de rezervare, un calendar, memento-uri, o zonă de cont. Memento-urile sunt singurul punct interesant și sunt servite mai bine de SMS și e-mail decât de push pe piața aceasta, fiindcă o clientă care rezervă de două ori pe an nu va fi instalat nimic.

Descoperirea este factorul decisiv și favorizează webul fără drept de apel. Lumea găsește saloane prin căutare și prin hărți, nu răsfoind un magazin de aplicații, deci paginile care descriu serviciile și preiau rezervările trebuie să se claseze. O aplicație nativă este complet invizibilă pentru asta. Costul sitului în sine este adevărata linie de buget, cu stratul de aplicație adăugat deasupra ca instalabilitate.

Construiți cum trebuie situl de rezervări, faceți-l instalabil ca cliente fidele să îl țină pe ecranul principal, și adăugați push web pentru minoritatea care acceptă. O construcție nativă cheltuie aici £80.000 sau mai mult ca să atingă mai puțini clienți decât atinge deja situl.

Scenariul trei: un produs de fitness pe abonament

Antrenamente ghidate, conținut video, o integrare cu un dispozitiv purtabil, £12,99 pe lună, vândut direct consumatorului, creștere finanțată prin achiziție plătită. Scenariul acesta merge în cealaltă direcție și merită arătat de ce.

Descoperirea în magazin contează aici, fiindcă fitnessul este o categorie de răsfoit, iar o fișă este un canal real de achiziție. Integrarea cu purtabilul înseamnă HealthKit, la care webul nu ajunge. Sunetul în fundal și comportamentul ecranului în timpul unui antrenament sunt mai bune pe nativ. Descărcarea de video pentru folosire offline la scară este realizabilă pe web, dar nu comodă.

Facturarea este partea interesantă. Comisionul de magazin pe £12,99 pe lună înseamnă circa £23 pe an per abonat la 15 % și £47 la 30 %, ceea ce la 20.000 de abonați face £460.000 până la £940.000 pe an. Acesta este un argument puternic pentru a încasa pe web și a trata aplicația drept client, ceea ce fac acum câteva produse mari pe abonament.

Răspunsul înseamnă aplicații native pentru produs și o PWA sau o aplicație web obișnuită pentru înscriere, facturare și marketing de conținut. Ambele există, iar împărțirea este deliberată, nu accidentală.

Cum decideți într-o după-amiază

Decizia nu are nevoie de o fază de descoperire. Are nevoie de patru răspunsuri, scrise.

Întâi, listați capacitățile de dispozitiv de care aveți cu adevărat nevoie, apoi verificați fiecare în documentația furnizorului, nu într-un rezumat. Majoritatea listelor se scurtează dramatic la pasul acesta. Al doilea, stabiliți de unde vin utilizatorii: dacă răspunsul este căutarea, webul are deja avantajul, iar dacă este răsfoirea magazinului, nu îl are.

Al treilea, cotați toate cele trei căi pe trei ani, nu pe unul, incluzând cifrele de întreținere de mai sus, și includeți comisionul magazinului pe tot ce plănuiți să vindeți. Al patrulea, fiți sinceri despre echipa dvs. O bază de cod întreținută de trei ingineri livrează mai mult decât trei baze de cod întreținute de trei ingineri, de fiecare dată.

Dacă răspunsul rămâne ambiguu după asta, construiți întâi PWA. Este opțiunea mai ieftin de inversat. Trecerea de la o PWA la nativ mai târziu înseamnă să scrieți clienții nativi peste un API care există deja și s-a dovedit, iar drumul invers înseamnă să o luați de la capăt. Acea asimetrie valorează mai mult decât majoritatea comparațiilor de funcționalități de mai sus.

Unde vă lasă asta

Dezvoltarea de progressive web app nu este un compromis pentru cei care nu își permit nativ și nu este nici un răspuns universal. Este arhitectura corectă pentru o categorie definită și mare de produse: software de business, unelte interne, sisteme de rezervare și de cont, produse de conținut și tot ce are clienți care ajung prin căutare.

Decalajele iOS sunt reale, precise și în mare parte ocolibile, nu fatale. Push-ul funcționează dacă utilizatorul instalează. Stocarea este generoasă, dar poate fi evacuată. Execuția în fundal nu există și oricum îi este locul pe serverul dvs. Bluetooth și NFC nu funcționează pe iPhone și nicio cantitate de inginerie nu schimbă asta.

Mecanik construiește ambele căi și vă va spune când răspunsul este nativ. Dacă vreți comparația făcută pe cerințele dvs. reale, nu pe o listă generică, paginile de dezvoltare de site-uri web și dezvoltare software descriu cum o încadrăm, iar ghidul nostru despre construirea unei aplicații web în 2026 tratează deciziile de stivă care decurg din asta.

Întrebări frecvente

Ce este o progressive web app? O progressive web app este o aplicație construită cu tehnologii web care se comportă ca o aplicație specifică platformei. Tehnic, este o aplicație web servită prin HTTPS cu un manifest care îi descrie numele, pictogramele și comportamentul la lansare, plus un service worker care poate servi cereri dintr-un cache și primi mesaje push. MDN o definește drept software care rulează pe mai multe platforme dintr-o singură bază de cod, rămânând instalabil și capabil să funcționeze offline.

Poate o PWA să trimită notificări push pe iPhone? Da, cu o condiție. Apple a adăugat Web Push în iOS și iPadOS 16.4, dar WebKit cere ca aplicația web să fi fost mai întâi adăugată pe ecranul principal și ca permisiunea să fie cerută ca răspuns la o interacțiune directă a utilizatorului, de exemplu atingerea unui buton de abonare. Push-ul nu funcționează pentru un sit care rulează într-o filă Safari. Declarative Web Push, adăugat în iOS și iPadOS 18.4, simplifică implementarea, dar păstrează aceeași cerință a ecranului principal.

Cât costă dezvoltarea unei progressive web app în Regatul Unit? Pentru o aplicație de business de complexitate medie, așteptați-vă la £35.000 până la £75.000 pentru construirea unei singure baze de cod PWA și la £8.000 până la £20.000 pe an pentru întreținere. Calea nativă comparabilă, cu aplicații iOS și Android separate plus un sit de prezentare, costă £110.000 până la £250.000 la construcție și £35.000 până la £80.000 pe an după aceea. Sunt intervale de agenție britanică, nu oferte, iar diferența recurentă contează de obicei mai mult decât cea de construcție.

Se poate pune o PWA în App Store sau în Google Play? În Google Play da, în App Store nu. Pe Android, o Trusted Web Activity învelește PWA într-un strat nativ subțire verificat prin Digital Asset Links, așa că aceeași bază de cod primește o fișă în Play pentru câteva zile de împachetare. Apple nu are echivalent, iar ghidurile sale de revizuire tratează un înveliș în jurul unui sit drept insuficient, deci o prezență în App Store înseamnă să construiți ceva cu adevărat nativ.

Când ar trebui să alegeți o aplicație nativă în locul unei PWA? Alegeți nativ când aveți nevoie de urmărirea locației în fundal cât timp aplicația este închisă, de widgeturi pe ecranul principal, de integrări cu ceasul sau cu mașina, de Bluetooth sau NFC pe iPhone, de HealthKit sau Apple Pay în aplicație, de calcul greu și susținut precum prelucrarea video în timp real, sau de prezență în App Store drept canal real de achiziție. Dacă niciuna nu se aplică, o PWA este foarte probabil corectă, iar sarcina probei revine celui care vrea să întrețină trei baze de cod.