Decisions de producte
Aplicació web, PWA o mòbil: quina solució triar per al vostre projecte?
Compareu aplicació web, PWA, mòbil híbrid i natiu segons els usos, els dispositius i el que ja existeix. Una guia pràctica per definir la primera versió.
La resposta breu
El model adequat depèn de les accions que cal fer, dels dispositius utilitzats i de les limitacions de distribució. Definiu aquestes necessitats abans de triar entre navegador, aplicació instal·lable i botigues mòbils.
- Una aplicació web és adequada per a recorreguts accessibles en un navegador, tant en ordinador com en mòbil segons el disseny.
- Una PWA pot afegir una experiència instal·lable; el treball sense connexió i les notificacions s’han de definir per separat.
- El mòbil híbrid i el natiu tenen abasts diferents: examineu el que existeix, les plataformes previstes i les capacitats necessàries.
- WebAccés pel navegador
- PWAUna aplicació instal·lable
- MòbilEls usos del telèfon
Comenceu per tres accions concretes
«Necessitem una aplicació» encara no diu què cal construir. Un client ha de reservar un servei des d’un enllaç? Un col·laborador ha d’introduir dades sobre el terreny? Un administrador treballa tot el dia en un ordinador? Descriviu les accions principals, la freqüència i el context d’ús abans de triar el suport.
Per a una primera versió, distingiu el que és necessari per al servei del que podria arribar després. Un espai connectat, rols i un back-office descriuen funcions, no una obligació de publicar a les botigues. En canvi, una limitació de maquinari o un ús sobre el terreny poden exigir comprovacions tècniques abans de validar una solució web.
- Quines són les tres accions que l’usuari ha de poder completar?
- En quins dispositius i en quin context les fa?
- Disposa de connexió durant aquestes accions?
- Com descobreix el servei: enllaç, cerca web, eina interna o botiga?
- Ja existeix un disseny, una aplicació o una API reutilitzable?
Web, PWA, híbrid i natiu: les diferències útils
Una aplicació web s’utilitza en un navegador. Una PWA continua sent una aplicació web a la qual s’afegeixen capacitats com la instal·lació en dispositius compatibles. Una aplicació mòbil híbrida comparteix una base de desenvolupament entre diverses plataformes; la nativa es dissenya específicament per a la plataforma triada. Aquests models no determinen per si sols la qualitat de l’experiència.
| Model | Punt de partida útil | Què cal comprovar en definir l’abast |
|---|---|---|
| Aplicació web | Un servei accessible des d’un enllaç al navegador | Recorreguts en cada mida de pantalla, permisos i intercanvis de dades. |
| PWA | Usos web amb una experiència instal·lable | Navegadors, instal·lació, memòria cau i comportament sense xarxa. |
| Mòbil híbrid | Usos mòbils que cal cobrir amb una base compartida | Elements reutilitzables, capacitats necessàries i proves iOS/Android. |
| Mòbil natiu | Una necessitat dissenyada per a una plataforma concreta | Plataforma triada, API disponible i funcions pròpies del dispositiu. |
Una PWA instal·lable no implica processos de negoci disponibles sense connexió
La instal·lació d’una aplicació web depèn del navegador i de la plataforma. Cal acordar els dispositius compatibles i verificar-hi l’experiència. La memòria cau pot permetre accedir a certs recursos sense xarxa; no converteix automàticament una reserva, un pagament o una entrada de dades de negoci en una operació sense connexió.
A l’oferta PWA estàndard de CUB3, l’abast inclou instal·lació, icones, memòria cau dels recursos estàtics i una pantalla sense connexió. La introducció de dades sense xarxa i la sincronització posterior requereixen un disseny específic: què conserva el dispositiu, quan retorna els canvis i què passa si la informació ha canviat mentrestant?
Les notificacions també s’han de precisar. En versions compatibles d’iOS i d’iPadOS, Web Push s’aplica a les aplicacions web afegides a la pantalla d’inici i continua subjecte al permís de l’usuari. Cal verificar les condicions en els dispositius previstos. Una funció tècnicament possible no queda automàticament inclosa en una oferta inicial.
Per al mòbil, feu avaluar el que ja existeix
Recuperar una aplicació mòbil i crear-la completament no exigeixen el mateix treball. El disseny, els mòduls disponibles i les API determinen què es pot reutilitzar. Una API és la interfície que permet a l’aplicació intercanviar amb les seves dades i serveis: cal conèixer-ne les capacitats reals abans de pressupostar les pantalles que en depenen.
L’oferta híbrida inicial de CUB3 correspon a la recuperació acordada d’una aplicació existent, amb disseny conservat i mòduls reutilitzables. L’oferta nativa inicial s’adreça a un MVP per a una plataforma, iOS o Android, amb una API existent utilitzable. Una creació híbrida completament nova, un backend per construir o una segona plataforma nativa requereixen un pressupost adaptat. Les ofertes detallen aquestes hipòtesis.
La distribució mòbil afegeix etapes: preparació dels elements exigits per les botigues, enviament i validacions externes. Cal distingir-les del final del desenvolupament. El calendari ha de precisar què controla l’equip i què depèn de la distribució.
Promo.dev: un producte web i mòbil, amb lliuraments diferenciats
Per a Promo.dev, CUB3 va desenvolupar una aplicació web React i aplicacions mòbils React Native, amb un sistema de components compartit. Shopify gestionava el catàleg, els pagaments i l’inventari; una capa API cobria la lògica de negoci i les integracions. L’elecció tècnica va tenir en compte què es podia confiar a un servei existent i quina experiència s’havia de desenvolupar a mida.
El web estava preparat per a producció en vint-i-vuit dies. Les aplicacions mòbils estaven desenvolupades, amb un termini addicional vinculat a les validacions de les botigues. Aquest cas mostra la utilitat de distingir l’abast comú, les interfícies i la distribució. No significa que tot projecte hagi de començar en tres plataformes ni adoptar aquesta arquitectura.
Prepareu un pressupost a partir de les funcions esperades
Trieu primer un model plausible i enumereu les funcions necessàries: comptes i connexió, gestió de rols, administració, cerca, pagaments o notificacions. Afegiu les pàgines de presentació a part de les pantalles necessàries per a aquestes funcions. El simulador CUB3 ofereix una primera referència; el pressupost confirma l’abast, les integracions i les limitacions després d’una conversa.
Per comparar propostes, observeu què inclouen més enllà de les pantalles: disseny, proves, posada en producció, possible enviament a les botigues i seguiment. Separeu les despeses de serveis de tercers i el manteniment del pressupost de desenvolupament. Si una capacitat continua sent incerta, demaneu que es verifiqui abans de triar el model.
Sobre el terreny
Un projecte concret
Un frontend web a mida, aplicacions React Native i un motor de comerç existent, amb una distinció clara entre desenvolupament i validació de les botigues.
El producte web i mòbil de Promo.dev