Com crear una app: de la idea a l’App Store i Google Play

Crear una app té menys a veure amb el codi que amb les decisions: quin problema resol, què entra a la primera versió, quina tecnologia hi encaixa i qui controla què un cop publicada. Aquesta guia repassa cada pas, de la primera idea a l’App Store i Google Play i el manteniment que ve després, perquè puguis planificar amb realisme i explicar bé el projecte a un equip de desenvolupament.

Idea clau

La millor primera app és petita: un MVP que resol bé un sol problema, normalment multiplataforma, o una web o PWA si els clients només et necessiten de tant en tant. Incorpora la privadesa i els requisits de les botigues des del disseny, publica-la amb els teus propis comptes de desenvolupador perquè el codi i les dades siguin teus, i reserva pressupost per al manteniment després del llançament.

Defineix el problema, el MVP i un prototip

El primer pas per crear una app és definir el problema que resol; el MVP i un prototip navegable surten d’aquí. Abans de fer la llista de funcions, escriu tres coses:

Per a qui és l’app i què vol aconseguir aquesta persona. «Clients habituals que volen repetir una comanda amb pocs tocs» és un problema. «Una app amb carta, punts i xat» és una llista de funcions.
Per què una app. Què farà que la gent la instal·li i hi torni, en lloc de fer servir la teva web o WhatsApp?
Com sabràs que funciona. Tria indicadors que puguis mesurar, com més comandes repetides, menys trucades o reserves gestionades sense intervenció del personal.

Després defineix el MVP (producte mínim viable): la versió més petita que resol prou bé el problema principal perquè la facin servir persones reals. Escriu un o dos recorreguts clau, per exemple «registrar-se → veure productes → demanar → pagar → rebre l’avís», i passa tota la resta a una llista de «més endavant». Un MVP no és una app a mig fer: és una app polida dins d’un abast reduït.

Abans de programar, converteix aquests recorreguts en un prototip navegable amb una eina com Figma i observa uns quants usuaris del públic objectiu mentre el proven al mòbil. Canviar una pantalla en la fase de prototip costa molt menys que canviar codi acabat. Dissenya també al prototip els casos en què alguna cosa falla: sense connexió, un pagament rebutjat, un permís denegat.

Nativa, multiplataforma o web?

Per a la majoria d’apps de negoci, la multiplataforma és l’opció assenyada per defecte; la nativa compensa per a gràfics exigents o un treball avançat amb la càmera o l’àudio, i una web app o PWA sovint n’hi ha prou si els clients només et necessiten de tant en tant. Les tres opcions es comparen així:

Nativa: una app diferent per a cada plataforma, amb Swift per a iOS i Kotlin per a Android. Accés complet a les funcions del dispositiu, però dues bases de codi per mantenir.
Multiplataforma: frameworks com Flutter o React Native comparteixen la major part del codi entre iOS i Android; la documentació de Flutter (en anglès) en descriu l’objectiu com crear apps multiplataforma a partir d’una sola base de codi. Per a les apps de negoci habituals (comandes, reserves, programes de fidelització, catàlegs, eines internes) és una opció assenyada per defecte. Els gràfics exigents, el treball avançat amb la càmera o l’àudio o la dependència de les funcions més noves de cada plataforma poden decantar la balança cap a la nativa.
Web app o PWA: una aplicació web progressiva funciona al navegador, es pot afegir a la pantalla d’inici i no passa per la revisió de les botigues. Sovint n’hi ha prou si els clients et necessiten de tant en tant o mentre encara valides la idea. A canvi, no ets a les botigues, la integració amb el dispositiu és més difícil i el suport de les PWA a iOS és més limitat.

Una prova ràpida: els usuaris et necessiten cada setmana o poques vegades l’any? Necessites notificacions push, ús sense connexió o ubicació en segon pla? Ser a les botigues és important per generar confiança? Si la majoria de respostes a aquestes preguntes és «no», una web ràpida i pensada primer per al mòbil, o una PWA, pot ser un primer pas millor. Per decidir amb què fer-la, compara Wix, WordPress o una web a mida.

Backend, panell d’administració i API

La majoria d’apps de negoci són només la punta d’un sistema més gran: darrere les pantalles hi ha un backend, un panell d’administració i integracions amb pagaments, enviaments i els sistemes que ja fas servir.

