Adding a second person is three invitations, and the first role most people pick cannot press submit.
You add a second person by inviting them into each account in their own name, with a role, and never by sharing your password. There are three doors, not one: your App Store Connect team, your Google Play developer account, and whatever holds the code. Apple documents eight named roles. Google documents three levels of access and a list of permissions you tick one at a time. The trap is the same on both stores. The permission that lets someone build and upload is not the permission that lets them ship. Every role name, permission name and time limit below comes from Apple's and Google's own help pages, read on 16 October 2026. A second pair of hands is also a line item in what an app costs to maintain.
What follows is which Apple role can do which job, why Google asks whether a permission is account level or app level, and how you take the access back when the work is done. One store gives you an expiry date. The other gives you three days to accept and a ten minute wait to leave.
Start hereThe short version
Work backwards from the job, then set the end date on the way in.
Write down the one thing the person is blocked on. Find the role or the permission that covers exactly that, grant it, and stop. Both consoles let you narrow access to a single app, and both have a quiet way of widening it again behind your back if you also tick reports or an account level permission.
The two consoles are not two versions of the same screen. Apple hands out named roles, and each task page in its help carries a Required role line that tells you which roles may do that one thing. Google hands out individual permissions, each marked app level, account level or both, and an admin is simply a person who holds the one called Admin (all permissions). Reading one console's answer does not give you the other's.
What roles does App Store Connect document, and which one can submit a build?
App Store Connect documents eight roles, and they are not a ladder. Account Holder is the person who completed enrolment and is responsible for entering into legal agreements with Apple. Admin is the second pair of hands with many of the same responsibilities, and sees every app. Finance manages financial information, including downloading reports and uploading tax forms. App Manager manages all aspects of an app, including pricing, App Store information and delivery. Developer manages development and delivery. Marketing looks after marketing materials and promotional artwork, and is who Apple contacts if the app is considered for featuring. Sales analyses sales, downloads and other analytics. Customer Support analyses and responds to customer reviews. Choosing one is a question about tasks, not about seniority.
The real answer is not in the role descriptions. It is in the Required role line printed at the top of each task page. Uploading builds reads Account Holder, Admin, App Manager, or Developer. Submitting an app for review reads Account Holder, Admin, or App Manager. Developer is missing from the second one. So the contractor you put on Developer can write the code, upload the binary and watch it finish processing, and then cannot click Add for Review. Nobody discovers this on a quiet Tuesday. They discover it on the day they wanted to launch.
Other jobs land in other places, and the pattern is not obvious. Adding internal testers is wider than submitting: Account Holder, Admin, App Manager, Developer, or Marketing. Internal testers also have to be users on your account, which is the other reason to invite someone properly, and a group holds up to 100 of them. Replying to a customer review is narrower and sideways: Account Holder, Admin, or Customer Support, a role that does little else. If a submission comes back refused, the person who can act is the one who could submit in the first place, so appealing a rejection needs the same role you used to send it.
Restricting someone to one app works, with a catch worth reading twice. Apple says App Manager, Customer Support, Developer, Marketing and Sales users without access to reports can have their app access limited. Admin and Finance cannot, because they view all app information by definition. Neither can anyone you granted access to reports or to Certificates, Identifiers and Profiles, since both let a person see every app anyway. Tick one app carefully, then tick reports access, and you have handed over the whole account without noticing.
The invitation itself takes a minute. In Users and Access, under People, click the plus button, enter a first name, a last name and a valid email address, assign the roles, and select the apps if the role allows it. The email does not have to be associated with an Apple Account, because the person can create one while activating. Then watch the clock, because Apple says user invitations expire 3 days after they are sent. Three days, not thirty. Send one on a Friday to someone on holiday and you will be resending it on Tuesday. Afterwards only the Account Holder or an Admin can change a user's roles or app access, so an App Manager can invite somebody and then be unable to correct the role they picked.
Apple, App Store Connect Help, role permissions, read 16 October 2026
Work backwards
What the second person needs to be able to do
Tick the jobs you are handing over. The names shown are the ones each console uses in its own documentation.
Nothing ticked yet. Start from the one job you are actually blocked on and add the rest only when someone asks for it.
Why does Google Play ask whether a permission is account level or app level?
Because Play Console is built the other way round. Google documents three levels of access rather than eight roles: the account owner, admins, and users. The owner is the first registered account in Play Console and has full access. An admin is anybody holding the permission called Admin (all permissions), and can invite users, remove them and manage their permissions. Everyone else is a user and can do neither. Instead of picking a title you tick individual permissions, and each tick has to be attached to a scope. That is where the question comes from.
Google's own wording is two short lines. Account permissions apply to all apps in your developer account. App permissions only apply to the selected app. Then the line that causes most of the confusion: some permissions are exclusively available to app or account level users only. The same ability can carry two different names depending on which level you grant it at. View financial data is app level. The account level version is called View financial data, orders, and cancellation data survey responses. View app information (read-only) is app level, and its account level twin is View app information and download bulk reports (read-only). Admin (all permissions) is the one you can set either way, per app or globally, which is why an app level admin exists at all.
Release permissions carry the same trap as Apple's, with clearer labels. Release apps to testing tracks lets somebody put a build on a testing track, and Google states plainly that it does not allow users to publish apps to production on Google Play. The permission that does is called Release to production, exclude devices, and use Play App Signing. Two separate ticks, so you can hand over the entire testing loop and keep the production button for yourself. Manage testing tracks and edit tester lists is a third tick again, as are Reply to reviews and Manage store presence.
Two things stay with the owner whatever you tick. Google says the account owner is the only person who can have a linked payments profile or reach the Payments settings page. And an admin does not need to pay the registration fee the owner paid, which is the arithmetic answer to anybody suggesting a second developer account instead. If you are going to do this more than once, build a permission group on the Permission Groups tab rather than ticking boxes again: a name, an optional access expiry date, a description only admins can see, a set of app and account permissions, and a list of members on the Users in this group tab.
Google, Play Console Help, add developer account users and manage permissions, read 16 October 2026
How do you give a contractor access and then take it back?
Access you grant is access you have to remember to remove, and the two consoles help you unequally. Google lets you set an access expiry date at the moment you invite, and again on a permission group. Without one, Google says the person has ongoing access to your Play Console account or app indefinitely. Apple documents no expiry field at invitation time, so on the App Store side the end date lives in your calendar and nowhere else. If you only read one sentence of this page, read that one before you invite a freelancer for a two week job.
Removal is a few clicks and one piece of small print. On the App Store, the Account Holder or an Admin opens the person in Users and Access and deletes them, and Apple warns that caching may take up to 10 minutes to complete, fully revoking access. Ten minutes is not a security hole on its own, but it is long enough to make you think the deletion failed and do it twice. On Google Play the owner selects users under Manage users and chooses Remove, admins can remove users as part of their permissions, and app level admins cannot remove users with global access. One more detail that saves a support thread: Google says invited users can only sign in to Play Console using the same email address you provided, so somebody who accepts on a work address and then signs in with a personal one gets nowhere.
There is a point where adding a person is the wrong tool entirely. If the second person is taking the app over rather than helping with it, what you want is transferring an app to another account, which moves the app record and its history rather than lending out a key. Adding a user leaves the app, the agreements and the bank details with you, which is exactly right for a contractor and exactly wrong for a handover. Decide which one you are doing before you start clicking.
Apple, App Store Connect Help, role permissions, read 16 October 2026
The same job, handled differently by each console
| The step | App Store Connect | Google Play Console | Same idea on both |
|---|---|---|---|
| Where you invite them | Users and Access, under People, the plus button | The Users and permissions page | No |
| How long the invitation lasts | 3 days, then you resend it | 30 days, then you resend it | No |
| An end date you set while inviting | Not documented, you delete the user | Optional access expiry date | No |
| Limiting someone to one app | Yes, for App Manager, Developer, Marketing, Sales and Customer Support | Yes, on the App permissions tab | Yes |
| Reports access overrides that limit | Yes | Account permissions apply to every app by design | Yes |
| Reusable permission sets | No | Permission groups, with their own expiry date | No |
| Who holds the agreements and the bank details | Account Holder | Account owner | Yes |
Google, Play Console Help, add developer account users and manage permissions, read 16 October 2026
What about the code, and the builder account that made it?
Two store invitations cover publishing. They do not cover the part the second person is usually being hired for, which is changing the app. That is a third invitation, in whatever holds the source, and it is the one people forget until something breaks on a weekend. If a builder generated the app, check what you actually own before you promise anybody access to it.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync. So the second person you add to the code is a collaborator on your repository, invited in GitHub, with nothing to do with either store account. Newly uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK, so the developer you added can get a build into a tester's hands without touching the production button. It is $25 a month and there is no free tier, which is a separate bill from the store fees in what it costs to publish an app.
What no builder does is press submit for you, and the reason is written down. App Store Review Guideline 4.2.6, read on 16 October 2026, says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content, and that these services should not submit apps on behalf of their clients. So the last link in the chain is always a human on your side of the account, holding App Manager or above. Work out who that person is on the day you add them, not on the day you want to launch.
Questions people ask about adding someone to their app
In Users and Access, under People, click the plus button on the top left. Enter the person's first name, last name and a valid email address, assign the roles, and if the role allows it, select the apps they can access. Click Next, then Invite. You have to be the Account Holder, an Admin or an App Manager to do it. The email does not have to be associated with an Apple Account, because the person can create one during activation. App Store Connect Help, read 16 October 2026, says user invitations expire 3 days after they are sent and can be resent after that.
Name the job first, then hand over the key that opens it
Write the one task down, grant the role or permission that covers it, put the end date in the invitation where the console lets you, and keep the submit button on your side of the table.
Start building