Guideline 2.1 App Store: entendre i corregir un rebuig

La guideline 2.1 és la norma que fa caure més enviaments. Ho escriu la mateixa Apple a la seva pàgina App Review: de mitjana, més del 40 % dels problemes no resolts tenen a veure amb la 2.1, la que cobreix els tancaments inesperats, el contingut provisional i la informació incompleta.

Aquest article tracta només aquesta norma: què cobreix, les seves dues variants, com prova el revisor la teva app i què li has de respondre, amb tres rebuigs que he rebut a les meves pròpies apps. Per a la visió de conjunt de tots els motius de rebuig, llegeix millor per què Apple rebutja una app.

Què és la guideline 2.1 App Completeness?

La guideline 2.1 exigeix que l'app enviada a Apple sigui una versió final i completa: cap tancament inesperat, cap enllaç trencat, cap text provisional, un compte de demostració si l'app demana iniciar sessió, i compres integrades visibles i funcionals. Si el revisor no pot recórrer la teva app fins al final, és un rebuig 2.1.

El text oficial és a les App Review Guidelines, secció 2 "Performance". Es divideix en dos apartats.

2.1(a) demana que cada enviament sigui una versió final, amb totes les metadades i URL que funcionin. El text provisional, els llocs web buits i qualsevol contingut temporal han de desaparèixer abans de l'enviament. L'app s'ha d'haver provat en un dispositiu real per detectar errors i comprovar-ne l'estabilitat. Si demana iniciar sessió, has de proporcionar un compte de demostració i deixar el servidor encès. Un mode demo integrat pot substituir aquest compte, però només amb l'acord previ d'Apple, i ha de mostrar totes les funcions de l'app. La frase que ho resumeix tot: "We will reject incomplete app bundles and binaries that crash".

2.1(b) tracta les compres integrades: han de ser completes, actualitzades, visibles per al revisor i funcionals. Si una compra configurada a App Store Connect no es troba enlloc dins l'app, has d'explicar per què a les notes de revisió.

Què cobreix la guideline 2.1 a la pràctica

A la pràctica, un rebuig 2.1 arriba per una d'aquestes raons:

• Un tancament inesperat. En obrir l'app, després d'un permís denegat, sense xarxa. N'hi ha prou amb un.
• Un enllaç trencat. Privadesa, condicions d'ús, suport: s'obrirà cada URL declarada.
• Una funció inaccessible. Un botó que no porta enlloc, una pantalla obligatòria impossible de superar, un onboarding sense sortida. La forma més traïdora: invisible al teu propi telèfon.
• Un compte de demostració inexistent o caducat. El revisor es queda bloquejat a la pantalla d'inici de sessió, o el compte proporcionat ja no funciona, o el servidor està apagat.
• Contingut de farciment. Lorem ipsum, "Aviat disponible", pantalla buida, dades de prova visibles.
• Compres integrades que no es troben. La subscripció existeix a App Store Connect, però el revisor no troba la pantalla que la ven, o la compra falla en sandbox. Els errors més habituals a la pantalla de pagament són a paywall iOS: 7 errors de principiant.

2.1 Information Needed o 2.1(a): quina diferència hi ha?

No tots els missatges d'Apple porten el mateix títol, i la diferència canvia la teva resposta.

"Guideline 2.1 - Information Needed" vol dir que el revisor no ha pogut acabar la revisió i et fa una pregunta. Hi falta un identificador, una explicació, una manera d'arribar a una funció. Encara no és la constatació d'un error: és una petició. De vegades n'hi ha prou amb una resposta precisa a App Store Connect. Però si la pregunta revela un bloqueig real a l'app, cal un build nou.

"Guideline 2.1(a) - Performance - App Completeness" vol dir que el revisor ha constatat un problema: un tancament inesperat, un error, una pantalla que no respon. El missatge sol indicar el dispositiu utilitzat i sovint hi adjunta una captura. Aquí cal corregir, tornar a enviar un build i després respondre.

Com prova Apple la teva app

Posa't al lloc del revisor. Hi ha tres punts que compten.

Prova en un dispositiu que potser no tens. El missatge de rebuig sovint precisa el model. La norma 2.4.1 indica que les apps d'iPhone han de funcionar a l'iPad sempre que sigui possible, i una app pensada per a iPhone s'hi mostra en mode de compatibilitat, en una finestra amb format d'iPhone. Els meus rebuigs 2.1 recents venien d'un iPad Air: si només proves al teu iPhone, no veus el que veu el revisor.

Parteix d'una primera obertura. App nova, sense memòria cau, sense sessió, sense cap actualització descarregada.

