How Should You Structure Your App Store Connect Account?

App Store Connect is the kind of thing you set up once, under pressure, with a launch deadline looming, and then live with the consequences of for years. The decisions made in those first few minutes, who holds the account, what roles get assigned, how testing groups get organised, shape everything that follows. Get them right and the account becomes a quiet, reliable backbone. Get them wrong and you spend the next twelve months fighting the structure you created.

The decisions made in those first few minutes shape everything that follows, and undoing them later is rarely straightforward.

The social football product we worked on is a good example of this. The client registered the App Store Connect account in their own name, which made sense at the time. We were given admin access to the majority of the account and set up three internal testing groups: one for our team, one for the client, and one external QA beta test group for their testers. That structure worked well during development.

But as launch approached, the client started going into the account and manually sending already-uploaded builds to whichever group they wanted, bypassing the process we had built. Because the account was theirs, they had the access to do it. We had limited ability to prevent it, and it caused problems.

That experience is not unusual. Account structure decisions feel administrative until they are not. This article walks through how to set up App Store Connect so that the structure serves the product rather than complicating it.

The Two Account Models: Personal and Organisation

Apple offers two types of Apple Developer Program membership: Individual and Organisation. The Individual account is registered to a single person using their personal Apple ID. The Organisation account is registered to a legal entity, a limited company, partnership, or incorporated body, and requires a DUNS number to verify the organisation's existence.

For any serious commercial product, the Organisation account is the right choice. An Individual account ties the entire programme to one person's Apple ID and personal identity. If that person leaves, changes their name, or loses access to their account, the entire programme is at risk. An Organisation account belongs to the business, not the person who set it up.

There is also the Apple Developer Enterprise Program, which costs $299 USD per year and is built for internal distribution rather than public App Store release. Most founders and studios will not need it, it exists for companies distributing proprietary apps to their own employees, not for consumer-facing products.

Who Should Be the Account Holder?

The Account Holder role in App Store Connect carries more weight than most people realise. This is the person or entity with full control over the account: they can add and remove team members, manage contracts and tax agreements, and access every part of the programme. Critically, only one person can hold this role, and transferring it requires deliberate action through Apple's support process.

For a client-owned product, the account should be registered to and held by the client's legal entity. This seems obvious, but we have seen projects where a developer or agency registers the account in their own name as a convenience, creating a dependency that becomes painful when the relationship ends. The client then has no direct access to their own product's distribution infrastructure.

Register the account under the client's legal entity from day one, even if setup takes a little longer. Transferring account ownership later requires going through Apple support and is far more disruptive than doing it properly at the start.

For a founder building their own product, the account should sit under their company rather than their personal Apple ID, unless the product is a genuine solo side project with no commercial ambitions. A personal Apple ID is fine for prototyping. It is not the right vehicle for a business.

On the social football product, the client was already incorporated, and the account sat in their name from the start. That part of the structure was correct. The problems came elsewhere, as we will come to.

Team Roles and What Each One Actually Controls

App Store Connect uses a role hierarchy to determine what each team member can see and do. Understanding where the boundaries sit saves a lot of confusion during development and testing.

Role boundaries are about structure, about giving each person exactly the access the work requires.

The main roles are roughly as follows. The Account Holder has unrestricted access. Admins have almost equivalent access, minus some legal and financial controls. App Managers can manage specific apps but cannot access financial data or add team members. Developers can upload builds and manage TestFlight, but they cannot submit to the App Store or see revenue. Finance roles give read access to financial reports without touching the product itself. Marketing roles allow access to metadata and screenshots but nothing operational.

Give developers the Developer role, not Admin. They need to upload builds and manage TestFlight. They do not need to see revenue data or alter App Store metadata, and giving them Admin access creates unnecessary exposure.

On the social football project, we were given admin access to the majority of the account. That was appropriate for the scope of work we were doing, but it is worth being deliberate about this rather than defaulting to Admin for everyone involved. A clean role structure limits what can go wrong if someone acts outside the process, even accidentally.

Setting Up Testing Groups Without Losing Control

TestFlight is Apple's official beta testing tool and it sits inside App Store Connect. It supports two types of testers: internal testers, who are members of your App Store Connect team, and external testers, who are invited via email or a public link. According to Foresight Mobile, TestFlight supports up to 10,000 external testers, which is more than sufficient for most pre-launch testing programmes.

The practical approach we use is to set up distinct groups rather than adding everyone to a single pool. On the social football product, we created three groups: one for the WAA team, one for the client's internal team, and one external QA group for the client's nominated testers. Each group received specific builds at specific points in the process. The intent was that new builds went through our group first, then the client's group, then external QA, a structured flow that kept control with the people responsible for quality.

The problem that emerged on that project was that the client, having admin access to their own account, started going directly into App Store Connect and manually distributing uploaded builds to whichever group they wanted. Because the account was theirs, there was no technical barrier to this. The group structure we had built was a process, not a permission, and when the client bypassed the process, the structure offered no protection.

Document the testing process clearly and agree it with the client before any builds go up. A TestFlight group structure only works if everyone involved understands the flow and agrees to follow it. Without that agreement, the groups are labels, not controls.

Managing Multiple Apps Under One Account

App Store Connect allows you to manage multiple apps under a single Organisation account, which is the normal arrangement for any studio or company with more than one product. Each app is listed separately in App Store Connect, with its own metadata, its own TestFlight groups, its own review submissions, and its own sales data.

