Guideline 5.6: el paywall que hace rechazar tu app

La guideline 5.6 es el código de conducta del desarrollador. En el caso de un paywall, Apple la cita con una frase tipo: la app “attempts to manipulate customers into making unwanted In-App Purchases”. Dicho claro: un botón de tu flujo de compra no hace lo que anuncia, o una oferta vuelve a aparecer sin que el usuario la haya pedido. La corrección cabe en una regla: cada botón hace lo que dice, y solo el usuario decide cuándo vuelve a ver una oferta.

Recibí este rechazo con TradaZen, mi app para practicar trading, cuyo lanzamiento cuento en este caso de estudio. Aquí tienes la regla, lo que encontré en mi paywall, los patrones que debes evitar y mi respuesta a Apple. Para la regla vecina sobre las solicitudes de calificación, mejor lee la guía de la guideline 5.6.3.

¿Qué dice la guideline 5.6?

La 5.6, “Developer Code of Conduct”, está en la sección 5 “Legal” de las App Review Guidelines. Su primer párrafo habla de respeto: hacia los clientes, en las respuestas a las reseñas y en los intercambios con Apple. El segundo apunta directamente a las compras.

El texto vigente plantea el principio: “Customer trust is a cornerstone of the App ecosystem.” Después enumera lo que una app nunca debe hacer: aprovecharse de los usuarios, estafarlos, “trick them into making unwanted purchases”, obligarlos a compartir datos innecesarios, “raise prices in a tricky manner”, cobrar por lo que no se entrega, o cualquier otra práctica manipuladora, dentro o fuera de la app.

En pocas palabras: no debes conseguir una compra con engaños. El texto no da una lista de botones prohibidos. Juzga el efecto: ¿el usuario pagó porque quería, o porque la pantalla lo atrapó?

La 5.6 también agrupa cuatro subreglas:

Subregla	A qué apunta
5.6.1 App Store Reviews	Reseñas y solicitud de calificación
5.6.2 Developer Identity	Información exacta sobre ti
5.6.3 Discovery Fraud	Fraude de visibilidad
5.6.4 App Quality	Quejas, reembolsos

La sanción está escrita en la regla: “Repeated manipulative or misleading behavior or other fraudulent conduct will lead to your removal from the Apple Developer Program.” Es decir, los comportamientos manipuladores repetidos llevan a la expulsión del programa de desarrolladores. Es una regla general, y una buena razón para corregir todo el flujo de compra desde el primer rechazo.

El mensaje de rechazo 5.6 por un paywall

El mensaje suele repetir la misma frase: “The app attempts to manipulate customers into making unwanted In-App Purchases.” Apple no siempre dice qué elemento señala. En mi rechazo no había nada más.

Otros desarrolladores describen la pantalla en cuestión. En un hilo del foro de Apple de noviembre de 2024, un desarrollador relaciona su rechazo 5.6 con una oferta única que aparecía cuando el usuario cerraba la primera pantalla de suscripción.

La 5.6 no apunta solo a los paywalls. A otro desarrollador también lo rechazaron por funciones que parecían ocultas durante la revisión. Si tu rechazo 5.6 no habla de compras, busca primero lo que el revisor no pudo ver.

Mi rechazo 5.6 con TradaZen

El 12 de octubre de 2026, Apple rechaza la versión 1.5.1 de TradaZen, probada en un iPad Air. Motivo: guideline 5.6, con la frase tipo sobre compras no deseadas. No se menciona ninguna pantalla.

Así que revisé todo mi flujo de compra como alguien que solo quiere decir que no. El paywall al final del onboarding no tiene forma de cerrarse: la app pide la prueba o la suscripción para continuar. Había tres mecanismos alrededor que podían pasar por manipulación:

• Una X falsa. Arriba en la pantalla, un botón con forma de X, anunciado como “Cerrar” en VoiceOver, abría una oferta con descuento en lugar de cerrar.
• Una oferta que volvía sola. Mientras la oferta seguía vigente, se reabría cuando el usuario volvía a la app.
• Un recordatorio promocional. Salir de la app desde el paywall programaba una notificación que anunciaba un descuento exclusivo.

Un detalle importa: estos mecanismos ya existían en la versión anterior, aceptada tres días antes. Una aprobación no valida tu paywall para siempre: otro revisor puede leer la misma pantalla de otra manera.

