Somia Digital
Guies

Què cal per fer una app i de què depèn el preu

Plataformes, disseny, privacitat i publicació a l'App Store i Google Play: el que cal decidir per fer una app, amb Pattio com a exemple real.

Què cal per fer una app i de què depèn el preu

Per fer una app cal decidir quatre coses abans de programar: per a quines plataformes serà (iPhone, Android, tauleta, ordinador o web), com ha de ser el disseny, què farà amb les dades de qui la faci servir i com es publicarà a l'App Store i a Google Play, que tenen normes pròpies i una revisió prèvia. El preu i el termini depenen sobretot d'aquestes decisions: quantes funcions entren a la primera versió, si cal compte d'usuari i servidor, quantes plataformes i idiomes s'han de cobrir i què demana cada botiga. Per posar-hi cara, farem servir d'exemple Pattio, una app per organitzar notes, fotos, enllaços i llistes que hem fet a Somia Digital i que ja és a l'App Store.

Quin problema ha de resoldre l'app?

Gairebé tots els projectes d'app comencen igual: «tenim una idea i no sabem per on començar». El primer pas no és triar la tecnologia, sinó escriure en una frase què resol l'app i per a qui. Si aquesta frase no és clara, les funcions s'amunteguen i el pressupost es dispara.

La frase de Pattio és aquesta: un suro infinit on hi tires notes, fotos, enllaços i llistes, les mous amb el dit com si fossin papers i les agrupes com vulguis. Primer ho guardes; després, si vols, ho ordenes. D'aquí en surten decisions concretes: no cal crear carpetes ni categories abans de començar, i tot hi ha d'entrar fàcil, ja sigui compartint des de qualsevol altra app (Safari, Fotos…), arrossegant i deixant anar o enganxant el que hi ha al porta-retalls.

Quines plataformes: iPhone, Android, web o totes?

És la decisió que més pesa en el cost. Les opcions habituals són tres:

  • Una sola plataforma (iOS o Android) per validar la idea amb el públic que més la farà servir.
  • iOS i Android alhora, amb una base de codi multiplataforma o amb dues apps natives, segons el rendiment i les funcions del sistema que calguin.
  • App i web: hi ha coses que funcionen millor al navegador, sobretot quan qui les ha de veure no té l'app instal·lada.

Per a Pattio vam triar l'ecosistema d'Apple: iPhone, iPad i Mac amb Apple Silicon, amb una app nativa (no una web empaquetada) que al Mac té barra de menús i dreceres de teclat de debò. I hi vam afegir una peça web: quan comparteixes un tauler, qui rep l'enllaç l'obre al navegador, el mira, vota a les enquestes i hi afegeix notes sense instal·lar ni pagar res. Així, compartir no depèn que tothom tingui l'app.

Què ha de tenir en compte el disseny d'una app?

Una app no es fa servir com un web: es toca, s'arrossega i s'obre moltes vegades al dia. El disseny ha de partir d'una idea que s'entengui sense instruccions i ha de respectar els gestos i les convencions del sistema. A Pattio, aquesta idea és el suro: targetes com papers amb xinxetes, que es giren amb dos dits i s'obren en gran des d'on són. Hi ha una benvinguda animada que es pot saltar i tornar a veure, i un mode fosc amb una paleta pròpia, càlida, en lloc d'un simple gris.

L'accessibilitat també és disseny. Les pautes WCAG 2.2 demanen, al nivell AA, un contrast mínim de 4,5:1 per al text normal (criteri 1.4.3). A Pattio, el contrast del mode clar i del fosc es comprova amb tests automàtics, i el títol de cada tauler, que va damunt d'una imatge de fons, calcula el vel que necessita segons la lluminositat de la imatge perquè no baixi mai d'aquest mínim. Si l'app forma part d'un servei per a consumidors, com una botiga en línia, també cal tenir present la Llei europea d'accessibilitat.

Els idiomes també són una decisió de disseny, no un retoc final: cada idioma afegeix textos, captures i una fitxa de botiga. Pattio funciona en tretze llengües, i el català no hi és una traducció, sinó una llengua de primera.

Privacitat i dades: què cal decidir abans de programar?

