Una app per a iOS i Android té sentit quan acompanya un ús freqüent i necessita capacitats del dispositiu, com notificacions, càmera, localització o funcionament sense connexió. Si l'ús és ocasional o consisteix sobretot a consultar informació, amb una web ben feta acostuma a haver-n'hi prou: és més barata de mantenir i no depèn de les botigues.
Necessites una app o n'hi ha prou amb una web?
Les apps que funcionen en una empresa es recolzen en situacions concretes: un equip en mobilitat, un client que consulta alguna cosa sovint o una operació que necessita avisos i accés immediat.
Una app acostuma a estar justificada si es compleixen diverses d'aquestes condicions:
- L'usuari l'obrirà diverses vegades per setmana.
- Necessita notificacions perquè el procés avanci.
- Fa servir la càmera, la localització, el Bluetooth o un altre maquinari del telèfon.
- Ha de funcionar amb mala cobertura o sense connexió.
- El rendiment i la fluïdesa són part del valor del producte.
Si no és el teu cas, comença per una web adaptada al mòbil. Podràs validar la idea amb menys inversió i decidir després si l'app hi aporta res més. A com crear una web corporativa preparada per al SEO expliquem què ha de complir aquesta base.
Nativa, multiplataforma o web app: diferències
No hi ha una opció millor en abstracte. Hi ha una opció adequada per a cada producte, equip i pressupost.
| Criteri | Nativa | Multiplataforma | Web app (PWA) |
|---|---|---|---|
| Tecnologia | Swift a iOS i Kotlin a Android | React Native o Flutter | HTML, CSS i JavaScript |
| Base de codi | Una per plataforma | Compartida en gran part | Una de sola |
| Accés al dispositiu | Complet i al dia amb cada versió del sistema | Ampli, amb mòduls natius quan cal | Limitat, sobretot a iOS |
| Rendiment | El més alt | Molt bo en la majoria de casos | Depèn del navegador |
| Distribució | App Store i Google Play | App Store i Google Play | Navegador, sense passar per les botigues |
| Encaixa quan | L'experiència i el maquinari són el centre del producte | Vols arribar a les dues plataformes amb un equip i un calendari | L'ús és ocasional o vols validar abans d'invertir |
Sigui quina sigui la tecnologia, l'experiència ha de respectar els patrons de cada plataforma. Apple els documenta a les seves Human Interface Guidelines i Google a Material Design. Copiar les mateixes pantalles a iOS i Android acostuma a produir una app que resulta estranya a totes dues.
Què cal definir abans d'escriure codi
Dissenyar els fluxos abans de construir evita refer decisions cares. Aquestes són les definicions que demanem en començar:
- Qui la fa servir, en quin moment del dia i què fa avui per resoldre aquesta tasca.
- L'acció principal de l'app i els passos mínims per completar-la.
- Quina informació és imprescindible en una pantalla petita i quina pot esperar.
- D'on surten les dades: una API existent, un sistema intern o un backend nou.
- Com s'identifica l'usuari i quins permisos se li demanaran.
- Què es mesurarà des del primer dia per saber si l'app es fa servir.
Quan l'app forma part d'una operació interna, el més habitual és que convisqui amb software a mida que gestiona les dades per darrere.
Publicar a l'App Store i Google Play
Publicar té requisits propis que convé preveure al calendari i al pressupost.
- Comptes de desenvolupador a nom de l'empresa: l'Apple Developer Program costa 99 USD l'any i Google Play cobra un pagament únic de registre de 25 USD.
- Revisió prèvia: Apple i Google revisen cada app abans de publicar-la i la poden rebutjar si incompleix les seves normes.
- Fitxes de botiga amb textos, captures i categoria, que també influeixen en el fet que l'app es trobi.
- Política de privacitat i declaració de les dades que recull l'app.
- Proves en dispositius reals abans del llançament, amb TestFlight a iOS i les pistes de prova de Google Play.
Recomanem que els comptes siguin sempre de l'empresa propietària de l'app i no del proveïdor. Així el producte no queda lligat a qui el va desenvolupar.
Després del llançament: manteniment i evolució
Publicar no és el final. Apple i Google presenten una versió major dels seus sistemes operatius cada any, les botigues actualitzen els requisits i les dependències necessiten revisions de seguretat.
Una app sense manteniment acaba fallant en dispositius nous o perdent visibilitat a les botigues. Per això convé reservar capacitat per a tres coses: corregir el que l'ús real destapi, adaptar-se als canvis de plataforma i continuar millorant el que més es fa servir.
Una bona base tècnica i un acompanyament continuat permeten evolucionar sense refer-ho tot cada pocs mesos.
Preguntes freqüents
Què és una app nativa?
És una aplicació desenvolupada amb les eines pròpies de cada sistema operatiu: Swift i SwiftUI a iOS, Kotlin i Jetpack Compose a Android. Ofereix el millor rendiment i accés complet a les funcions del dispositiu.
És millor una app nativa o multiplataforma?
Depèn del producte. La nativa és preferible quan el rendiment o el maquinari del dispositiu són centrals. La multiplataforma, amb React Native o Flutter, permet arribar a iOS i Android compartint gran part del codi i encaixa bé en moltes apps de negoci.
Quant costa publicar una app a les botigues?
L'Apple Developer Program costa 99 USD l'any i el compte de desenvolupador de Google Play requereix un pagament únic de 25 USD. A això cal sumar-hi el cost de desenvolupament i de manteniment de l'app.
Cal mantenir una app després de publicar-la?
Sí. Els sistemes operatius reben una versió major cada any i les botigues actualitzen els requisits. Sense manteniment, una app acaba fallant en dispositius nous o incomplint les normes de publicació.
Què convé recordar
- Decideix primer si l'ús justifica una app o si n'hi ha prou amb una web.
- Nativa, multiplataforma o PWA: la tria depèn del producte, no de la moda.
- Defineix usuaris, acció principal i origen de les dades abans de desenvolupar.
- Preveu els comptes de desenvolupador, la revisió de les botigues i el manteniment anual.
