User Roles & Permissions
Least privilege principle: give product/operations/development/finance only the permissions they need to avoid mistakes and security risks. The fewer permissions granted, the fewer incidents.
Main Roles
| Role | Scope | Typical member |
|---|---|---|
| Account Holder | Sole holder: sign agreements, manage banking/tax, add members | Founder / owner |
| Admin | Almost everything except signing agreements (incl. managing members) | Tech lead |
| App Manager | Manage versions, IAP, TestFlight for specific apps | Product manager |
| Developer | Upload builds, manage TestFlight, view technical data | iOS engineer |
| Marketing | Access App Analytics and sales data; cannot change versions | Ops / marketing |
| Finance | Access financial/payment reports | Finance |
| Cloud Managed Distribution | Access to distribution certificates for Xcode automatic signing | CI / auto-signing |
Roles can usually be scoped to specific apps or account level: for example, give an engineer Developer access to one app only rather than the whole account. Using “App scope” tightens permissions further.
Inviting Members
- Go to Users and Access → ”+” → Invite User.
- Enter email and name.
- Choose a role and set App scope (all apps / specific apps).
- Optionally toggle finance access, cloud signing, and API key access.
- Members accept the invitation email to activate.
Sandbox Accounts
In “Users and Access → Sandbox” you can create sandbox test accounts for testing IAP/subscriptions:
- Sandbox accounts are independent test identities; they don’t affect real Apple IDs.
- To test IAP, sign out of the real account on the device, then sign in to the App Store with the sandbox account.
- Sandbox accounts are limited; delete and recreate as needed.
Best Practices
- Agreements, tax, and banking only for Account Holder / Admin to avoid exposing sensitive info.
- Use dedicated machine accounts for build uploads (CI account instead of personal accounts) to reduce sensitive email exposure.
- Revoke permissions for departing members regularly, and enforce Two-Factor Authentication (2FA).
- Use App Store Connect API keys instead of shared passwords: create independent keys for CI/scripts and revoke them anytime.
- Keep an audit mindset for high-risk operations (member management, agreement changes).
Self-Check List
- Each member has the least privilege role
- Finance, tax, and banking access limited to necessary people
- CI uses a dedicated account/API key, not a personal account
- Two-Factor Authentication enabled
- A departing-member permission recovery process exists
FAQ
- Locked out / insufficient permission? Ask an Admin to check the role; some operations (signing agreements) can only be done by Account Holder.
- Member didn’t receive the invite? Check email and spam; confirm the email isn’t already used by another developer account.
- Can I change the Account Holder? Yes, but only the current Account Holder can do it, and it involves agreement/tax transfer — be very careful.
PreviousApp Store Connect Interface OverviewUnderstand the main modules of App Store Connect — home, My Apps, TestFlight, App Analytics — and quickly locate common entries.
NextCertificates & SigningUnderstand the relationships among certificates, App IDs, devices, and provisioning profiles, and master iOS code signing and common error troubleshooting.