The developer is gone: a first-aid protocol for orphaned iOS apps

The developer has stopped answering. The app still runs, but nobody in-house can build it, and the next forced SDK deadline is already on the calendar. The first question owners ask me in this situation is almost always the wrong one: "Can you take over the code?" The right one is: who actually owns the accounts?

Code can be reconstructed. An Apple developer account registered to a private individual cannot.

Why the order decides how much damage you take

An orphaned app rarely dies of its code. It dies of access that runs through a name nobody can reach, and of deadlines that keep running while the company is still deciding what to do.

Two clocks tick independently here. The first is the Apple Developer Program membership, which renews annually. Let it lapse and the app disappears from the App Store. The second is Apple's minimum SDK requirement for submitted builds, which is raised regularly. If you cannot build by then, you cannot release at all — not even a one-line bugfix.

Neither clock cares that you are busy looking for a successor. That is why the first steps are administrative, not technical.

Step 1: Establish who holds the Apple account

Sign in to App Store Connect and check which role your access has and who is listed as Account Holder. That role is the only one that can sign agreements, change banking details and grant rights to others. Everything else can be derived from it; it cannot be derived from anything.

Then check the membership type. An Organization account belongs to the company and is tied to a D-U-N-S number, which makes a transfer an administrative procedure. An Individual account belongs to a person. If your app sits inside the departed developer's Individual account, that is the most serious finding in this entire protocol, and it belongs at the start of the week, not the end of it.

What remains in that case is Apple's official app transfer between accounts — which requires the other side to cooperate — or republishing under your own account. Republishing means a new app ID, lost ratings, lost ranking history, and existing users who receive no update but would have to install a second app. That is not a technical problem. It is the most expensive line item in the whole bill, and it is created months before the first meeting with a new developer.

Step 2: Freeze access before it expires

Collect in one document what exists and who owns it: App Store Connect, the code repository and its hosting provider, the signing key for push notifications, the backend environment, domains, analytics and crash reporting accounts, and every third-party service the app needs at runtime.

For each item note only two things: which email address it runs on, and whether anyone at the company has administrative access today. An address on a company domain can be recovered. A private address cannot.

The item most often missed is the payment method. Renewals frequently run on a credit card that belonged to the developer. When the charge fails, you do not lose one service — you lose several at once, quietly and without warning.

Step 3: Find out whether the app can still be built at all

Only now does this get technical, and the question is narrower than it sounds. Not "is the code any good", but: does what you have produce an installable build?

In practice this fails at three points. The code is incomplete because parts lived only on the developer's machine and never reached the repository. Dependencies no longer resolve because external libraries have disappeared or moved on to incompatible versions. Or signing is missing, because certificates and profiles hung on a personal account and are expiring.

You do not need a multi-week contract for this answer. It is a tightly bounded question that can be settled in a day or two, and it is the basis of any honest estimate. That is exactly why my emergency stabilization package puts a 48-hour analysis before the fixed price: any number quoted earlier would be a guess.

Step 4: Read the store situation before submitting anything

In App Store Connect, check whether submissions are pending or rejected, whether there are notices about outdated SDK requirements, and whether the privacy disclosures still match what the app actually does. Read the last few weeks of reviews for crash patterns following an iOS update.

Submit nothing during this phase. A rejection from App Review is harmless when you expected it, and a loss of several days when you were using it to probe the situation.

The part that hurts

This protocol puts administration before engineering, and you pay for that in patience. The first days feel like standing still: nothing is being fixed while the app keeps crashing. I have found that unsatisfying more than once, and it is still the right order — a perfectly stabilized app inside an account you do not control is an asset that belongs to someone else.

The second cost: part of this work is unpaid archaeology. Reconstructing who owns what is tedious and produces nothing visible. It is hard to sell as progress, and nobody applauds it.

Where this protocol does not apply

It assumes at least one administrative access still exists inside the company — some way in. If that is gone too, and the account belongs to a private individual who will not cooperate, this is no longer an engineering case but a legal one. Then the first call is to a lawyer, not to me.

It equally does not apply when the app is only distributed internally or is being sunset anyway. There is no store risk to justify the urgency, and the emergency turns into an unhurried migration decision.

The actual finding

When a developer disappears and the app is endangered by it, the mistake was not the departure. The mistake was that a single person held access that belongs to the company.

That is why stabilization work ends with a documented handover: changes traceable, project buildable, access where it belongs. Not as a sales argument, but because otherwise the exact same week happens again two years from now.