La xarxa ha de funcionar només amb IPv6. La norma 2.5.5, veïna de la guideline 2.5.4 sobre els modes en segon pla, exigeix que l'app funcioni plenament en una xarxa només IPv6, i la pàgina de suport d'Apple sobre IPv6 ho converteix en un requisit per a totes les apps enviades des de l'1 de juny de 2016. El risc ve d'una adreça IPv4 escrita a mà al codi: Apple recomana provar en una xarxa només IPv6, amb les dades mòbils desactivades.

Per reproduir aquestes condicions abans de l'enviament, TestFlight en diversos dispositius continua sent el més senzill: mira TestFlight: provar la teva app d'iPhone.

Tres rebuigs que he rebut, i la seva causa real

Tres rebuigs recents a les meves pròpies apps, amb la seva causa real.

Solys: una demo de minijoc impossible de guanyar a l'iPad

Solys és el meu despertador amb minijocs. El 18 d'agost de 2026, un build és rebutjat amb "2.1 Information Needed": Apple demana una manera de superar la missió del joc. El revisor provava en un iPad Air, amb l'app d'iPhone en mode de compatibilitat.

La causa real era a la demo de minijoc de l'onboarding. Les altures dels obstacles estaven escrites en punts fixos. Amb l'altura de targeta disponible a l'iPad en compatibilitat, el pas quedava més estret que el personatge: la demo era impossible de guanyar. I el botó "Continuar" només s'activava en cas de victòria. Cap sortida: el revisor no podia veure l'app.

La correcció: una geometria proporcional a la mida mesurada de la targeta, i un enllaç "Saltar la demo" que apareix després d'una derrota.

La lliçó: qualsevol pas bloquejat per una prova d'habilitat ha de tenir una sortida sense condicions. I cada pantalla obligatòria es prova a la pantalla més petita compatible I a l'iPad en mode de compatibilitat.

Nolera: una correcció invisible per al revisor

El 17 de setembre de 2026, Nolera és rebutjada després d'una revisió en un iPad Air. El missatge combinava la 2.1(a) i altres punts. La correcció del problema assenyalat s'havia publicat amb una actualització remota (OTA), sense build nou.

El problema: en la primeríssima obertura, el revisor veu el codi inclòs al build, no l'actualització descarregada després. Per a ell, la correcció no existia.

La lliçó: una correcció pensada per a la revisió ha de ser al binari enviat a Apple.

Clic: la causa no era a l'app

El 16 de setembre de 2026, Clic és rebutjada. L'app, en canvi, estava al dia. La causa real era en un altre lloc: la política de privadesa publicada en línia no estava actualitzada pel que fa al proveïdor d'IA utilitzat. Aquest rebuig és més de privadesa que de 2.1, però il·lustra el mateix: les causes reals no sempre són les que el missatge fa pensar.

La lliçó: comprova el que hi ha en línia, no el que hi ha al teu repositori. Obre cada URL declarada el dia de l'enviament.

Què respondre al Resolution Center

Després d'un rebuig, el teu enviament passa a "Unresolved Issues" i la conversa amb Apple té lloc a la secció App Review de la teva app, que encara s'anomena Resolution Center. El procediment oficial per respondre a App Review permet un missatge de 4.000 caràcters com a màxim, amb un fitxer adjunt.

Escriu en anglès, amb sobrietat. El revisor vol tres informacions: què bloquejava, què ha canviat, com comprovar-ho. Aquest és el model que faig servir (substitueix el número de build i la correcció pels teus):

Hello,

Thank you for your review.

Issue: the onboarding game demo could not be completed on iPad
(iPhone app running in compatibility mode), so the user could
not continue.

Fix in build 1.0.3 (42):
- The game layout now scales to the measured screen size.
- A "Skip demo" link appears after a failed attempt, so the
  onboarding can always be completed.

How to verify: launch the app, start the onboarding demo,
lose once, then tap "Skip demo".

A screen recording is attached.

Best regards,

Algunes regles:

• Respon a la pregunta que et fan. En un "Information Needed", comença per la resposta exacta, no pel context.
• Indica el build i dona el camí fins a la pantalla corregida, en tres o quatre accions.
• Adjunta una prova. Un vídeo curt en un dispositiu semblant al del revisor evita una nova anada i tornada.
• Res d'al·legats. L'apel·lació davant l'App Review Board existeix, però en un rebuig 2.1 merescut només allarga l'espera. El detall dels terminis és a termini de validació de l'App Store.

Si el motiu continua sent confús després de llegir-lo, tens el procés complet a la pàgina aplicació rebutjada per Apple.