La pregunta clau és si l'app necessita compte d'usuari. Un compte permet sincronitzar entre dispositius o compartir, però porta servidor, dades personals, política de privacitat i obligacions a les botigues. El Reglament general de protecció de dades exigeix protecció de dades des del disseny i per defecte (article 25 de l'RGPD): s'ha de decidir abans d'escriure codi, no afegir-ho al final.

Així ho vam resoldre a Pattio:

  • L'app funciona sencera sense compte. Sense compte, tot es queda al dispositiu i no hi ha res al núvol.
  • El compte és opcional i serveix per sincronitzar. Els taulers privats viatgen i es desen xifrats de punta a punta, amb una clau que no surt mai dels dispositius de l'usuari.
  • L'excepció es diu clarament: un tauler compartit no pot anar xifrat, perquè el navegador de qui el rep l'ha de poder llegir, i l'app ho avisa abans.
  • Marxar és fàcil: qualsevol persona pot descarregar totes les seves dades en un fitxer, de franc i sense escriure a ningú, i esborrar el compte esborra les dades del núvol.
  • Sense anuncis, i l'analítica d'ús, pseudònima, es pot desactivar a la configuració.

Les botigues ho demanen explícitament. Apple exigeix un enllaç a la política de privacitat a la fitxa i dins de l'app, el consentiment de l'usuari abans de recollir dades i que cada permís que l'app demana (càmera, fotos, ubicació…) expliqui clarament per a què es fa servir; i, si l'app permet crear un compte, també n'ha de permetre l'esborrat des de dins (directriu 5.1.1 de les App Review Guidelines). Google Play també demana que el compte es pugui esborrar des de l'app i, a més, un enllaç web per sol·licitar-ho sense haver de tornar a instal·lar-la (requisits d'eliminació de comptes). I totes dues botigues obliguen a declarar quines dades es recullen i per a què: les etiquetes de privacitat d'Apple i la secció Seguretat de les dades de Google Play.

Què demanen l'App Store i Google Play per publicar una app?

Publicar no és pujar un fitxer i prou. Cal un compte de desenvolupador a cada botiga, una fitxa (nom, subtítol, descripció, paraules clau i captures per a cada mida de pantalla i idioma) i superar una revisió. Alguns punts que convé preveure:

  • El revisor ho ha de poder provar tot. Si l'app té inici de sessió, Apple demana un compte de demostració actiu; un mode de demostració només s'accepta, amb permís previ, quan hi ha motius legals o de seguretat (directriu 2.1).
  • Compres i subscripcions: per desbloquejar funcions dins de l'app s'ha de fer servir la compra integrada de la botiga (directriu 3.1.1).
  • Inici de sessió amb Google o amb xarxes socials: si serveix per crear el compte principal, Apple obliga a oferir també una alternativa equivalent que limiti les dades al nom i al correu i permeti amagar l'adreça, com l'inici de sessió amb Apple (directriu 4.8).
  • Comptes personals de Google Play creats després del 13 de novembre de 2023: abans de poder publicar, han de fer una prova tancada amb almenys 12 persones inscrites durant 14 dies seguits (requisits de prova).

A Pattio, les notes per al revisor d'Apple expliquen què és l'app (un suro buit podria semblar una app buida), que no cal cap compte i, tot i així, com s'hi entra pas a pas (amb Apple, amb Google o amb un correu i un codi de sis xifres, sense contrasenya), els gestos bàsics, com provar les subscripcions a l'entorn de proves i per què es demana cada permís. I la fitxa es va escriure pensant en el que busca la gent: en lloc de competir per paraules genèriques com «notes», Pattio es presenta com el que és, un suro.

El model de negoci també s'ha de decidir aquí, perquè les botigues hi tenen normes. Pattio es pot fer servir de franc, i el que es paga, amb una subscripció de l'App Store, és més espai al núvol, més taulers i alguns tipus de targeta més; qui rep un tauler compartit no paga mai.

De què depenen el preu i el termini d'una app?

