En la Unión Europea puedes llevar a tus usuarios de iOS a pagar la suscripción fuera de la compra integrada, dentro de la propia app, con un enlace accionable. No es una zona gris: hay un entitlement, un addendum que firma tu Account Holder, una API de StoreKit para la hoja de divulgación y una obligación de reportar cada transacción a Apple para que te facture su parte.

Esa última frase es la que decide si el proyecto compensa. Apple sigue cobrando. Lo que cambia es cuánto, y todo lo que pasa a ser tuyo: la pasarela, el fraude, los reembolsos, los impuestos, el soporte y un informe mensual.

Esto es cómo se hace, de arriba abajo.

Lo primero: elegir addendum

Hay dos entitlements y son mutuamente excluyentes. Los dos los tiene que aceptar el Account Holder de la cuenta:

External Purchase Link Entitlement, bajo el Alternative Terms Addendum for Apps in the EU.
StoreKit External Purchase Link Entitlement (EU) Addendum.

La diferencia práctica está en la estructura de tarifas —el primero arrastra la tarifa de tecnología por instalación, el segundo una comisión sobre ventas—, así que la elección se hace con los números delante, no por preferencia técnica.

Lo que te va a cobrar Apple

Aquí es donde la mayoría de las estimaciones se rompen, porque no es una comisión: son tres capas que se suman.

Bajo el StoreKit External Purchase Link Entitlement (EU) Addendum:

Concepto	Nivel 1 (obligatorio)	Nivel 2 (opcional)	Tarifa de programa*
Tarifa de adquisición inicial	2 %	2 %	0 %
Tarifa de servicios de tienda	5 %	13 %	5 % / 10 %
Comisión de tecnología básica (CTC)	5 %	5 %	5 %

Bajo el Alternative Terms Addendum, mismas dos primeras capas y, en lugar de la CTC, la tarifa de tecnología básica (CTF): 0,50 € por primera instalación anual, para apps que superen el millón de primeras instalaciones al año.

* La tarifa de programa aplica a participantes del programa de pequeñas empresas y a suscripciones a partir de su primer año.

Sobre qué se aplica cada una:

Adquisición inicial: compras dentro de los 6 meses siguientes a la primera instalación del cliente.
Servicios de tienda y CTC: todas las ventas dentro de los 12 meses desde la instalación, actualización o reinstalación más reciente.
Incluyen ajustes por reembolsos, reversiones y cargos revertidos.

Sobre qué NO se aplican, y esto sí es dinero:

Renovaciones automáticas de suscripciones contratadas antes de que la app incluyera el entitlement.
Transacciones hechas fuera de la app sin enlace accionable.
Ventas que usan la compra integrada.

Haz la cuenta con tu propio caso antes de seguir leyendo: en Nivel 1 con tarifa estándar hablamos de 12 % durante los primeros seis meses del cliente y 10 % después, más tu pasarela, más el trabajo operativo. Comparado con el 30 % o el 15 % de la compra integrada, hay margen — pero no es gratis y hay un suelo de complejidad que no baja.

La regla que decide la arquitectura

«Debido a la estrecha integración de la App Store con la compra integrada, y para reducir la confusión de los usuarios, no podrás ofrecer compra integrada mientras comunicas y promocionas ofertas dentro de la misma app en la misma tienda y plataforma de la App Store.»

Una cosa o la otra por tienda. Puedes decidir app por app y tienda por tienda, pero no mezclar en la misma. Eso significa que tu app tiene que soportar dos modos de monetización según el país de la tienda del usuario, y que la elección no es un ajuste: es una rama de producto.

Implementación, paso a paso

1 · Entitlement y perfil de aprovisionamiento

Una vez aceptado el addendum, la cuenta recibe el entitlement. Se activa en Xcode desde la biblioteca de capacidades o en el portal de desarrollador:

com.apple.developer.storekit.external-purchase-link  →  Boolean  →  true

Al añadir la capacidad al App ID, hay que regenerar el perfil de aprovisionamiento. Es el paso que más veces rompe la primera compilación de CI: el perfil cacheado no tiene la capacidad y la firma falla sin decir por qué.

