PWA: ce este, când aduce ROI și capcanele iOS

O Progressive Web App (PWA) este o aplicație web care folosește API-uri moderne ale browserului pentru a oferi o experiență apropiată de cea nativă: se poate instala pe home screen, funcționează parțial fără conexiune și poate trimite push notifications. Nu este un framework separat, ci un set de capabilități adăugate peste o aplicație web obișnuită.

Termenul a fost introdus de Google în 2015 și s-a maturizat odată cu adoptarea Service Workers în toate browserele majore. Atracția principală este că distribui o singură bază de cod web și ocolești review-ul din App Store, dar iOS a pus bariere care îngreunează această promisiune.

Ce este o PWA (Progressive Web App) mai exact?

O aplicație web care îndeplinește trei criterii cumulative:

• Progresivă. Funcționează pe orice browser, inclusiv pe cele fără suport PWA. Capabilitățile avansate (instalare, offline, push) se activează progresiv dacă browserul le permite.
• Instalabilă. Utilizatorul poate adăuga aplicația pe home screen fără App Store. Pe Android, Chrome afișează automat un banner de instalare dacă sunt îndeplinite criteriile; pe iOS, utilizatorul trebuie să acceseze manual opțiunea din Safari.
• Conectivitate independentă. Un service worker interceptează cererile de rețea și poate servi răspunsuri din cache când conexiunea lipsește sau este lentă.

O PWA nu este o aplicație nativă cu branding web. Nu are acces la toate API-urile hardware ale dispozitivului și nu apare implicit în App Store. Este o aplicație web cu un strat de capabilități adăugat deasupra.

Care sunt componentele tehnice obligatorii: manifest, service worker, HTTPS?

O PWA minimă are trei componente. Fără toate trei, browserul nu o va trata ca instalabilă:

• Web App Manifest. Un fișier JSON referit din <link rel="manifest"> care descrie aplicația: name, short_name, icons (cel puțin 192px și 512px), start_url, display (de obicei standalone sau minimal-ui), theme_color și background_color. Fără manifest corect completat, browserul nu oferă posibilitatea de instalare.
• Service Worker. Un script JavaScript care rulează separat de pagina principală, într-un fir de execuție propriu, și acționează ca un proxy programatic între aplicație și rețea. Interceptează cererile fetch și poate răspunde din cache sau din rețea, după o strategie aleasă de dezvoltator. Strategiile comune sunt cache-first (servește din cache, actualizează în fundal), network-first (încearcă rețeaua, cade pe cache la eroare) și stale-while-revalidate (servește imediat din cache și actualizează cache-ul în paralel). Biblioteci precum Workbox simplifică implementarea acestor strategii fără a scrie manual interceptorii.
• HTTPS obligatoriu. Service Workers funcționează numai pe origini HTTPS (plus localhost pentru dezvoltare). Fără certificat valid, browserul nu va înregistra service worker-ul, indiferent de restul configurației.

Pe lângă aceste trei, o PWA complet capabilă poate folosi Push API (notificări trimise de server), Background Sync (trimiterea cererilor amânate când rețeaua revine) și Badge API (numere afișate pe iconița de pe home screen). Aceste API-uri au suport variabil pe iOS față de Android.

Care sunt capcanele iOS: instalare neevidentă, push limitat, storage limits?

Promisiunea PWA de „un singur cod pentru toate platformele" se lovește de restricțiile Safari pe iOS. Dacă publicul tău folosește iPhone în proporție semnificativă, acestea nu sunt detalii de ignorat:

• Fără install prompt automat. Pe Android, Chrome afișează un banner de instalare dacă PWA-ul îndeplinește criteriile. Pe iOS nu există echivalent: utilizatorul trebuie să deschidă manual meniul Share din Safari și să aleagă „Add to Home Screen". Rata de instalare pe iOS este semnificativ mai mică decât pe Android.
• Push notifications abia din iOS 16.4, cu condiții. Apple a adăugat suport pentru Web Push în Safari 16.4 (martie 2023), dar numai pentru PWA-uri deja instalate pe home screen. Un site deschis ca tab obișnuit în Safari nu primește push. Dacă aplicația depinde de push pentru engagement, calculează acoperirea pe baza ratei de instalare efective, nu a bazei de utilizatori iOS totale.
• Storage mai strict. Safari pe iOS aplică un plafon de stocare mai mic față de Chrome pe Android (tipic 50 MB). Aplicațiile care stochează seturi mari de date sau resurse media în cache pot atinge plafonul în uz normal; sistemul poate șterge cache-ul PWA când dispozitivul intră sub pragul de spațiu liber.
• Background Sync și starea service worker-ului sunt mai puțin fiabile. Background Sync are suport incomplet pe iOS, iar iOS poate termina service worker-ul mai agresiv decât Android când aplicația trece în fundal. Funcționalitățile offline-first care depind de sincronizare în fundal trebuie testate explicit pe dispozitiv fizic iPhone, nu presupuse ca funcționale din documentație.

