Temps de revisió de l'App Store: quant has d'esperar

El temps de validació de l'App Store és curt sobre el paper: Apple diu 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. Aquesta xifra surt de la pàgina oficial d'App Review. Per a una app que passa a la primera, doncs, pots esperar una resposta en un dia, més o menys.

El temps real, en canvi, es compta d'una altra manera: és el temps entre el teu primer enviament i el moment en què l'app està a la venda. I el que el fa disparar gairebé mai és l'espera a la cua, són els rebutjos. Cada rebuig torna a engegar un cicle complet: llegir el motiu, corregir, tornar a enviar, tornar a esperar, fins i tot per a un rebuig automàtic en l'enviament com ITMS-90338. Aquesta guia explica què allarga aquest temps, com gestionar un rebuig sense perdre dies i quins motius cauen més sovint en una primera app.

En parlo a partir dels meus propis enviaments. Les meves apps iOS, entre elles Solys (un despertador amb minijocs) i TradaZen (un simulador de trading), són a l'App Store, i m'he menjat diversos rebutjos pel camí, tant a Solys com a dues altres apps, Clic i Nolera. Els motius estan detallats més avall.

Temps de validació de l'App Store: el que Apple anuncia de veritat

Un cop el teu build està enviat, sense cap error automàtic com ITMS-90725, i la teva fitxa està completa, l'envies a revisió des d'App Store Connect. La sol·licitud passa llavors per diversos estats: en espera (Waiting for Review), en revisió (In Review) i després acceptada o rebutjada. Apple t'avisa per correu a cada canvi, i pots seguir l'estat a App Store Connect o a la seva app per a iPhone.

Tres precisions oficials útils per planificar:

• Aquestes xifres són tendències, no una garantia: fins a una sol·licitud de cada deu espera més de 48 hores.
• Les sol·licituds no es revisen necessàriament en l'ordre d'enviament, precisa l'ajuda d'App Store Connect.
• Només pot haver-hi una versió de l'app en revisió per plataforma. No pots apilar diverses versions per «guanyar temps».

Un cop acceptada l'app, pots triar publicar-la automàticament o llançar-la tu mateix. Aquesta segona opció val or: primer fas validar l'app, i després fixes la data de llançament quan ja tens llum verda.

Què allarga l'espera

L'espera rarament s'allarga per culpa d'Apple. Gairebé sempre s'allarga per culpa del que li envies.

El primer enviament

Per a una primeríssima versió, Apple ho revisa tot de cop: la fitxa, les captures, la classificació per edat, la política de privacitat, les declaracions de recollida de dades, les subscripcions i l'app mateixa. Cada element és una ocasió de rebuig. No és que la cua sigui més llarga, és que la superfície és més gran. Si encara no has publicat mai, els passos que cal preparar estan a publicar una aplicació a l'App Store.

Les subscripcions i les compres integrades

Si la teva app ven una subscripció, dues regles et canvien el calendari:

1. La teva primera subscripció s'ha d'enviar amb una nova versió de l'app. Està escrit ben clar a l'ajuda sobre les compres integrades. Si l'app surt sense ella, caldrà una nova versió per fer-la validar.
2. Tots els elements d'una sol·licitud han de ser acceptats perquè la sol·licitud ho sigui. Una subscripció rebutjada ho bloqueja tot.

La regla 2.1(b) també exigeix que les compres integrades estiguin completes, siguin visibles per al revisor i funcionin. Si alguna no apareix a l'app, explica per què a les notes de revisió. El muntatge complet d'una subscripció està detallat a subscripcions in-app a iOS.

El compte de demostració que falta

Si la teva app demana iniciar sessió, les App Review Guidelines exigeixen un compte de demostració actiu o un mode demo complet, i serveis de servidor encesos durant la revisió. Sense credencials a la secció App Review Information de la teva versió, el revisor es queda bloquejat a la pantalla d'inici de sessió, i això és un rebuig. Recorda també no apagar el servidor de proves durant la revisió.

Els rebutjos mateixos

És el primer factor, i de molt. Apple indica que més del 40 % dels problemes no resolts tenen a veure amb la regla 2.1, la que cobreix els penjaments, el contingut provisional i la informació incompleta. Un rebuig evitat és, com a mínim, un cicle guanyat.

