Apple dejó por escrito cómo funciona App Review. Esto es lo que cambiaría antes de enviar

Casi todo lo que sé de App Review lo aprendí con correos de rechazo. Así que cuando el Hello Developer del noviembre de 2026 de Apple dijo “Browse new App Review help articles”, los leí todos. Ahora viven en un solo sitio, App Review Help, y dicen en voz alta muchas cosas que antes eran folclore.

Esto es lo que contienen que importa para una app de Mac, y lo que cambiaría antes de mi próximo envío.

Primero, para quién es esto

App Review solo mira lo que pasa por App Store Connect: el Mac App Store, TestFlight, las compras dentro de la app y el resto. Si vendes tu app de Mac desde tu propio sitio con un Developer ID, nadie en Apple la revisa. Pasa por la notarización, que es una comprobación automática. Así que si solo distribuyes directamente, échale un vistazo y guárdalo para el día en que añadas una versión en el Mac App Store.

Cuánto tarda una revisión

El artículo sobre el estado de revisión da el objetivo de Apple: revisar al menos el 50% de los envíos en menos de 24 horas y el 90% en menos de 48 horas. También dice qué la hace más lenta, como un historial de revisión limitado, documentos que Apple necesita o problemas complejos o novedosos.

Lo que haría: planificar un día de lanzamiento con dos días libres antes, más si es tu primera app. Y enviar pronto con publicación manual, para elegir el minuto en que sale.

El campo Notes es donde se ganan las revisiones

El artículo sobre la revisión completa es directo: “Incomplete submissions will be rejected.” Los detalles que importan:

• Los accesos de demostración tienen que funcionar cuando empieza la revisión, no solo cuando envías. Una cuenta de prueba que caduca o cambia entre medias puede costarte un rechazo.
• Si el acceso necesita un código, ponlo en Notes. Sin él, Apple puede tener que llamar, y las llamadas suelen hacerse en tres a cinco días hábiles. Es una semana perdida.
• Las suscripciones necesitan una cuenta de demostración con la suscripción caducada, para que quien revisa vea todo el flujo de compra.

Lo que haría: escribir el campo Notes como un tutorial corto para un desconocido. Dónde hacer clic primero, qué cuenta usar y qué hace el icono de la barra de menús si tu app no tiene ventana. Esto último es muy de Mac.

Cuando te rechazan

Esta es la parte que ojalá hubiera tenido por escrito hace años.

• No reenvíes para responder una pregunta. Si App Review pide información, responde en App Store Connect. Reenvía solo para corregir algo en el build, y solo cuando hayas corregido todos los problemas que mencionaron.
• Busca “Bug Fix Submissions:” al principio. Si un rechazo empieza con esa nota, el artículo sobre Bug Fix Submissions dice que puedes responder para aceptarlo y resolver el problema en tu próxima actualización. No reenvíes. Solo funciona con apps aprobadas antes, nunca con problemas legales o de seguridad, y un problema no se puede aplazar dos veces.
• Pide una revisión urgente solo si es real. Apple dice que las solicitudes de revisión urgente “deben reservarse para asuntos de verdadera urgencia”, y solo para builds ya enviados a revisión. Si el lanzamiento va ligado a un evento, escribe el evento y su fecha en Notes.
• Apela al final. Primero responde al rechazo y explícate. Si no funciona, el App Review Board admite una apelación por app, y una vez que has reenviado, ya no puedes apelar ese rechazo.

Cuatro reglas, con números

Los artículos sobre las guidelines son cortos y concretos.