Backend: servidors i una base de dades per a comptes, comandes, continguts i notificacions. Els serveis gestionats com Firebase poden accelerar un MVP; un backend propi dona més control sobre les dades, les integracions i els costos de funcionament a mesura que creixes.
Panell d’administració: la interfície web que el teu equip fa servir cada dia per gestionar productes, comandes, usuaris i notificacions. El panell d’administració és fàcil de deixar fora del pla, així que defineix-lo aviat, amb rols i permisos: qui pot veure les dades dels clients, qui pot fer reemborsaments.
API i integracions: pagaments, mapes, enviaments, missatgeria i els sistemes que ja tens, com la botiga online, l’ERP, el CRM o el programari de comptabilitat; si aquests sistemes encara són fulls de càlcul, la nostra guia d’ERP a mida o programari estàndard t’ajuda a triar. Cada integració depèn de la documentació, l’aprovació d’accés i els límits de l’altra banda, així que revisa-ho abans de tancar el pla.

Decideix aviat on s’allotgen les dades, perquè la regió importa per a la normativa de privadesa. Si vols vendre contingut digital o subscripcions dins de l’app, revisa les normes de pagament vigents de cada botiga, que varien segons la regió i canvien sovint. Per a productes físics i serveis, el més habitual és fer servir la teva pròpia passarel·la i mètodes de pagament locals, com Bizum a Espanya.

Privadesa i protecció de dades

La privadesa s’incorpora des del principi: recull només les dades que necessites, esbrina quines lleis s’hi apliquen, demana permís abans de fer seguiment, declara l’ús de dades a les botigues i permet que la gent esborri el compte. La privadesa és alhora una obligació legal i un requisit de les botigues, i és molt més fàcil incorporar-la des del disseny que afegir-la després:

Recull només el que necessites. Cada camp de formulari i cada permís (ubicació, contactes, càmera) ha de correspondre a una funció que puguis explicar.
Esbrina quines lleis s’hi apliquen. Amb usuaris a la Unió Europea, s’aplica el RGPD. La guia de protecció de dades per a petites empreses del Comitè Europeu de Protecció de Dades (en castellà) confirma que també afecta les organitzacions de fora de l’Espai Econòmic Europeu que ofereixen productes o serveis a persones que hi són. El RGPD exigeix una base jurídica per a cada ús de les dades, informació clara, el respecte als drets dels usuaris i contractes amb els proveïdors que tracten dades per compte teu. Molts altres països i diversos estats dels EUA tenen les seves pròpies lleis de privadesa.
Demana permís abans de fer seguiment. A la UE, els SDK d’analítica i de publicitat que no són estrictament necessaris solen requerir consentiment previ, i ets responsable del que recullen els SDK de tercers. A iOS, fer el seguiment de les persones a través d’apps i webs d’altres empreses requereix el permís d’App Tracking Transparency d’Apple.
Declara-ho a les botigues. Apple demana la informació de privadesa de l’app i Google Play, la secció de seguretat de les dades. Totes dues botigues exigeixen una política de privadesa, i el que declaris ha de coincidir amb el que fa l’app.
Permet esborrar el compte. Segons la directriu 5.1.1 de les directrius de revisió de l’App Store (en anglès), si l’app permet crear un compte, també ha de permetre eliminar-lo des de dins de l’app. Els requisits de Google Play per a la supressió de comptes hi afegeixen un enllaç web perquè els usuaris puguin sol·licitar la supressió del compte i de les dades fora de l’app.

Proves, revisió de les botigues i comptes de desenvolupador propis

Abans del llançament, una app necessita tres coses: proves en dispositius reals i una beta, l’aprovació a la revisió d’Apple i de Google, i la publicació amb els comptes de desenvolupador de la teva empresa.

Proves. Fes servir dispositius reals: mòbils antics i nous, pantalles petites i grans, i totes les versions del sistema que admetis. Després fes una beta amb TestFlight d’Apple i els canals de prova de Google Play. Segons els requisits de proves de Google Play, els comptes de desenvolupador personals creats després del 13 de novembre de 2023 han de fer una prova tancada amb un mínim de 12 verificadors donats d’alta durant almenys 14 dies seguits abans de sol·licitar l’accés a producció; el requisit només s’aplica als comptes personals.

Revisió de les botigues. Apple revisa les apps segons les seves directrius de revisió de l’App Store (en anglès), i Google segons les seves polítiques del programa per a desenvolupadors. La directriu 4.2 d’Apple diu que una app ha d’incloure funcions, contingut i interfície que la portin més enllà d’un lloc web reempaquetat. Entrebancs habituals: tancaments inesperats, fitxes incompletes, falta d’informació de privadesa, no permetre esborrar el compte, no donar al revisor un accés de prova i apps que són poc més que una web embolcallada. Deixa marge al calendari per a un possible rebuig i un nou enviament.