Lo que cambié

• La X desapareció de esa pantalla. En su lugar, un ícono de regalo, anunciado como “Descuento exclusivo” en VoiceOver, abre la oferta al tocarlo. Ya nada finge cerrar.
• La oferta ya nunca se abre sola al volver a la app.
• Se eliminó la notificación de descuento. Queda un recordatorio suave, enviado una sola vez por instalación y solo si las notificaciones están permitidas. No habla de precio, ni de descuento, ni de plazo.
• Ese recordatorio está descrito en el mensaje a App Review, con su texto y el momento de envío.

Lo que mantuve

También revisé lo que quedaba, preguntándome si cada elemento realmente dejaba elegir.

• Una oferta después de una compra cancelada. Si el usuario cancela la hoja de pago de Apple para la suscripción anual, se abre una oferta de bienvenida. Tiene una sola ventana de 5 minutos, que no se reinicia: si el usuario vuelve a cancelar dentro de ese plazo, se reabre. Se cierra con un gesto, con la X o con “No, gracias”, y muestra el precio real del producto.
• Un temporizador real de 5 minutos. Su vencimiento se guarda en el dispositivo la primera vez que se muestra. Sigue corriendo con la app cerrada y no vuelve a cero al reabrirla. Cuando termina, la oferta desaparece para esa instalación de la app. Si la cierras antes, una pequeña pastilla muestra el tiempo restante y solo reabre la oferta si la tocas.
• Un cofre con candado. Muestra los objetos ganados durante el onboarding, y solo esos, bloqueados mientras la app no esté desbloqueada. Nada anuncia que se vayan a perder.

Estos elementos aparecen en las notas de revisión. El rechazo no mencionaba ninguna pantalla, así que no los presento como validados por Apple. Son, a mi juicio, las versiones transparentes de esas mecánicas, y los declaré.

La corrección exigió un nuevo build, ya que todo ocurría dentro de la app. TradaZen volvió a revisión el 13 de octubre de 2026.

Los dark patterns de paywall que activan la 5.6

Apple no publica una lista. Una misma mecánica suele existir en dos versiones: la que atrapa y la que deja elegir. Esta tabla las separa, cruzando el texto de las reglas, rechazos publicados por otros desarrolladores y el mío. La versión transparente no garantiza la aprobación. Es la que no busca engañar. La última columna indica en qué se basa cada fila.

Versión manipuladora	Versión transparente	En qué se basa
Una X que abre una oferta en lugar de cerrar	La X cierra. Una pantalla que no se cierra no muestra una X	Corregido tras mi rechazo de TradaZen
Una oferta “única” que aparece al cerrar el paywall	Un descuento detrás de un botón que lo anuncia claramente	Rechazo publicado en el foro de Apple
Una segunda oferta lanzada tras un rechazo, en un paywall con precio engañoso	Una sola oferta tras una compra cancelada, al precio real, que se cierra con un gesto	Caso Cal AI; intercambio reportado por Superwall
Un paywall o una oferta que se reabre solo al volver a la app	Vuelve cuando el usuario llega a un límite o toca un botón que lo anuncia	Corregido tras mi rechazo de TradaZen
Una notificación promocional nunca solicitada	Promoción tras consentimiento explícito, con opción de darse de baja en la app	Regla 4.5.4
Un temporizador falso, que vuelve a cero o cuya oferta regresa al terminar	Un plazo real, que sigue con la app cerrada y termina de verdad	Mi lectura de “trick them”, regla 5.6
Recompensas inventadas, o amenazadas con desaparecer si no compras	Las ganancias reales del usuario, mostradas sin amenaza de perderlas	Mi lectura de la regla 5.6
Una prueba gratis que oculta el cobro automático	Duración de la prueba y precio que se cobra después, junto al botón	Página de suscripciones de Apple
Un precio semanal en grande y el monto cobrado en pequeño	El monto cobrado es el precio más visible de la pantalla	Página de suscripciones de Apple
Un botón de rechazo que hace sentir culpable	Un rechazo neutro, como “Ahora no” o “No, gracias”	Mi lectura de la regla 5.6