No hi ha preu de catàleg, perquè dues apps que s'anomenen igual poden ser projectes molt diferents. El que més el fa variar és:

  1. El nombre de pantalles i funcions de la primera versió. És el factor principal i el que més es pot ajustar.
  2. Si cal compte d'usuari i servidor (sincronització, dades compartides, panell d'administració, notificacions).
  3. Les plataformes: només iOS, iOS i Android, tauleta, ordinador o també web.
  4. Les integracions: pagaments i subscripcions, mapes, calendari, càmera, sistemes de l'empresa.
  5. La privacitat i la seguretat que cal garantir (xifratge, funcionament sense connexió, exportació i esborrat de dades).
  6. Els idiomes i el material de botiga per a cadascun.
  7. La publicació: la preparació de la fitxa i les rondes de revisió.
  8. El manteniment: cada any surten versions noves d'iOS i d'Android, i l'app s'hi ha d'adaptar.

La manera més eficaç de controlar el cost és començar petit. Pattio ha crescut per fases: primer el suro, les targetes i el compte amb sincronització xifrada; després hi han arribat els ginys de la pantalla d'inici, el quadern per dibuixar i el document per escriure. Una primera versió ben delimitada surt abans, costa menys i permet decidir la resta amb dades reals d'ús.

Què has de tenir clar abans de demanar pressupost?

  • Quin problema resol l'app i per a qui, en una frase.
  • Les tres o quatre funcions sense les quals no té sentit.
  • Si la faran servir clients, l'equip intern o tots dos.
  • Si cal compte d'usuari i quines dades personals tractarà.
  • Les plataformes i els idiomes imprescindibles d'entrada.
  • Si s'ha de connectar amb eines que ja feu servir.
  • Com es finançarà: gratuïta, de pagament, amb subscripció o com a servei per als vostres clients.

Tens una idea d'app?

A Somia Digital fa més de deu anys que fem projectes digitals, ja n'hem fet més de cent i també desenvolupem apps pròpies, com Pattio. Al servei de desenvolupament d'apps hi trobaràs com treballem, i si vols, pots demanar un pressupost guiat: et responem en 24-48 hores laborables amb el pressupost, que és tancat, o amb les preguntes que calguin, i t'ajudem a decidir què ha d'entrar a la primera versió. També ens pots escriure per WhatsApp.

Fonts: App Review Guidelines d'Apple (directrius 2.1, 3.1.1, 4.8 i 5.1.1) i detalls de privacitat de l'App Store; ajuda de Google Play Console sobre eliminació de comptes, Seguretat de les dades i requisits de prova; Reglament (UE) 2016/679 i WCAG 2.2. Informació revisada l'octubre de 2026; les normes de les botigues canvien sovint, comprova-les abans de publicar.

Preguntes freqüents

He de fer l'app per a iPhone i Android alhora?

No necessàriament. Començar amb una sola plataforma, la que més fa servir el teu públic, permet validar la idea amb menys inversió. Si des del principi les necessites totes dues, una base de codi multiplataforma sol sortir més a compte que dues apps natives, tot i que depèn de les funcions del sistema que calgui fer servir.

Què demanen Apple i Google per publicar una app?

Un compte de desenvolupador a cada botiga, una fitxa amb textos i captures, una política de privacitat enllaçada, la declaració de les dades que es recullen i superar una revisió. Si l'app permet crear un compte, també n'ha de permetre l'esborrat des de l'app, i el revisor d'Apple necessita un compte de demostració per provar-la. A Google Play, els comptes personals de desenvolupador creats després del 13 de novembre de 2023 han de fer abans una prova tancada amb almenys 12 persones durant 14 dies seguits.

La meva app necessita que els usuaris es registrin?

Només si alguna funció ho exigeix, com sincronitzar entre dispositius, compartir o desar dades en un servidor. Cada compte suposa tractar dades personals amb les obligacions del RGPD i oferir-ne l'esborrat des de l'app. Pattio, per exemple, funciona sencera sense compte i el deixa per a qui vol sincronitzar.

De què depèn el preu d'una app?

Sobretot del nombre de pantalles i funcions de la primera versió, de si cal compte d'usuari i servidor, de les plataformes i els idiomes, de les integracions (pagaments, mapes, sistemes de l'empresa), dels requisits de privacitat i de publicació, i del manteniment posterior. Per això convé començar amb una primera versió ben delimitada.

Una app necessita manteniment després de publicar-la?

Sí. Apple i Google publiquen versions noves dels seus sistemes cada any i actualitzen sovint les normes, així que l'app s'ha de provar i adaptar periòdicament. També convé preveure marge per corregir errors i afegir millores a partir de l'ús real.

Parlem del teu projecte

Demana pressupost