Plan limits, catalogs, build credits, and allowances
Current customers stay on legacy_v1; launchlayer_v2 is an unpublished proposal until prices and backend enforcement are connected.
What this does
Centralizes plan entitlements and separates project, QA, approval, package, build-credit, and future push allowances.
What you need
An active subscription and the catalog version attached to it.
What LaunchLayer automates
Current UI reads enforced legacy allowances from one catalog; missing subscription versions resolve to legacy_v1.
What remains external
V2 prices, payment catalog records, add-ons, and migration decisions.
Exact setup steps
No action for existing customers; no silent migration occurs.
How to verify it
Compare pricing, meters, prompts, checkout, and server authorization against the same catalog before enabling V2.
Common failures
Hardcoded pricing drift, showing unenforced features, unmetered macOS builds, or silently downgrading legacy users.
Security considerations
Backend authorization—not pricing-page text—must enforce every sensitive entitlement.
Related articles
Cloud Build stages; security and ownership.