El caso Cal AI lo reporta TechCrunch: Apple citó la 5.6 por una segunda oferta de suscripción mostrada a quienes rechazaban la primera. Ese mismo paywall también fue señalado por la 3.1.2(c): el precio semanal dominaba sobre el monto cobrado, y la prueba ocultaba la renovación automática. El artículo no describe la segunda oferta con más detalle.

En cambio, Superwall, un proveedor de herramientas de paywall que vende este tipo de oferta, reporta un intercambio extraoficial con Apple en junio de 2026. Ahí, una oferta mostrada tras una compra cancelada se describe como permitida. La insistencia no lo está: una oferta que vuelve en cada sesión, o un recorrido del que solo se sale pagando. Superwall aclara que no son reglas oficiales y que el revisor conserva su criterio. Una oferta tras un rechazo sigue siendo, entonces, una zona de interpretación: el texto no la prohíbe, existen rechazos publicados, y la forma importa.

La regla sobre notificaciones es la 4.5.4: nada de promociones por notificación sin un consentimiento explícito obtenido en la app, ni sin una forma de darse de baja.

Sobre el precio, la página de Apple sobre suscripciones es clara: el monto cobrado debe ser el elemento de precio más visible. La razón cabe en una frase: “This ensures that people are not misled.” La regla 3.1.2 añade que Apple retira las apps que venden una suscripción de forma engañosa o con “bait-and-switch”.

La prueba que aplico ahora: ¿cada botón hace exactamente lo que promete su apariencia, y el usuario puede decir que no con un gesto, sin que la oferta vuelva por sí sola?

Los errores de paywall más clásicos, los que cuestan ventas sin necesariamente provocar un rechazo, están en paywall iOS: 7 errores de principiante.

Cómo corregir un rechazo 5.6

1. Haz una lista de todo tu flujo de compra. Paywall, ofertas secundarias, temporizadores, notificaciones, recordatorios al volver a la app. Apple no siempre dice qué señala. Para cada elemento, comprueba que esté en su versión transparente: se cierra con un gesto, temporizador real, precio exacto, sin regreso automático. Corrige o quita todo lo que parezca una trampa, no solo el elemento más probable.
2. Repite el recorrido del revisor. Borra la app, reinstálala, termina el onboarding y luego rechaza todo: cierra, cancela, sal de la app, vuelve. Anota cada pantalla que se abra sin que la hayas pedido, y comprueba que puedes cerrarla con un gesto.
3. Prepara un nuevo build. La causa está en la app, por lo tanto en el código incluido. Una actualización remota no reemplaza el build, como explico en la guía de la guideline 2.1.
4. No guardes nada en reserva. Reactivar una oferta de forma remota después de la aprobación equivale a ocultarle una función al revisor. La propia RevenueCat advierte contra ese reflejo en su artículo sobre las ofertas de salida.
5. Responde en App Store Connect, en inglés, respondiendo al mensaje de App Review.

Aquí tienes una plantilla basada en mi respuesta y mis notas de revisión, resumida. Reemplaza el número de build y los cambios por los tuyos, y luego enumera lo que queda:

Hello,

Thank you for your feedback on Guideline 5.6.

Issue: on the subscription screen, the button in the top
corner looked like a close button, but it opened a
discounted offer instead of closing the screen.

Changes in build X:
- Nothing on the subscription screen pretends to close it.
  A clearly labeled button now opens the optional offer.
- The offer never reopens by itself when the user comes
  back to the app.
- The notification announcing a discount has been removed.

Still in this build (also described in the review notes):
- [Each remaining offer: what triggers it, how often it
  appears, how the user dismisses it.]
- [Each remaining reminder: its text, when it is sent,
  and under which conditions.]

If another part of the purchase flow still looks unclear,
please tell me which screen, and I will change it.

Best regards,

Lo que escribas debe corresponder exactamente al build. Si mantienes un recordatorio o una oferta, aunque se active automáticamente, descríbelos en la respuesta y en las notas de revisión. Si crees que el revisor se equivocó, Apple permite apelar ante el App Review Board, con una sola apelación por envío rechazado. Para un paywall, corregir me parece más seguro que impugnar. Los demás motivos de rechazo y cómo responderlos están en por qué Apple rechaza una app.

La checklist anti-5.6 antes del envío

