Passo quase dez anos vendo equipes lançar apps de consumo, e um padrão se repete em qualquer mercado. No momento em que um app começa a ganhar dinheiro de verdade, a plataforma que o distribui vira a plataforma que o taxa. Não por acidente: por contrato. O corte de 30%, a fila de revisão de dias, o sistema de compra in-app (IAP) que rejeita seu meio de pagamento local: isso não são bugs. É o modelo de negócio.
Vamos precisar o que é realmente cobrado, porque os números têm consequências reais na economia unitária.
A App Store da Apple cobra 30% de comissão sobre bens digitais e assinaturas, caindo para 15% apenas no Small Business Program para desenvolvedores abaixo de um milhão de dólares ao ano. O Google Play usa a mesma estrutura 30/15. Para um negócio de assinatura com margem bruta de 70% a 80%, 30% sobre a receita não é uma taxa: é um segundo custo de vendas empilhado sobre o seu.
E a comissão é só metade da história. A outra metade é o controle sobre a velocidade de distribuição.
Uma atualização nativa passa por revisão humana. A aprovação média leva de um a dois dias; uma rejeição por política pode esticar por semanas, e chega sem a previsibilidade de um pipeline de release normal. Para uma equipe que lança experimentos toda semana, essa latência é um imposto à iteração. Você não lança quando está pronto: lança quando o revisor te libera.
Depois tem a via de pagamento. A IAP, por design, gira em torno do cartão e é acoplada à plataforma. Nos mercados onde a audiência dos onze países realmente vive — Indonésia, Brasil, Quênia, Filipinas — as vias dominantes são GoPay, OVO, GCash, Pix, M-Pesa: redes bancárias e de carteira em tempo real que a IAP não suporta nativamente. Obrigar um usuário a passar por um fluxo IAP baseado em cartão em um mercado onde a maioria dos adultos não tem cartão internacional não é uma opção de pagamento: é um penhasco de conversão.
Os números, lado a lado
| Dimensão | App nativo + App Store | Runtime de mini-programa (do host) |
|---|---|---|
| Ritmo de release | Fila de revisão 1–7 dias | Canary no mesmo dia, controle do host |
| Comissão de pagamento | 30% (15% pequena empresa) via IAP | Carteira do host, termos a seu critério |
| Vias de pagamento locais | Não suportadas nativamente | Plugáveis por mercado |
| Incerteza de revisão | Externa, inegociável | Política interna, auditável |
| Exposição regulatória | DMA / Coreia / CCI pressionam as lojas | Transferida ao operador host |
| Reuso multi-host | Build por loja | Um build, muitos hosts |
Nada disso é teórico. O modelo de loja está sob cerco legal ativo em três continentes.
Nos Estados Unidos, a Epic Games processou tanto a Apple quanto o Google. O caso da Apple, decidido em setembro de 2021, manteve grande parte do modelo intacta mas anulou as regras anti-desvio. O caso do Google terminou em dezembro de 2023 com veredito do júri declarando a Play Store e a Play Billing um monopólio ilegal. Na União Europeia, o Digital Markets Act entrou em vigor em março de 2024 e designou Apple e Google como «gatekeepers», abrindo legalmente a distribuição e o pagamento alternativos. A Coreia aprovou em 2021 a primeira lei que obriga as lojas a permitir sistemas de pagamento alternativos. A autoridade de concorrência da Índia multou o Google em 1.337 crore de rúpias — cerca de 161 milhões de dólares — em outubro de 2022 e ordenou o faturamento de terceiros.
Leia essa lista como uma linha de tendência, não como um ciclo de notícias. O mundo regulatório converge em uma única conclusão: o controle combinado da loja sobre distribuição e pagamento é um problema estrutural, não uma disputa de preços.
Então, o que realmente muda a equação? A resposta não é «sair da loja». Para a imensa maioria dos apps de consumo, a loja segue sendo o único canal de aquisição viável, e isso não vai mudar. A resposta é desacoplar a camada de serviços da camada de distribuição.
É aqui que um runtime de mini-programa justifica sua existência. Quando um app host entrega serviços via runtime em vez de builds nativos ou webviews embutidos, acontecem duas coisas que a loja não pode taxar.
Primeiro, o serviço se atualiza sem a fila de revisão da loja. Um mini-programa em runtime é interpretado em carga; o host pode lançar uma correção ou um fluxo novo no mesmo dia, atrás de um canary, sem enviar um binário. O imposto à iteração some.
Segundo, o pagamento ocorre dentro da carteira própria do host, numa via local que o host já integrou. A transação nunca toca a IAP, então os 30% não incidem — e, mais importante, o penhasco de conversão em mercados sem cartão desaparece, porque o host pluga Pix ou M-Pesa exatamente como faria com qualquer fluxo in-app.
Quero ser cuidadoso e não exagerar. Um runtime não te isenta da política de plataforma. Apple e Google ainda governam o que um app host pode fazer; as concessões do DMA valem só para a UE e trazem seu próprio custo de compliance — a Core Technology Fee da Apple é o exemplo óbvio — e várias jurisdições ainda litigam o limite. A afirmação sustentável é mais estreita e mais forte: ao mover a camada de serviço e pagamento para um runtime controlado pelo host, você converte um pedágio externo, inegociável, em uma decisão operacional interna e auditável. Você troca um imposto imprevisível por um custo que você fixa.
Para os operadores que constroem em mercados emergentes, essa troca é o jogo inteiro. Você não está brigando com Apple e Google pelo direito de existir. Você está construindo uma camada de serviços que compõe dentro do seu próprio app — uma que a loja não consegue medir, a fila de revisão não consegue atrasar, e a IAP só-para-cartão não consegue quebrar.
Os 30% são a manchete. A vantagem durável é o controle sobre sua própria velocidade de release e pagamento. Recupere-os, e a loja volta a ser o que deveria ser: uma porta de entrada, não uma caseta de pedágio.
