Per què el PWA no és mort: cas d'estudi de trefa.app

Blog · 17 de maig del 2026

Per què el PWA no és mort: cas d'estudi de trefa.app

El hype de les Progressive Web Apps es va acabar, però la tecnologia ha madurat en silenci. Això és el que ha après trefa.app en un any de producció amb milers d'usuaris a iOS i Android.

Entre el 2017 i el 2020, el PWA va viure el seu cicle de hype tecnològic. Conferències, articles de blog, suport oficial de Google i de Microsoft. Després va arribar la decepció: iOS mantenia tancades les API clau, els prompts d'instal·lació resultaven confusos i el màrqueting de les aplicacions natives seguia sent més fort. La comunitat es va decantar cap a Flutter, React Native i Capacitor.

Però, en silenci, va passar una altra cosa: la tecnologia PWA va continuar madurant. Apple ha anat afegint les API que hi faltaven, els navegadors han millorat el flux d'instal·lació i l'especificació dels service workers s'ha estabilitzat. I per als equips de producte sense un gran pressupost, el PWA s'ha convertit en una solució sorprenentment sòlida.

Aquest article és un cas d'estudi honest de trefa.app —una aplicació de porres d'empresa construïda com a PWA— després d'un any en producció. Què ha funcionat, què no i a qui recomanaria avui el PWA.

Context: què és trefa.app

Trefa.app és una aplicació web per fer una porra d'empresa. L'usuari inicia sessió amb Google, crea una lliga per a la seva empresa, convida els companys amb un enllaç o un codi QR, i tots junts pronostiquen els resultats dels partits. L'aplicació sincronitza dades de diverses API esportives (l'Extralliga txeca d'hoquei, la Premier League, el Campionat del Món) i, un cop acabats els partits, recalcula els punts.

El frontend és Next.js 16 + React 19 + Tailwind, allotjat a Hetzner darrere de nginx. El backend és Django 5 + DRF + Channels, també a Hetzner. Entre tots dos hi ha PostgreSQL 17 en un contenidor al mateix servidor i Redis per a la comunicació en temps real.

Un detall que m'agrada: no existeix cap aplicació nativa per a iOS ni Android. El PWA és l'únic client. Els usuaris d'iPhone, Android, Windows i macOS fan servir exactament el mateix.

Per què vam optar pel PWA i no per aplicacions natives

La decisió va ser, sobretot, econòmica. Una aplicació nativa hauria significat:

  • Desenvolupar dos clients en paral·lel (iOS amb Swift + Android amb Kotlin), o bé algun framework multiplataforma (Flutter, React Native).
  • El procés d'enviament a l'App Store i a Google Play: quota d'enviament, retards de revisió i haver de tornar a publicar cada cop que canvia l'API del backend.
  • Notificacions push a través d'APNs i FCM: dues infraestructures diferents, dos processos de certificació diferents.
  • Un flux d'actualització que passa per les botigues: l'usuari ha d'actualitzar activament i una part es queda mesos amb una versió antiga.

Per a un producte amb un públic objectiu relativament petit (equips d'empresa, no mass-market), el cost del desenvolupament natiu era molt més alt que el benefici. El PWA eliminava tots aquests punts d'un sol cop.

Avantatges tècnics que l'usuari mai no nota

Aquesta és la part que hauria subestimat abans de posar-ho en producció. Des del punt de vista del desenvolupament, el PWA té una sèrie d'avantatges concrets que estalvien setmanes de feina cada any:

El desplegament és immediat. Genero la imatge → docker save/load al servidor → un cop l'/api/health confirma que tot va bé, la nova versió ja és a mans de tots els usuaris. Sense enviaments, sense esperes, sense haver de fer coincidir versions de client i de backend. Si faig un canvi que trenca l'API, l'endemà ho arreglo i tothom té la solució a l'instant.

Un sol codi per a tot. iOS, Android, Windows, macOS, Linux: a tot arreu la mateixa aplicació. Sense errors específics d'una plataforma ("això només es trenca a l'iPhone 13 en mode fosc"), sense implementacions duplicades.

El camí fins a l'usuari és curtíssim. Envies un enllaç, la persona hi fa clic i ja és dins l'aplicació. Res de "descarrega't la nostra app de l'App Store, registra't i després inicia sessió". Per a productes B2B que s'utilitzen amb poca freqüència (una porra només és activa mentre dura el torneig esportiu), això és un avantatge de conversió enorme.

Les notificacions push funcionen fins i tot sense instal·lar l'aplicació. El service worker registra la subscripció push. Quan l'usuari fa clic a «Activar notificacions», comença a rebre avisos abans dels partits, tant si ha afegit l'aplicació a la pantalla d'inici com si només l'obre de tant en tant a Safari.

El que el PWA no sap fer (secció honesta)

Aquí la sinceritat pesa més que el màrqueting. El PWA té limitacions reals amb què ens hem topat en producció.

Les notificacions push a iOS tenen les seves particularitats. L'Apple Web Push existeix des d'iOS 16.4, però només funciona si l'usuari afegeix el PWA a la pantalla d'inici. Si fa servir l'aplicació des d'una pestanya de Safari, la subscripció push no es desa. És una fricció que una aplicació nativa no té.

No hi ha presència a l'App Store. Per a certs perfils de comprador (departaments de RRHH, responsables d'IT en corporacions), «no ho tinc a l'App Store» equival a «no és seriós». És subjectiu, però és real.