• Cada X cierra la pantalla. Una pantalla que no se cierra no muestra una X.
• Cada botón dice lo que hace, en pantalla y para VoiceOver.
• Ninguna oferta se esconde detrás de un botón de cierre.
• Una oferta activada por un rechazo, si mantienes una, cabe en una sola ventana que no se reinicia, al precio real, y se cierra con un gesto.
• Ningún paywall ni oferta se reabre solo al volver a la app.
• Ninguna notificación promocional sin consentimiento explícito en la app.
• Nada de temporizadores falsos: un plazo mostrado es real, no vuelve a cero y termina de verdad.
• Lo que la pantalla muestra como ganado se ganó de verdad, sin amenaza de perderlo.
• La prueba muestra su duración y el precio que se cobra después.
• El monto cobrado es el precio más visible de la pantalla.
• Las notas de revisión describen cada oferta y cada recordatorio presentes en el build.
• Repetiste el recorrido rechazando todo, en iPhone y en iPad.

Haz revisar tu paywall antes que Apple

El Review Kit reúne mi checklist previa al envío, mis rechazos corregidos y dos skills de Claude Code que revisan tu proyecto, tu paywall y tu ficha. Si Apple rechaza, preparan tu respuesta. Si quieres una mirada humana, reserva una hora conmigo: repasamos juntos tu flujo de compra, en tu pantalla. El proceso completo después de un rechazo está en la página app rechazada por Apple, y la parte técnica de las suscripciones en suscripciones in-app en iOS.

Si estás preparando tu primer lanzamiento, haz tu diagnóstico gratuito: ordena los pasos y te envía mi checklist antirrechazo de Apple. La página de inicio muestra cómo crear una app móvil con un paywall pensado para la revisión desde el principio.

Nadie puede garantizar que Apple aceptará tu app. Lo que sí puedo hacer es ayudarte a evitar un rechazo 5.6 que yo ya pagué con un ciclo de revisión.

Preguntas frecuentes

¿Qué significa “Guideline 5.6 - Developer Code of Conduct” en un rechazo?

Es el título de la regla sobre el código de conducta del desarrollador. En una app con compras integradas, casi siempre señala un flujo de compra considerado manipulador: un cierre falso, una oferta que vuelve sola, una prueba o un precio presentados de forma engañosa. El mensaje no siempre indica la pantalla en cuestión.

¿Apple prohíbe las ofertas de salida?

El texto no lo prohíbe de forma explícita. RevenueCat también lo señala, aunque advierte que a algunos desarrolladores los han rechazado por ese motivo. Los rechazos publicados apuntan a una oferta que aparece cuando el usuario cierra el paywall, o a una segunda oferta lanzada tras un rechazo. Lo que distingue la versión transparente: una oferta opcional, limitada a una sola ventana que no se reinicia, al precio real, que se cierra con un gesto, que no vuelve por sí sola, y con un temporizador real si lo hay. Descríbela en las notas de revisión. Nadie puede garantizar que un revisor la lea así.

¿Se permite un paywall sin X?

Las reglas no exigen una X, y es la opción que tomé en TradaZen después de este rechazo. Lo que Apple rechaza es un botón que parece de cierre y hace otra cosa. Aun así, un desarrollador reportó un rechazo 5.6 por un paywall sin salida en una app de descarga gratuita. Muestra el valor antes de pedir la prueba, y deja claro en tu ficha que la app es de pago.

¿Hace falta un nuevo build después de un rechazo 5.6?

Sí, en la mayoría de los casos, porque la causa es una pantalla o un comportamiento de la app. Si el problema está fuera de la app, en la ficha o en los metadatos, puede bastar una corrección sin build. Si tienes dudas, pregúntale al revisor qué pantalla señala.

¿Un rechazo 5.6 puede llevar al cierre de la cuenta de desarrollador?

La regla lo prevé en caso de comportamientos manipuladores repetidos, con expulsión del programa de desarrolladores. También prevé que una cuenta cerrada pueda restablecerse tras un plan de mejora por escrito, aprobado y luego verificado por Apple. Por eso conviene corregir todo el flujo desde el primer rechazo.

¿Qué diferencia hay entre la 5.6 y la 5.6.3?

La 5.6 es el código de conducta general: respeto, confianza, ninguna compra conseguida con engaños. La 5.6.3 es una de sus subreglas, sobre la manipulación de rankings, búsquedas y reseñas. Apple la citó con Solys por una solicitud de calificación colocada en el onboarding.