¿Hay vida después del recorte del 30%?
Cada equipo de minijuegos hace la misma cuenta en el dorso de una servilleta: ingresos menos 30% igual a supervivencia. Y ahí se detienen, como si el 30% fuera una ley de la física. No lo es. Es un peaje en una carretera concreta, y hay otras carreteras. Separemos qué es realmente ese recorte y qué queda cuando sumas lo que el titular esconde.
Q: ¿El recorte del 30% de las tiendas es fijo?
Para una app nativa distribuida vía App Store o Google Play, sí: es contractual y se aplica en la capa de pago. Pero el "30%" solo describe una vía de distribución. En cuanto tu juego corre dentro de un runtime o de un super-app en vez de un binario nativo independiente, la estructura de comisión cambia, porque quien cobra no es quien tiene el dispositivo. El impuesto es un peaje en un camino, no un impuesto a la gravedad.
Q: ¿De verdad un runtime o plataforma de minijuegos puede batir el 30%?
Depende de qué se cobra. Un runtime que aloja tu juego y gestiona los pagos toma una participación de plataforma, pero esa participación se negocia y suele ser menor que la de la tienda; y, sobre todo, a menudo empaqueta alojamiento, distribución y una base de usuarios compartida por la que de otro modo pagarías adquisición. Los equipos en un runtime suelen quedarse con mucho más que el 70% que sobrevive al impuesto de la tienda, en parte porque la participación del runtime reemplaza tanto la comisión como un trozo del gasto en marketing.
Q: ¿Es conforme desviar pagos por webview para esquivar el recorte de la tienda?
Esta es la línea que no se cruza a la ligera. Las tiendas prohíben dirigir a pagos externos para bienes digitales dentro de una app nativa, y lo aplican. Un minijuego que vive en un runtime es otro animal: el runtime es la superficie de distribución, así que la relación de pago es con el runtime, no un canal paralelo pegado a una app nativa. Construir fuera del muro de pago de la tienda es legítimo; colarse por dentro es como los equipos acaban baneados.
Q: ¿Cómo calculo de verdad lo que me quedo?
Deja de mirar la comisión del titular y arma toda la pila: participación de plataforma, más procesamiento de pago al 2–3%, más coste de UA (el asesino silencioso), más rechazos y reembolsos. Un recorte del 30% en un juego que luego gasta el 40% de sus ingresos en UA es peor que una participación de runtime del 15% en un juego que hereda una base cálida de usuarios. Lo que queda neto es el único número que paga sueldos.
Q: ¿Qué canal debería elegir un equipo pequeño?
El que con su comisión te compra algo que no podrías pagar solo: una base de usuarios, una vía de pago que funcione en tu mercado objetivo, o distribución instantánea sin ciclo de revisión de la tienda. Los equipos pequeños mueren en la adquisición de clientes, no en el porcentaje de comisión. Elige el canal que te ponga jugadores en la mano y luego optimiza lo que te queda.
| Canal | Comisión típica | Lo que recibes | La trampa |
|---|---|---|---|
| App Store / Google Play | 15–30% | facturación, confianza, alcance | pago bloqueado, ciclo de revisión |
| Runtime / plataforma de minijuegos | ~10–20% | alojamiento + usuarios compartidos + pago local | vas sobre sus rieles |
| Web directo (webview) | solo procesamiento (~3%) | control total | tú pagas toda la UA |
| Facturación operador / monedero | 10–25% | llega a quienes no tienen banco | integración por mercado |
Fuentes
- Apple — Guías de revisión de App Store (reglas de negocio)
- Google Play — política de Play Billing
- Sensor Tower — ingresos de apps y economía de tiendas
- Deconstructor of Fun — despieces de plataforma y take-rate
- Think with Google — monetización de juegos móviles
- Statista — participación de ingresos de apps por tienda