What to do when your iOS developer leaves

When an iOS developer leaves, protect access before making code changes. Confirm ownership of the source repository, Apple Developer and App Store Connect accounts, signing assets, backend services, analytics and release pipeline. Then create a reproducible build, document the current production version, and triage urgent risk before starting a rewrite or a feature push.

That order matters. The instinct after a departure is to get moving again: pick up the roadmap, fix the thing that has been annoying everyone, prove to the board that momentum is intact. But an app you cannot build, sign and ship is not an asset you control, and every week that passes makes the reconstruction harder. Access first, evidence second, code third.

The first 24 hours

The goal in the first day is not to fix anything. It is to make sure nothing else can be lost.

Keep accounts under company control. Your Apple Developer Program membership, App Store Connect, Git host, CI provider and backend accounts should be owned by a company identity: a company-controlled email address, ideally on a domain you own, with billing on a company card. If any of them is currently registered to a personal address belonging to the person who has left, that is the single most urgent item on this list.

Do not ask anyone to share a password. Every service worth using supports named accounts, roles and invitations. Ask for ownership to be transferred and for you to be added with the right role, not for a credential to be handed over. This protects both sides and avoids a shared secret nobody can safely rotate later.

Do not remove the departing person’s access on the first afternoon. It is tempting, and occasionally necessary, but revoking access before you have verified continuity is how businesses lock themselves out of their own Apple Developer account. Verify that you can sign in, that you hold the Account Holder or Admin role where it matters, and that a second person also has access. Then remove what should be removed.

Write down what you find as you go. The inventory below is worth keeping as a living document. It will be the first thing any incoming engineer or consultant asks for.

The access inventory

Work through these systematically. For each one, record who owns it, who has access, and what role they hold.

• Source control. The Git host, the specific repositories, and whether the organisation account is company-owned. Check for a repository that only exists on a laptop.
• Apple Developer Program. Membership status, renewal date, the Account Holder identity, and the list of users and roles.
• App Store Connect. App records, roles, agreements, tax and banking details, and any pending or in-review submissions.
• Signing assets. Distribution certificates, provisioning profiles, push notification keys, App Store Connect API keys, and their expiry dates.
• CI and build systems. The provider, the pipeline definitions, any self-hosted runner, and secrets stored in that provider.
• Package registries and private dependencies. Any private Swift package, internal framework, or licensed binary SDK, along with its licence and support contract.
• Firebase, Crashlytics, analytics and monitoring. Project ownership, admin users, and whether historic data is exportable.
• Backend and APIs. Hosting, databases, environment configuration, API keys, and which of them are embedded in the app rather than fetched.
• Design and product assets. Source design files, App Store screenshots, icon source artwork and brand assets.
• Supporting URLs. The domain, the marketing site, the support URL and the privacy policy URL referenced by your App Store listing. Apple requires those to resolve.

Two of these hide the worst surprises. Expiring certificates and keys will stop you shipping without warning, sometimes months after the departure. And API keys embedded in the app binary cannot be rotated without a release, which turns a routine security action into a full release cycle.

Capture the production baseline

Before anything changes, record what is live. This is the reference point you will compare everything against, and it takes about an hour.

Note the current App Store version and build number, and its release date. Check whether any submission is in review, rejected, or sitting in a phased release. Capture the current crash-free rate and the trend over the last few releases. Record the supported iOS version range and the device classes in real use, taken from your own analytics rather than assumed. List any known incidents or recurring support complaints.

If you have no crash reporting at all, that itself is a finding, and adding it is one of the highest-value early changes you can make.

Reproduce the build on a clean machine

This is the moment of truth, and it is worth doing early even though it can be uncomfortable.

Take a fresh checkout of the repository on a machine that has never built this project. Follow whatever documentation exists, exactly as written. Note every step you had to work out yourself, every tool you had to install, every value you had to obtain from somewhere other than the repository.

