Per què la revisió de l'app triga tant?

Una revisió lenta no vol dir automàticament que la teva app tingui un problema. Aprèn a distingir un retard de cua d'una tramesa bloquejada, què prometen realment Apple i Google, i quan contactar amb el suport.

Has pujat la build, has comprovat les captures de pantalla i has planificat el llançament. Llavors no passa res. App Store Connect encara diu Waiting for Review, o Play Console manté els teus canvis en revisió. Mentrestant, cada dia d'incertesa fa més difícil coordinar el màrqueting, l'atenció al client i un anunci de llançament.

La part frustrant és que un retard té diverses explicacions possibles. La teva presentació podria simplement estar esperant el seu torn. Un revisor podria necessitar informació. La teva compilació podria no haver arribat a la revisió en absolut. O la revisió podria ja haver acabat, amb la publicació esperant-te a tu. Aquesta guia explica com distingir aquestes situacions. Se centra en Apple App Review, amb una comparació separada de Google Play. Les fonts es van comprovar el 3 d'octubre de 2026.

Quant de temps hauria de trigar la revisió de l'app?

Apple diu que, de mitjana, el 90% de les trameses es revisen en menys de 24 hores. Això és un context útil, però no és un termini garantit per a la teva app individual. Algunes trameses queden fora d'aquesta finestra, i l'estadística no et dona un temps de finalització per a aquestes excepcions. Apple també adverteix que les trameses incompletes poden retardar la revisió. [1]

Tracta aquest número com una referència de planificació, no com un compromís de llançament. Una presentació que triga més d'un dia no és, per si mateixa, evidència de rebuig o d'un compte trencat. Igualment, una mitjana no t'ha de persuadir per ignorar un missatge accionable. L'estat i la correspondència del revisor importen més que les comparacions amb l'aprovació més ràpida d'un altre desenvolupador.

Primer, identifica on és realment el retard

Llegeix l'estat precís en lloc de traduir cada indicador groc a "Apple està revisant la meva app". Esperant revisió significa que l'enviament està a la cua; En revisió significa que la revisió ha començat. Pendent de llançament del desenvolupador significa que l'app ha estat acceptada però encara necessita la teva acció de llançament. Esperant compliment d'exportació és un procés diferent. Un element acceptat també pot romandre sense publicar si un altre element del seu enviament va ser rebutjat. [2]

Comprova la versió de l'aplicació i l'enviament junts, no només la compilació penjada. Una captura de pantalla de la llista de compilacions pot explicar una història diferent de la pàgina d'enviament. Anota la versió, el número de compilació, l'hora d'enviament i l'estat actual. Aquest petit registre evita que solucionis problemes d'una compilació antiga o confonguis un enviament de TestFlight amb un llançament a l'App Store.

Els revisors han d'experimentar l'aplicació completa

Un revisor no pot avaluar una funció a la qual no pot accedir. La llista de verificació d'enviament d'Apple demana accés complet, un compte de demostració actiu o un mode de demostració adequat, maquinari necessari o recursos de mostra, i serveis de backend en funcionament. També demana als desenvolupadors que expliquin les funcions i compres no òbvies a les notes de revisió. Aquests requisits fan que l'accés sigui un primer lloc sensat per investigar. [3]

Prova les credencials exactes que has proporcionat, preferiblement en un dispositiu net. Comprova si un compte necessita verificació per correu electrònic, un dret de pagament, una invitació o una contrasenya d'un sol ús. Prova el camí d'incorporació sense el teu compte de desenvolupador. Si una funció requereix una regió particular o un segon usuari, explica com el revisor pot reproduir aquesta configuració. No assumeixis que inferirà el flux de treball que pretenies.

Una guia breu i reproduïble és més útil que un discurs de vendes. Per exemple: inicia sessió amb el compte proporcionat, obre Biblioteca, selecciona el projecte de mostra i toca Exporta. Inclou qualsevol limitació esperada i explica per què existeix. Això no compra prioritat; redueix l'ambigüitat evitable quan algú arriba a la teva tramesa.

Un rebuig necessita una resposta, no més espera

Quan Apple rebutja una app, el seu missatge explica el problema i la directriu rellevant. App Store Connect et permet respondre i adjuntar material de suport. Apple també afirma que un rebuig de metadades es pot resoldre i tornar a enviar utilitzant la mateixa build. Per tant, no sempre cal un binari nou. [4]

Respon a l'objecció específica. Si el revisor no ha pogut trobar una funció, proporciona els passos de navegació. Si la seva preocupació és una captura de pantalla enganyosa, corregeix la captura. Si no hi estàs d'acord, explica el comportament i proporciona proves en lloc de repetir que altres aplicacions ho fan. Separa el que has canviat del que demanes a Apple que aclareixi.

Mantingues un registre d'incidències senzill: la pregunta del revisor, la teva resposta, l'actiu o build canviat i la següent acció requerida. Això fa que la correspondència posterior sigui més fàcil de seguir. També evita que un equip enviï de manera independent explicacions diferents. La comunicació de revisió és una conversa de depuració, no un concurs per enviar la resposta més llarga.

El processament de compilació i TestFlight són punts de control separats

Una build pujada no està necessàriament llesta per a l'enviament. La referència d'estat de build d'Apple distingeix processament, informació de compliment que falta i disponibilitat per enviar. També distingeix els estats de TestFlight 'Esperant revisió' i 'En revisió beta' de la disponibilitat per a testers interns. Les proves beta externes poden requerir la revisió d'app de TestFlight. [5]

Si la teva beta està bloquejada, inspecciona l'estat de la build abans de buscar un problema a la cua de revisió de l'App Store. Per a Compliment pendent, Apple indica als desenvolupadors que responguin les preguntes de xifratge o proporcionin la documentació pertinent. Algunes builds poden declarar una exempció aplicable mitjançant la seva configuració, però hauries de respondre amb precisió en lloc de canviar la configuració només per evitar el missatge. [6]