Respondre al Resolution Center

Quan una sol·licitud és rebutjada, el seu estat passa a Unresolved Issues. El missatge d'Apple cita la regla incomplerta, sovint amb una captura del problema. Tot passa a la secció App Review de la teva app a App Store Connect, que encara s'anomena sovint Resolution Center.

El procediment oficial per respondre a App Review:

1. A la teva app, fes clic a l'enllaç dels problemes no resolts a dalt de la pàgina.
2. Fes clic a Resolve al costat de la sol·licitud.
3. Fes clic a Reply to App Review, escriu la resposta (4.000 caràcters com a màxim) i, si cal, adjunta una captura o un document.

Què fa que una resposta sigui eficaç:

• Anomena la correcció, no el que sents. «La petició de valoració ara apareix després de guanyar la demo, captura adjunta» val més que un llarg al·legat.
• Adjunta una prova. Una captura o un vídeo curt de la pantalla corregida evita una anada i tornada de preguntes.
• Si el rebuig només afecta les metadades (text de la fitxa, captures, enllaços, com un rebuig 2.3.10), Apple precisa que pots tornar a enviar el mateix build després de corregir. No cal recompilar.

Apel·lar, només si n'estàs segur

Pots impugnar un rebuig davant l'App Review Board. Apple demana que expliquis amb precisió per què l'app compleix les regles, que facis una sola apel·lació per sol·licitud rebutjada i que primer responguis les peticions d'informació pendents. Apel·lar un rebuig merescut només allarga l'espera.

Enviar una correcció ràpidament

Quan el motiu és clar, la rapidesa ve de la disciplina:

• Corregeix el motiu, i només el motiu. Colar tres novetats al build corregit és tornar a obrir la superfície de revisió.
• Prova la correcció en les condicions del revisor. Per a un problema de visualització, això vol dir l'iPhone més petit compatible i el més gran, no només el teu.
• Compte amb els elements retirats. En una sol·licitud amb problemes no resolts, l'ajuda d'Apple precisa que un element retirat no es pot tornar a afegir a la mateixa sol·licitud, i que cada element només es pot modificar una vegada abans de tornar a enviar. Pensa-t'ho abans d'eliminar una subscripció rebutjada.
• Torna a enviar i després respon. Una o dues frases factuals a la resposta per dir què ha canviat.

I la revisió accelerada? Existeix, però Apple la reserva per a dos casos: la correcció d'un error crític en una versió ja publicada, amb els passos per reproduir-lo, i les apps lligades a un esdeveniment amb data. No és una drecera per a una primera publicació que va tard.

Els rebutjos més freqüents entre principiants

Ja vaig explicar amb detall els meus dos rebutjos de Solys a per què Apple rebutja una app. Aquests són els motius que he rebut de veritat, amb el número de regla, perquè són exactament els que amenacen una primera app.

2.1, l'app no funciona (Solys). La demo de benvinguda de Solys era impossible de guanyar en una pantalla petita d'iPhone: un pas obligatori insuperable, i per tant una app considerada incompleta. Ja està corregit.

5.6.3, la petició de valoració massa aviat (Solys). La valoració de l'App Store es demanava al principi de l'onboarding, abans que la persona hagués viscut res a l'app. Ha d'arribar després d'un moment de valor real.

5.1.1, la política de privacitat no actualitzada (Clic). La regla 5.1.1 exigeix un enllaç a la política de privacitat a App Store Connect i a l'app, i aquesta política ha de descriure amb precisió les dades recollides, com s'utilitzen i com es poden eliminar. A Clic, la versió en línia no estava actualitzada. Una política que no segueix el teu producte n'hi ha prou per fer rebutjar la sol·licitud.

5.1.1, el botó «Allow» abans de la petició del sistema (Nolera). Nolera mostrava una pantalla d'explicació abans de la petició d'accés a la càmera, amb un botó anomenat «Allow». Les Human Interface Guidelines sobre privacitat són clares: una pantalla abans de l'alerta del sistema està permesa, però el botó no ha de repetir «Allow» ni un terme semblant, perquè en aquell moment no s'autoritza res. Apple recomana «Continue» o «Next».

