App Store Connect roles explained: who can do what
Eight roles, and only three of them matter for shipping. App Manager is the role that can do the work of releasing an app without being able to touch people, money or legal agreements, which makes it the correct answer for almost every tool and almost every teammate. Admin adds user management. Account Holder is the one human who signs things.
If you are here because a build server or a submission tool is asking which role to give an API key, the short answer is App Manager, and the reason is in the section on least privilege below.
The eight roles
Apple's role list for the Apple Developer Program, as written in App Store Connect:
Account Holder. One person. Renews the annual membership, accepts legal agreements on behalf of the organisation, approves banking changes, and initially adds Admins to the team. Has every permission. This is the role that unblocks the Paid Applications agreement, which is why an unsigned agreement can only ever be fixed by one specific person.
Admin. Full access to most features, and the role that manages users. Apple notes an Admin "can add Developer or Marketing users and grant access to apps they have permission to view". Admin does not independently manage business agreements; that stays with the Account Holder.
App Manager. The shipping role. It can create app records, upload builds, create and submit app versions, edit App Store details and App Clip details, manage pricing and availability, manage in-app purchases and in-app events, manage TestFlight builds and external groups, and manage Game Center and promo codes. It gets read-only access to app analytics.
Developer. A signing and build role, not a publishing one. It submits certificate signing requests, creates and revokes development certificates, creates and deletes development provisioning profiles, registers and configures App IDs, adds and disables UDIDs, downloads provisioning profiles, and uploads builds. Critically, it has read-only access to the apps section of App Store Connect.
Marketing. Edits App Store details, edits app pricing and availability, responds to app privacy questions, creates and edits in-app events, manages promo codes and promo art, views ratings and reviews, responds to customer reviews, and views app analytics and sales and trends. It cannot upload a build.
Finance. Views payments and financial reports and sales and trends reports, uploads tax forms, and gets read-only app analytics. Needs the separate access to reports granted in Users and Access.
Sales. Edits app pricing and availability, views app analytics, views sales and trends, and can respond to App Review.
Customer Support. Views ratings and reviews, responds to customer reviews, can Report a Concern, can respond to App Review, and gets read-only app analytics.
The distinction that trips people up
Developer sounds like the most powerful role and is one of the weakest inside App Store Connect. It is a certificates-and-builds role.
A Developer can push a build to App Store Connect. A Developer cannot edit the description, replace a screenshot, change the price, or submit the version for review, because their access to the apps section is read-only. This is why a new hire says "the upload worked but I cannot see the Save button", and it is not a bug.
App Manager is the inverse of that in one respect: it can do all the listing and submission work, and it also uploads builds, but it cannot invite people or read the money.
The narrow permissions worth knowing
A few capabilities are attached to more roles than you would guess, and it is these that let you avoid handing out Admin.
Age rating. Apple states the required role for setting an app age rating is "Account Holder, Admin, App Manager, or Marketing." Marketing is on that list, so a non-engineer can complete the questionnaire.
Adding internal TestFlight testers. The required role is "Account Holder, Admin, App Manager, Developer, or Marketing." Developer is on that list, so a developer can wire up internal testing without escalation.
Rejection notifications. Apple's definition of the Rejected status says App Review "notifies App Store Connect users with the Admin, App manager, or Developer role with the issues." If the person who needs to act on rejections is a Marketing user, they will not get the email. Give them App Manager or forward it.
Responding to App Review. Sales and Customer Support can respond to App Review, which is unexpected but useful in a support-heavy team.
Additional access, separate from the role
Two toggles sit alongside the role rather than inside it, and forgetting them produces failures that look like the role is wrong.
Access to Certificates, Identifiers & Profiles is granted per user in Users and Access, and Admin, App Manager and Developer all need it for certificate work on an organisation team. Access to Reports is what actually lets a Finance user download the reports their role implies.
The least-privilege choice for an API key
An App Store Connect API key is created under Users and Access → Integrations → App Store Connect API, and at creation you assign it an access level from the same family of role names. Two rules shape the decision, and both are unforgiving.
Rule one: a key's role cannot be changed after it is created. If you pick wrong, you create a second key and swap the credentials over. There is no edit.
Rule two: a team key cannot be scoped to one app. There is no per-app restriction on App Store Connect API keys. A key with App Manager can read and write metadata, upload and manage builds, invite TestFlight testers and submit versions across every app on the team. This is the single most important thing to understand before you paste one into a CI provider.
Given that, here is how to choose:
For a CI pipeline that only uploads builds and manages TestFlight: Developer is tempting, because it uploads builds. It is usually the wrong answer anyway, because the moment the pipeline is asked to also set "What to Test" text, manage external groups or submit anything, it fails with a permission error rather than a clear message. If your pipeline genuinely only uploads and you will never extend it, Developer is the tighter grant. If it will ever touch TestFlight groups or submissions, use App Manager and stop fighting it.
For a submission or listing tool: App Manager. It covers metadata, screenshots, versions, builds, TestFlight, submitting for review and replying to customer reviews, and it stops short of user management, agreements and finance. That is the honest least-privilege line for a tool that ships apps.
For a reporting or analytics job: Finance, or a role limited to reports. There is no reason for a script that pulls sales data to be able to submit a version.
For anything: not Admin. A key with Admin can manage your team's people. Nothing about uploading a build needs that.
Who can create a key
You need to be the Account Holder or an Admin to create a team key. If the Integrations tab is not visible to you, that is why, and no amount of clicking elsewhere will reveal it.
Team keys act as the team with the role you assigned and survive people leaving. Individual keys act as the user who made them and inherit that person's permissions, so they die with the account. For anything a second person will ever touch, use a team key.
A workable team layout
For a small team, the arrangement that produces the fewest surprises:
- One Account Holder, the person who can legally sign for the company
- One or two Admins, so nobody is locked out when someone is on leave
- Everyone who ships gets App Manager
- Contractors doing device and certificate work get Developer
- Whoever writes the listing and answers reviews gets Marketing if they should not be able to submit, App Manager if they should
- Finance for the accountant, with access to reports ticked
- One App Manager team key per automated system, named after that system
That last line is the one people skip. One key per system, named after the system, so that revoking a leaked credential takes down one pipeline rather than everything at once.
AppSubmit asks for an App Manager key for exactly the reasons above, and verifies it against Apple the moment you paste it, so a Developer key fails at the connection screen instead of halfway through a submission. The key is created in your account and you can revoke it without asking anyone.