Handing an app to a developer is an access problem before it is a code problem.
Handing a live app to a developer means three handovers, not one: the code, the two store accounts, and the keys to everything the app talks to. The code is the easy part. The store accounts are where people either give away too much or give away too little and spend a fortnight on email instead of work. Apple and Google both document exactly how this is meant to go, and they do it differently. Apple hands out one of eight named roles. Google hands out a list of permissions you tick, one by one. Every screen name and figure below comes from Apple's and Google's own help pages, read on 16 October 2026.
What follows is who needs what, the two identities you keep, and how to get the access back on the day the invoice is paid. If you are bringing someone in because the upkeep is more than you expected, read what an app costs to maintain first, because the answer changes who you hire.
Start hereThe short version
What does a developer actually need from you?
Less than they will ask for, and in a particular order. Start with the code, because that costs you nothing and unblocks them for a week. Then add them to the store account the work touches, scoped to the one app if the store lets you scope it. Then hand over third party keys last, one at a time, as the work reaches them. Most contractors never need your payment settings, your tax forms or your legal agreements, and those are the parts you cannot undo with a click.
The shape of the invitation differs by store, so decide once and write it down. On Apple you pick a role, and the role decides what they see. On Google you pick permissions, and you can give someone the right to push a build to a testing track without the right to release to production. That single difference is worth the ten minutes it takes to understand, because it is the difference between a nervous Friday and an ordinary one.
Which Apple role should a developer get?
Apple publishes eight roles for the Apple Developer Program, and you assign them in App Store Connect under Users and Access. They are Account Holder, Admin, Finance, App Manager, Developer, Marketing, Sales and Customer Support. Two of them cover the work you are hiring for. Developer, which Apple describes as managing development and delivery of an app. App Manager, described as managing all aspects of an app, such as pricing, App Store information, and app development and delivery. If the person is writing code and handing you builds, Developer is the honest fit. If they are also editing the listing and pressing buttons on release day, they need App Manager.
The other five exist so you do not have to over grant. Finance manages financial information, including downloading reports and uploading tax forms. Sales analyses sales, downloads and other analytics. Customer Support analyses and responds to customer reviews. Marketing manages marketing materials and promotional artwork, and Apple notes it is the role it contacts if your app is considered for featuring. Admin is the secondary contact for the team with many of the same responsibilities as the Account Holder, and in an organization team it gets Certificates, Identifiers and Profiles by default. That is a lot of authority for a six week contract.
Sending the invitation needs the Account Holder, an Admin or an App Manager. Open Users and Access, and under People click the plus button on the top left, then enter a first name, last name and a valid email address. Apple is explicit that any email can activate the account and that it does not have to be associated with an Apple Account, which is the detail that saves people from sharing a password. Then scope it: if the user is App Manager, Developer, Marketing, Sales or Customer Support, and you have not given them reports access, you select the apps they can reach. Admin and Finance always see every app, and so does anyone holding reports access or Certificates, Identifiers and Profiles access.
One number catches everybody. An Apple invitation expires 3 days after it is sent. Send it on a Friday to someone starting Monday and it is dead before they open it, and you will both assume the other one is holding things up. It can be resent after it expires, so this is an annoyance rather than a disaster, but send it on the first morning rather than the week before.
App Store Connect Help, add and edit users, read 16 October 2026
Check yours
What to give the person in front of you
Tick who you are adding. The names shown are the ones each store uses inside its own screens.
Nothing ticked. Start from the task the person was hired to do, not from the role name that sounds closest to their job title.
What are the equivalent permissions in Play Console?
There is no equivalent role, and that is the point. Google hands out permissions one at a time. You open Users and permissions, enter the email address, set an access expiry date if you want one, then choose permissions on the App permissions tab for named apps or on the Account permissions tab for every app, and select Invite user. You need Admin (all permissions) at account level to send it. If you hand out the same bundle often, Google lets you build it once with Create permission group and apply it to several people.
The permission names tell you what they do, which makes the choice easier than Apple's. View app information (read-only) and View app quality information (read-only) are enough for someone diagnosing a crash. Release apps to testing tracks lets a developer get a build in front of your testers. Release to production, exclude devices, and use Play App Signing is the separate one, and keeping it to yourself means nobody ships to real users without you. Manage testing tracks and edit tester lists, Manage store presence and Reply to reviews cover the listing side. View financial data and Manage orders and subscriptions cover the money. Give out the first group freely and the last group almost never.
Three levels sit above all of that. The account owner is the first account registered in Play Console, with full access, and the only one who can have a linked payments profile or open the Payments settings page. An Admin holds Admin (all permissions), can be given all apps or specific apps, and can invite and remove users. Everyone else is a user whose access depends on what you ticked, and who cannot invite anyone or edit permissions. A contractor belongs in that third group.
Google's invitation window is 30 days rather than 3, measured from the invite to the person accepting and signing in, and an expired one has to be resent by an admin. Sent invitations show as Invite sent and flip to Active once accepted, so you can tell whether the silence is theirs or yours. Before the first handover release, agree on how you number builds, because two people guessing at that produces a mess that outlives the contract. The rules for version numbers are worth ten minutes on the first call.
Google Play Console Help, add developer account users and manage permissions, read 16 October 2026
What should you never hand over?
Two identities, one per store, and neither is a permission you can tick back off. Apple's Account Holder is the person who completed program enrollment and is responsible for entering into legal agreements with Apple. Apple states that this is the only user who can sign legal agreements, renew the membership, request access to the App Store Connect API, remove auto-renewable subscriptions from sale, submit Safari Extensions, or create developer ID certificates. Google's account owner is the first account registered in Play Console, and the only one who can have a linked payments profile or reach the Payments settings page. Those two identities are the business. A developer does not need either of them to write code or ship a build.
A buyer taking the app over for good is therefore not a user invitation at all. Apple assigns the Account Holder role at enrollment, and Google names the first registered account as the owner, so an ownership change is a separate process on both stores and not something you do from the people list. If somebody asks you to make them an Admin so they can take the app off your hands, that is the wrong request and the answer is no.
Keep the correspondence with App Review, too. It arrives in the account you control, it is written to the person Apple thinks owns the app, and it is the thread you will be reading closely if a release comes back rejected. A developer can fix what the reviewer objected to. Deciding whether to change the app or argue with the decision is yours, and the mechanics of appealing a rejection are worth knowing before you need them.
App Store Connect Help, add and edit users, read 16 October 2026
How do you take the access back when the work ends?
Decide this while you are still friends. On Google Play the cheapest answer is built into the invitation: set an access expiry date when you add the person, and the access lapses on its own. Google is blunt about the alternative, which is that a user with no expiry date keeps access indefinitely. Afterwards, the account owner or an Admin changes or removes access on the Users and permissions page, and admins with global access can also move an expiry date.
Apple has no end date in the invite flow, so the removal is a job somebody has to do. Editing a user requires the Account Holder or an Admin. An App Manager can send invitations but cannot edit an existing user, which bites the owner who delegated everything and then finds the only Admin in the account is the contractor who left. Open Users and Access, click the person, and change their roles or app access from there.
Store access is the half people remember. The other half is every credential the developer touched: the repository, the backend, the analytics project, the payment provider, the push certificates. Rotate them rather than trusting the handover note, and do it in the same hour you remove the store access. Then ship one small release yourself, so you find out now whether you can still get a build out of the door alone. If that release is the first one in months, look at rejection rates before you plan the timing around it.
Google Play Console Help, add developer account users and manage permissions, read 16 October 2026
The same handover, run differently by each store
| The step | App Store Connect | Play Console | Same answer on both |
|---|---|---|---|
| Where you add someone | Users and Access, People, the plus button | Users and permissions, then Invite user | No |
| Who is allowed to invite | Account Holder, Admin or App Manager | Admin (all permissions) at account level | No |
| Access arrives as | One or more of eight named roles | A list of individual permissions you tick | No |
| Can be scoped to one app | Yes | Yes | Yes |
| The invitation expires | 3 days after it is sent, resendable | 30 days without a sign-in, resendable | No |
| An end date on the access itself | Not offered in the invite flow | Optional access expiry date | No |
| Changing it later | Account Holder or Admin only | The account owner or an Admin | No |
Where this lands if a builder generated your app
The store half does not change. The code half is where most builders make the handover painful, because there is nothing to hand over: the app lives inside the tool and a developer cannot open it in an editor. Ask any builder one question before you commit to it. What exactly does a developer receive on the day I hire one?
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two way GitHub sync, so the handover is a repository invitation and a developer starts from a codebase and its history rather than from an export. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. The plan is paid from $25 a month, with no free tier.
The honest limit sits on the Apple side. Newly does not submit to the App Store for you, because App Store Review Guideline 4.2.6 requires apps created from a commercialized template or an app generation service to be submitted directly by the provider of the app's content. That is you, or a person you added to your own account with a role that covers it. Either way the account is yours, which is the part that makes a developer replaceable.
Questions people ask about handing an app to a developer
In App Store Connect, open Users and Access, and under People click the plus button on the top left. Enter the person's first name, last name and a valid email address. Apple says any email can activate the account and that it does not have to be associated with an Apple Account, so there is never a reason to share your own login. Assign one or more roles, then select the apps they can reach if their role allows that. You need to be the Account Holder, an Admin or an App Manager to send the invitation, and it expires 3 days after it is sent. An expired invitation can be resent.
Own the account, then hire whoever you like
Keep the two owner identities, scope every invitation to the app and the job, and put an end date on the access while the work is still starting. A handover done that way takes an afternoon, in either direction.
Start building