Host-App Package Budget
also called Mini-App Size Ceiling, Embedded App Package Limit
The hard size ceiling a super-app platform imposes on code shipped inside it - the price of escaping app-store review, and a constraint that shapes the architecture rather than the build pipeline.
Shipping inside a host application removes the three costs of the mobile release cycle at once: review latency on every change, a population that updates when it feels like it, and old versions live forever. Your code is content the host fetches rather than a binary a store distributes, so a fix reaches everyone in minutes.
The bill is a size ceiling, and it is not a guideline. Tencent's WeChat Mini Program documentation states that a single package - including the main package - cannot exceed 2 MB, that all subpackages together must not exceed 30 MB (20 MB where a service provider develops on another company's behalf), and that pages within one package share a 2 MB pre-download limit.
Why it matters
Teams first meet the number as a build failure and try to compress their way out. It is a permanent allocation problem: a feature that cannot fit without pushing something out now competes with existing screens for space.
The split boundaries also become user-visible latency. A subpackage is fetched on navigation, so a boundary in the wrong place turns a tap into a download - and pre-download, which hides that, has its own 2 MB ceiling.
And you traded one dependency for another: you now depend on a host platform's review, API surface, runtime and commercial terms.
Implementation patterns
- Budget per package, with a byte allowance and an owner.
- Split along navigation, not team boundaries, so a package matches a journey and a fetch lands at a natural pause.
- Keep the main package to the entry journey - launch, home, authentication.
- Move assets onto a CDN, treat shared libraries as a tax paid per package, and pre-download the next likely package during a pause from measured navigation paths.
- Assert the budget in CI, because a ceiling found at submission is found too late.
Industry example
WeChat Mini Programs are the developed version of this model and the one with published numbers, and the platform provides subpackage loading as the mechanism for living inside the limits above.
The resulting architecture is consistent across mini programs: a small entry package, journeys split into subpackages fetched on navigation, nearly all media held remotely, and server-driven content wherever a screen's shape might change. That last point is the interesting one, because the size constraint pushes teams toward describing screens as data rather than shipping more code - the same move a native app makes to escape store review, reached for a different reason.
Failure scenarios
- A package at 1.9 MB, where the next feature cannot ship until something is removed.
- A split along team lines, so one journey crosses three packages and the user waits three times.
- Assets inside packages - the usual reason a budget is exhausted.
- A host API change you depend on, with no host version you can pin.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Ship inside a host application | minutes to a fix - no store review - no old versions of your code in the field | a hard per-package ceiling - a runtime you do not control - policy risk |
| Native app through the stores | full platform access - no ceiling - a direct user relationship | review latency on every change - a version long tail forever - no reverse gear |
When not to use it
When the product needs platform capability the host does not expose - background location, a persistent connection, custom cryptography, high-performance rendering. If any is central, the ceiling is the smaller problem.
When the host's user base is not your market. The value is that distribution comes free with somebody else's installed base; without that overlap you accepted every constraint and bought nothing.
And when a simpler mechanism solves the complaint. If the pain is that a screen cannot change without a release, server-driven UI in your own native app gets most of that benefit without surrendering the runtime.
Interview question
Q: Your native app takes two weeks from merge to a user's device and you have a weekly-changing promotional journey. Someone proposes rebuilding it inside a super-app with a 2 MB per-package ceiling. How do you evaluate that, and what would you propose instead?
What a strong answer covers: separating the two things being bought - distribution reach versus release cadence - and testing which is the actual complaint · that if it is cadence alone, server-driven UI in the existing app delivers it without surrendering the runtime · what the ceiling does to architecture, since 2 MB per package forces splits along navigation and badly placed splits turn taps into downloads · and that the condition justifying it is the host's installed base being your market.
Quick check
Quiz: What does a 2 MB per-package ceiling in a host application actually constrain? — The architecture, not the build. It decides how many screens share a package and what a cold open must fetch; a badly placed split converts a tap into a download.
Flashcard: When is a mini program inside a super-app the right answer rather than server-driven UI? — When the host's installed base is the distribution you need. If only cadence is the problem, server-driven UI in your own app achieves it and keeps the runtime.