Notes de revisió i compte de demo

La secció App Review Information de la teva versió, a App Store Connect, és la teva millor defensa contra la 2.1. Segons la referència oficial d'aquests camps, conté:

• Sign-in required: l'usuari i la contrasenya d'un compte de demostració. Aquest compte no ha de caducar. Si la teva app fa servir un inici de sessió de tercers, proporciona les credencials d'aquest servei.
• Notes: fins a 4.000 bytes, en l'idioma que vulguis. Tot el que ajudi a provar.
• Contact: un nom, un correu electrònic i un número en format internacional.

El que poso sempre a les notes:

1. El camí fins a cada compra integrada, com demana la norma 2.1(b).
2. Les funcions poc evidents: un gest, un permís, un contingut lligat a una hora.
3. L'estat del compte de demo: subscrit o no, dades preomplertes o buides.
4. Les limitacions conegudes: per a un maquinari o un entorn difícil de reproduir, Apple demana estar preparat per proporcionar un vídeo.

I una regla fora del formulari: mantén el servidor encès durant tota la revisió. Un servidor de proves apagat és un compte de demo que ja no funciona, i per tant un rebuig 2.1.

La checklist 2.1 abans d'enviar

La que aplico abans de cada enviament, construïda a partir dels meus rebuigs:

• App instal·lada des de zero a l'iPhone compatible més petit, al més gran i a un iPad en mode de compatibilitat
• Onboarding recorregut sencer, fallant expressament a cada pas que demana una prova d'habilitat
• Cada pantalla obligatòria amb una sortida sense condicions
• Cap correcció pensada per a la revisió publicada només per actualització remota
• App oberta en mode avió, i després en una xarxa només IPv6
• Cada URL declarada oberta el mateix dia: privadesa, condicions, suport
• Cap text provisional, pantalla buida o dada de prova visible
• Compte de demo provat el dia de l'enviament, sense data de caducitat, servidor encès
• Cada compra integrada trobada des de l'app i provada en sandbox, restauració inclosa
• Notes de revisió que indiquen on són les compres i les funcions poc evidents

Si és la teva primera publicació, tots els passos previs són a publicar una aplicació a l'App Store.

Envia el teu expedient amb algú que ja ha rebut aquests rebuigs

L'Apple Review Kit reuneix la meva checklist d'abans de l'enviament, els models de notes per al revisor i skills de Claude Code que revisen el teu projecte abans que l'enviïs.

Acabes de rebre un rebuig 2.1? El kit també t'ajuda a trobar la norma citada, què demana, i un exemple de correcció i de resposta. Si vols que mirem el teu expedient junts ara mateix, reserva una hora amb mi, per videotrucada.

Ningú no pot garantir que Apple acceptarà la teva app. El que sí que puc fer és ajudar-te a evitar els rebuigs 2.1 que jo ja he pagat amb un cicle de revisió.

Encara no has enviat la teva app? El diagnòstic gratuït t'envia la meva checklist antirebuig d'Apple, norma 2.1 inclosa, i et diu què et queda per fer abans de l'enviament. Si encara l'estàs construint, la pàgina d'inici mostra com crear una aplicació mòbil amb la revisió al cap des del principi.

Preguntes freqüents

Què vol dir "Guideline 2.1 - Information Needed"?

El revisor no ha pogut acabar la revisió i et fa una pregunta: un identificador, una explicació, una manera d'accedir a una funció. Respon amb precisió a App Store Connect. Si la pregunta revela un bloqueig real a l'app, com a Solys, corregeix-lo i envia un build nou.

Cal un build nou després d'un rebuig 2.1?

Per a un tancament inesperat, un error o una pantalla que bloqueja, sí: la correcció ha de ser al binari. Una actualització remota no n'hi ha prou, perquè el revisor veu el codi inclòs a la primera obertura. Per a una simple informació que falta, pot bastar una resposta.

La meva app demana iniciar sessió: què he de proporcionar al revisor?

Un compte de demostració que no caduqui, indicat a la secció App Review Information, i un servidor encès durant tota la revisió. Un mode demo integrat pot substituir aquest compte només amb l'acord previ d'Apple, i ha de mostrar totes les funcions.

Un rebuig 2.1 pot venir d'alguna cosa que no sigui l'app?

Sí. N'hi ha prou amb una URL trencada a la fitxa, un compte de demo caducat, un servidor apagat o una compra integrada mal configurada. I de vegades, com a Clic, la causa real és en línia i no al codi: comprova tot el que el revisor pot obrir.