Developers who scale on Google Play with a fleet of accounts often assume the same playbook works on iOS — open several Apple developer accounts, split the apps, and publish. That assumption is wrong, and it ends with frozen accounts and apps pulled from the store. Under the Apple Developer Program License Agreement, the membership is personal and non-transferable and belongs to one legal entity. The App Store version of an app matrix is therefore built inside a single account: one membership, one team, many apps. This tutorial walks through the six steps that make that structure work in 2026.
Step 1. Choose the right account structure before you scale
Your enrollment type decides how far the portfolio can grow. An Individual program account is tied to one person and is the wrong base for a multi-app business. Enroll as an Organization instead — the membership belongs to the legal entity, you can add team members with separate roles, and the account survives staff changes. Two rules from the Program License Agreement matter more than anything else:
- Do not share or rent the account. The license is personal and non-transferable — a shared or traded account is a termination risk, and Apple reviews accounts involved in such patterns.
- Keep the Account Holder seat with the owner. The Account Holder is the only role that signs legal agreements and renews the membership, so it must stay with someone you control.
Step 2. Split responsibilities with App Store Connect roles
Apple's role permissions let a growing team work on the same membership without everyone holding full control. Map your portfolio ops onto these roles:
- Account Holder — the person who completed enrollment; signs agreements, renews membership, and is the only role allowed to request App Store Connect API access.
- Admin — secondary contact with access to all apps; the natural deputy when the Account Holder is not available.
- App Manager — runs pricing, App Store information, and app development and delivery for individual apps. This is the day-to-day owner of each product in your portfolio.
- Developer — manages development and delivery only; no store metadata, no pricing.
- Finance — downloads reports and uploads tax forms, and can view all apps in Payments and Financial Reports, Sales and Trends, and App Analytics.
- Marketing / Sales / Customer Support — marketing materials, analytics, and review responses respectively.
Practical split: one App Manager per app (or per app family), a single Finance user for tax and payout reports, and Account Holder access locked to the owner. Never hand App Manager rights to freelancers who should only get the Developer role.
Step 3. Register Bundle IDs with portfolio discipline
Every app needs a globally unique Bundle ID in reverse-DNS form (for example com.yourcompany.rummy). Three rules keep a multi-app portfolio clean:
- One Bundle ID per app, per platform — never reuse an ID for a second product.
- Bundle IDs are never reusable once registered — deleting an App ID does not free the identifier, so pick names you can live with for years.
- Keep a registry: app name, Bundle ID, App ID capabilities, and which team member manages it. With ten or more apps this registry becomes your source of truth.
Step 4. Design the portfolio to survive App Review
This is where portfolios die. Apple's App Review Guidelines section 4.3 Spam is unambiguous:
- Do not create multiple Bundle IDs of the same app. Apple's own example: a separate map app for every city instead of one worldwide map — that pattern results in "unnecessary apps" and is rejected.
- Do not submit apps indistinguishable from what is already widely available. Opportunistic variants of popular apps degrade discovery; "repeated submissions of this kind may lead to removal from the Apple Developer Program."
- If your product needs regional or tiered variations, ship one app and offer the variations through in-app purchase, which is the path 4.3 explicitly recommends.
Every app in the portfolio must also pass 2.1 App Completeness: final versions only, no placeholder text or empty websites, tested on-device, and a working demo account with the backend live during review. A portfolio multiplies the review surface — one sloppy submission can flag the whole account.
Step 5. Build a cross-app release pipeline with TestFlight
Testing many apps at once needs structure, and Apple's TestFlight has the limits you plan around:
- Up to 100 builds per app, with multiple builds testable at the same time.
- Up to 100 internal testers (team members with Account Holder, Admin, App Manager, Developer, or Marketing roles) — no beta review, builds available almost immediately.
- Up to 10,000 external testers, each install on up to 30 devices; external builds need a beta app description plus beta app review, and each new build passes a quick Beta App Review.
- Use groups to attach different builds to different tester sets — per-app QA teams, feature rounds, or platform-specific test groups.
On the store side, give every app its own record in App Store Connect (name, SKU, Bundle ID), its own App Privacy labels that match the code's actual data collection, and its own localization set. The portfolio should reuse tooling — not metadata.
Step 6. Operate the portfolio as one business
- Finance: have the Finance role pull Payments and Financial Reports and Sales and Trends for all apps, and keep tax forms for the single entity up to date — one set of forms covers the whole portfolio.
- Analytics: App Analytics per app, compared side by side; a new app that underperforms its siblings is usually a store-listing problem, not a code problem.
- Reviews: the Customer Support role responds to App Store reviews — respond on all apps, not just the flagship.
- Watch the 4.3 risk: every time you plan a new app, ask "is this meaningfully different from what is already on the store?" If the honest answer is no, rethink the product instead of resubmitting a variant.
The one-line takeaway: on the App Store the matrix lives inside one account — enroll as an Organization, split work with App Store Connect roles (Account Holder locked to the owner), keep Bundle ID discipline, design each app to pass Guideline 4.3 rather than clone a winner, and standardize release with TestFlight groups. That structure scales to dozens of apps without tripping Apple's spam rules.