Devoria
Guideline 3.1.1: cuándo es obligatoria la compra in-app
Por Mehdi Azizi
Publicado el , 9 min
Guideline 3.1.1: todo contenido o función digital que se desbloquea en la app pasa por la compra in-app de Apple. Excepciones, reglas UE y EE. UU., soluciones.
La guideline 3.1.1 exige la compra in-app de Apple en cuanto tu app desbloquea contenido o una función digital: suscripción, versión completa, moneda de juego, contenido premium. Un rechazo 3.1.1 significa que Apple encontró otra puerta de entrada a ese contenido: pago en tu sitio web, clave de licencia, código propio, botón hacia una página de pago. La solución pasa por la compra in-app, salvo que tu caso entre en una excepción o en una regla regional.
Publico mis propias apps iOS, y las que tienen suscripción la venden mediante la compra in-app de Apple. Nunca me han rechazado por la 3.1.1, y no te voy a contar lo contrario. Esta guía se basa en el texto oficial, en su versión del 8 de junio de 2026 leída el 15 de octubre de 2026, y en las condiciones regionales publicadas por Apple. El caso vecino de las suscripciones, con dos rechazos reales, está en la guía sobre la guideline 3.1.2.
¿Qué dice la guideline 3.1.1?
La 3.1.1, "In-App Purchase", abre la sección 3.1 "Payments" de las App Review Guidelines. De ahí el asunto del correo: "Guideline 3.1.1 - Business - Payments - In-App Purchase". Su primera frase dice lo esencial: para desbloquear funciones en tu app, "you must use in-app purchase", tienes que usar la compra in-app. Apple menciona las suscripciones, las monedas de juego, los niveles, el contenido premium y la versión completa.
La frase siguiente apunta a los atajos. Una app no puede usar su propio mecanismo para desbloquear contenido: Apple nombra las claves de licencia, los marcadores de realidad aumentada, los códigos QR, las criptomonedas y las billeteras cripto.
La misma regla añade obligaciones que a menudo se olvidan:
- los créditos y monedas comprados con compra in-app no caducan, y toda compra restaurable tiene un mecanismo de restauración;
- un cofre o sorteo de pago ("loot box") muestra las probabilidades de obtener cada tipo de objeto antes de la compra;
- una tarjeta de regalo, un vale o un cupón digital se vende en la app mediante compra in-app; una tarjeta física enviada por correo puede usar otro medio;
- una app sin suscripción puede ofrecer una prueba limitada en el tiempo, en forma de compra in-app gratuita llamada "XX-day Trial", que indica antes de empezar su duración, lo que se perderá y lo que habrá que pagar;
- las propinas al desarrollador están permitidas, mediante compra in-app.
Las situaciones que provocan un rechazo 3.1.1
| Lo que hace la app | Por qué Apple rechaza | La solución |
|---|---|---|
| Desbloquea un contenido comprado en tu sitio | No hay compra in-app equivalente | Venderlo también por compra in-app |
| Muestra "Paga en nuestro sitio" | Redirige a otro pago | Quitar el botón, salvo excepción |
| Pide una clave de licencia o un código propio | Mecanismo de desbloqueo prohibido | Códigos de oferta de Apple |
| Desbloquea a cambio de una criptomoneda | Mecanismo de desbloqueo prohibido | Compra in-app |
| Vende créditos que caducan | Obligación de la 3.1.1 | Créditos permanentes y restauración |
| Vende un cofre sin probabilidades | Probabilidades no mostradas | Probabilidades visibles antes de comprar |
La primera fila es la peor entendida. En un rechazo publicado en los foros de Apple, el mensaje dice que la app "accesses digital content purchased outside the app", accede a un contenido comprado en otro lugar, "but that content isn't available to purchase using in-app purchase". Apple no te reprocha tener un sitio que vende: te reprocha que la app no ofrezca la misma compra a través de Apple.
Para ofrecer acceso gratuito o un descuento, Apple tiene su propio sistema, los códigos de oferta. Según la documentación de StoreKit, funcionan para todos los tipos de compras in-app: suscripciones, consumibles y no consumibles. Los creas en App Store Connect, y el usuario los introduce en el App Store o en tu app.
Las excepciones: cuándo no se exige la compra in-app
La regla 3.1.3 enumera las apps que pueden usar otro medio de pago. Esta es la tabla que uso para saber dónde encaja un proyecto.
| Tu caso | ¿Se exige compra in-app? | Regla |
|---|---|---|
| Suscripción, versión completa, contenido digital | Sí | 3.1.1 |
| Producto físico, servicio consumido fuera de la app | No, otro medio obligatorio | 3.1.3(e) |
| Clase o consulta en vivo, entre dos personas | No | 3.1.3(d) |
| Clase en vivo con varias personas | Sí | 3.1.3(d) |
| Prensa, libros, música, video comprados en otro lado | No para acceder | 3.1.3(a) |
| Servicio multiplataforma comprado en tu sitio | Acceso permitido si también hay compra in-app | 3.1.3(b) |
| Herramienta vendida a una empresa para sus empleados | No | 3.1.3(c) |
| App gratuita complementaria de una herramienta web, sin compras | No | 3.1.3(f) |
Dos límites. Una app que se acoge a una excepción no puede, dentro de la app, empujar hacia otro medio de pago, salvo en la tienda de EE. UU. y en los casos previstos por Apple. En cambio, Apple aclara que "Developers can send communications outside of the app": puedes escribir a tus usuarios fuera de la app, por correo electrónico por ejemplo.
Las reglas por región en octubre de 2026
Aquí los textos cambian rápido. Lo que sigue retoma los de Apple leídos el 15 de octubre de 2026: vuelve a leerlos antes de programar un pago externo.
| Región | Lo que se permite además de la compra in-app |
|---|---|
| Estados Unidos | Botones y enlaces hacia otro pago, sin entitlement |
| Unión Europea | Pago alternativo en la app y ofertas fuera de la app, reguladas |
| Japón, Brasil, Corea del Sur | Programas propios, solicitando un entitlement |
| Otros países | Ningún botón, enlace ni llamado hacia otro pago |
Estados Unidos
La regla 3.1.1(a) aclara que los entitlements "are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps". En la tienda de EE. UU., entonces, se permite un botón hacia tu sitio. Tu binario es el mismo en todas partes: si añades ese botón, la app debe saber en qué tienda está el usuario. StoreKit lo indica con Storefront.
Unión Europea
Desde el 1 de octubre de 2026 se aplican nuevas condiciones, según la página de Apple sobre las opciones de pago en la UE. Puedes quedarte solo con la compra in-app, sin cambiar nada. También puedes ofrecer un proveedor de pagos dentro de la app, u ofertas fuera de la app, hacia tu sitio por ejemplo. En ese caso Apple exige, entre otras cosas:
- el entitlement "StoreKit External Purchases or Offers" y, para un enlace o un pago dentro de la app, la ventana informativa del sistema;
- la compra in-app al menos igual de visible que la otra opción, cuando ambas están en pantalla;
- ninguna mención de estos pagos en tu ficha del App Store;
- control parental para menores, y ninguna oferta fuera de la app antes de los 13 años, o más según el país;
- la misma elección en todas las tiendas de la UE durante 12 meses.
Se aplican comisiones según la opción elegida. Lee su sección en la misma página antes de decidir.
Los demás países
En el resto, la regla sigue siendo estricta: "apps and their metadata may not include buttons, external links, or other calls to action" hacia otro medio de pago. La palabra "metadata" importa: una descripción que anuncia "más barato en nuestro sitio" también cae bajo la regla. Algunos países, entre ellos Japón, Brasil y Corea del Sur, tienen sus propios programas, listados en la documentación de External Purchase.
Corregir un rechazo 3.1.1 y responder a Apple
- Encuentra la puerta de entrada. El mensaje cita el contenido o la pantalla en cuestión: contenido comprado en otro lado, botón, código, enlace.
- Ciérrala o duplícala. O quitas el botón o el código, o vendes el mismo contenido mediante compra in-app.
- Invoca una excepción solo si es real. Cita el inciso de la 3.1.3 y explica en dos frases por qué tu caso entra ahí.
- Dale al revisor con qué probar. Una cuenta demo y el camino hasta el paywall, en las notas de revisión, como explico en la guía sobre la guideline 2.1.
Respondes en la sección App Review de App Store Connect, siguiendo el procedimiento para responder a App Review. Aquí tienes un modelo para el caso más común, un contenido comprado en el sitio. Es un ejemplo: reemplaza el build, el producto y el recorrido por los tuyos.
Hello,
Thank you for your review.
Issue: the app gave access to premium content purchased on our
website, without offering the same purchase in the app.
Fix in build X:
- Premium access is now available as an auto-renewable
subscription through in-app purchase, on the paywall.
- The "Subscribe on our website" button has been removed.
- A "Restore Purchases" button is available on the paywall.
How to verify: launch the app and open any premium screen.
The paywall shows the in-app purchase options.
Best regards,
El botón y el paywall están en el código: necesitas un build nuevo. Si sigues convencido de que tu caso es una excepción, Apple también permite apelar ante el App Review Board.
Conectar la compra in-app sin reescribirlo todo
Para un principiante, el camino más sencillo es crear los productos en App Store Connect y luego conectarlos a la app con RevenueCat: la receta está en RevenueCat: configurar una suscripción in-app. Si dudas entre los dos modelos, lee suscripción o compra única. Si construyes con una herramienta sin código, comprueba que sepa manejar la compra in-app: es uno de los puntos de crear una aplicación sin programar.
En cuanto tu compra in-app es una suscripción, se suma la 3.1.2: monto cobrado destacado, duración, renovación, enlaces. Los errores de pantalla más frecuentes están en paywall iOS: 7 errores de principiante.
La checklist 3.1.1 antes de enviar
- Todo lo que se desbloquea en la app (función, contenido, nivel, moneda) se compra mediante compra in-app.
- Ningún botón, enlace ni texto redirige a un pago externo, salvo en la tienda de EE. UU. o con un programa regional obtenido.
- La descripción de tu ficha no menciona ningún otro medio de pago.
- Un contenido vendido en tu sitio también está a la venta por compra in-app en la app.
- Ninguna clave de licencia, código QR, código propio ni cripto desbloquea nada.
- Para ofrecer acceso, usas los códigos de oferta de Apple.
- Los créditos comprados no caducan, y un botón "Restaurar compras" funciona.
- Cada cofre o sorteo de pago muestra sus probabilidades antes de la compra.
- Un producto físico o un servicio fuera de la app se paga con Apple Pay o tarjeta, no con compra in-app.
- Tus notas de revisión indican dónde encontrar las compras y, si invocas una excepción, cuál.
Revisar tu app antes de enviarla
Si tu app acaba de ser rechazada por la 3.1.1, el Apple Review Kit te ayuda a encontrar la regla citada, lo que exige, y un ejemplo de corrección y de respuesta. Sus notas para el revisor cubren la compra in-app. Si quieres una mirada humana, reserva una hora conmigo: leemos el mensaje de Apple y buscamos la puerta de entrada que vio. El proceso completo está en la página aplicación rechazada por Apple, y la configuración de la compra en la página suscripción in-app iOS.
Si estás preparando tu primer lanzamiento, haz tu diagnóstico gratuito: pone los pasos en orden y te envía mi checklist antirrechazo de Apple. Para crear una aplicación móvil que venda con compra in-app desde el principio, el iOS Kit parte de un código donde el paywall y las suscripciones ya están listos.
Nadie puede garantizar que Apple acepte tu app. Lo que sí puedo hacer es ayudarte a elegir el medio de pago correcto antes de escribir el código.
Preguntas frecuentes
¿Qué significa "Guideline 3.1.1 - Business - Payments - In-App Purchase"?
Es el título completo de la regla sobre la compra in-app en el mensaje de Apple. Indica que tu app da acceso a un contenido o a una función digital por otro camino que no es la compra in-app: pago en un sitio, código, clave de licencia o enlace a una página de pago.
¿Se puede poner un enlace a tu sitio para pagar menos?
En la tienda de Estados Unidos, sí: la regla permite botones y enlaces sin entitlement. En la Unión Europea, es posible con el entitlement de Apple y sus condiciones. En el resto, salvo programa regional, ni la app ni su ficha pueden redirigir a otro medio de pago.
¿Se puede desbloquear la app con un código promocional?
No con un código propio: la 3.1.1 prohíbe los mecanismos de desbloqueo propios de la app, como las claves de licencia. Usa los códigos de oferta de Apple, creados en App Store Connect. Funcionan para las suscripciones y para los demás tipos de compras in-app.
¿Hace falta la compra in-app para vender un producto físico o un servicio?
No. Un producto físico o un servicio consumido fuera de la app, como una comida a domicilio o un viaje en auto, debe pagarse con otro medio, Apple Pay o tarjeta bancaria. Una clase en vivo entre dos personas también puede prescindir de ella, pero no una clase en vivo con varias personas.
¿Un cliente suscrito en mi sitio puede iniciar sesión en la app?
Sí para un servicio multiplataforma, siempre que el mismo acceso también esté a la venta por compra in-app en la app. Es la regla 3.1.3(b). Sin esa oferta en la app, vuelves al rechazo 3.1.1 típico: un contenido comprado en otro lado e imposible de comprar a través de Apple.
¿Basta RevenueCat para cumplir la 3.1.1?
RevenueCat se apoya en la compra in-app de Apple, así que no genera problemas con la 3.1.1. Pero no elimina un botón de pago externo ni un código propio que tu app pudiera tener. El cumplimiento hay que revisarlo pantalla por pantalla, y también en tu ficha.
