Quant de temps per crear una app: terminis reals

Quant de temps per crear una aplicació: la resposta curta

Quant de temps cal per crear una aplicació? Ningú no et pot donar una xifra universal honesta, perquè la durada depèn sobretot de dues coses que només coneixes tu: la mida de la teva primera versió i el nombre d'hores que hi pots dedicar cada setmana. En canvi, una part del calendari se sap per endavant: les etapes d'Apple es compten en dies, no en mesos. Apple indica per exemple que revisa el 90 % de les sol·licituds en menys de 48 hores.

La clau, doncs, és acotar bé. Una app que fa una sola cosa, només a iOS, amb una stack que no descobreixes el mateix dia, es construeix en unes quantes setmanes de feina regular. Un catàleg de dotze funcions en dues plataformes es pot allargar mesos i no sortir mai. Aquesta guia detalla on se'n va el temps, etapa per etapa, perquè puguis estimar el teu propi calendari.

Publico les meves pròpies apps iOS: Solys, un despertador amb minijocs, i TradaZen, un simulador de trading, són a l'App Store. Nolera i Clic van ser rebutjades per Apple i després corregides. Les etapes de sota són les que travesso a cada llançament.

Temps de desenvolupament d'una aplicació mòbil: de què depèn?

Abans de parlar d'etapes, aquests són els factors que fan variar el temps de desenvolupament d'una aplicació mòbil, del que pesa més al que pesa menys.

• El nombre de funcions de la primera versió. És de lluny el factor principal. Cada funció afegeix pantalles, estats buits, errors per gestionar i proves.
• Els comptes i el backend. Una app les dades de la qual es queden al telèfon és molt més senzilla que una app amb registre i sincronització entre dispositius.
• El pagament. Una subscripció demana configuració a Apple, a RevenueCat i al teu codi, a més de proves de compra.
• Una o dues plataformes. Publicar a iOS i Android vol dir dos expedients, dues revisions i dues tandes de proves. Detallo aquesta decisió a app iOS i Android alhora.
• El teu temps disponible. Deu hores per setmana i quaranta hores per setmana, evidentment, no donen el mateix calendari.
• El teu nivell inicial i l'ús de la IA. La IA accelera molt l'escriptura del codi, molt menys la resta. Ho veurem més avall.

Etapa per etapa: on se'n va el temps quan crees una app iOS

1. Acotar la idea

És l'etapa que decideix totes les altres. Hi fixes el públic, el problema, la funció principal, el model de negoci i el que queda fora de la primera versió. Si dura setmanes, és que les decisions no estan preses. Un plec de condicions d'una pàgina n'hi ha prou per tancar-la.

2. Obrir el compte Apple Developer

Sense aquest compte, a 99 $ l'any, no pots publicar, i el programa Enterprise d'Apple no el substitueix. Per a un particular, Apple indica que si no has rebut la confirmació d'adhesió en les 24 hores següents a la compra, has de contactar amb el suport. Per a una empresa, primer cal un número D-U-N-S: Apple preveu fins a 5 dies laborables per rebre'l, i després fins a 2 dies laborables perquè la informació li arribi. Comença aquest tràmit en paral·lel al desenvolupament, no al final. El detall és a compte de desenvolupador Apple: preu i registre.

3. Construir la funció principal

Aquí és on les diferències són més grans, i gairebé totes vénen de l'abast. Una funció ben definida, amb els seus estats buits i els seus errors, es construeix ràpid, sobretot amb React Native, Expo i la IA. Cada funció afegida «ja que hi som» allarga aquesta etapa i totes les següents. La pàgina MVP d'aplicació iOS t'ajuda a retallar pel lloc adequat.

4. Provar al teu iPhone amb TestFlight

El simulador no n'hi ha prou: alguns errors fatals només apareixen en un telèfon real. Les proves internes comencen tan bon punt la teva build està processada. Per a testers externs, Apple precisa que la primera build enviada a un grup passa per App Review, i que les següents no necessàriament requereixen una revisió completa. Preveu, doncs, una petita espera la primera vegada. Tot està explicat a TestFlight: provar la teva app d'iPhone.