• Capturas de pantalla, 2.3.3. Más de la mitad de tus capturas deben mostrar la app en uso, contando por tipo de dispositivo. Con tres capturas, dos tienen que ser de la app. Una pantalla de inicio o una tarjeta de título está bien mientras sea la minoría. El verificador de capturas de MacPip revisa los tamaños, y lo demás lo puedes contar tú.
• Imitaciones, 4.1. No pongas nombres de apps populares ni términos con marca registrada en ningún campo de metadatos. Eso incluye tus palabras clave, donde el nombre de un rival es el error clásico. El verificador de palabras clave de App Store cuenta tus campos para que veas qué hay en ellos.
• Purpose strings, 5.1.1(ii). Cada recurso protegido necesita su propio purpose string claro, localizado si tu app lo está. El mal ejemplo de Apple es “To use location.” Y también eres responsable de lo que piden tus SDK. Pega tu Info.plist en el explicador de Info.plist y marca los vacíos y los vagos.
• Eliminación de cuentas, 5.1.1(v). Si la gente puede crear una cuenta en tu app, tiene que poder iniciar su eliminación desde la app. Desactivarla no basta, y no puedes obligarla a llamarte por teléfono. Si hay suscripción, avísale de que el cobro sigue por Apple hasta que la cancele.

La línea sobre el Mac

Solo el artículo sobre dispositivos compatibles nombra el Mac. Dice que las apps compatibles de iPhone y iPad pueden ejecutarse sin modificar en Mac con Apple silicon, y que las apps que dependen de un toque que no se puede hacer con teclado no son adecuadas para macOS. Si haces una app de iPad, comprueba si aparece en el Mac App Store y desactívalo si no funciona bien con teclado y trackpad. La misma página dice que TestFlight admite hasta 100 testers internos y 10.000 externos, y que el primer build que das a los testers externos también pasa por App Review.

What's New también cuenta

Una más, de las guidelines y no de los artículos nuevos. La Guideline 2.3.12 dice que el texto de What's New debe describir las funciones nuevas y los cambios, y que solo las correcciones simples y el trabajo de rendimiento pueden salir con una línea genérica. “Bug fixes and improvements” en una versión con una función nueva es pedir que te hagan una pregunta.

Así que la herramienta gratuita de hoy es el formateador de notas de versión. Pega notas sin pulir o tus líneas de git log --oneline. Las ordena en Nuevo, Mejorado y Corregido, descarta las líneas de chore, ci y merge, marca números de ticket y nombres de archivo, comprueba el límite de 4000 caracteres y te da tres copias: texto sin formato para App Store Connect, HTML para tu appcast de Sparkle y Markdown para GitHub. Tus notas se quedan en tu navegador. El verificador de appcast de Sparkle está al lado, para el feed donde van.

Mi lista corta

1. Dos días libres antes del día de lanzamiento y una publicación manual.
2. Un campo Notes que un desconocido pueda seguir, con una cuenta de demostración que funcione.
3. Responde, no reenvíes, cuando solo te hacen una pregunta.
4. Cuenta las capturas, lee cada purpose string y deja los nombres de otras apps fuera de las palabras clave.
5. Un What's New que diga qué cambió.

Y cuando ya esté publicada, añadirla a MacPip es gratis, esté o no en el Mac App Store. Las fichas se analizan automáticamente al enviarlas, y un tic azul solo significa que una persona probó la app en una fecha.

Fuentes

• Apple Developer: Hello Developer, noviembre de 2026
• Apple Developer: App Review Help
• App Review Help: Seguir el estado de revisión de un envío
• App Review Help: Proporcionar información para una revisión completa
• App Review Help: Aceptar ofertas de Bug Fix Submission
• App Review Help: Solicitar una revisión urgente
• App Review Help: Apelar ante el App Review Board
• App Review Help: 2.3.3, Muestra tu app en uso con capturas de pantalla
• App Review Help: 4.1, Cómo evitar rechazos por imitación y suplantación
• App Review Help: 5.1.1(ii), Escribe purpose strings claros
• App Review Help: 5.1.1(v), Ofrecer la eliminación de cuenta en tu app
• App Review Help: Probar tu app en dispositivos compatibles
• Apple Developer: App Review Guidelines

Sigue leyendo