Aprovat no sempre vol dir disponible immediatament

El flux de treball de publicació d'Apple separa triar una build, establir la disponibilitat, enviar, resoldre problemes de revisió i distribuir. Diu que una app aprovada pot trigar fins a 24 hores a estar disponible. També tries si el llançament és manual, automàtic o per fases. Comprova aquests paràmetres abans de descriure una versió aprovada com a “encara en revisió”. [7]

Per a les actualitzacions, un llançament per fases distribueix gradualment la versió als usuaris elegibles amb actualitzacions automàtiques durant set dies. Això és una opció de desplegament, no set dies extres de revisió. Si un client encara veu una versió antiga, confirma primer el mètode de llançament i la disponibilitat en lloc de suposar que el revisor ha retingut l'aprovació. [8]

Google Play té una finestra de revisió diferent

No apliquis el temps d'Apple a Google Play. Google diu que les ressenyes poden trigar unes hores o fins a set dies, i més en casos excepcionals. La seva visió general de publicació també adverteix que enviar un altre canvi mentre hi ha canvis en revisió pot fer retrocedir l'aplicació a la cua de revisió. Per tant, les petites edicions repetides poden jugar en contra d'un llançament predictible. [9]

La visió general de publicació de Play Console distingeix els canvis en revisió dels canvis llestos per publicar. Amb la publicació gestionada activada, l'aprovació i la publicació són decisions separades. Mira la cua de canvis, no només si la nova fitxa és visible en un telèfon. Acaba el paquet de llançament previst abans d'enviar-lo i evita edicions no relacionades mentre esperes, tret que alguna cosa necessiti realment correcció.

Un exemple pràctic: diagnostica abans de tornar a enviar

Imagina una app de seguiment d'hàbits enviada dilluns al matí. Dimarts al vespre, el fundador comença a reconstruir-la perquè l'aprovació no ha arribat. Abans de fer-ho, comprova tres coses: si la versió està realment a la cua, si la revisió ha enviat un missatge i si el compte proporcionat pot completar l'onboarding. Aquest és un escenari il·lustratiu, no un cas mesurat de client d'AsoTheory.

Si l'app simplement espera i l'accés funciona, una build de substitució no ofereix cap solució demostrada. Si un revisor informa d'un error d'inici de sessió, arreglar l'accés aborda un obstacle real. Si l'estat és Pendent de llançament del desenvolupador, l'acció correcta és llançar, no tornar a enviar. El mateix temps transcorregut pot requerir tres respostes totalment diferents. Per això, diagnosticar l'estat ve abans de triar un remei.

Quan hauries de contactar amb Apple?

Per a un retard inexplicable i inusualment llarg, utilitza la via de contacte de revisió d'Apple amb una línia de temps concisa i els identificadors de l'enviament. Descriu l'estat actual, qualsevol correspondència prèvia i què ja has comprovat. No hi ha cap llindar universal de dies a la guia citada que garanteixi una escalada. Evita inventar-ne un o prometre que un missatge de suport farà avançar la teva aplicació.

La revisió accelerada és una sol·licitud separada. Apple dona exemples com una correcció d'error crítica o un llançament lligat a un esdeveniment amb el qual estàs directament associat. Explica la circumstància real i l'impacte; la impaciència de màrqueting ordinària no és el mateix. Una sol·licitud accelerada no s'ha de presentar com una drecera garantida. [1]

Planifica el llançament al voltant de la incertesa

Una nota de llançament interna útil té quatre camps: què canvia, què poden accedir actualment els clients, qui vigila la correspondència de revisió i què desencadena l'anunci. Assigna una persona com a responsable de la tramesa. Acorda un calendari de seguiment en lloc de fer que tothom actualitzi la consola tota la tarda. Mantén les proves juntes, inclosos els missatges del revisor i la versió exacta enviada. Res d'això escurça la cua d'Apple, però evita que la incertesa es converteixi en reconstruccions innecessàries o decisions contradictòries.

Si el teu llançament afegeix una subscripció nova o canvia l'onboarding, prepara respostes de suport abans que arribi l'aprovació. Assegura't que els teus enllaços de màrqueting descriguin la versió que la gent pot descarregar realment. Evita anunciar que una funció està activa només perquè la seva build ha estat acceptada. Per a un primer llançament, tingues a punt un missatge de pàgina d'aterratge alternatiu. Aquestes són recomanacions operatives, no requisits de la botiga ni promeses sobre la velocitat de revisió: el seu valor és que el teu equip pugui actuar amb sensatesa quan el calendari està fora del seu control.

Mantingues la preparació de la revisió en una llista de verificació de llançament: accés funcional, notes clares, fluxos de compra provats, actius precisos, correspondència supervisada i una configuració de publicació deliberada. Deixa marge entre l'enviament i qualsevol data de campanya fixa. Si el temps és essencial, decideix per endavant què passa si l'aprovació arriba tard: pausa l'anunci, mantén la versió actual disponible o comunica una finestra revisada.

Finalment, distingeix l'evidència de les històries. Les llargues esperes d'altres desenvolupadors poden ser reals, però no demostren per què la teva aplicació està retardada. Ni la guia citada d'Apple ni la de Google estableixen una explicació universal com ara que les aplicacions generades per IA causen un coll d'ampolla. La pregunta útil no és "quina rumor ho explica?" sinó "en quin estat es troba el meu enviament i hi ha alguna acció que pugui prendre realment?"

Relacionat

Blog · Estudis de cas · Free ASO tools · Productes · Privacitat i termes · AsoTheory