Una app mòbil s'ha de guanyar un lloc al telèfon del client. Primer cal saber què farà que la web no fa
Una web la troba qualsevol des d'un cercador. Una app, en canvi, s'ha de descarregar, s'ha d'obrir més d'una vegada i ha de superar la revisió d'Apple i de Google abans d'arribar a ningú. Per això, la primera pregunta d'un projecte d'app no és quina tecnologia farà servir, sinó quina feina farà que justifiqui ocupar espai a la pantalla d'algú.
Daimatics fa desenvolupament d'apps mòbils. En aquesta pàgina expliquem què convé decidir abans de programar: si ha de ser una app o una web, quin camí tècnic té sentit, quines normes de les botigues afecten el disseny i com es llegeix què passa a dins un cop publicada.
Cinc respostes sobre una app imaginària, i què se'n desprèn per al projecte.
- Els clients hi tornen cada setmanaA favor
- Ha de fer servir la càmera i enviar avisosA favor
- Els usuaris s'hi crearan un compteEsborrat dins l'app
- Vendrà productes físicsCobrament propi
- Una part només ha d'informar i captar contactesFeina de la web
Exemple il·lustratiu · no correspon a cap projecte real.
Qui hi ha darrere de Daimatics abans de parlar de pantalles
Daimatics, fundada per David Nogués, amb més de 20 anys de trajectòria professional en l'àmbit digital. Daimatics fa desenvolupament d'apps mòbils, i és una agència que també treballa el SEO, la publicitat, l'analítica i la web. Per això aquesta pàgina parla tant de la web, de les dades i de com es mesura l'ús com de l'app mateixa.
Abans de proposar res es revisen el negoci, la web i les dades. I la web, Analytics, Search Console, la fitxa de Google i els comptes publicitaris queden a nom del client; l'agència hi accedeix amb usuaris i permisos propis.
Google Partner
Acreditació de l'agència a Google.
Els comptes, teus
La web, l'Analytics i la Search Console continuen a nom del client.
Sense permanència
Per plegar, n'hi ha prou avisant uns quinze dies abans.
David NoguésFundador i CEO de Daimatics
Quatre motius pels quals una app acaba sense ningú que l'obri
Cap d'aquests problemes depèn de com de bonic sigui el disseny. Tots neixen d'una decisió que no es va prendre a temps.
Era la web, dins d'un marc
Embolcallar la web en una app sembla una drecera. La guia de revisió d'Apple hi és explícita: una app ha d'oferir funcions, contingut i interfície que vagin més enllà d'una web reempaquetada. Si no aporta res que la web no faci, pot quedar fora de l'App Store; i si hi entra, ningú no té cap motiu per instal·lar-la.
Ningú no arriba a la fitxa de la botiga
L'App Store i Google Play tenen el seu propi cercador, però qui busca una solució a Google troba sobretot webs, i és la web la que ha de portar cap a l'app. Si la web no en parla, o si els seus enllaços no obren l'app quan ja està instal·lada, el camí es trenca abans de començar.
Es queda enrere sense que ningú la toqui
Google Play exigeix que les apps apuntin a versions recents d'Android, i les que no s'actualitzen deixen d'estar disponibles per als usuaris nous que tenen telèfons més moderns. Una app no es publica i s'oblida: té un calendari de manteniment que marquen les plataformes, no l'empresa.
Ningú no sap què hi passa a dins
Si l'app es publica sense mesura, no se sap quantes persones l'obren, en quin pas abandonen el registre ni quines funcions fan servir de debò. Sense aquestes dades, la segona versió es decideix per intuïció, i les decisions d'inversió que la segueixen, també.
Els quatre es poden veure venir abans de programar si es comença per l'ús que en farà la persona que la descarrega, i no per la tecnologia.
De vegades, l'app que convé és una bona web
Una app guanya quan la gent hi torna sovint i quan necessita coses del telèfon que una web aprofita pitjor. Si la feina és informar, captar contactes o vendre a visitants que arriben un sol cop, la web sol fer-ho millor i amb menys passos.
Sol bastar una web
Quan l'ús és puntual
- La visita arriba des de Google o des d'un anunci, i no tornarà cada setmana
- L'objectiu és que demani pressupost, que truqui o que compri
- El contingut canvia sovint i ha de posicionar
- No cal res del telèfon més enllà de la pantalla
Té sentit una app
Quan l'ús és recurrent
- Clients o equips que l'obren cada dia o cada setmana
- Funcions que depenen de l'aparell: càmera, ubicació, avisos, ús sense connexió
- Un compte d'usuari amb historial, reserves o comandes
- Un servei que ja funciona i que el mòbil fa més còmode
Si en fer aquest repàs surt que ara et cal una web, el punt de partida és desenvolupament web. I sovint la resposta és tenir totes dues: una web que es troba i una app per a qui ja és client.
Nativa, multiplataforma o web instal·lable: cada camí porta un compromís
No hi ha un camí millor en abstracte. N'hi ha un de més adequat per a cada app, segons què ha de fer, a quanta gent ha d'arribar i qui la mantindrà quan ja sigui publicada.
App nativa
Es programa per separat per a iOS i per a Android, amb les eines de cada plataforma. Aprofita l'aparell sense intermediaris, a canvi de mantenir dues bases de codi.
Dues basesApp multiplataforma
Una part important del codi es comparteix entre iOS i Android, i això redueix la feina duplicada. Algunes funcions molt lligades al telèfon poden necessitar peces pròpies de cada sistema.
Codi compartitWeb instal·lable
És una web que es pot afegir a la pantalla d'inici i comportar-se com una app. Tal com és, no passa per la revisió de les botigues i no hi té fitxa, tot i que es pot empaquetar per publicar-la a Google Play; el que pot fer amb el telèfon depèn del navegador, i a iOS és més limitat.
Sense botigaFuncions del telèfon
Càmera, ubicació, avisos, pagaments o ús sense cobertura: com més pes tinguin dins de l'app, més pes tenen en la tria del camí.
DecideixenQui la mantindrà
El camí que es tria determina qui podrà fer les actualitzacions d'aquí a uns anys. És una pregunta tan important com la del pressupost inicial, i sovint es fa massa tard.
Es preguntaTres preguntes que acoten el camí
- L'úsAmb quina freqüència s'obrirà i on: a la feina, al carrer, en un magatzem sense cobertura.
- L'aparellQuines funcions del telèfon són imprescindibles, i quines només serien un detall agradable.
- El desprésQui farà les actualitzacions que exigeixen Apple i Google, i amb quin pressupost. Si ningú no ho sap, el camí encara no està triat.
El camí concret depèn del cas real: no hi ha cap tecnologia que convingui a tothom, i per això se'n parla amb el projecte damunt de la taula.
Les normes d'Apple i de Google es llegeixen abans de dissenyar
L'App Store i Google Play revisen les apps abans de publicar-les. Algunes de les seves normes canvien el disseny, el registre d'usuaris i fins i tot la manera de cobrar. Si es descobreixen el dia d'enviar-la, toca refer pantalles.
Ha d'aportar alguna cosa pròpia
La guia de revisió d'Apple demana que l'app vagi més enllà d'una web reempaquetada i que sigui prou útil per tenir-hi lloc. També demana que el que s'envia a revisar sigui la versió final, provada en dispositius reals i sense textos provisionals ni pàgines buides.
Qui crea un compte, l'ha de poder esborrar
Si l'app permet crear un compte, Apple exigeix que també permeti esborrar-lo des de dins de l'app. Google Play hi afegeix un enllaç web on l'usuari pugui demanar que s'esborrin el compte i les dades associades. Totes dues coses es dissenyen, no s'improvisen.
Com es cobra depèn del que es ven
El contingut i les funcions digitals que es fan servir dins de l'app es cobren, en general, amb el sistema de pagament de cada botiga. En canvi, els productes físics i els serveis que es presten fora de l'app s'han de cobrar, en general, per altres vies: ho indiquen tant Apple com Google, amb excepcions segons el país i el tipus d'app.
La privadesa es declara abans d'instal·lar
Apple mostra a la fitxa de cada app quines dades recull, i Google Play hi té una secció de seguretat de les dades que s'omple amb un formulari. Apple, a més, vol l'enllaç a la política de privadesa dins de l'app i un permís explícit de l'usuari abans de seguir-ne l'activitat en apps i webs d'altres empreses.
Aquestes normes canvien. Les que surten aquí s'han contrastat amb la documentació oficial d'Apple i de Google l'octubre del 2026; abans d'enviar cap app, convé tornar-les a llegir.
Quatre coses per tenir clares abans de demanar preu per una app
No cal tenir l'app dibuixada. Cal saber per a qui és, amb què s'ha de connectar i qui en serà el titular quan ja sigui a les botigues.
Qui la farà servir, i cada quan
Clients finals, un equip comercial que visita empreses o el personal d'un centre no necessiten la mateixa app. La freqüència d'ús és el que indica si una app tindrà vida o si es quedarà instal·lada sense obrir.
Amb quins sistemes ha de parlar
Botiga online, programa de gestió, CRM, agenda de reserves o passarel·la de pagament: cada connexió és feina pròpia, i i cadascuna suma feina pròpia al projecte.
A nom de qui van els comptes de desenvolupador
Apple i Google permeten publicar com a organització, i Apple mostra el nom de l'empresa com a venedor a l'App Store. En general, totes dues plataformes demanen un número D-U-N-S per verificar-la (amb excepcions, com les entitats públiques); si l'empresa encara no en té, cal demanar-lo abans de començar.
Qui la mantindrà quan ja sigui publicada
Apple cobra una quota anual pel seu programa de desenvolupadors, i Google Play, una quota única de registre. Al cost de les plataformes s'hi suma la feina de seguir-les: noves versions de sistema, normes que canvien i connexions que s'han de revisar.
Amb aquestes quatre respostes, la primera conversa ja pot anar al gra. Sense elles, qualsevol preu és una suposició.
El que passa dins de l'app s'ha de poder llegir des de la primera versió
Les setmanes que segueixen la publicació són les que més ensenyen sobre com es fa servir una app. Si la mesura arriba a la segona versió, aquesta informació ja no es recupera.
Web i app a la mateixa propietat
Google Analytics permet afegir fluxos de dades d'apps d'iOS i d'Android a la mateixa propietat on hi ha la web, i en crear-los hi enllaça un projecte de Firebase. Així, un recorregut que comença a la web i continua a l'app es pot llegir sencer.
Què compta, acordat abans
Registre completat, reserva, comanda o sol·licitud: allò que es considerarà un resultat s'acorda abans de dissenyar la pantalla que el genera. Si es decideix després, la primera versió es publica sense saber què ha d'aconseguir.
El permís de seguiment a iOS
Apple demana el permís de l'usuari per relacionar les dades de l'app amb les d'apps i webs d'altres empreses amb finalitats publicitàries. Afecta com es mesuren les campanyes i les instal·lacions, i convé saber-ho abans de comprometre cap objectiu de captació.
Enllaços de la web que obren l'app
Amb els App Links d'Android, un enllaç verificat de la web obre directament el contingut corresponent dins de l'app, sense preguntar amb què obrir-lo. La verificació depèn d'un fitxer publicat a la web: una feina de la web que l'app necessita.
La part de la web, de les etiquetes al consentiment de galetes, és la feina d'analítica web.
Cinc moments en què una app es fa o es desfà
Per a què
Qui l'obrirà, per fer què i cada quant temps. Si aquesta resposta no és clara, la resta del projecte tampoc no ho serà, per bona que sigui la programació.
Prototip
Les pantalles principals, ensenyades a persones que s'assemblen als usuaris reals abans d'escriure codi. És el moment en què canviar d'idea costa menys.
Construcció i proves
L'app es prova en telèfons reals, com demana Apple. Google Play ofereix vies de prova interna, tancada i oberta; en els comptes personals nous, la tancada és obligatòria abans de passar a producció.
Revisió de les botigues
Fitxa, captures, política de privadesa, declaració de dades i, si hi ha comptes, un usuari de demostració perquè l'equip de revisió d'Apple hi pugui entrar.
Després de publicar
Lectura de la mesura, correcció d'errors i les actualitzacions que exigeixen les plataformes. Aquí comença la segona versió, la que ja es decideix amb dades.
Esquema general d'un projecte d'app, no un compromís de calendari: quant dura cada moment ho marquen les funcions, les connexions i les revisions de les botigues.
La llista que es repassa abans d'enviar l'app a revisió
Cada línia que queda pendent pot ser un motiu de rebuig o una dada que no es podrà llegir.
Botigues
- La política de privadesa està enllaçada a la fitxa i dins de l'app.
- La declaració de dades coincideix amb el que l'app recull de veritat.
- L'equip de revisió té un compte de demostració per entrar-hi.
Producte
- No queda cap text provisional ni cap pantalla buida.
- Qui es crea un compte el pot esborrar des de l'app.
- S'ha provat en telèfons reals, no només en simuladors.
Web i mesura
- Els fluxos de dades de l'app ja envien informació a Analytics.
- Els enllaços de la web obren l'app quan està instal·lada.
- La web té una pàgina que explica l'app i porta a les botigues.
Quan l'app ja és a les botigues, la web que l'acompanya continua necessitant manteniment web, perquè és el que troba qui busca l'app a Google.
Els assistents d'IA no veuen l'app: llegeixen la web que les explica
La guia de Google per a la cerca amb IA indica que les mateixes bones pràctiques de SEO de fons que valen per a la Cerca també valen per a aquestes funcions. La conclusió pràctica: el que vols que se sàpiga d'una app ha d'estar escrit en una web que es pugui rastrejar.
Una pàgina per a l'app
Què fa, per a qui és, en quins sistemes funciona i on es descarrega, explicat amb text i no només amb captures. És la part que un cercador pot rastrejar i entendre.
Els controls d'indexació
Google indica que noindex, nosnippet i max-snippet limiten com apareix el contingut a les seves experiències amb IA. Convé comprovar que la pàgina de l'app no en porti cap per error, heretat d'una versió de proves.
La mateixa explicació a tot arreu
La descripció de l'App Store, la de Google Play i la de la web han de dir el mateix sobre què fa l'app. Quan es contradiuen, qui les llegeix no sap quina creure, i acostuma a no creure'n cap.
Ningú pot garantir que un assistent citi una web. A l'abast de qualsevol hi ha una altra cosa: explicar bé l'app en un lloc on es pugui llegir. La visibilitat en aquestes respostes té servei propi: GEO.
Daimatics OS, al costat de l'app
Daimatics OS és l'ecosistema tecnològic propi que dona suport al model de treball de Daimatics: centralitza i relaciona dades, evidències, analítica, coneixement i processos de diferents disciplines per ampliar la capacitat d'anàlisi, priorització, execució i millora contínua de l'agència. No és una IA que ho fa tot ni un producte que es vengui: és infraestructura pròpia al servei de l'agència.
Dins seu, el sistema SEO propi s'estructura en capes especialitzades que organitzen l'auditoria, el contingut, l'autoritat, el SEO local, les dades, la mesura i la millora contínua. Una app no és un canal de SEO, però viu al costat d'una web, d'unes campanyes i d'unes dades que sí que ho són.
Les persones de l'equip de Daimatics
La primera conversa la sol conduir David. Roberto i Leticia treballen en el SEO i els continguts web dels clients.
David Nogués
Fundador i CEO
Sol conduir la primera conversa, i els projectes de més dimensió, complexitat o importància estratègica els pot portar directament.
LinkedIn
Roberto E. Funes Stephen
Equip de Daimatics
Treballa principalment en el SEO de les webs dels clients: anàlisi, recerca de paraules clau i gestió SEO.
LinkedIn
Leticia E. Tonelli Alva
Equip de Daimatics
Treballa principalment en els continguts web dels clients i en el seu SEO: continguts SEO, recerca de paraules clau, anàlisi i gestió SEO.
LinkedInPer a qui és aquesta pàgina, i per a qui n'hi ha una altra
Hi encaixa
- Tens clients o equips que farien servir una app cada setmana.
- L'app ha d'aprofitar el telèfon: càmera, ubicació, avisos o ús sense connexió.
- S'ha de connectar amb la botiga, el programa de gestió o les reserves que ja tens.
- Vols que la web i la mesura formin part del projecte des del primer dia.
Et convé una altra pàgina
- Necessites una web nova i l'app pot esperar: desenvolupament web.
- Tens una botiga online i vols que rendeixi més: tria la teva plataforma a tots els serveis tècnics.
- La web va lenta al mòbil: optimització de velocitat.
- Vols entendre què passa a la web i a les campanyes: analítica web.
Si dubtes entre app i web, la resposta surt de com es farà servir, no de què ha fet la competència.
Preguntes abans d'encarregar una app mòbil
Respostes que serveixen encara que no treballis amb nosaltres.
Reserva una trucada amb un sèniorQuant costa desenvolupar una app mòbil per a una empresa a Espanya?
Cap xifra de referència serveix per a totes les apps, perquè el cost el marquen les funcions, les connexions amb altres sistemes, com la botiga, el programa de gestió o les reserves, i si cal fer-la per a iOS i per a Android. A més, hi ha els costos de les plataformes: Apple cobra una quota anual pel seu programa de desenvolupadors, i Google Play, una quota única de registre. Per comparar pressupostos, mira si inclouen proves en telèfons reals, la publicació a les botigues i el manteniment posterior. A Daimatics el preu i les condicions es parlen a la reunió.
És millor fer una app nativa o multiplataforma?
Depèn del que ha de fer l'app. La nativa es programa per separat per a iOS i per a Android i aprofita al màxim les funcions del telèfon, a canvi de mantenir dues bases de codi. La multiplataforma comparteix bona part del codi i redueix la feina duplicada, tot i que algunes funcions molt lligades a l'aparell poden necessitar peces específiques de cada sistema. Abans de triar, fes la llista de funcions del telèfon que són imprescindibles i pregunta qui farà les actualitzacions d'aquí a uns anys: aquestes dues respostes solen decidir-ho.
Necessito una app o em basta una web adaptada al mòbil?
Si la gent hi arribarà des de Google o des d'un anunci, ho farà una sola vegada i l'objectiu és que demani pressupost o compri, una web ben feta sol ser suficient i és més fàcil de trobar. Una app té sentit quan l'ús és recurrent, quan cal un compte amb historial o quan necessita funcions del telèfon com la càmera, la ubicació o els avisos. Molts projectes acaben tenint totes dues coses: una web que capta i una app per a qui ja és client. Per decidir-ho, comença mirant amb quina freqüència la farien servir.
Per què l'App Store pot rebutjar apps que només mostren una web?
Perquè la guia de revisió d'Apple, a l'apartat de funcionalitat mínima, demana que una app ofereixi funcions, contingut i interfície que vagin més enllà d'una web reempaquetada, i que sigui prou útil o pròpia per tenir lloc a l'App Store. Una app que només obre la web dins d'un marc no aporta res que el navegador no faci ja. Si el projecte va per aquí, val més invertir en la web, o pensar quina funció pròpia justificaria l'app: un compte, avisos útils, ús sense connexió o accés a funcions del telèfon.
Qui ha de ser el titular dels comptes de l'App Store i de Google Play?
De l'empresa que és propietària de l'app. Apple i Google permeten registrar-se com a organització, i Apple mostra aquest nom com a venedor a la fitxa de l'App Store. En general, totes dues plataformes demanen un número D-U-N-S per verificar l'empresa, així que convé tenir-lo abans de començar. Que els comptes siguin de l'empresa evita dependre de ningú per publicar una actualització o canviar de proveïdor. Convé deixar per escrit, abans de començar, a nom de qui van aquests comptes.
Quant es triga a publicar una app a Google Play i a l'App Store?
Depèn de l'app i de les revisions, i ningú no pot comprometre una data que decideixen Apple i Google. Hi ha requisits que sí que es coneixen: a Google Play, els comptes personals creats després del 13 de novembre de 2023 han de fer una prova tancada amb almenys 12 persones durant 14 dies seguits abans de demanar l'accés a producció. A l'App Store, la revisió vol la versió final, provada en dispositius reals i, si hi ha comptes, un usuari de demostració. Preparar-ho bé evita rebutjos i reenviaments.
Quan s'ha de cobrar amb el sistema de pagament d'Apple o de Google dins d'una app?
En general, quan el que es ven és digital i es consumeix dins de l'app: continguts, funcions premium o subscripcions. Si l'app ven productes físics o serveis que es presten fora de l'app, com una comanda a domicili o una cita, Apple i Google indiquen que s'han de cobrar per altres vies, per exemple amb una passarel·la de pagament. Cada botiga detalla excepcions i matisos a les seves normes. Convé tenir-ho clar abans de dissenyar el procés de compra, perquè canvia les pantalles i també el model de negoci.
Una app necessita manteniment encara que no se li afegeixi res?
Sí. Les plataformes canvien i l'app les ha de seguir. Google Play, per exemple, demana que les apps noves i les actualitzacions apuntin a una versió recent d'Android: a partir del 31 d'agost de 2026, a Android 16 (API 36) o superior, amb pròrroga possible fins a l'1 de novembre de 2026; Wear OS i TV tenen nivells propis. Les apps que es queden enrere deixen d'estar disponibles per als usuaris nous amb telèfons més moderns. A això s'hi sumen les versions noves d'iOS, els canvis de normes de les botigues i les connexions amb altres sistemes. Abans d'encarregar una app, pregunta qui farà aquestes actualitzacions i com es pressuposten.
Explica'ns què ha de fer l'app i qui l'obrirà
Ens expliques què vols resoldre, per a qui i amb quins sistemes s'ha de connectar l'app. Si hi veiem encaix, l'abast i les condicions es parlen a la reunió.
- Qui la farà servir
- Cada quant temps l'obriran
- Funcions del telèfon
- Sistemes que ha de connectar
- iOS, Android o tots dos
- Si hi encaixem
