Handing a React Native project to an agency is three grants, and only one of them is the code.

What are you actually handing over, and what is already gone?

Three grants, and a fourth thing you cannot take back. The fourth is the copy of the code that exists the moment anybody clones the repository. GitHub says this plainly on its page titled Permission levels for a personal account repository, read on 17 October 2026: forks of private repositories are deleted when a collaborator is removed, but the person still keeps any local clones. Removing access stops future pulls. It does not unsend the code. So the first thing to settle is not an access setting. It is the contract: who owns the code, what the agency may keep, and what happens to their copy when the work ends.

The second thing owners get wrong is assuming the code is the hard part. It is not. A React Native and Expo project is a readable repository: a package manifest, a source directory, a configuration file and a lockfile. A competent mobile team reads it in an afternoon. The store accounts are the hard part, because those carry your legal identity, your money and your ability to ship anything at all. Agencies lose their first week waiting on an invitation, not reading your components. If the team is strong on native work but new to this stack, an hour on getting started with Expo saves a day of confusion about which commands build what.

The useful discipline is to start from the job rather than the role. Write down what you are paying them to do, then look up what each provider requires for exactly that. The jobs below are the ones that come up in almost every engagement, with the role or permission each provider names for each one.

What can you give on the repository, and what can you take back?

It depends entirely on whether the repository belongs to a person or to an organization, and the difference is sharper than most owners expect. GitHub documents that a repository owned by a personal account has exactly two permission levels, the repository owner and collaborators. Then comes the line that decides this for a lot of small companies: in a private repository, owners can only grant write access to collaborators, because collaborators cannot have read-only access to a repository owned by a personal account. There is no way to let an agency look at your private personal repository without also letting them push to it. GitHub's own suggestion, on the same page, is to transfer the repository to an organization if you need finer control.

Do that and you get five levels instead of two. GitHub lists them from least access to most as Read, Triage, Write, Maintain and Admin, on its page titled Repository roles for an organization, also read on 17 October 2026. Write is what an agency needs: push, merge a pull request, create and edit releases, and create, update and delete Actions secrets. Admin is what to withhold. Admin is the only role on that page that can manage individual, team and outside collaborator access, manage webhooks and deploy keys, manage branch protection rules and rulesets, change the repository's visibility, and delete or transfer the repository out of the organization. None of that is needed to write code. A contractor who is not in your organization is what GitHub calls an outside collaborator, and if you keep forks around, GitHub notes you have to add them to each fork you want them to reach.

Two things survive removal, and both are in GitHub's own words. The local clone, already covered. And deploy keys: GitHub warns that when someone adds a deploy key to a repository, any user holding the private key can read from or write to that repository, depending on the key settings, even after they are removed from the organization. If the agency wired your CI with a deploy key, deleting their user account does nothing to it. Offboarding is therefore three steps, not one: remove the accounts, rotate the deploy keys and Actions secrets, then check what is still authenticating. GitHub also caps how many people can be invited to a repository in a 24 hour period, which is a non-event for one agency and a surprise if you onboard a whole team at once.

One decision belongs before the grants, because it changes what you are buying. An agency that would rather work in its own stack will often open with a rewrite proposal. That conversation is legitimate and it is also expensive, and it tends to be won by whoever argues hardest rather than by the numbers. If it comes up, have it with Flutter against React Native in front of both of you, and remember that the project you already own ships to both stores today.

Which App Store Connect role lets them ship without letting them submit?

Developer. Apple splits those two tasks and prints the required role at the top of each help page. For uploading builds, Apple lists Account Holder, Admin, App Manager or Developer. For submitting an app, the list is Account Holder, Admin or App Manager. Developer is not on the second one. A Developer can deliver a build to TestFlight and cannot put it in front of App Review. For most agency work that is the right grant, because submission is the point at which your company stands behind the app, and that is not something to delegate by accident.

