Saltar al contenido principal

Investigación — Suscripciones en Apps Móviles

Las suscripciones en apps móviles funcionan de forma distinta a la web. Apple y Google exigen que los pagos recurrentes dentro de sus apps pasen obligatoriamente por sus propios sistemas de facturación (App Store / Google Play Billing), con las consecuencias económicas y de integración que eso implica.

Cómo funciona cada plataforma​

iOS — App Store Subscriptions (StoreKit 2)​

  • Apple gestiona el cobro directamente al usuario; nosotros nunca procesamos la tarjeta.
  • Se definen los planes ("Auto-Renewable Subscriptions") en App Store Connect.
  • El SDK de iOS es StoreKit 2 (Swift, desde iOS 15). Para versiones anteriores existe StoreKit 1, pero se recomienda migrar.
  • Apple retiene una comisión del 30% (15% si la app lleva más de 1 año con el mismo suscriptor, o si es parte del Small Business Program con ingresos < $1M/año).
  • El estado de la suscripción se verifica en el backend mediante App Store Server Notifications (webhooks de Apple) o consultando el recibo con la API /verifyReceipt (deprecada) o la nueva App Store Server API.

Android — Google Play Billing​

  • Google gestiona el cobro; se definen los planes en Google Play Console.
  • SDK del lado cliente: Google Play Billing Library (Kotlin/Java) o vía el plugin correspondiente en React Native / Flutter.
  • Comisión del 30% (15% para los primeros $1M de ingresos anuales por app).
  • El backend valida compras usando la Google Play Developer API y recibe eventos mediante Real-time Developer Notifications (Pub/Sub de Google Cloud).

Restricción de plataforma (regla del 30%)​

Tanto Apple como Google prohíben ofrecer en la app web prices más baratos que los precios in-app, ni enlazar directamente a una página de compra externa desde dentro de la app. Esto afecta directamente la estrategia de monetización:

  • No se puede cobrar en Stripe dentro de la app móvil para evitar la comisión.
  • Sí se puede tener una suscripción activa comprada en web y que la app la reconozca (flujo "web first").
  • Apple abrió una excepción en EE.UU. para poder enlazar a la web, pero con restricciones; en otros mercados la norma sigue vigente.

Alternativas de integración​

Opción A — RevenueCat (recomendada para investigar primero)​

RevenueCat es un SDK + backend que abstrae App Store y Google Play en una sola API.

Ventajas:

  • Un solo SDK para iOS y Android (hay plugins para React Native y Flutter).
  • Dashboard unificado con métricas de suscripciones, churn, MRR.
  • Maneja la validación de recibos, webhooks y sincronización de estado sin infraestructura propia.
  • Plan gratuito hasta $2,500/mes de revenue rastreado.

Desventajas:

  • Dependencia de un tercero en la capa de pagos.
  • A partir de cierto volumen tiene costo (1% del revenue rastreado).

Opción B — Integración nativa directa​

Implementar StoreKit 2 (iOS) y Google Play Billing (Android) de forma independiente y construir el backend de validación propio.

Ventajas:

  • Control total; sin dependencia de terceros.
  • Sin costo adicional de plataforma.

Desventajas:

  • Mayor complejidad de implementación y mantenimiento.
  • Hay que manejar por separado webhooks de Apple y Google, casos de reembolso, expiración, reintentos, etc.

Opción C — "Web First" con Stripe​

Evitar in-app purchases e incentivar al usuario a suscribirse desde la web (donde sí usamos Stripe). La app solo verifica el estado de la suscripción en nuestro backend.

Ventajas:

  • Evita la comisión del 30%.
  • Una sola integración de pagos (Stripe, ya definida).
  • Menos complejidad móvil.

Desventajas:

  • Fricción para el usuario (salir de la app para suscribirse).
  • Apple puede rechazar apps que no ofrezcan in-app purchase cuando el producto es digital.

Sincronización web ↔ mobile​

Sea cual sea la opción elegida, el estado de la suscripción debe vivir en nuestro backend y ser la fuente de verdad para ambas plataformas:

Usuario suscrito (App Store / Google Play / Stripe)
          ↓
    Backend Finnova
    [ user.subscription_status, user.plan, user.expires_at ]
          ↓
   App móvil y web consultan el mismo endpoint

Esto permite que una suscripción comprada en web sea reconocida en la app y viceversa.

Recursos​