nodralabs.Parlem
Parlem

Apps natives per a iOS i Android: què cal decidir abans de desenvolupar-les

Una app nativa és una aplicació desenvolupada amb les eines pròpies de cada sistema: Swift a iOS i Kotlin a Android. Abans de triar tecnologia hi ha una pregunta prèvia que decideix gairebé tota la resta: quina acció freqüent resoldrà l'app millor que una web o un procés manual.

RESPOSTA RÀPIDA

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.

01

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.

02

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.

Comparativa entre app nativa, multiplataforma i web app (PWA)
CriteriNativaMultiplataformaWeb app (PWA)
TecnologiaSwift a iOS i Kotlin a AndroidReact Native o FlutterHTML, CSS i JavaScript
Base de codiUna per plataformaCompartida en gran partUna de sola
Accés al dispositiuComplet i al dia amb cada versió del sistemaAmpli, amb mòduls natius quan calLimitat, sobretot a iOS
RendimentEl més altMolt bo en la majoria de casosDepèn del navegador
DistribucióApp Store i Google PlayApp Store i Google PlayNavegador, sense passar per les botigues
Encaixa quanL'experiència i el maquinari són el centre del producteVols arribar a les dues plataformes amb un equip i un calendariL'ú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.

03

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:

  1. Qui la fa servir, en quin moment del dia i què fa avui per resoldre aquesta tasca.
  2. L'acció principal de l'app i els passos mínims per completar-la.
  3. Quina informació és imprescindible en una pantalla petita i quina pot esperar.
  4. D'on surten les dades: una API existent, un sistema intern o un backend nou.
  5. Com s'identifica l'usuari i quins permisos se li demanaran.
  6. 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.

04

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.

05

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.

FAQ

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ó.

EN RESUM

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.

Fonts i referències

VOLS APLICAR-HO AL TEU CAS?

Parlem del que necessites.

Explica'ns el teu cas