For most of the App Store's history, the commission structure has been simple and unforgiving: 30% on in-app purchases, dropping to 15% only after a subscription crossed its first year, or for Small Business Program participants under a million in annual revenue. Apple's Mini Apps Partner Program — announced late 2025 and now actively onboarding developers in 2026 — is the first program in years to put a flat 15% rate on a much broader category of in-app revenue. If your app hosts third-party experiences, or you've been looking at the mini-app pattern as a way to scale your platform without writing every feature yourself, this program changes the unit economics enough to warrant a real read.
This guide walks through what mini apps actually are under Apple's definition, who qualifies for the reduced commission, the API requirements that come with the program, and the trade-offs indie developers should weigh before restructuring their app around the model.
What Apple means by "mini app"#
Apple's definition is narrower than the term suggests in the wider industry. A mini app, in the program's language, is a self-contained experience built using web technologies — HTML, CSS, JavaScript — that runs inside a native iOS host app. The host app is yours; the mini apps are typically built by other developers, published into a directory or marketplace your app exposes, and run inside a webview or a WKWebView-equivalent surface.
The pattern is most familiar from Asian super-apps like WeChat and Alipay, where a single host app contains thousands of small experiences for ordering food, paying bills, booking travel, and so on. It's also the pattern behind some of the larger Western developer-platform plays — Shopify's storefront extensions, Slack's app directory, the Discord activities surface — where a host product hosts third-party software that completes specific user jobs.
What it is not: it's not a "lite version" of your own app, it's not a hybrid React Native or Capacitor build, and it's not the distinction Apple draws elsewhere between AppClips and full apps. Mini apps under this program are explicitly third-party content rendered inside your native host. If you wrote it, it's not a mini app — it's just your app.
The 15% commission and what it covers#
The headline of the program is the commission. For any mini app not made by the host developer, the host developer pays Apple a flat 15% commission on qualifying in-app purchases. That's half the standard 30% rate, and applies to:
- Consumable in-app purchases inside the mini app (think credits, tokens, one-shot unlocks).
- Non-consumable in-app purchases inside the mini app (one-time content unlocks).
- Auto-renewable subscriptions purchased inside the mini app.
- Non-renewing subscriptions purchased inside the mini app.
It does not apply to in-app purchases for content the host developer ships themselves, and it does not apply to physical goods or services already exempt from the App Store commission (Uber rides, Amazon orders, etc.).
The math gets interesting fast. A mini-app marketplace processing $500K in annual mini-app subscriptions under the standard 30% rate keeps $350K after Apple's cut. Under the Mini Apps Partner Program's 15% rate, it keeps $425K. The 75% commission reduction stacks with whatever revenue split the host has with the mini-app developers, which means the host can pay creators more without eating its own margin.
The API requirements you have to support#
To get into the program, your host app needs to implement a specific set of Apple APIs that give Apple visibility into the mini-app surface and let users access standard iOS protections inside what is functionally a third-party experience.
The Declared Age Range API. Your host app has to participate in Apple's age-range disclosure, which propagates into the mini-app environment so age-gated content (alcohol-adjacent purchases, gambling, certain wellness products) is rendered the same way it would be in a native app. The API is straightforward — you read the user's declared age range and surface it to the mini-app sandbox — but it's a hard requirement, not optional.
The Advanced Commerce API. This is the heaviest lift. Apple's Advanced Commerce API gives the host app the ability to register, sell, and refund mini-app in-app purchases through a programmatic surface designed for variable, large-catalog products. If your mini-app marketplace has 500 mini apps each with a few subscription tiers, you're not creating those products by hand in App Store Connect — you're registering them at runtime through Advanced Commerce. The API has been in beta since iOS 18 and went stable in iOS 26.
The In-App Purchase system. All purchases inside mini apps have to flow through Apple's IAP infrastructure. There's no exception that lets a mini app run its own card processor inside your host app. The host is responsible for ensuring every monetization surface inside a mini app uses StoreKit, and that the receipts are validated against Apple's servers, not the mini-app developer's.
The Send Consumption Information endpoint. When a user requests a refund on a mini-app purchase, your host app has to forward consumption data to Apple's consumptionRequest endpoint so the refund decision is informed by actual usage. This is the same endpoint major subscription apps already use, but mini-app marketplaces have to implement it more rigorously because the consumption signal often comes from the mini-app developer's analytics rather than your own.
The implementation cost for a small team is meaningful. If you're building a mini-app marketplace from scratch, expect 6-10 weeks of integration work to hit all four requirements cleanly. If you're retrofitting an existing host app, the timeline depends on how clean your IAP plumbing already is.
When the program makes sense for indie devs#
Most indie iOS developers should not chase the Mini Apps Partner Program. If your app is a productivity tool, a game, a journaling app, a fitness tracker, or any other primarily-first-party experience, the program is irrelevant — the commission you pay on your own IAPs isn't governed by it.
The program makes sense in three specific archetypes:
You're building a creator marketplace where creators ship interactive content. A platform for indie game developers, an interactive-fiction marketplace, a learn-to-code platform with embedded student projects — these are mini-app shapes. The 15% rate gives you headroom to take a meaningful platform fee from creators while leaving them more revenue than competing platforms typically allow.
You operate a developer tools or no-code platform with embedded apps. If your no-code product lets users publish small apps that other users can run inside your host, those embedded apps are mini apps, and the program applies. This is the closest fit to the Asian super-app pattern in the Western indie market.
You're building a vertical super-app. A finance app that hosts third-party budgeting tools, a health app that hosts third-party meditation programs, a parenting app that hosts third-party child-development modules. The vertical super-app is rare in the West but increasingly funded; if you're shipping in this category, the program's economics are part of your fundability story.
For most other indie shapes — solo dev with a single app, two-person studio with a few apps, agency shipping client work — the program adds operational overhead without changing the unit economics of your business, and the right move is to skip it.
How to actually apply#
Once you've decided the program fits, the application path is predictable. You log into App Store Connect, navigate to the Mini Apps Partner Program section under Agreements, Tax, and Banking, and submit an application that includes a description of your host app's mini-app surface, the categories of mini apps you'll host, your moderation policy for third-party content, and your plan for implementing the four required APIs.
Apple typically responds in 2-4 weeks. Approval comes with a separate addendum to your developer agreement that governs the mini-app surface; pay attention to the moderation provisions, which include a fairly aggressive takedown obligation for mini apps that violate the standard App Store guidelines. You're effectively running a small App Store inside your app, with the same content responsibilities Apple has at the platform level.
After approval, the technical integration begins. The cleanest sequence is: implement the In-App Purchase plumbing first, layer in the Advanced Commerce API for catalog management second, wire in the Declared Age Range API third, and finish with the Send Consumption Information endpoint. Apple's developer relations team usually offers a kickoff call for approved partners, and the call is worth taking — the implementation guidance evolves quickly and the docs lag behind the actual review expectations by a few months.
Practical takeaways#
If you're considering the Mini Apps Partner Program, three things determine whether it's worth your time:
First, model the revenue. Take your projected mini-app GMV for the next 12 months, multiply by 0.15, and compare it to the engineering cost of the four required APIs. If the savings versus the standard 30% rate doesn't comfortably exceed two engineer-quarters of work, the program isn't worth the operational overhead.
Second, audit your moderation capacity. Hosting third-party experiences means hosting third-party content quality issues, and Apple's program addendum gives you very little wiggle room on response times for guideline violations. If you don't have someone whose job is content review, the program will quietly become that person's full-time problem.
Third, plan the migration. If your host app already exists and already monetizes its own content, splitting first-party and third-party purchases into the right commission tiers is a meaningful StoreKit refactor. Don't underestimate the QA cost of getting the receipt routing right.
Where Stora fits#
Stora's submission pipeline handles the App Store Connect side of mini-app marketplaces — the host app's metadata, the privacy disclosures around third-party content, the screenshot generation that has to communicate the marketplace pattern clearly to App Review. The compliance engine flags the most common rejection reasons specific to host apps (unclear third-party-content disclosures, missing parental controls on age-gated mini apps, IAP routing inconsistencies), which are the exact issues that delay approvals for first-time program applicants. The platform doesn't write your Advanced Commerce integration — that's still your engineering team's job — but it gets you through the review and listing surface around it without the usual back-and-forth.
If the Mini Apps Partner Program fits your roadmap, the application is the easy part. The implementation is where most teams stall, and it's where shipping cleanly matters most.