What you learn here tells you more about the handover than any document. A project that builds from a clean checkout with a README and a .xcconfig is in good shape. A project that needs a specific Xcode version nobody recorded, three environment variables that live in someone’s shell profile, and a manually installed dependency is a project where the knowledge left with the person.

If the build fails outright, that is a common and recoverable situation, but it needs a methodical approach rather than a flurry of upgrades. I have written a separate walkthrough of how to rescue an iOS app that no longer builds, which sets out a safe troubleshooting order.

Assess the quality of the handover

With the build attempted, you can judge what you have actually inherited. Look for:

• A README that explains setup, configuration and release.
• Documented configuration and a clear approach to secrets, ideally with nothing sensitive committed.
• Tests, and whether they pass. Their existence matters less than whether they run and whether anyone trusted them.
• A deployment runbook: how a release is actually cut, submitted and rolled out.
• Architecture decisions, design docs or ADRs explaining why the app is shaped the way it is.
• The real backlog, including known issues that were being lived with rather than fixed.

Be careful about how you interpret gaps here. A thin handover is usually a symptom of a small team under delivery pressure rather than negligence, and framing it that way makes it far easier to get useful cooperation from the person leaving during their notice period.

Decide what is genuinely urgent

Once you can see the state of things, rank the work. In my experience the order is nearly always this:

1. Access and account control. Anything that could lock you out permanently.
2. Expiring credentials. Certificates, provisioning profiles and API keys with a date on them.
3. Inability to ship. A broken build or release path, because it blocks every other fix.
4. Critical production defects. Crashes and broken flows affecting real users now.
5. Security exposure. Embedded secrets, unprotected data, unpatched dependencies with known advisories.
6. Delivery friction. Slow builds, flaky tests, manual release steps.
7. Technical debt. Real, but it should almost never outrank the six items above in the first month.

What not to do

Do not immediately rewrite. A codebase you do not yet understand always looks worse than it is. Give it a month of real contact before making that judgement, because the cost of being wrong is enormous and the decision is very hard to reverse.

Do not rotate credentials you do not understand. Rotating a key that turns out to be embedded in the shipped app, or used by a backend job nobody documented, converts a manageable problem into an outage. Map first, then rotate deliberately.

Do not upgrade every dependency at once. Upgrading everything simultaneously destroys the information you need to work out which change broke what. One at a time, with a commit each.

Do not let a new supplier start without company-owned access. If you are bringing in an agency or contractor, the accounts must be yours and they must be added as users. Otherwise you repeat this entire exercise the next time someone moves on.

When an independent rescue engagement makes sense

You can do most of the above yourself with a technically confident person and a careful week. Outside help is worth it when the build will not come back, when nobody internally can judge whether the codebase is sound, when an urgent release is blocked, or when a decision with real money attached is waiting on a technical answer.

The useful shape is a short, contained engagement rather than an open-ended contract. A one-to-three-day triage should tell you whether the immediate problem is fixed, what remains, and whether more work is justified. If a broader picture is what you need instead, a structured assessment of how to evaluate an inherited iOS codebase covers the ground more thoroughly.

My iOS App Rescue service exists for exactly this situation: an app that has lost its owner and needs someone senior to establish what still works before anyone commits to what happens next.

The checklist

Work through this in order. It is deliberately blunt.

• Apple Developer Program membership is owned by a company identity, and at least two people hold access.
• App Store Connect roles are confirmed, including Account Holder.
• Source repositories are under a company-owned organisation.
• Signing certificates, profiles and keys are inventoried with expiry dates.
• CI provider access and stored secrets are inventoried.
• Backend, database, Firebase and analytics ownership is confirmed.
• Private dependencies, licences and support contracts are recorded.
• Support URL, privacy policy URL and marketing domain resolve and are controlled by you.
• Current App Store version, build number and release state are recorded.
• Crash-free rate and recent trend are recorded.
• A clean-machine build has been attempted and the result documented.
• Handover artefacts (README, runbook, tests, decisions) have been assessed.
• Urgent risks are ranked and the top three have owners.
• The departing person’s access is removed, after continuity is verified.