Algunes API del sistema operatiu no hi són disponibles. Bluetooth Low Energy, NFC, accés profund al sistema de fitxers... Per a una aplicació normal no és cap problema, però si necessites aquestes funcions, el PWA et limita.

El mode offline és possible, però no automàtic. Cal configurar el service worker a mà, dissenyar l'estratègia de memòria cau i implementar cues de sincronització. Per a una aplicació realment offline-first, és més feina del que molts desenvolupadors s'imaginen.

Rendiment comparat amb el natiu: el PWA és entre un 15 i un 25 % més lent a la primera càrrega (pel parsing del bundle de JS) i entre un 5 i un 10 % en la interacció habitual. Per a la majoria d'aplicacions és una diferència imperceptible; per a jocs exigents o edició de vídeo, és un motiu de descart.

Resultats després d'un any en producció

Dades concretes de trefa.app després d'un any en marxa:

  • Estabilitat multiplataforma — un equip de desenvolupament d'una sola persona manté l'aplicació a tots els sistemes operatius sense errors específics de cap d'ells. Un mateix cicle de proves per a tots.
  • Freqüència de desplegament — de mitjana, entre 3 i 5 desplegaments per setmana, cap dels quals ha de patir els retards d'enviament a l'App Store.
  • Notificacions push — ~70 % dels usuaris les tenen activades, amb una taxa de lliurament d'~95 % a Android i ~85 % a iOS (a causa del requisit d'instal·lar-se a la pantalla d'inici).
  • Cap comissió de les botigues d'aplicacions — ens estalviem uns 70 USD anuals dels comptes de desenvolupador, més la comissió d'aproximadament el 30 % sobre les transaccions que s'aplicaria a les compres dins de l'aplicació.

Al final, el benefici de negoci principal no ha estat tècnic, sinó la velocitat d'iteració. Si un client escrivia «em vindria bé aquesta funció», normalment la començava el mateix dia i, en una setmana, ja era a producció. Amb una aplicació nativa, això simplement no és possible.

A qui recomanaria el PWA avui

El PWA té sentit si es compleixen almenys dos dels punts següents:

  • Tens recursos limitats i no et pots permetre dues aplicacions natives més la versió web.
  • Els teus usuaris fan servir l'aplicació de tant en tant (no cada dia), de manera que és important que el primer accés tingui poca fricció.
  • La teva aplicació no necessita API avançades del sistema operatiu (Bluetooth, NFC, accés complet al sistema de fitxers).
  • Vols poder desplegar sense passar per les portes de les botigues d'aplicacions.
  • El teu públic és mixt: iOS i Android, mòbil i escriptori.

En canvi, el PWA probablement no és la tria encertada si:

  • La teva aplicació s'utilitza cada dia, diverses hores al dia, i els usuaris en fan un ús intensiu (xarxes socials, missatgeria).
  • Necessites integracions avançades amb el sistema operatiu.
  • Els teus compradors esperen trobar-te a l'App Store.
  • El rendiment és crític (jocs, vídeo, realitat augmentada).

Conclusió

Pot ser que el hype del PWA s'hagi acabat, però la tecnologia ha madurat en silenci fins al punt que, per a molts productes, és una opció millor que el desenvolupament natiu. Trefa.app fa un any que funciona sobre PWA i no hi veig cap motiu per canviar-ho. Al contrari: si tornés a començar avui, m'hi llançaria més de pressa.

Si per al teu projecte dubtes entre un PWA i una aplicació nativa, tingues en compte una cosa que va més enllà dels arguments tècnics: el PWA et porta més ràpid a producció. I, en una fase inicial, la velocitat d'iteració val més que qualsevol altra cosa.

Per cert, pots provar trefa.app tu mateix — sense instal·lació, només un clic i ja pots fer els teus pronòstics.