我在这行待了快十年，看过无数团队做消费类 App，一个规律反复出现：当一个 App 真正开始赚钱，分发它的平台就会变成抽它的平台。不是意外，是合同写明的。那 30% 的抽成、动辄几天的审核队列、强制走 IAP 而把你本地支付通道拒之门外的规则——这些不是 bug，是商业模式本身。
先把账算清楚，因为数字对单位经济有真实影响。
Apple App Store 对数字商品与订阅抽 30%，只有「小型企业计划」（年流水低于 100 万美元）才能降到 15%。Google Play 同样 30%/15%。对一个毛利率 70%—80% 的订阅生意，营收上 30% 的抽成不是一笔费用，而是叠在你自己成本之上的第二道销货成本。
抽成只是故事的一半，另一半是对分发速度的控制权。
一次原生 App 更新要过人工审核。中位审批要 1—2 天，政策驳回能拖到几周，而且不像正常发布流水线那样可预期。对一个每周做实验的团队，这种延迟本身就是对迭代的征税。你不是准备好了才发版，是审核员放你走才发版。
再说支付通道。IAP 在设计上以银行卡为中心、与平台耦合。而在那 11 国受众真正生活的市场——印尼、巴西、肯尼亚、菲律宾——主流通道是 GoPay、OVO、GCash、Pix、M-Pesa：实时银行与钱包网络，IAP 原生不支持。在一个大多数成年人没有国际银行卡的市场，逼用户走基于银行卡的 IAP 流程，那不是一种支付选项，而是一道转化断崖。
把账摆到桌面上
| 维度 | 原生 App + 应用商店 | 小程序 runtime（宿主自有） |
|---|---|---|
| 发版节奏 | 1—7 天审核队列 | 当天灰度，宿主掌控 |
| 支付抽成 | 30%（小企业 15%）走 IAP | 宿主钱包，运营方自定 |
| 本地支付通道 | 原生不支持 | 按市场可插拔 |
| 审核不确定性 | 外部、不可协商 | 内部策略、可审计 |
| 监管暴露 | DMA / 韩国 / CCI 三面对商店施压 | 转移给宿主运营方 |
| 多宿主复用 | 按商店分别打包 | 一次开发，多宿主 |
这些都不是纸上谈兵。商店模式正在三大洲被法律围攻。
美国，Epic Games 同时起诉 Apple 和 Google。Apple 案（2021 年 9 月裁决）保留了 Apple 大部分模式，但推翻了反导流规则；Google 案在 2023 年 12 月以陪审团裁定 Play 商店与 Play Billing 构成非法垄断收场。欧盟《数字市场法》（DMA）2024 年 3 月生效，将 Apple 与 Google 同时列为「守门人」，从法律上开放了替代分发与替代支付。韩国 2021 年通过首部强制商店允许替代支付系统的成文法。印度竞争委员会 2022 年 10 月对 Google 处以 1337 亿卢比（约 1.61 亿美元）罚款，并责令开放第三方计费。
把这份清单读作一条趋势线，而不是几条新闻。监管世界正在就一个结论收敛：商店对分发与支付的双重把持，是结构性问题，不是定价纠纷。
那么真正改变这门账的是什么？答案不是「离开商店」。对绝大多数消费类 App，商店仍是唯一可行的获客渠道，这一点不会变。答案是把服务层从分发层解耦。
这正是小程序 runtime 的价值所在。当宿主 App 通过 runtime 而非原生包或内嵌 webview 来交付服务，商店征不到税的地方发生了两件事：
第一，服务更新绕开商店审核队列。runtime 承载的小程序在加载时被解释执行，宿主可以当天发一个修复或新流程，背后挂灰度，无需提交二进制包。迭代税消失了。
第二，支付发生在宿主自有钱包内，走宿主早已接好的本地通道。交易根本不碰 IAP，因此 30% 不适用——更关键的是，非银行卡市场的转化断崖消失了，因为宿主接入 Pix 或 M-Pesa，跟接任何应用内流程没有区别。
我想谨慎一点，不要夸大。runtime 并不能让你豁免平台政策——Apple 和 Google 仍然管着宿主 App 能做什么，DMA 的放行仅限欧盟且自带合规成本（Apple 的「核心技术费」就是典型），若干司法辖区仍在诉讼边界。站得住脚的说法更窄也更强：把服务与支付层移入宿主掌控的 runtime，你就是把一道外部控制、不可协商的过路费，换成一项内部、可审计的运营决策。你用一笔自己定价的成本，替换掉一笔你无法预判的税。
对在新市场做产品的运营者，这笔交易就是全部。你不是在跟 Apple、Google 争存在的权利，你是在构建一层能在自己 App 内复利的服务层——商店没法对它计价，审核队列没法拖它，只认银行卡的 IAP 也没法卡它。
30% 是 headline，但持久的 advantage 是你对自己发版与支付速度的控制权。把这两样拿回来，商店才回到它本该有的位置：一扇前门，而不是收费站。
