¿Por qué Apple rechaza una app? Mis rechazos reales y cómo los resolví

Apple rechaza una app cuando no cumple sus pautas de revisión: que se cierre o tenga errores visibles, que falte información de privacidad, que pida permisos que el revisor no puede verificar, o que la considere demasiado parecida a otra app (la guideline 4.3, "spam"). Casi todos los rechazos se pueden evitar preparando la app con esas reglas en mente desde el principio.

Te lo cuento con mis propios casos. Publicando mis juegos en la App Store, Apple me rechazó tres veces por motivos distintos, y también me aprobó una app a la primera. Acá va qué decía cada rechazo, cómo lo resolví y el checklist que uso desde entonces. Si lo que buscás son los costos y requisitos básicos de cada tienda, están en cuánto cuesta publicar una app en Google Play y App Store.

¿Qué es la guideline 4.3 y por qué es tan común?

La guideline 4.3 de la App Store apunta contra el "spam": Apple no quiere la tienda llena de apps casi idénticas. El problema es que cualquier desarrollador que reutiliza código entre apps (que es lo razonable para no pagar todo dos veces) queda expuesto a que el revisor vea dos apps parecidas y las trate como copias.

No alcanza con que la app sea distinta por dentro: tiene que verse distinta y no arrastrar rastros de la otra. Dos de mis tres rechazos fueron por esta regla, y por motivos bastante diferentes.

Rechazo 1: "demasiado parecida" (Color Sudoku Play)

Color Sudoku Play es un Sudoku en el que los números del 1 al 9 se reemplazan por 9 colores. Para mí era un producto distinto; para Apple, era demasiado similar a Sudoku Play, mi app anterior. Cambiar números por colores no fue diferenciación suficiente.

La solución fue un rediseño completo con un sistema visual propio: glassmorphism, con gradientes en capas, superficies translúcidas, círculos flotantes con desenfoque y una paleta cyan y coral que no tiene nada que ver con Sudoku Play. La app fue aprobada, y ese rediseño terminó siendo su identidad. Hoy está publicada en App Store y en Google Play.

Rechazo 2: "spam" por IDs copiados (Block Drop Merge)

Block Drop Merge mezcla Tetris con 2048 y reutiliza mucho código de Block Drop Play. Su versión 1.0.1 fue rechazada por la 4.3(a), y cuando revisé a fondo entendí por qué: los identificadores de anuncios de AdMob eran los de Block Drop Play, había quedado activado el modo de anuncios de prueba en producción, algunas claves de almacenamiento y los códigos de los productos de compra eran de otra app, y el ícono era genérico.

Hice una auditoría completa del código buscando cada resto de la otra app, corregí todos los identificadores, rediseñé el ícono (bloques numerados en forma de L), hice capturas nuevas y respondí formalmente a Apple. La versión 1.0.2 quedó enviada a revisión, y de ese rechazo salió un protocolo de auditoría que ahora uso antes de cada lanzamiento derivado.

Rechazo 3: "no encontramos el permiso" (Color Match Drop)

En Color Match Drop, Apple no encontraba el diálogo de App Tracking Transparency, el que pregunta si permitís que la app te rastree para publicidad. El diálogo estaba bien implementado. El problema era otro: el iPad del revisor tenía desactivada, a nivel de sistema, la opción "Permitir que las apps soliciten rastreo". Con esa opción apagada, iOS nunca muestra el diálogo, a ninguna app.

Lo resolví sin cambiar código ni subir un build nuevo: respondí a Apple explicando el escenario. La lección es que no todo rechazo es un error tuyo, y que una respuesta clara y técnica también es una herramienta. Dejé el procedimiento documentado para las próximas apps.

¿Y la que aprobaron a la primera?

Block Puzzle Play fue aprobada por Apple en la primera revisión. No fue suerte: la preparé de forma sistemática. Declaré cada dato que la app recopila, revisé que los identificadores del paquete fueran los correctos, publiqué el app-ads.txt para la publicidad, completé la clasificación por edad y dejé en regla todo lo que tocaba privacidad: anuncios, reportes de errores e inicio de sesión con Google y Apple. En otras apps sumé también política de privacidad, términos y la opción de eliminar la cuenta desde la app.

¿Qué reviso antes de enviar una app a Apple?

• Que no quede nada de otra app: identificadores de anuncios, códigos de productos de compra, claves de almacenamiento, nombres e íconos.
• Que los anuncios de prueba estén apagados en el build de producción.
• Que la app se vea distinta desde la primera captura, si comparte base con otra.
• Privacidad completa: qué datos se recopilan y para qué, política de privacidad accesible y opción de borrar la cuenta.
• Permisos explicados: cada permiso que pide la app tiene que tener un motivo claro, y el de rastreo tiene que aparecer antes de mostrar publicidad personalizada.
• Plugins nativos declarados: en Sudoku Play, la librería de compras no estaba en la configuración y el build de iPhone salió sin el permiso de suscripciones.
• Ficha completa: ícono propio, capturas actuales, descripción que coincida con lo que hace la app y clasificación por edad.

¿Qué aprendí de Google Play?

En Android, los dolores de cabeza que me tocaron fueron técnicos. En celulares Samsung, la tarea de sincronizar en segundo plano hacía que la app se cerrara antes de arrancar, así que pasé a sincronizar cuando el usuario vuelve a abrirla. En Huawei y en emuladores sin los servicios de Google, la app se caía: agregué una detección de esos servicios antes de usarlos. Y en Samsung, una grilla de notas del Sudoku se dibujaba mal porque el sistema acomodaba los elementos distinto; la reemplacé por una estructura fija de 3×3.

La lección: probá en celulares reales de varias marcas antes de publicar. El emulador no te muestra lo que le pasa a tu usuario.

¿Todo arreglo tiene que pasar por revisión?

No. Con Expo, las correcciones del código JavaScript se pueden enviar directo a los usuarios con actualizaciones OTA (por el aire), sin pasar por la tienda. Eso sí: en Block Drop Merge mandé actualizaciones a un canal de pruebas y nunca llegaban a los usuarios, porque los builds de producción escuchan el canal de producción. Una vez alineados, los arreglos urgentes salen en minutos. Lo que cambia la parte nativa, como agregar un permiso o una librería, sí necesita un build nuevo y otra revisión.

La historia completa de cómo publiqué las primeras apps está en cómo publiqué 6 apps como desarrollador independiente, y por qué reutilizar código obliga a cuidar estos detalles, en cómo reutilizar código entre apps.

Preguntas frecuentes