Între 2017 și 2020, PWA a fost un hype-cycle tehnologic. Conferințe, articole pe bloguri, suport oficial din partea Google și Microsoft. Apoi a venit dezamăgirea — iOS a ținut API-urile cheie închise, promptul de instalare s-a dovedit confuz, iar marketingul aplicațiilor native era în continuare mai puternic. Comunitatea s-a mutat spre Flutter, React Native și Capacitor.
Dar, în liniște, s-a mai întâmplat ceva. Tehnologia PWA a continuat să se maturizeze. Apple a completat în ultimii ani API-urile lipsă, browserele au îmbunătățit fluxul de instalare, iar specificația service worker s-a stabilizat. Iar pentru echipele de produs fără bugete mari, PWA a devenit o soluție surprinzător de solidă.
Acest articol este un studiu de caz onest despre Trefa.app — o aplicație de pronosticuri pentru companii, construită ca PWA — după un an în producție. Ce a funcționat, ce nu a funcționat și cui i-aș recomanda azi PWA.
Context: ce este Trefa.app
Trefa.app este o aplicație web pentru un concurs de pronosticuri de companie. Utilizatorul se autentifică prin Google, își creează o ligă pentru firma sa, își invită colegii printr-un link sau un cod QR, iar toți fac împreună pronosticuri pentru rezultatele meciurilor. Aplicația sincronizează date din API-uri sportive (NHL, Premier League, campionate mondiale) și recalculează punctele în timp real.
Frontend-ul este Next.js 16 + React 19 + Tailwind, găzduit pe Vercel. Backend-ul este Django 5 + DRF + Channels pe Hetzner. Între ele, PostgreSQL pe Supabase și Redis pentru comunicarea în timp real.
Un detaliu plăcut: nu există nicio aplicație nativă iOS sau Android. PWA este singurul client. Utilizatorii de pe iPhone, Android, Windows și macOS folosesc exact același lucru.
De ce am ales PWA în locul aplicațiilor native
Decizia a fost, în mare parte, economică. O aplicație nativă ar fi însemnat:
- Dezvoltarea a doi clienți paraleli (iOS Swift + Android Kotlin), sau a unui framework cross-platform (Flutter, React Native).
- Procesul de submisie App Store + Google Play — taxă de submisie, întârzieri la review, republicare periodică la fiecare schimbare a API-ului din backend.
- Notificări push prin APNs și FCM, două infrastructuri separate, două procese de certificare diferite.
- Fluxul de update prin magazine — utilizatorul trebuie să actualizeze activ, iar o parte rămâne luni de zile pe o versiune mai veche.
Pentru un produs cu un public-țintă relativ mic (echipe de companie, nu mass-market), costul dezvoltării native era semnificativ mai mare decât beneficiul. PWA a eliminat dintr-odată toate punctele de mai sus.
Avantaje tehnice pe care utilizatorii nu le observă
Aceasta e partea pe care aș fi subestimat-o înainte de lansarea în producție. Din perspectiva dezvoltării, PWA aduce o serie de avantaje concrete care economisesc săptămâni de muncă pe an:
Deploy-ul este instant. Push în main → Vercel face build → în 2 minute, versiunea nouă ajunge la toți utilizatorii. Fără submisie, fără așteptare, fără jonglat cu versiuni de client compatibile cu backend-ul. Dacă fac o schimbare breaking în API, a doua zi pot livra un fix și toată lumea îl are imediat.
Un singur cod pentru tot. iOS, Android, Windows, macOS, Linux — aceeași aplicație peste tot. Fără bug-uri specifice unei platforme ("asta se strică doar pe iPhone 13 în dark mode"), fără implementare duplicată.
Drum scurt către utilizator. Trimiți un link, dai click, ești în aplicație. Fără „descarcă aplicația noastră din App Store, înregistrează-te și apoi autentifică-te". Pentru produse B2B cu frecvență scăzută de utilizare (concursul de pronosticuri funcționează doar în timpul unui turneu sportiv), acesta este un beneficiu uriaș de conversie.
Notificările push funcționează chiar și fără instalare. Service worker-ul înregistrează abonamentul push. Când utilizatorul dă click pe „Permite notificări", începe să primească alerte înainte de meciuri, indiferent dacă a adăugat aplicația pe ecranul de start sau doar a deschis-o ocazional în Safari.
Ce nu poate face PWA (secțiunea onestă)
Aici onestitatea contează mai mult decât marketingul. PWA are limite reale, de care ne-am lovit în producție.
Notificările push pe iOS au particularități. Apple Web Push există din iOS 16.4, dar funcționează doar dacă utilizatorul a adăugat PWA pe ecranul de start. Dacă folosește aplicația prin tab-uri Safari, abonamentul push nu se salvează. Este o fricțiune pe care aplicațiile native nu o au.
Prezența în App Store lipsește. Pentru unele buyer persona (departamente HR, manageri IT din corporații), „nu e în App Store" echivalează cu „nu e serioasă". Subiectiv, dar real.
Unele API-uri de sistem de operare nu sunt disponibile. Bluetooth Low Energy, NFC, acces profund la sistemul de fișiere — pentru o aplicație obișnuită nu contează, dar dacă ai nevoie de aceste funcționalități, PWA te limitează.
Modul offline este posibil, dar nu automat. Service worker-ul trebuie configurat manual, strategiile de cache gândite, cozile de sincronizare implementate. Pentru o aplicație complet offline-first, e mai multă muncă decât își imaginează dezvoltatorii.
Benchmark de performanță vs. nativ: PWA este mai lentă cu ~15–25 % la primul load (din cauza parsării bundle-ului JS) și cu ~5–10 % în interacțiunea obișnuită. Pentru majoritatea aplicațiilor, diferența e imperceptibilă; pentru gaming hardcore sau editare video, e un deal-breaker.
Rezultate după un an în producție
Date concrete de la Trefa.app după un an de funcționare:
- Stabilitate cross-platform — o echipă de dezvoltare de o singură persoană întreține aplicația pe toate sistemele de operare fără bug-uri specifice. Același ciclu de testare pentru toate.
- Frecvența deploy-urilor — în medie 3–5 deploy-uri pe săptămână prin Vercel. Niciunul dintre ele nu se lovește de întârzieri de submisie App Store.
- Notificări push — ~70 % dintre utilizatori activi, rata de livrare push ~95 % pe Android, ~85 % pe iOS (din cauza cerinței de instalare pe ecranul de start).
- Fără taxe App Store — economie de cca. 70 USD pe an la conturile de dezvoltator, plus cca. 30 % comision pe tranzacții (care altfel ar fi amenințat achizițiile in-app).
Principalul beneficiu de business, până la urmă, nu a fost tehnic. A fost viteza de iterație. Dacă un client scria „mi-ar fi de folos funcția asta", de obicei o începeam în aceeași zi și era în producție într-o săptămână. La o aplicație nativă, pur și simplu nu se poate așa.
Cui i-aș recomanda azi PWA
PWA se potrivește dacă se aplică cel puțin două dintre următoarele:
- Ai resurse limitate și nu-ți poți permite două aplicații native plus o versiune web.
- Utilizatorii tăi folosesc aplicația ocazional (nu zilnic), deci fricțiunea scăzută la prima deschidere contează.
- Aplicația ta nu are nevoie de API-uri hardcore de sistem de operare (Bluetooth, NFC, sistem de fișiere complet).
- Vrei să faci deploy fără porțile magazinelor de aplicații.
- Publicul tău țintă este mixt — iOS și Android, mobil și desktop.
Pe de altă parte, PWA probabil nu este alegerea potrivită dacă:
- Aplicația ta rulează zilnic, câteva ore pe zi, iar utilizatorii o folosesc intensiv (rețele sociale, messaging).
- Ai nevoie de integrări avansate cu sistemul de operare.
- Cumpărătorii tăi se așteaptă la prezență în App Store.
- Performanța este critică (gaming, video, AR).
Concluzie
Hype-ul PWA s-a stins poate, dar tehnologia a crescut în tăcere până în punctul în care, pentru multe produse, e o alegere mai bună decât dezvoltarea nativă. Trefa.app rulează pe PWA de un an și nu văd niciun motiv să schimb asta. Dimpotrivă — dacă aș începe azi din nou, aș merge mai rapid pe această cale.
Dacă ești în dilema PWA vs. aplicație nativă pentru proiectul tău, ia în calcul un lucru dincolo de argumentele tehnice: PWA te duce mai repede în producție. Iar în fazele incipiente, viteza de iterație e mai valoroasă decât orice altceva.
Apropo, poți încerca și tu Trefa.app — fără instalare, doar un click și faci pronosticuri.