2 · Info.plist: las regiones

<key>SKExternalPurchaseCustomLinkRegions</key>
<array>
  <string>es</string>
  <string>fr</string>
  <string>de</string>
  <!-- … -->
</array>

Los códigos válidos son los 27: at, be, bg, hr, cy, cz, dk, ee, fi, fr, de, gr, hu, ie, it, lv, lt, lu, mt, nl, pl, pt, ro, sk, si, es, se.

Versiones mínimas: iOS y iPadOS 17.4, macOS 14.4, tvOS 17.4, visionOS 1.2, watchOS 10.4. Por debajo, la funcionalidad no existe, así que la app necesita camino alternativo para usuarios en versiones antiguas.

3 · Las URLs, que ya no se declaran

Desde el otoño de 2024 se simplificó bastante: se pueden usar cualquier número de URLs sin declararlas en el Info.plist, y están permitidos parámetros, redirecciones y páginas de aterrizaje intermedias.

Eso habilita lo que necesita cualquier equipo de producto serio: pasar identificador de usuario, campaña y oferta en la URL, y aterrizar en una página propia antes del checkout.

4 · Elegibilidad, antes de enseñar nada

En iOS 18.1 y superior se resuelve con una propiedad:

if ExternalPurchaseCustomLink.isEligible {
    // mostrar la comunicación de la oferta
}

Por debajo de 18.1 hay que implementar las tres comprobaciones a mano:

canMakePayments() — si es false, no hay elegibilidad.
Leer la tienda actual con Storefront.current y su countryCode.
Verificar que esa tienda está entre las regiones permitidas y que tu app soporta compra externa en esa región.

Ese fallback hay que escribirlo igual mientras soportes versiones anteriores, y es donde aparecen los fallos raros: un usuario español con la tienda en otro país no es elegible aunque esté físicamente en España. Manda la tienda, no la ubicación.

5 · La hoja de divulgación, obligatoria

No es opcional ni personalizable:

«Cuando lleves a los usuarios a su destino mediante un enlace accionable (es decir, un enlace que se pueda tocar, pulsar o escanear), tu app debe usar la API ExternalPurchaseCustomLink para mostrar una hoja de divulgación proporcionada por el sistema que explique al usuario que va a realizar la transacción con el desarrollador y no con Apple.»

Se invoca con showNotice(type:) después de una interacción deliberada del cliente —pulsar un botón— y antes de enlazar fuera. La hoja incluye un botón de continuar y una opción de «¿Mostrar este recordatorio la próxima vez?».

Diseño del enlace: Apple publica plantillas localizadas en 40 idiomas, con estilo de botón plano, del tipo «Compra en la web www.ejemplo.com» o «Precios más bajos en www.ejemplo.com».

Y una restricción de metadatos que se olvida: no puedes incluir información sobre compras externas en la ficha de la App Store. La comunicación va dentro de la app.

La parte que nadie presupuesta: el reporte

Esto no es un detalle de cumplimiento. Es un subsistema de tu backend, y es la mitad del proyecto.

«Si tu app adopta el StoreKit External Purchase Link Entitlement, estás obligado a usar la External Purchase Server API para reportar transacciones a Apple a efectos del cálculo y cobro de comisiones y tarifas.»

Tokens

En el arranque de la app se piden los tokens con token(for:), con dos tipos:

ACQUISITION — vinculado a la adquisición inicial del cliente.
SERVICES — vinculado a la ventana de servicios de tienda.

Esos tokens se asocian a la cuenta del cliente en tu servidor. Es la pieza de diseño crítica: si tu producto no tiene identidad de usuario propia y persistente, no hay dónde guardarlos, y sin ellos no puedes reportar correctamente.

Qué hay que reportar

Y aquí viene lo que sorprende a todos los equipos:

Reembolsos.
Correcciones.
Renovaciones.
Compras únicas.
Y las transacciones que no acabaron en compra.

Esa última obliga a instrumentar el embudo entero, no solo el éxito. Si tu web de pago no notifica los intentos fallidos a tu backend, te falta información que estás obligado a enviar.

