Meypi Developers, iniciDemana pressupost
Demana pressupost

App nativa o PWA: què necessita la teva empresa

Meypi Developers · Actualitzat el

Triar entre una app nativa o PWA comença pel que ha de poder fer qui la fa servir. Un web instal·lable pot encaixar si el recorregut funciona al navegador; val la pena estudiar una app quan hi ha requisits que aquest recorregut no cobreix. A Meypi Developers, un estudi de software de l’àrea metropolitana de Barcelona, proposem decidir-ho amb una llista de tasques i una prova del requisit més difícil.

1. Què compares quan dius app o web

Un web s’obre amb un enllaç. Una PWA és un web instal·lable que es pot afegir al dispositiu i obrir des de la seva icona. Una app nativa es construeix per a una plataforma; un projecte multiplataforma comparteix part del desenvolupament per a més d’una. Aquests noms descriuen la solució, però no decideixen si resol el negoci.

La instal·lació d’una PWA varia segons el navegador i el sistema. La documentació d’instal·lació de MDN en recull les diferències. Tenir una icona al telèfon no demostra, per si sol, ús sense cobertura ni compatibilitat amb una funció concreta.

2. Una taula per començar a triar

Què cal comprovar abans de triar
La teva necessitatPrimera opció que cal estudiarProva que ha de superar
Publicar informació i rebre consultesWeb adaptat al mòbilObrir un enllaç, llegir i contactar sense instal·lar res.
Reservar o consultar un compte sovintWeb instal·lable o app, segons els requisitsCompletar la tasca als dispositius del públic real.
Treballar sense coberturaQualsevol opció que implementi el recorregutDesar sense xarxa i recuperar la connexió sense perdre ni duplicar feina.
Fer servir una funció concreta del telèfonComparar la funció exacta en totes dues opcionsAssajar-la amb permisos concedits, rebutjats i retirats.
Ser a les botigues d’aplicacionsProjecte d’app amb la distribució definidaConcretar qui és titular dels comptes i què es publica.

La taula és un criteri de treball de Meypi, no una regla que doni per guanyadora una tecnologia. Si diverses opcions superen les proves, comparem el cost de construir-les i mantenir-les.

3. Escriu els requisits com a tasques

  • Qui hi entra: un client ocasional, un soci que torna cada setmana o un equip que hi treballa tot el dia.
  • Què ha d’acabar: demanar cita, consultar un document, registrar una visita o pagar.
  • Què passa sense xarxa: què pot consultar, què pot desar i quan rep la confirmació.
  • Quins avisos necessita: per a què serveixen i què passa si no dona permís o no els rep.
  • Quins dispositius utilitza: telèfons, ordinadors, versions i navegadors habituals.
  • Amb què es connecta: quin programa conserva la dada i qui resol una connexió interrompuda.

Per exemple, «registrar una visita en una zona sense cobertura i enviar-la un sol cop quan torna la connexió» permet preparar una prova. «Que sigui com una app» encara no diu què cal comprovar. L’exemple defineix un requisit; no descriu un projecte de client.

4. Instal·lar, rebre avisos i treballar sense xarxa són tres decisions

L’ús sense connexió requereix preparar què es desa i com se sincronitza. MDN explica el funcionament sense connexió i en segon pla. Cal provar tot el recorregut, inclòs el que veu la persona quan alguna cosa encara no s’ha enviat.

A l’iPhone i l’iPad, WebKit documenta els avisos web per a aplicacions afegides a la pantalla d’inici des d’iOS i iPadOS 16.4, amb permís demanat després d’una acció de la persona.Condicions de Web Push a WebKit. Abans de pressupostar avisos, cal fixar els dispositius i el recorregut de permisos.

5. Dos recorreguts per posar a prova la decisió

A la pàgina de desenvolupament d’apps il·lustrem un avís de classe i un test sense connexió. Aquí els fem servir per preparar requisits; no els presentem com dos clients ni com proves noves de compatibilitat.

  • L’avís d’una classe.: El soci accepta avisos, en rep un i obre la classe correcta. Demana provar també què passa si no dona permís i com consulta l’activitat per una altra via. Tenir avisos en una llista de funcions no resol aquests passos.
  • El test al metro.: L’alumne respon sense xarxa, tanca l’aplicació i recupera la feina. Quan torna la connexió, comprova el progrés desat i que un reintent no el dupliqui. La tria queda pendent d’aquesta prova als dispositius acordats.

6. Demana una prova del requisit que pot canviar la decisió

Abans de construir totes les pantalles, tria el requisit que podria descartar una opció. Prepara un recorregut petit: entrar, completar la tasca, comprovar la dada i recuperar-se d’una fallada. La decisió s’ha de basar en el resultat, no només en una llista de funcions.

  • Repeteix la tasca als telèfons i navegadors acordats.
  • Prova amb poca connexió i torna a obrir l’aplicació.
  • Comprova què passa en rebutjar un permís i com es pot continuar.
  • Verifica el resultat al programa que desa la dada.
  • Anota què funciona, què falta i què obliga a canviar d’opció.

7. Què cal comparar al pressupost

Compara la mateixa primera versió, amb les mateixes proves. Separa disseny, funcions, connexions, distribució, manteniment i atenció d’incidències. Un web instal·lable no té un estalvi fix respecte d’una app: depèn del que s’hagi de construir i conservar.

La guia de quant costa crear una app explica els factors del pressupost. Per conèixer les fases del projecte, pots llegir com es desenvolupa una app.

8. Què cal preparar per estudiar el projecte

Porta tres tasques imprescindibles, els dispositius del teu públic i els programes amb què cal connectar. Si ja hi ha un web o una aplicació, afegeix què es vol conservar i què falla avui. Això ajuda a delimitar la primera versió i decidir què cal assajar.

Per valorar l’encàrrec, consulta el servei de desenvolupament d’apps o explica’ns què necessita l’empresa.

Continua llegint

Explica’ns què necessites

Què vols construir, per a quan i amb quin pressupost.

Fem servir les teves dades només per respondre’t.