Publicación en la App Store: todas tus preguntas respondidas en nuestro AMA de Reddit

Las capturas de pantalla cumplen dos funciones a la vez: convencen a alguien de descargar tu app y ayudan a Apple a entender qué hace durante la revisión. Destaca tus funciones principales y el valor que aportan, en lugar de mostrar pantallas al azar: si algo hace diferente a tu app (un flujo único, una función de comunidad, un caso de uso concreto), asegúrate de que se vea.

Un detalle con el que mucha más gente de la que crees tropieza: tus capturas de pantalla tienen que coincidir con la versión de la app que estás enviando de verdad. Es sorprendentemente habitual rediseñar parte de una app, enviar un nuevo build y olvidarse de actualizar las capturas de la App Store; y un desajuste importante entre lo que se muestra y lo que se está revisando puede levantar dudas durante la App Review. Apple también ofrece marcos de producto oficiales para presentar tus capturas de forma limpia y coherente, vale la pena usarlos si aún no lo haces. Un último apunte de nuestros ingenieros iOS: las capturas que muestran el producto o servicio de un competidor ya han causado problemas en la revisión, así que es mejor evitarlas por completo.

Solo necesitas un número D-U-N-S si quieres inscribirte en el Apple Developer Program como Organización. Si publicas como individuo, no lo necesitas en absoluto.

Para conseguir una cuenta de Organización, primero tienes que registrar tu entidad en Dun & Bradstreet (o en un socio local): obtener el número D-U-N-S suele tardar unas dos semanas, y Apple puede pedir información adicional durante la inscripción. A cambio, una cuenta de Organización aporta ventajas reales: tu organización aparece como desarrollador en la App Store en lugar de tu nombre personal, encaja mejor en empresas y equipos (sobre todo si la propiedad cambia con el tiempo), facilita demostrar la propiedad de tu marca y tu contenido durante la revisión, y en algunos países puede darte derecho a una exención de la cuota del Apple Developer Program. Si eres un desarrollador independiente que publica sus propias apps, en cambio, una cuenta Individual es perfectamente válida y te libra por completo del requisito del D-U-N-S.

Una fuente de confusión habitual: los crípticos errores de Transporter al subir un build. Los tres más comunes, explicados:

• "No suitable application records were found" → lo más probable es que el registro de la app todavía no exista en App Store Connect.
• "Potential loss of keychain" → normalmente solo es un aviso, que aparece cuando la app se transfirió entre cuentas de desarrollador de Apple.
• "Redundant binary upload" → probablemente estás subiendo un build con el mismo número de versión o de build que uno que ya está ahí.

Una de las preguntas que más nos hacen. Por lo que vemos ayudando a nuestros clientes a publicar, la mayoría de las revisiones se completan en 24 a 48 horas, aunque puede tardar más según la app y la carga de trabajo de Apple.

Si tienes una fecha límite (un evento de lanzamiento, una fecha de salida), envía tu app cuanto antes en lugar de esperar hasta el último momento. Así, si Apple pide cambios antes de aprobarla, todavía tendrás tiempo de resolverlos. Y si tu calendario se aprieta de verdad, Apple ofrece una solicitud de revisión acelerada para situaciones urgentes. No está garantizada, pero merece la pena intentarlo siempre que tengas una fecha fija que cumplir.

El mejor momento para dejar la beta no es cuando tu app es perfecta, sino cuando está lista para usuarios reales. En la práctica: la experiencia principal es sólida, la app ya tiene contenido con sentido, y tus usuarios beta siguen volviendo porque de verdad les resuelve un problema.

La segunda parte importa igual de mucho: no publiques sin un plan de lanzamiento. Un error frecuente es volcar toda tu energía en conseguir la aprobación, para darte cuenta después de que nadie sabe que la app existe. Tener un público objetivo claro y una respuesta clara a "por qué alguien elegiría esta app en lugar de otra" influye mucho más en la tracción que publicar unos días antes. Y esa respuesta no solo ayuda a tu marketing: también suele encajar con lo que busca Apple durante la App Review. Las apps que aportan algo realmente útil o diferente suelen tener un camino más fácil que las que parecen una variación más de algo que ya existe.

Las dos plataformas pueden complicarse, cada una a su manera. Por lo que vemos, las primeras publicaciones se rechazan más a menudo en el lado de Apple que en Google Play, pero eso no significa que Google Play sea más fácil. Tiene sus propias limitaciones, que pueden generar tanta fricción como las de Apple según el tipo de cuenta de desarrollador y la configuración de la app. En las actualizaciones, la tasa de rechazo suele ser mucho más parecida entre ambas.

Un usuario veterano de GoodBarber resumió muy bien este equilibrio en el hilo: publicar en Apple es todo un proceso, y siempre hay algún motivo por el que una app acaba marcada, pero contar con la documentación y el soporte de GoodBarber para resolverlo quita la mayor parte del estrés, y garantiza que la app se mantenga conforme con las políticas de las tiendas con el tiempo. También señaló que Google Play, antes la plataforma más sencilla, también se ha vuelto más estricto: ahora las apps necesitan actualizaciones regulares, o la cuenta de desarrollador corre el riesgo de acabar marcada. Un soporte fiable en ambos frentes, según él, no tiene precio.

Hay mucho que contar sobre Google Play en concreto, tanto que estamos preparando un AMA dedicado a ese tema en lugar de mezclarlo todo aquí.

Todo lo anterior es justo lo que nuestro equipo de soporte gestiona día tras día, y por eso este servicio existe como una oferta propia: GoodBarber Takes Care (GBTC). En vez de lidiar tú mismo con la App Review, el equipo de GBTC envía la app a la App Store y a Google Play en tu nombre, de principio a fin. Apple rechaza en torno al 42 % de las primeras publicaciones de media, muchas veces por motivos difíciles de anticipar, pero en los últimos 12 meses el equipo de GBTC ha conseguido que se acepte finalmente el 91 % de esas primeras publicaciones rechazadas. En las actualizaciones, el trabajo de prevención reduce la tasa de rechazo a solo un 5 %. Si prefieres dejar la App Review en manos de un equipo que lidia con ella a diario, para eso está GBTC exactamente.

Hasta aquí el resumen, pero el hilo original sigue mereciendo una lectura para el detalle completo de cada respuesta, y sigue abierto: si tienes una pregunta que no hemos cubierto, todavía puedes publicarla ahí: AMA de publicación en la App Store en r/GoodBarber.

Este fue nuestro segundo AMA en directo. Cuéntanos en los comentarios qué tema te gustaría que tratáramos la próxima vez.