Apple’s new Mini Apps Partner Program trims the Apple mini apps commission to 15% for qualifying in‑app purchases. Announced on November 13, 2025, it formalizes something many teams have been experimenting with for years: self‑contained web experiences (HTML5/JS) distributed inside a native iOS host app. If you run a marketplace, a platform, or a game hub—and you embed partner experiences—this isn’t a theoretical policy tweak. It’s a structural change to your unit economics, your review flow, and your compliance roadmap.
What Apple actually changed on November 13, 2025
Apple introduced a formal program for apps that host mini apps and mini games—web‑based experiences added after installation and executed on device. Program members earn 85% of qualifying mini app in‑app purchase sales (that is, a 15% commission to Apple) when they meet specific requirements.
Those requirements are concrete:
• Your host app must be live on iOS and iPadOS and offer mini apps that comply with App Review Guideline 4.7, including a manifest listing each hosted mini app’s metadata.
• You must integrate the Advanced Commerce API to merchandise and transact digital goods within mini apps and the Declared Age Range API to align experiences with user age ranges.
• Purchases must run through Apple’s in‑app purchase system, and you’ll send consumption info via the App Store Server API when a user requests a refund.
Two subtle but crucial definitions sit under the headline:
• A qualifying mini app is created by an entity you don’t directly or indirectly control.
• A qualifying mini app purchase includes consumables, non‑consumables, and subscriptions bought and used within a single mini app. Importantly, consumables can’t be shared across mini apps.
Translation: if you operate a platform that curates third‑party micro‑experiences, Apple is incenting you to do it “the right way” on iOS, with clear age gates, proper SKUing, and purchase transparency.
How the Apple mini apps commission works
Here’s the practical model product and finance teams should plan around:
• Commission: 15% on qualifying mini app in‑app purchases when you’re approved for the program and implement required APIs.
• Scope: This is about digital goods and services sold inside mini apps through the Advanced Commerce API. Physical goods remain outside IAP, as usual, and won’t be part of this program’s economics.
• Who pays Apple? The host developer remits the commission to Apple on qualifying transactions; commercial terms between you (host) and each mini app creator are up to your private contracts.
• Compatibility with other Apple programs: You can participate in the Mini Apps Partner Program while in other programs (e.g., the Small Business Program). The mini app benefit itself pegs qualifying purchases at 15%.
One operational implication: program‑eligible mini app SKUs aren’t managed in App Store Connect the way your main app’s IAPs are. You’ll define and operate them through the Advanced Commerce API, with extra metadata so Apple can attribute what’s being sold, by which mini app, to which user age range.
Is it worth building a mini app strategy now?
Short answer: if you’re a platform with user‑generated experiences, a marketplace that curates third‑party vendors, or a game publisher with micro‑titles, yes—evaluate immediately. The policy cements a financially viable path to host partner experiences on iOS without rewriting every idea as a full native app. It also aligns with user behavior: people love lightweight experiences that open quickly, feel safe, and don’t require new installs.
When it’s a clear win:
• You already run a web‑first catalog of partners (events, creators, minigames, education modules) and can package them as HTML5/JS.
• You need fast iteration across hundreds of experiences, where App Store binaries as the only distribution channel would bottleneck releases.
• You benefit from a shared shell (accounts, safety, payments, moderation, analytics) while letting partners ship content.
When to be cautious:
• You sell cross‑experience currency. Apple’s rules prohibit sharing consumables across mini apps. That complicates economy design.
• Your partners insist on non‑IAP payment rails for digital goods. That’s incompatible with the program.
• Your content relies heavily on platform‑specific native APIs; a web mini app may struggle to match the experience.
What this changes for product, engineering, and legal
Product managers get leverage: more ideas shipped without binary churn. Engineering teams inherit platform responsibilities: a robust Advanced Commerce API layer, a manifest pipeline, and refund telemetry. Legal and trust & safety teams get clearer rules: age alignment, explicit partner qualification, and a defined review surface.
Budget owners should recalibrate LTV/CAC models with 15% instead of 30% on eligible sales. That delta is material for subscription mini apps, educational modules, and in‑mini‑game consumables that don’t cross experiences.
A practical 10‑step plan to ship a compliant mini app in 60 days
Here’s the path I’d run if I were hired to stand this up fast.
1) Define the catalog and partner model
Identify 5–10 founding mini apps that aren’t under your control. Keep scope tight: one job per mini app, clear value, no cross‑app entanglements. Draft lightweight partner terms covering content standards, refund cooperation, and data sharing.
2) Design the manifest and review surface
Create a manifest generator for each mini app: name, description, developer identity, declared age range, SKU list, and technical endpoints. Make it a CI artifact partners sign off on. Your app review package will include this manifest.
3) Implement Declared Age Range API
Plumb age-range gating at the shell level so every mini app inherits it. Build a test matrix for transitions (under 13, 13–15, 16–17, 18+) and ensure UI states never leak age‑inappropriate content.
4) Implement Advanced Commerce API for mini app SKUs
Define mini app SKUs in your commerce service, not in App Store Connect. Tie each SKU to exactly one mini app. Enforce “no cross‑consumption” server‑side. Add a catalog UI for partners to request changes without redeploying your native binary.
5) Wire App Store Server API: Send Consumption Information
On refund requests, send consumption signals so Apple can adjudicate fairly and so your support team sees the same truth. Build an internal tool showing purchase, entitlement, and consumption timelines.
6) Build a per‑mini app purchase receipt view
Expose to users exactly which mini app they purchased from, what was bought, and how to cancel subscriptions. This isn’t just good UX; it reduces refunds and chargebacks.
7) Create a partner sandbox
Spin up a mini app sandbox with mocked commerce, age ranges, and error states. Provide a CLI or dashboard so partners can test entitlements, 3‑D Secure flows, and retry logic.
8) Lock down security controls
Gate mini app code by signature and origin. Use CSP with strict script‑src and connect‑src. Disallow inline scripts. Set caching budgets to avoid bloat. Audit every third‑party library partners include.
9) Stand up policy review and moderation
Borrow from App Review discipline: linters for manifest and bundle size, screenshots, contact info, and a pre‑flight privacy check. Make partner shipping predictable with a 48‑hour SLA and a status page.
10) Pilot, measure, and iterate
Ship with 1–2 categories, measure attach, conversion, and refund rates by mini app. Kill the bottom quartile ruthlessly, lean into the winners, and use the 15% economics to fund promotions.
The HOST framework: a quick readiness checklist
When executives ask “Are we ready?”, run this:
H — Host Eligibility: iOS/iPadOS app live; Guideline 4.7 compliant; manifest generator in place; partner identities verified.
O — Offer Design: Each mini app has single‑app entitlements; no shared consumables; clear cancellation paths; SKUs map 1:1 to value.
S — Safety & Signals: Declared Age Range API wired; content filters by age; refund telemetry via App Store Server API; sandbox test cases documented.
T — Transactions & Tech: Advanced Commerce API integrated; per‑mini app receipts; CSP hardened; performance budgets set; analytics segmented by mini app.
People also ask: common mini app questions
Do mini apps bypass App Review?
No. Your host app undergoes review, and you must submit a manifest of hosted mini apps. Apple expects rule‑compliant content, proper disclosures, and accurate metadata.
Who pays Apple’s commission—the host or the mini app developer?
The host developer remits commission to Apple on qualifying purchases. Your rev‑share with each mini app partner is contractual between you and them.
Can I use Stripe or my own gateway?
Not for digital goods inside mini apps if you want the program’s benefits. Purchases must run through Apple’s in‑app purchase flow via the Advanced Commerce API. Physical goods remain outside IAP.
Can a currency or subscription span multiple mini apps?
No for consumables; they cannot be shared across mini apps. Subscriptions should be scoped to a single mini app when sold through this program.
Does the 15% stack with the Small Business Program?
You can be in both programs, but the qualifying mini app purchases are already at 15% under the Mini Apps Partner Program. Don’t model additive discounts.
Mini apps vs. full native apps: how to choose
Mini apps shine when you need breadth over depth: many partner experiences, frequent updates, lower friction to ship. Full native apps win when you need heavy device integration, offline capabilities at scale, and bespoke performance.
I advise clients to map ideas across two axes—experience depth and partner count. High partner count with modest depth favors mini apps. Low partner count with deep native integrations favors a traditional app. Hybrid is common: a native core plus a curated mini app gallery.
Performance, UX, and engineering guardrails
Shipping a great mini app experience is more than policy box‑checking. Treat performance like a first‑class requirement:
• Cap bundle sizes. Target sub‑150 KB of critical JS and CSS per mini app, with async hydration.
• Avoid unbounded memory growth. Tear down iframes on navigation, cache only what you measure.
• Design for interruption. Purchases can be canceled mid‑flow; handle partial failures and delayed receipts.
• Accessibility matters. Partners must meet WCAG; your shell should enforce focus management and color contrast baselines.
Data and timelines to brief your stakeholders
• Announcement date: November 13, 2025.
• Commission: 15% for qualifying mini app in‑app purchases when you implement the required technologies and are approved.
• Eligibility: Host app on iOS/iPadOS; mini apps built with HTML5/JS; partners not under your control; purchases via Advanced Commerce API; age range alignment required.
• Refunds: You must send consumption information to support fair outcomes and reduce abuse.
• Cross‑program: May participate alongside other Apple programs; don’t assume stacked rates.
Risks and edge cases you should plan for
• Economy design: No shared consumables means your cross‑experience design might need a re‑think. Consider “status” or “progress” that’s earned across mini apps, but keep paid consumables scoped per app.
• Partner fraud: With easier distribution comes risk. Require signed bundles, run automated malware scans, and block network calls outside an allowlist.
• Refund arbitrage: Align support playbooks with Apple’s refund systems; always send consumption signals promptly.
• Analytics fragmentation: Build per‑mini app dashboards: traffic, conversion, ARPPU, refund rate, and latency—each can mask platform‑level health if you only view aggregates.
• App Review drift: Keep your manifest and screenshots current. Out‑of‑date metadata is a common rejection vector.
Where this lands in your 2026 roadmap
Expect more platforms to formalize mini app ecosystems on iOS: creators, education networks, live events, and game hubs. The 15% rate legitimizes what used to be a gray zone for economics. The teams that win will invest in partner tooling and safety as core features, not afterthoughts.
If you’re weighing whether to move early, consider the marketing upside: a curated “apps within your app” page, editorial campaigns for new mini apps, and the ability to localize category storefronts more nimbly than shipping new binaries.
Let’s get practical: What to do next
For engineering leads:
• Prototype the Advanced Commerce API and Declared Age Range API in a feature branch.
• Build a manifest CLI and validation linter.
• Add CSP, signature checks, and a partner sandbox with mocked purchase outcomes.
• Ship per‑mini app receipt and refund logs for support.
For product and ops:
• Draft partner guidelines and a two‑page revenue share template.
• Stand up a moderation queue with a 48‑hour SLA.
• Define category launch waves and set performance SLOs by category (e.g., first interactive under 2s on mid‑tier devices).
• Plan messaging and lifecycle: in‑app discovery, push, and email for new mini app drops.
For finance and legal:
• Reforecast P&L using 15% on qualifying sales, with a sensitivity range for refunds.
• Add a partner addendum covering content takedowns, chargebacks, and telemetry cooperation.
• Confirm tax handling for partner payouts by region.
Related reading and how we can help
If you’re building a platform and want a pragmatic partner to design the commerce layer, manifest pipeline, and review flow, our team at By Bowu can help. Start with an overview of what we do for product teams, browse a few representative builds in our portfolio of shipped platforms, and scope the work on our mobile and platform services page. When you’re ready, drop us a note and we’ll map a 60‑day pilot.
One more thing: web tech still matters
Mini apps are just the web, thoughtfully packaged. Your team’s web fundamentals—performance budgets, strong CSP, clean state management—will determine whether these experiences feel instant or flimsy. If you’re juggling privacy and identity work across web and app, our take on cookie realities is a helpful complement: read our perspective on why third‑party cookie timelines keep evolving and what to do.
The bottom line: Apple has given platforms a clear, lower‑friction path to host partner experiences on iOS. The winners will move fast, wire the required APIs correctly, and build the boring but essential tooling that makes hundreds of small experiences feel cohesive, safe, and trustworthy.