Comptes propis. Publica amb els comptes de desenvolupador de la teva empresa, no amb els del teu proveïdor. L’Apple Developer Program té una quota anual i Google Play Console, una quota de registre única; en tots dos casos, els comptes d’organització requereixen un número D-U-N-S i verificacions d’identitat, així que comença aviat. Mantén també a nom teu el domini, l’allotjament, el repositori de codi i les credencials de signatura.

Què determina el cost i els terminis, abans i després del llançament

El cost i els terminis d’una app depenen sobretot de les plataformes i els rols d’usuari, la complexitat de les funcions, les integracions, l’ambició del disseny, els requisits normatius i la rapidesa amb què respon la teva banda, a més del manteniment posterior. Cap equip seriós no pot posar xifra a una app sense un abast clar, perquè aquests factors la fan variar:

Plataformes i rols: iOS, Android, web i el panell d’administració sumen feina cadascun; una app per a clients, una per al personal i un panell d’administració són tres productes, no un.
Complexitat de les funcions: el xat en temps real, la ubicació en directe, el vídeo, la sincronització sense connexió i les regles de reserva són de les funcions més exigents.
Integracions: cada sistema extern hi afegeix feina, sobretot els antics sense bones API.
Ambició del disseny: els components estàndard són més ràpids que els elements visuals i les animacions a mida.
Llengües, mercats i normativa: traduccions, mètodes de pagament locals, migració de dades, requisits de seguretat estrictes.
La teva banda: la rapidesa amb què arriben les decisions i si els textos, les imatges i les dades de producte estan a punt a temps.

El llançament no és el final del pressupost. Apple i Google publiquen versions noves dels seus sistemes cada any i els requisits de les botigues canvien amb elles. Les biblioteques necessiten actualitzacions de seguretat, els servidors tenen costos de funcionament i l’ús real et dirà què construir després.

Com explicar el projecte a un equip de desenvolupament

Explica el projecte a un equip de desenvolupament amb un document breu per escrit que reculli el problema, els recorreguts clau, les plataformes, les integracions i les teves limitacions; és el que permet a l’equip donar-te una estimació útil. Inclou-hi:

El problema, els usuaris objectiu i com mesuraràs l’èxit.
Els recorreguts clau, la llista de funcions del MVP i la llista de «més endavant».
Plataformes, països i llengües.
Els sistemes i les dades amb què s’ha de connectar l’app.
Qui farà servir el panell d’administració, i per a què.
Apps que t’agraden, i què t’agrada exactament de cadascuna.
Limitacions: dates objectiu i per què són importants, una franja de pressupost i qui decideix.

Després pregunta a l’equip de desenvolupament: com dividiríeu la feina en fases? De qui seran el codi, els dissenys i els comptes? Com es gestionen els canvis d’abast? Com serà el manteniment?

Preguntes freqüents

És millor una app nativa o multiplataforma?

Per a la majoria d’apps de negoci, com comandes, reserves, programes de fidelització o eines internes, la multiplataforma és una opció assenyada per defecte perquè una sola base de codi serveix per a iOS i Android. La nativa té més sentit quan l’app depèn de gràfics exigents, de funcions avançades de càmera o d’àudio o de les capacitats més noves de cada plataforma.

Quant costa fer una app?

Depèn de l’abast, no d’una llista de preus: plataformes, pantalles i rols d’usuari, integracions, ambició del disseny i requisits normatius, a més del manteniment després del llançament. Un document clar del MVP és la millor manera d’obtenir una estimació fiable, idealment desglossada per fases.

Necessito els meus propis comptes de desenvolupador d’Apple i de Google?

Sí, és molt recomanable. Amb comptes propis controles la fitxa, les ressenyes i les actualitzacions, i pots canviar d’equip de desenvolupament sense haver de traslladar l’app. Apple cobra una quota anual i Google Play una quota de registre única; els comptes d’organització necessiten un número D-U-N-S.

A UsualMatrix dissenyem i desenvolupem apps per a iOS i Android, amb el backend i el panell d’administració que hi ha al darrere, per a clients de tot el món, i treballem en xinès, castellà i anglès. Consulta el nostre servei de disseny i desenvolupament d’apps a mida o escriu-nos per parlar de la teva idea.

Important: aquest article és informació general sobre el desenvolupament d’apps, les normes de les botigues i la normativa de privadesa a la data de publicació i no constitueix assessorament jurídic. Les normes canvien, així que comprova els requisits vigents i consulta un advocat o un especialista en protecció de dades per al teu cas.