El informe mensual

«Estás obligado a enviar a Apple un informe con todas las ventas de bienes o servicios digitales realizadas en cualquier plataforma. Debes proporcionar este informe mensualmente, dentro de los 15 días naturales siguientes al cierre del mes fiscal de Apple.»

Léelo bien: todas las ventas en cualquier plataforma, no solo las que vinieron de iOS. Y con calendario fiscal de Apple, que no coincide con el mes natural.

Y la factura

Apple agrega las transacciones y calcula las comisiones por el día 15 del mes siguiente, y hay 30 días para pagar desde que se recibe la factura. El impago acumula intereses y puede acabar en compensación contra los ingresos de la compra integrada, retirada de la app y expulsión del programa de desarrollador.

O sea: esto entra en el circuito de facturación de tu empresa, con su responsable. No es una tarea del equipo móvil.

Lo que pasa a ser tuyo

Apple lo dice sin rodeos: si adoptas el entitlement, Apple no podrá ayudar a tus clientes con reembolsos, historial de compras, gestión de suscripciones ni otros problemas.

Traducido a trabajo real:

Pasarela de pago con su integración, sus métodos locales y su tasa.
Impuestos: el IVA por país lo gestionas tú, o tu proveedor.
Reembolsos y disputas, con su política y su gente.
Gestión de suscripción: cambiar de plan, pausar, cancelar. Todo lo que hoy hace la ficha de suscripciones del sistema.
Fraude y cargos revertidos.
Soporte, que es el que más volumen genera.
Recuperación de pagos fallidos, que en suscripción web es una disciplina en sí misma.

Y un detalle de producto que se ve en las métricas: sacar al usuario de la app rompe el embudo. Se pierde gente en el salto, en la hoja de divulgación y en el checkout web. Ese abandono hay que medirlo antes de celebrar el ahorro de comisión.

La arquitectura que aguanta las dos vías

Como la app tiene que soportar compra integrada en unas tiendas y pago externo en otras, la única forma de que esto no se convierta en un árbol de condicionales es la capa de derechos:

Tu backend es la fuente de verdad de qué tiene contratado cada usuario.
La app pregunta por el derecho, nunca por el recibo ni por el estado de StoreKit.
Los mecanismos de cobro son proveedores que alimentan esa tabla: compra integrada por un lado, tu pasarela por otro, cada uno con su webhook.
La tienda del usuario decide qué mecanismo se ofrece, y es un dato de presentación, no de negocio.

Con eso, activar el pago externo en un país nuevo es configuración; y si mañana cambian las reglas —que cambiarán—, se toca el proveedor y no el producto.

Cuándo compensa, con números

Antes de abrir el proyecto, tres cálculos:

Volumen anual de suscripción en tiendas de la UE, separando primer año de renovaciones. Recuerda que las renovaciones de suscripciones contratadas antes del entitlement quedan fuera de estas tarifas.
Ahorro bruto: comisión actual menos la suma de las capas que te apliquen.
Coste real: pasarela, impuestos, desarrollo del reporte, soporte, recuperación de pagos y la pérdida de conversión del salto fuera de la app.

Si ya tienes una plataforma de suscripción web funcionando —con su facturación, sus impuestos y su soporte—, el cálculo suele salir. Si el único canal es la app, estás construyendo un negocio de facturación desde cero para ahorrar unos puntos.

Checklist de implementación

Catorce puntos, y solo cinco son de la app. Esa proporción es la verdadera respuesta a «¿cuánto cuesta quitarse la comisión de Apple?».

El panorama general de qué se puede hacer en cada tienda —Estados Unidos, la Unión Europea y el resto— está en compras dentro de la app: qué ha cambiado.

Fuentes primarias, consultadas el 14 de agosto de 2026: Communication and promotion of offers on the App Store in the EU y Updates to the StoreKit External Purchase Link Entitlement, de Apple Developer. Las tarifas cambian: antes de fijar un modelo, contrástalas contra esa página el mismo día.

Pago externo para suscripciones de iOS en la UE: guía técnica de implementación