• Claude Fable 5.2 y Mythos 5.2: qué hay de nuevo, los benchmarks y qué significa para tu MacClaude Fable 5.2 y Mythos 5.2 salieron el 9 de noviembre de 2026. Los benchmarks de Anthropic en gráficos, los precios, qué cambia en un Mac y cuatro herramientas gratuitas.
• El Swift Student Challenge ya acepta apps para Mac. Esto es lo que yo crearíaEl Swift Student Challenge 2027 de Apple se abre del 8 de febrero al 28 y, por primera vez, acepta apps para cualquier plataforma de Apple, macOS incluido. Las reglas, las fechas y cómo planearía yo una participación para Mac.
• macOS 27.2.1 hace que curl deje de confiar en eMudhra. Esto es lo que revisaría en mi app de MacmacOS 27.2.1, 26.7.3 y 15.8.3 eliminan cinco certificados raíz de /etc/ssl/cert.pem tras el compromiso de claves de eMudhra. Qué cambió, a quién afecta y qué deberían probar los creadores de apps de Mac.
• Las Live Activities llegan a la barra de menús del Mac. Esto es lo que haría yo con mi app para MacLa beta de macOS 27.3 lleva las Live Activities a la barra de menús de los Mac con Apple silicon, y las apps para Mac pueden iniciar las suyas. Qué cambió, los límites y qué probar primero.
• La memoria está encareciendo los Mac. Esto es lo que haría yo con mi app de MacApple dice que la memoria seguirá escaseando y encareciendo los Mac hasta 2027, y el Mac más barato tiene 8 GB. Por qué importa para tu app de Mac y qué revisar esta semana.
• Apple ahora te deja hablar con quien cancela. Esto es lo que haría yo con mi app para MacDesde el 4 de noviembre, las suscripciones de la App Store pueden mostrar un mensaje u oferta cuando alguien cancela. Las reglas, lo que dice Apple que hace y qué revisar en el Mac.
• Apple añade dos preguntas a la clasificación por edad. Esto haría yo con mi app de MacDesde el 16 de noviembre, App Store Connect pregunta por ubicación compartida y funciones de citas, y todas las apps deben responder antes del 12 de enero de 2027. Qué cambió y qué hacer.
• Siri AI ya está abierto a todos los desarrolladores. Esto es lo que haría yo con mi app de MacApple abrió Siri AI a todos los desarrolladores en la beta de macOS 27.3. Qué cambió, qué puedes y qué no puedes publicar todavía, y un plan corto para una app pequeña de Mac.
• Los Mac con pantalla táctil salen el 6 de noviembre. Esto es lo que revisaría en mi app de MacLos primeros Mac táctiles de Apple llegan el 6 de noviembre. Qué cambió, qué les dice Apple a los desarrolladores que hagan y una lista corta de cosas para probar en tu propia app de Mac.
• Presentamos MacPipQué es MacPip, por qué lo creé, cómo funcionan las fichas y el día de lanzamiento, qué significa de verdad una marca azul y las cifras reales de sus primeros días.
• Cómo lanzar una app para Mac: una lista que cabe en una páginaQué hacer antes, durante y después del día de lanzamiento de una app para Mac: firma, tu página, directorios, Product Hunt, Show HN y qué medir.
• Cómo escribir una descripción de una línea que diga qué hace tu app para MacUna forma sencilla de escribir la línea bajo el nombre de tu app para Mac: di qué hace, quita la exageración y pruébala con alguien que nunca haya visto la app.
• Firma y notarización, con palabras sencillas, para quien hace su primera app para MacQué hace cada paso de la firma de código, la notarización y el stapling, en qué orden, qué ven tus usuarios sin ellos, y cómo revisar tu propia compilación.
• Cuánto vale de verdad un enlace dofollow, desde un sitio que ofrece unoQué significa dofollow, qué dice Google sobre los enlaces, por qué un enlace de un directorio nuevo vale poco hoy, y qué hacer en lugar de comprar enlaces.

Envía tu appHerramientas gratuitas para creadores