2.3.2, la icona reutilitzada com a imatge promocional de la subscripció (Nolera). La regla 2.3.2 regula la promoció de les compres integrades a l'App Store: el nom, la imatge i la descripció han de ser adequats. A Nolera, la imatge promocional de la subscripció simplement repetia la icona de l'app. Cal una imatge pròpia de la compra.

El que uneix aquests cinc rebutjos: cap no era un problema de codi complex. Tots es veien rellegint el dossier amb els ulls d'un revisor. Si t'acaben de rebutjar l'app i el motiu no és clar, tens el procés complet a aplicació rebutjada per Apple.

Preveure el temps a la teva planificació

Unes quantes regles senzilles perquè la revisió no et retardi el llançament:

• No anunciïs cap data abans de l'acceptació. Fes validar l'app, tria la publicació manual i després fixa la data.
• Deixa un marge d'almenys un cicle de rebuig si és el teu primer enviament o la teva primera subscripció.
• Obre el compte de desenvolupador aviat si ho fas a través d'una empresa: només el número D-U-N-S pot trigar més d'una setmana. Tot està explicat a la guia del compte de desenvolupador d'Apple.
• Rellegeix el dossier com un revisor: compte de demo, política de privacitat actualitzada, privacy manifest complet, pantalles de permisos, imatges de subscripció i cada pantalla obligatòria en un iPhone petit i en un de gran.

Si vols que et revisin el dossier abans d'enviar-lo

L'Apple Review Kit reuneix la meva checklist abans de l'enviament, els meus rebutjos d'Apple corregits i skills de Claude Code que revisen el teu projecte, el teu paywall i la teva fitxa. No garanteix l'acceptació, qui decideix és Apple, però t'ajuda a detectar els motius de més amunt abans que et costin un cicle.

Prepares el teu primer enviament? El diagnòstic gratuït t'envia la meva checklist antirebuig d'Apple i et diu què et queda per fer. Si la teva app ja està bloquejada, reserva una hora amb mi: llegim junts el missatge d'Apple, per videotrucada. I si encara l'estàs construint, a la pàgina d'inici veuràs com crear la teva aplicació mòbil pensant en la revisió des del principi.

Preguntes freqüents

Quant triga Apple a validar una app a l'App Store?

Apple diu 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. No és una garantia: algunes triguen més, i no es revisen necessàriament en l'ordre d'enviament. El temps real és el que passa entre el teu primer enviament i la posada a la venda, i s'allarga sobretot pels rebutjos.

Què allarga el temps de validació d'una app?

Els rebutjos, de molt: cadascun torna a engegar un cicle complet (llegir el motiu, corregir, tornar a enviar, tornar a esperar). Apple indica que més del 40 % dels problemes no resolts tenen a veure amb la regla 2.1, la dels penjaments, el contingut provisional i la informació incompleta. Un primer enviament també multiplica les ocasions de rebuig, perquè Apple ho revisa tot de cop.

Com es respon a un rebuig de l'App Store?

A la secció App Review de la teva app, obre els problemes no resolts, fes clic a Resolve i després a Reply to App Review. Escriu la resposta (4.000 caràcters com a màxim), anomena la correcció en lloc del que sents i adjunta una captura o un vídeo curt. Si el rebuig només afecta les metadades, pots tornar a enviar el mateix build després de corregir. Si el motiu no és clar, llegeix aplicació rebutjada per Apple.

Es pot demanar a Apple una validació accelerada?

Sí, la revisió accelerada existeix, però Apple la reserva per a dos casos: la correcció d'un error crític en una versió ja publicada, amb els passos per reproduir-lo, i les apps lligades a un esdeveniment amb data. No és una drecera per a una primera publicació que va tard.

La primera subscripció s'ha d'enviar amb l'app?

Sí, segons l'ajuda d'Apple: la teva primera subscripció s'ha d'enviar amb una nova versió de l'app. Si l'app surt sense ella, caldrà una nova versió per fer-la validar. Perquè la sol·licitud sigui acceptada, tots els seus elements ho han de ser: una subscripció rebutjada ho bloqueja tot.

Quan s'ha d'anunciar la data de llançament d'una app?

No abans que Apple accepti l'app. Tria la publicació manual: primer fas validar l'app, i després fixes la data de llançament quan tens llum verda. Si és el teu primer enviament o la teva primera subscripció, deixa també un marge d'almenys un cicle de rebuig.