People are added in Users and Access, and who may add them is itself a role. Account Holder, Admin or App Manager can add a user, while only an Account Holder or Admin can change somebody's role or delete them. The details that bite are on the same page. A user invitation expires three days after it is sent, and can be resent afterwards. The email address does not have to belong to an existing Apple Account, because any email can activate the account and the person can create an Apple Account during activation. Two factor or two step verification is required to sign in, so an agency sharing one login between four people is already outside what Apple describes. And when you delete a user, Apple notes caching may take up to ten minutes to complete before access is fully revoked.

Then the part that decides whether this is easy or awkward: how you enrolled. Apple states that individuals enrolled in the Apple Developer Program can give up to 50 additional users access to their content in App Store Connect, and that those users receive access to App Store Connect but are not part of the Apple Developer Program team and will not receive access to other membership resources or benefits. Organizations can add an unlimited number of members to their team, and those users receive App Store Connect and all other membership resources and benefits. In practice, enrolled as an individual, the agency works inside App Store Connect and reaches nothing else. Enrolled as an organization, they are on your team.

This is also where a common conflation can be put down. The Apple Developer website and App Store Connect are not two separate grants. Apple's account help says each organization has one team with one set of roles across the Apple Developer website and App Store Connect, and that management of users and roles is done in App Store Connect. One invitation, two websites. What does not move is the Account Holder: only one person can hold it, and Apple says the Account Holder 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. Keep it. The annual membership and the rest of the bill sit inside what it costs to publish an app, and none of it moves to the agency.

Apple, App Store Connect Help, add and edit users, read 17 October 2026

What does Play Console hand over, and what stays with you?

Google's model is flatter and more adjustable. Play Console Help, read on 17 October 2026, says there are three access levels: account owner, admins and users. The account owner is the first registered account in Play Console, has full access, and is the only person who can have a linked payments profile to sell paid apps, and the only person who can access and edit the Payments settings page. Admins hold the Admin (all permissions) permission, can be given access to all apps or specific apps, and can invite and remove people. Users can have different levels of access and cannot invite anybody or edit permissions. Google says in both of those rows that neither admins nor users need to pay the registration fee that opened the account, which answers the question every agency asks on the first call.

Every permission is granted at one of two levels, and Google is explicit that some permissions exist at only one of them. Account permissions apply to all apps in the developer account. App permissions apply only to the app you picked. You add people on the Users and permissions page, where you can also set an access expiry date, and Google warns that if you do not choose one, the user has ongoing access to your account or app indefinitely. An invitation that is not accepted within 30 days expires and has to be resent. The invited person can only sign in with the exact email address you typed, so a typo is a resend rather than a support ticket. For a team rather than one contractor, permission groups do the same job for several people at once and can carry their own expiry date.

The release permissions are where Google is genuinely useful to a nervous owner. Release apps to testing tracks covers uploading draft apps, creating, editing and rolling out releases to testing tracks, and uploading APKs for internal sharing, and Google states that it does not allow users to publish apps to production. Release to production, exclude devices, and use Play App Signing is the other one, covering production rollouts, unpublishing and republishing, excluding devices, and using Play App Signing to sign APKs. Manage testing tracks and edit tester lists is separate again, covering the internal, open and closed track configuration and the tester lists. Grant the first, withhold the second, and the agency can put builds in front of your testers all week without being able to ship to the public.

Two more boundaries are worth keeping. Money is its own permission, View financial data, and the payments profile is not a Play Console permission at all: Google says Play Console permissions are separate from any permissions managed within the Google payments center, where payments users are added under Settings. Store paperwork is its own permission too, Manage policy declarations, which covers editing and submitting policy declarations including the Data safety section. If the agency is doing that work, hand it over deliberately, rather than discovering it was bundled with something else. And when somebody on their side hits Error 403 in the console, Google's answer is the boring one: ask the account owner to grant permission for that app.

Google, Play Console Help, add developer account users and manage permissions, read 17 October 2026