I've spent the better part of a decade watching teams ship consumer apps, and one pattern repeats regardless of market. The moment an app starts making real money, the platform that distributes it becomes the platform that taxes it. Not by accident — by contract. The 30 percent cut, the multi-day review queue, the in-app purchase system that rejects your local payment rail: these aren't bugs. They are the business model.
Let me be precise about what is actually being charged, because the numbers have real consequences for unit economics.
Apple's App Store takes a 30 percent commission on digital goods and subscriptions, falling to 15 percent only under the Small Business Program for developers below one million dollars in annual proceeds. Google Play runs the same 30/15 structure. For a subscription business running 70 to 80 percent gross margin, a 30 percent take on revenue is not a fee. It is a second cost of goods sold stacked on top of your own.
And the commission is only half the story. The other half is control over distribution velocity.
A native app update passes through human review. Median approval runs one to two days; policy rejections can stretch to weeks, and they arrive without the predictability of a normal release pipeline. For a team shipping weekly experiments, that latency is a tax on iteration itself. You do not ship when you are ready. You ship when the reviewer clears you.
Then there is the payment rail. In-app purchase is, by design, card-centric and platform-coupled. In the markets where the eleven-country audience actually lives — Indonesia, Brazil, Kenya, the Philippines — the dominant rails are GoPay, OVO, GCash, Pix, M-Pesa: real-time bank and wallet networks that IAP does not natively support. Forcing users through a card-based IAP flow in a market where most adults do not hold an international card is not a payment option. It is a conversion cliff.
The numbers, side by side
| Dimension | Native app + App Store | Mini-program runtime (host-owned) |
|---|---|---|
| Release cadence | 1–7 day review queue | Same-day canary, host-controlled |
| Payment commission | 30% (15% small business) via IAP | Host wallet, operator-set terms |
| Local payment rails | Not natively supported | Pluggable per market |
| Review uncertainty | External, non-negotiable | Internal policy, auditable |
| Regulatory exposure | DMA / Korea / CCI pressure on stores | Shifted to host operator |
| Multi-host reuse | Store-specific build | One build, many hosts |
None of this is theoretical. The store model is under active legal siege on three continents.
In the United States, Epic Games sued both Apple and Google. The Apple case, decided in September 2021, left most of Apple's model intact but struck the anti-steering rules. The Google case ended in a December 2023 jury verdict finding Play Store and Play Billing an illegal monopoly. In the European Union, the Digital Markets Act took force in March 2024 and designated both Apple and Google as gatekeepers, legally opening alternative distribution and payment. South Korea passed the first statute, in 2021, forcing stores to permit alternative payment systems. India's competition authority fined Google 1,337 crore rupees — about 161 million dollars — in October 2022 and ordered third-party billing.
Read that list as a trend line, not a news cycle. The regulatory world is converging on a single conclusion: the store's combined grip on distribution and payment is a structural problem, not a pricing dispute.
So what actually changes the math? The answer is not "leave the store." For the vast majority of consumer apps, the store remains the only viable acquisition channel, and that is not changing. The answer is to decouple the service layer from the distribution layer.
This is where a mini-program runtime earns its keep. When a host app delivers services through a runtime rather than native builds or embedded webviews, two things happen that the store cannot tax.
First, the service updates without the store's review queue. A runtime-hosted mini-program is interpreted at load time; the host can ship a fix or a new flow the same day, gated behind a canary, without submitting a binary. The iteration tax disappears.
Second, the payment happens inside the host's own wallet, on a local rail the host already integrated. The transaction never touches IAP, so the 30 percent does not apply — and, more importantly, the conversion cliff for non-card markets disappears, because the host plugs in Pix or M-Pesa exactly the way it would for any in-app flow.
I want to be careful not to overstate this. A runtime does not exempt you from platform policy. Apple and Google still govern what a host app may do, the DMA's allowances are EU-only and carry their own compliance overhead — Apple's Core Technology Fee is the obvious example — and several jurisdictions still litigate the boundary. The defensible claim is narrower and stronger: by moving the service and payment layer into a host-controlled runtime, you convert an externally-controlled, non-negotiable toll into an internal, auditable operating decision. You trade a tax you cannot see coming for a cost you set yourself.
For operators building in emerging markets, that trade is the whole game. You are not fighting Apple and Google for the right to exist. You are building a service layer that compounds inside your own app — one the store cannot meter, the review queue cannot delay, and the card-only IAP cannot break.
The 30 percent is the headline. The durable advantage is control over your own release and payment velocity. Get those back, and the store becomes what it should have been: a front door, not a tollbooth.