Team roles apply at the account level by default, but App Manager roles can be scoped to specific apps. This means you can give a team member full control over one app without giving them access to everything else on the account. For agencies managing multiple client apps under one account, which is a structural choice worth thinking through carefully, this scoping becomes relevant.

The more common question for founders is whether to put multiple apps under one developer account or create separate accounts. The practical answer is one account, unless there is a genuine business reason to separate them. Separate accounts mean separate Apple Developer Programme memberships, separate tax agreements, and separate review histories. The overhead is real and the benefit is rarely worth it. If the apps are owned by different legal entities, that is a legitimate reason for separate accounts. If they are all owned by the same company, one account is cleaner.

Revenue Reporting and Financial Visibility

App Store Connect's financial reporting tools are more granular than many people expect. Sales and Trends gives you download counts, re-downloads, and revenue broken down by app, territory, and time period. Payments and Financial Reports gives you the actual payment records, the exchange rates applied, and the tax withheld by territory. These are the numbers that matter when you are trying to understand whether a product is generating what you expected.

Access to this data is role-controlled. Finance roles exist specifically to give someone visibility into revenue without operational access. If your accountant or CFO needs to see App Store earnings, the Finance role gets them in without handing them control of the product. This is worth setting up properly rather than sharing credentials informally.

On the social football product, because the account sat with the client from the start, financial visibility was always theirs by default. That is the right arrangement. Where it becomes complicated is when an account is registered in a developer's or agency's name and the client needs revenue data, they either have to ask for it, or they need to be given a role on someone else's account, which creates its own awkwardness.

When Clients Override Structure: A Real Consequence

The social football project shows what happens when account access and process control become misaligned. We had built a three-group TestFlight structure and a clear deployment flow. Builds went to the WAA group first, then the client group, then external QA. The logic was straightforward: we needed to validate builds before they reached anyone outside the core team.

As the project moved toward launch, the pressure increased and the client's patience with the structured process shortened. They started going into App Store Connect directly and distributing already-uploaded builds to whichever group they felt should have them. Because the account was registered in their name and they held the Account Holder role, they had the access to do this. We had admin access, but admin access does not give you the ability to restrict the Account Holder.

The consequence was that builds reached external testers before they had gone through our QA process. Feedback came back on issues we had already identified and were fixing. Some of that feedback created confusion about the state of the product. The client's confidence in the build was affected by seeing issues that were already on our list.

This is an argument for agreeing the process clearly, getting alignment on who distributes builds and when, and building that agreement into the project documentation before a single build is uploaded.

Mistakes That Cause Problems at Scale

The mistakes that create the most trouble are the small structural decisions made at the start that compound over time.

1. Registering the account under an individual rather than a legal entity, then needing to transfer it when the business structure changes.
2. Giving everyone Admin access because it is easier than thinking through roles, then finding that multiple people have made conflicting changes to metadata or TestFlight groups.
3. Mixing client apps under an agency's account rather than helping the client set up their own, then facing a painful separation when the engagement ends.
4. Using Ad Hoc distribution for testing rather than TestFlight, hitting the 100-device-per-year ceiling at an awkward moment and having to revoke devices to add new ones.
5. Setting up a single TestFlight group for all testers, losing the ability to control which build reaches which audience at which point in the process.

The Ad Hoc limit is the one that catches people most often. Foresight Mobile confirms the 100-device annual ceiling, and it resets once per year, not on a rolling basis. If you exhaust your allocation in the first quarter, you are limited until the anniversary of your programme membership. TestFlight does not have this constraint and is the right route for most testing scenarios.

Transferring or Restructuring an Account Later

Apple does allow App Store Connect account restructuring, but it is not a quick process. Transferring individual app records between accounts is possible and is the cleaner route when a single app needs to move, for instance, when a client takes full ownership of a product after a development engagement ends. The transfer preserves the app's review history, ratings, and download data.

Transferring the Account Holder role is a separate process. It requires contacting Apple Developer Support and going through identity verification. It is not something you can do in a few minutes, and it cannot be done under deadline pressure without risk.

The lesson from the social football project and others like it is that the account structure should be decided before any development work begins, not after it. Who holds the account, who has admin access, and what happens to the account when the engagement ends, these are contractual and structural questions that belong in the project scoping conversation, not in a late-night email exchange as launch approaches.

Agree on account ownership and access in writing before any builds are uploaded. Include a clear statement in the contract about what happens to App Store Connect access if the working relationship ends. Apple's processes move slowly, and a disputed account during a live product crisis is a serious problem.

Conclusion

App Store Connect structure is one of those topics that feels secondary until it becomes primary. The decisions are straightforward when made deliberately, and they are expensive when made carelessly or not at all. Register under a legal entity. Assign roles that match the work each person actually does. Build TestFlight groups with a clear deployment flow, and get everyone's agreement on that flow before builds start going up.

The social football project taught us something concrete about the gap between technical structure and human process. We built a sensible three-group testing system. The system worked until the client had a reason to bypass it, and because the account was theirs, bypassing it was straightforward. The answer to that problem is an agreed process, documented and signed off, so that everyone understands why the structure exists and what happens when it is not followed.

If you are setting up App Store Connect for the first time, do it properly now. If you are inheriting an account that was set up in a hurry, audit it. Check who holds the account, what roles everyone has, and whether the TestFlight groups reflect how the team actually works. Small corrections made early are far simpler than restructuring a live product's distribution infrastructure under pressure.

If you would like help thinking through how to structure your App Store Connect account or a broader mobile product, let's talk about your project.

Frequently Asked Questions