Cum testezi o PWA înainte de production?

Testarea corectă necesită mai mulți pași. Un audit de tool nu este suficient pentru a detecta problemele de comportament real:

• Lighthouse PWA audit. Chrome DevTools include auditul Lighthouse care verifică prezența manifestului, service worker-ul, HTTPS și criteriile de bază. Auditul include și Core Web Vitals, care influențează percepția de performanță la prima deschidere. Un scor bun la Lighthouse confirmă criteriile tehnice minime, dar nu testează comportamentul offline sau instalarea pe iOS.
• Chrome DevTools, tab Application. Permite inspectarea manifestului, service worker-ului (stare: activat, în așteptare, erori), cache-ului (resurse stocate și strategie) și storage-ului (spațiu consumat). Este primul loc în care verifici dacă service worker-ul s-a înregistrat corect.
• Test manual pe iOS. Deschide aplicația în Safari pe un dispozitiv fizic, adaugă pe home screen și verifică lansarea în modul standalone. Testează deconectarea: utilizatorul trebuie să vadă un ecran offline funcțional, nu o eroare de rețea goală.
• Test offline pe Android. Chrome DevTools permite simularea offline din tab Network (checkbox Offline). Verifică că aplicația răspunde din cache și că eroarea de rețea este comunicată clar utilizatorului.

Pentru monitorizarea în producție, integrează metricile de eroare din service worker în stack-ul de observabilitate: erorile de fetch interceptate și ratele de cache hit/miss sunt semnale valoroase pentru a înțelege dacă PWA-ul funcționează corect în condiții reale.

Când o PWA înlocuiește o aplicație nativă și când nu?

Decizia nu este o preferință de arhitectură; este un calcul pe baza cerințelor concrete:

PWA câștigă față de nativ când:

• Distribuția contează mai mult decât capabilitățile hardware. Fără install din store, fără review de versiune. Update-urile sunt instant, ceea ce contează pentru produse cu iterații frecvente. Similar cu logica din spatele OTA updates în ecosistemul mobil nativ: codul ajunge la utilizator imediat, fără intermediar.
• Buget limitat, o singură echipă web. O echipă care stăpânește deja Angular, React sau Vue adaugă capabilități PWA fără developeri iOS și Android separați. Dacă funcționalitățile cerute sunt acoperite de API-urile web, costul de mentenanță pe termen lung este semnificativ mai mic.
• Aplicație B2B sau internă. Pentru dashboard-uri și portaluri interne unde utilizatorii sunt angajați cu dispozitive gestionate, barierele de instalare iOS pot fi depășite prin instrucțiuni explicite. Distribuția prin store nu este un avantaj relevant.

Nativul câștigă când:

• Acces hardware specific. Bluetooth LE, NFC, acces avansat la cameră, AR prin ARKit sau ARCore. Acestea fie nu sunt disponibile în API-urile web, fie au performanță semnificativ mai slabă față de nativ.
• Background tasks intense. Procesare audio sau video în fundal, sincronizare frecventă, notificări complexe cu acțiuni: iOS restricționează agresiv aceste scenarii pentru PWA.
• Discovery prin store. Dacă achiziția de utilizatori depinde de App Store Optimization sau dacă publicul tău caută aplicații în store, prezența nativă este necesară.

Există și varianta hibridă (React Native, Flutter, Capacitor) care partajează logica business și livrează aplicații native. O PWA servită prin server-side rendering reduce semnificativ timpul până la primul conținut vizibil; service worker-ul preia controlul după prima încărcare pentru vizitele ulterioare.