Llevo cerca de diez años viendo equipos lanzar apps de consumo, y un patrón se repite en cualquier mercado. En el momento en que una app empieza a ganar dinero de verdad, la plataforma que la distribuye se convierte en la plataforma que la grava. No por accidente: por contrato. El recorte del 30%, la cola de revisión de varios días, el sistema de compra dentro de la app (IAP) que rechaza tu método de pago local: esto no son fallos. Es el modelo de negocio.
Precisemos qué se cobra realmente, porque las cifras tienen consecuencias reales en la economía unitaria.
La App Store de Apple cobra una comisión del 30% sobre bienes digitales y suscripciones, que baja al 15% solo en el Programa de Pequeñas Empresas para desarrolladores por debajo de un millón de dólares anuales. Google Play usa la misma estructura 30/15. Para un negocio de suscripción con márgenes brutos del 70% al 80%, un 30% sobre los ingresos no es una tarifa: es un segundo costo de ventas apilado sobre el tuyo.
Y la comisión es solo la mitad de la historia. La otra mitad es el control sobre la velocidad de distribución.
Una actualización nativa pasa por revisión humana. La aprobación media tarda uno a dos días; un rechazo por política puede extenderse semanas, y llega sin la previsibilidad de un pipeline de release normal. Para un equipo que lanza experimentos cada semana, esa latencia es un impuesto a la iteración. No lanzas cuando estás listo: lanzas cuando el revisor te libera.
Luego está la vía de pago. La IAP, por diseño, gira en torno a la tarjeta y está acoplada a la plataforma. En los mercados donde realmente vive la audiencia de los once países — Indonesia, Brasil, Kenia, Filipinas — las vías dominantes son GoPay, OVO, GCash, Pix, M-Pesa: redes bancarias y de billetera en tiempo real que la IAP no soporta de forma nativa. Obligar a un usuario a pasar por un flujo IAP basado en tarjeta en un mercado donde la mayoría de los adultos no tiene una tarjeta internacional no es una opción de pago: es un precipicio de conversión.
Los números, cara a cara
| Dimensión | App nativa + App Store | Runtime de mini-programa (del host) |
|---|---|---|
| Ritmo de release | Cola de revisión 1–7 días | Canary el mismo día, control del host |
| Comisión de pago | 30% (15% pequeña empresa) vía IAP | Billetera del host, condiciones a su criterio |
| Vías de pago locales | No soportadas nativamente | Enchufables por mercado |
| Incertidumbre de revisión | Externa, innegociable | Política interna, auditable |
| Exposición regulatoria | DMA / Corea / CCI presionan a las tiendas | Transferida al operador host |
| Reuso multi-host | Build por tienda | Un build, muchos hosts |
Nada de esto es teórico. El modelo de tienda está bajo asedio legal activo en tres continentes.
En Estados Unidos, Epic Games demandó tanto a Apple como a Google. El caso de Apple, resuelto en septiembre de 2021, dejó gran parte del modelo intacto pero anuló las reglas anti-derivación. El caso de Google terminó en diciembre de 2023 con un veredicto del jurado que declaró a Play Store y Play Billing un monopolio ilegal. En la Unión Europea, el Digital Markets Act entró en vigor en marzo de 2024 y designó a Apple y Google como «gatekeepers», abriendo legalmente la distribución y el pago alternativos. Corea aprobó en 2021 la primera ley que obliga a las tiendas a permitir sistemas de pago alternativos. La autoridad de competencia de India multó a Google con 1.337 crore de rupias — unos 161 millones de dólares — en octubre de 2022 y ordenó la facturación de terceros.
Lee esa lista como una línea de tendencia, no como un ciclo de noticias. El mundo regulatorio converge en una sola conclusión: el control combinado de la tienda sobre distribución y pago es un problema estructural, no una disputa de precios.
Entonces, ¿qué cambia realmente la ecuación? La respuesta no es «salir de la tienda». Para la inmensa mayoría de las apps de consumo, la tienda sigue siendo el único canal de adquisición viable, y eso no va a cambiar. La respuesta es desacoplar la capa de servicios de la capa de distribución.
Aquí es donde un runtime de mini-programa justifica su existencia. Cuando una app host entrega servicios mediante un runtime en lugar de builds nativos o webviews embebidos, ocurren dos cosas que la tienda no puede gravar.
Primero, el servicio se actualiza sin la cola de revisión de la tienda. Un mini-programa en runtime se interpreta en carga; el host puede lanzar una corrección o un flujo nuevo el mismo día, detrás de un canary, sin enviar un binario. El impuesto a la iteración desaparece.
Segundo, el pago ocurre dentro de la billetera propia del host, en una vía local que el host ya integró. La transacción nunca toca la IAP, así que el 30% no aplica — y, más importante, el precipicio de conversión en mercados sin tarjeta desaparece, porque el host conecta Pix o M-Pesa exactamente como lo haría con cualquier flujo in-app.
Quiero ser cuidadoso y no exagerar. Un runtime no te exime de la política de plataforma. Apple y Google siguen gobernando lo que una app host puede hacer; las concesiones del DMA son solo para la UE y traen su propio costo de cumplimiento — la Core Technology Fee de Apple es el ejemplo obvio — y varias jurisdicciones aún litigan el límite. La afirmación defendible es más estrecha y más fuerte: al mover la capa de servicio y pago a un runtime controlado por el host, conviertes un peaje externo, innegociable, en una decisión operativa interna y auditable. Cambias un impuesto impredecible por un costo que fijas tú.
Para los operadores que construyen en mercados emergentes, ese intercambio es el juego completo. No estás peleando con Apple y Google por el derecho a existir. Estás construyendo una capa de servicios que compone dentro de tu propia app — una que la tienda no puede medir, la cola de revisión no puede retrasar, y la IAP solo-para-tarjeta no puede romper.
El 30% es el titular. La ventaja duradera es el control sobre tu propia velocidad de release y pago. Recupéralos, y la tienda vuelve a ser lo que debió ser: una puerta de entrada, no una caseta de peaje.