5. Connectar les subscripcions

Crear els productes a App Store Connect, enllaçar-los a RevenueCat, construir el paywall, provar les compres i la restauració. Un detall de calendari que cal saber: Apple exigeix que la primera compra integrada de cada tipus s'enviï amb una nova versió de l'app. Si te n'oblides, el teu primer enviament surt sense subscripció i has de tornar a començar un cicle. Tota la feina és a la pàgina subscripcions in-app iOS.

6. Preparar la fitxa de l'App Store

Captures de pantalla a les mides correctes, descripció, paraules clau, declaracions de privacitat, enllaços a les condicions d'ús, notes per al reviewer. Quan ho tens tot preparat per endavant, és qüestió d'hores. Quan descobreixes els camps el dia de l'enviament, pot trigar uns quants dies.

7. La revisió d'Apple

La revisió en si sovint és ràpida, segons les xifres d'Apple citades més amunt. El que costa temps són els rebuigs: cada rebuig vol dir llegir el motiu, corregir, tornar a enviar i esperar una nova resposta. He detallat els terminis reals i el que els allarga a termini de validació de l'App Store.

El calendari d'una app es guanya al principi, retallant funcions, i es perd al final, descobrint les regles d'Apple.

Quant de temps per crear una app amb la IA?

La IA ha canviat de debò la durada de l'etapa 3. Claude, ChatGPT o Cursor escriuen pantalles, navegació i lògica senzilla en uns segons, quan fa uns anys calien hores de recerca.

Ha canviat molt menys les etapes 2, 4, 5, 6 i 7. Sense accés a les consoles ni proves executades als dispositius afectats, un agent no pot confirmar l'estat del compte Apple, de les subscripcions o de la visualització. Aquestes comprovacions demanen un sistema de proves, encara que l'agent participi a automatitzar-les. Resultat: amb la IA, la construcció s'escurça, però la part del calendari dedicada a la configuració, les proves i la revisió creix en proporció. En parlo amb detall a crear una app iOS amb la IA.

Les tres coses que fan disparar els terminis

1. Canviar d'opinió a mitja construcció. Cada «ja que hi som» torna a obrir l'abast. La solució: tot el que no és a la primera versió queda escrit negre sobre blanc com a fora de l'abast, i es converteix en la matèria de la següent.
2. Descobrir les regles d'Apple al final. Compte de demostració que falta, pantalla tallada en un iPhone petit, petició de valoració mal col·locada, subscripció sense les mencions exigides: cada descoberta tardana costa un cicle de revisió complet. La pàgina aplicació rebutjada per Apple recull els motius més freqüents.
3. Quedar-te encallat tot sol amb un problema de configuració. Un certificat, un identificador de subscripció, una build que no es vol instal·lar: aquests bloquejos sovint només demanen la informació correcta, però poden immobilitzar un projecte durant dies quan ningú no et pot ajudar.

Per què «més ràpid» no sempre és millor

Una app pot sortir molt ràpid si et saltes les proves en pantalla petita, la gestió dels errors de xarxa i la verificació de les compres. Sortirà, i després petarà al primer contacte amb usuaris reals, i les primeres valoracions a l'App Store se'n recordaran.

El bon objectiu no és la velocitat pura. És la data de llançament més propera que no sacrifiqui ni la revisió d'Apple ni la primera impressió. Retalla funcions, mai solidesa.

Una referència real: els 26 dies abans de la publicació de TradaZen

A TradaZen, el primer commit és del 21 de juny de 2026, el primer TestFlight del 25 de juny i la publicació del 17 de juliol: 26 dies naturals del primer commit a l'App Store. No són 26 dies de feina a temps complet ni una mitjana per a totes les apps. L'abast va continuar evolucionant després del llançament.

La cronologia detallada de TradaZen distingeix les etapes de construcció, els problemes de revisió i els canvis de rumb. És un exemple per comparar amb el teu projecte, no una data de llançament per copiar.

Com estimar el teu propi termini?

En lloc d'una xifra trobada a internet, fes aquest càlcul per al teu projecte:

1. Escriu el teu plec de condicions d'una pàgina i fes la llista de les pantalles de la primera versió.
2. Estima cada pantalla en hores, amb els seus estats buits i els seus errors, i després afegeix-hi el paywall i la fitxa de l'App Store.
3. Divideix-ho per les teves hores reals per setmana, no per les que esperes tenir.
4. Afegeix-hi un marge per com a mínim una anada i tornada amb Apple, sobretot si és la teva primera app.
5. Comença el registre a Apple Developer des del principi, perquè no bloquegi mai el final.

Si el resultat et sembla massa llarg, no treballis més ràpid: treu una funció.

Fixar-te una data límit

Una data límit fixa ajuda molt a mantenir un abast ajustat. L'iOS Kit divideix el camí en quatre etapes: triar l'app que pot fer diners, construir el nucli de l'app i provar-la amb TestFlight, connectar els diners, i després publicar i fer-te trobar. Et toca a tu fixar una data per a cadascuna. La pàgina d'inici mostra aquestes quatre etapes per crear una aplicació mòbil amb Claude Code.

Per estimar el teu propi termini, el diagnòstic gratuït parteix de la teva situació i del temps que tens cada setmana, i et diu quina etapa atacar primer.

Una data límit és un marc de treball, no una garantia de publicació: qui valida és Apple, i el teu ritme compta. Per a la visió de conjunt del recorregut, la pàgina crear una aplicació d'iPhone continua sent el millor punt de partida.

Preguntes freqüents

Quant de temps cal per crear una aplicació d'iPhone?

Depèn sobretot de la mida de la teva primera versió i del nombre d'hores que hi pots dedicar cada setmana. Una app que fa una sola cosa, només a iOS, amb eines que no descobreixes el mateix dia, es construeix en unes quantes setmanes de feina regular. Un catàleg de dotze funcions en dues plataformes es pot allargar mesos i no sortir mai.

Quines són les etapes per crear una aplicació d'iPhone?

Set etapes: acotar la idea, obrir el compte Apple Developer, construir la funció principal, provar al teu iPhone amb TestFlight, connectar les subscripcions, preparar la fitxa de l'App Store i, finalment, passar la revisió d'Apple. L'acotació decideix totes les altres etapes. Comença el registre a Apple Developer en paral·lel al desenvolupament, no al final.

Quant dura la validació d'una aplicació per part d'Apple?

Apple indica que revisa com a mínim el 50 % de les sol·licituds en menys de 24 hores, i el 90 % en menys de 48 hores. La revisió en si, doncs, sovint és ràpida. El que costa temps són els rebuigs: cal llegir el motiu, corregir, tornar a enviar i esperar una nova resposta. Els terminis reals estan detallats a termini de validació de l'App Store.

La IA permet crear una aplicació més ràpid?

Sí, però sobretot per a la construcció. Claude, ChatGPT o Cursor escriuen pantalles, navegació i lògica senzilla en uns segons. La IA canvia molt menys el compte Apple, les proves, les subscripcions, la fitxa de l'App Store i la revisió. Resultat: la construcció s'escurça, però la part del calendari dedicada a la configuració, les proves i la revisió creix en proporció.

Què fa descarrilar el termini d'una aplicació?

Sobretot tres coses: canviar d'opinió a mitja construcció, descobrir les regles d'Apple al final i quedar-te encallat tot sol amb un problema de configuració. Cada descoberta tardana d'una regla d'Apple costa un cicle de revisió complet. Per mantenir l'abast, escriu negre sobre blanc el que no és a la primera versió: es converteix en la matèria de la següent.

Hi ha algun exemple real de termini per publicar una app iOS?

Sí: a TradaZen, una de les meves apps, hi ha 26 dies naturals entre el primer commit del 21 de juny de 2026 i la publicació del 17 de juliol. No són 26 dies de feina a temps complet ni una mitjana per a totes les apps, i l'abast va continuar evolucionant després del llançament. Compara aquesta referència amb el teu projecte, sense copiar-la com si fos una data de llançament.