Apple rechazó mi app dos veces: qué aprendí del App Store Review

Construí Stikr, una app gratis para coleccionistas, y la mandé a revisión confiado. Apple la rechazó. Dos veces. Y la lección que me llevé no tiene nada que ver con el código.

Te cuento qué pasó, porque si estás por publicar tu primera app, esto te puede ahorrar dos semanas.

El primer rechazo

Subí la app con todo listo: funcionaba, sincronizaba con iCloud, todo on-device, sin servidor. Tenía cero dudas de que pasaba.

Rechazo. Guideline 5.2.1 – Intellectual Property. El mensaje decía, en resumen, que la app incluía contenido que se parecía a una marca de terceros sin autorización.

El detalle: el problema no era la app. Era una palabra en la metadata. Una referencia que, sin querer, sonaba a una marca registrada. Apple no revisa solo tu binario: revisa el nombre, el subtítulo, la descripción, las capturas, la política de privacidad y los términos.

La quité de los 14 lugares donde aparecía —nombre, descripción, política de privacidad, hasta los términos de servicio— y reenvié.

El segundo rechazo

Mismo motivo. 5.2.1 otra vez.

Se me había escapado otra palabra, en otro campo, que arrastraba el mismo problema. El reviewer fue meticuloso. Donde yo veía una referencia inofensiva, Apple veía un riesgo legal de terceros.

Volví a barrer todo: metadata, textos dentro de la app, descripción, screenshots. Esta vez con una lista. Y a la tercera, pasó.

La lección: el 80% de los rechazos no son técnicos

Cuando uno empieza, asume que el App Store Review es sobre bugs y crashes. La realidad es otra: la mayoría de los rechazos son de metadata, copy, legal o privacidad, no de código.

Tiene sentido. Tu código probablemente funciona —lo probaste mil veces—. Lo que no revisaste con la misma obsesión es cómo describes la app, qué marcas mencionas, qué permisos pides y cómo los justificas. Ahí es donde Apple frena.

Desde entonces reviso eso antes de subir, no después.

El checklist que uso ahora (antes de cada submission)

• Marcas de terceros: ningún nombre de marca registrada en el nombre, subtítulo, keywords, descripción, screenshots ni dentro de la app. Si tienes que referenciar algo, usa lenguaje nominativo y un disclaimer claro.
• Permisos justificados: cada permiso (cámara, ubicación, etc.) con un usage description claro en el Info.plist, explicando para qué se usa de verdad.
• Privacy labels honestas: que coincidan exactamente con lo que la app hace. Si no recolectas datos, decláralo y que sea cierto.
• Notas para el reviewer: explica en App Review Information qué es la app, qué hace cada permiso y, si hay algo que pueda malinterpretarse, acláralo de entrada.
• Funcionalidad mínima: que la app aporte valor real y no parezca una web envuelta. La 4.2 (Minimum Functionality) también muerde.
• Probar en dispositivo real: sobre todo lo que no corre en simulador (cámara, push, compras).

Por qué cuento esto

Construyo en público. Las apps que publico no son solo producto: son la prueba de que también shippeo cosas terminadas al usuario final, no solo proyectos internos de cliente. Y parte de construir en público es contar los rechazos, no solo los lanzamientos.

Si estás haciendo tu primera app y este post te ahorró un rechazo, ya valió la pena escribirlo. Stikr ya está en la App Store, gratis. Y sí: a la tercera, pasó.