Source Code Escrow for Apps: What It Misses

Source code escrow is a contract where your software vendor deposits a copy of the application’s source code with a neutral third party, who releases it to you if the vendor goes bankrupt, stops supporting the product, or breaches the agreement in a way that never gets fixed. For a mobile app it protects less than most buyers assume, because source code is only one of the things you need in order to keep shipping to the App Store and Google Play. The signing key that Google holds for your Android app can never be handed to you, and your App Store listing lives inside a developer account that an escrow agreement has no claim over. Escrow is still worth buying in some situations, and the useful question is which ones.

Almost everything written about escrow comes from companies that sell it, aimed at enterprises licensing business software, and none of it mentions app stores or signing keys. This piece works through the same arrangement for a product people install on a phone, where owning the code and being able to ship an update are further apart than they look.

What is source code escrow, and how does it work?

Escrow is a contract between three parties, and its shape is broadly the same at every provider. Your vendor is the depositor, you’re the beneficiary, and an independent escrow agent holds the material. The vendor uploads a copy of the source code and its supporting files, agrees to keep that copy reasonably current, and the agent stores it without letting either side take it unilaterally. Nothing reaches you while the vendor is meeting its obligations, which is the whole reason for involving a third party rather than asking for a copy of the code.

Vaultinum describes three ways the arrangement gets papered, and the difference matters more than the legal language suggests. An access clause sits inside your existing licence agreement and commits the vendor to hand over code under named conditions, with no agent in the middle, while a bipartite agreement is signed by the vendor and you alone. A tripartite agreement adds the escrow agent as a signatory, and that’s the version people actually mean, because the agent carries its own duty to release rather than leaving you dependent on a company that has stopped answering email.

What has to go into a mobile app’s escrow deposit?

Source code alone won’t rebuild a mobile app, so the deposit has to name everything else the build depends on. Escode describes a proper deposit as source code, build instructions, libraries, dependencies, configuration files and technical documentation, and that broader definition is the one to insist on. A folder of Swift and Kotlin without the rest is a research project rather than a recoverable app.

For a mobile codebase, the parts that get forgotten are specific enough to list in the agreement itself:

• Dependency lockfiles and access to any private package repositories
• Backend configuration files such as GoogleService-Info.plist and google-services.json
• Continuous integration configuration and any secrets the build reads at compile time
• The bundle identifier, package name and the exact toolchain versions the app builds with
• Any self-managed signing keystore, along with its passwords

The other half of the problem is currency rather than completeness. A deposit made at contract signature and never touched again describes an app that stopped existing two years ago, and you’ll find that out at the worst possible moment. Escrow London offers automatic deposits straight from a Git repository, which removes the human step that fails most often, so take that option if your provider has it and make the frequency part of the contract.

Why can’t your app signing key go into escrow?

Because Google holds it and won’t give it back, and that’s deliberate rather than an oversight. Google’s own documentation states that with Play App Signing, “Google manages and protects your app’s signing key for you and uses it to sign your APKs for distribution”, and that once the feature is configured, “you cannot retrieve a copy of your app’s signing key”. There’s nothing for your vendor to deposit, so no escrow agreement can cover it.

The consequence cuts both ways, and the good news comes first. Because Google holds the key, it can’t vanish with a failed agency, which removes the most catastrophic outcome that used to face abandoned Android apps. What you need instead is access to the Play Console account the app lives in, which is an account question rather than a code question. The upload key you still hold is far more forgiving, because Google states that if you lose it, or if it’s compromised, you can request an upload key reset in the Play Console and carry on shipping updates.

Older apps that never opted into Play App Signing are the real exception, and they are still out there in quantity. For those, Google’s wording is blunt, noting that if you lose your app’s signing key, you lose the ability to update your app. That keystore file is genuinely irreplaceable, it belongs in the escrow deposit and in your own storage, and it’s the first thing to ask about when you inherit an Android project.

The iOS side is easier, because signing certificates and provisioning profiles belong to an Apple Developer team rather than to a codebase, and a new team simply regenerates them. Push notifications are the exception, since Apple’s transfer documentation notes that APNs certificates have to be regenerated by the receiving team, which is the sort of detail that turns a smooth handover into a week of silent notification failures.

Who actually owns your App Store listing?

Whoever enrolled the developer account it was published under, and if that’s your agency, escrow does nothing to solve it. The listing carries your reviews, your ratings, your install base and your ranking history, none of which sits in a repository or falls under a deposit agreement. Companies discover this late because the code question feels like the important one during contract negotiation.

Apple does provide a transfer process, and it works when everyone cooperates, but its conditions quietly rule out doing it in a hurry. Apple requires that the app has at least one version already released to the App Store, that it isn’t available for pre-order, and that it isn’t sitting in any review-related state, including “Waiting for Review”, “In Review” and “Pending Developer Release”. In-app purchase product identifiers can’t clash with identifiers already used in the receiving account, and Apple Arcade apps can’t be transferred at all.

Several other things stay behind once a transfer completes. Apple states that a merchant identifier used for Apple Pay doesn’t transfer with the app, that Game Center matchmaking configuration doesn’t come across, and that new promo codes can’t be generated afterwards. TestFlight builds and testers have to be removed before the transfer starts, and any Xcode Cloud data cleared first. Each of those needs a team that still exists and still cares, which is precisely what you lack in the scenario escrow was bought to cover.

Enrolling in your own name from the start is the cheap fix, since Apple charges a $99 annual membership for the Apple Developer Program and adding your agency as a team member costs nothing. Taking over an app published somewhere else is a real project, and our mobile app takeover work usually starts by untangling exactly this.

What triggers a release, and what happens next?

Release conditions are named in the agreement, and the standard set is narrower than most buyers expect. Escrow London lists five: bankruptcy, entering administration, discontinuing support for the software, a material breach unresolved after a ten-day notice period, and a transfer of intellectual property without equivalent protections carrying over. Escode publishes a closely matching list. An agency that merely becomes slow, expensive or unpleasant to deal with meets none of these, so escrow isn’t a lever in an ordinary commercial dispute.

When a genuine trigger fires, the release is a process rather than a download link. You notify the agent, the agent notifies the vendor, and there’s normally a window for the vendor to object before anything moves. Codekeeper is unusually open about charging for this step, publishing a rate of $199 per hour for release processing available around the clock. Build that delay into your planning, because a release arriving three weeks after your vendor collapsed is three weeks of an unmaintained app in production.

What you receive is a copy of a codebase written by people you can’t ask questions of, and turning that into shipped updates needs engineers who can read it, build it and take responsibility for it. Scoping that work before you need it beats scoping it during an emergency, which is what an independent code audit of the app you already have is for.

Does escrow verification prove your app can be rebuilt?

Only if you buy the level of verification that actually compiles the thing, and the cheapest tier does not. Vaultinum sells three grades: a standard deposit with no checking, an element-checked deposit that confirms the material is readable and structured as described, and a content-checked deposit involving functional testing. Escode frames verification as confirming that deposits are complete, current, buildable and aligned to production environments, and describes it as an essential control rather than an upsell.

For a mobile app, only the build-level check answers the question you care about. Verification that matters has to prove the code compiles with the exact toolchain versions recorded in the deposit, resolves every private dependency without credentials only the vendor holds, and produces an artifact you could install on a device. Anything less confirms the files are present and readable, which is a long way from confirming the app can be released again.

A simpler version of the same test costs nothing and works better as a habit. Ask your development partner, once a quarter, to build the app on a clean machine using only what is in the repository and the documented setup steps, then tell you how long it took. A team that manages it in an afternoon has a healthy project, and a team that needs three days and one specific engineer’s laptop has told you something no escrow agreement will fix. Our mobile app testing checklist covers the release-readiness side of the same discipline.

How much does source code escrow cost?

Almost nobody publishes a price, which makes it hard to judge whether the protection is proportionate. Escrow London, Escode and Vaultinum all route pricing through a quote request. Codekeeper is one of the few that publishes openly, listing software backup from $99 a month, software escrow from $139 a month, SaaS escrow from $199 a month and continuity escrow from $459 a month, with annual plans saving up to 12 percent. Those are starting rates, and verification testing is normally priced on top.

Set that against the alternatives and the decision gets easier. A year of entry-level software escrow at that published rate runs to more than $1,600, while the Apple Developer Program costs a $99 annual membership. Holding your own accounts and your own repository is far cheaper than paying a third party to keep a copy of something you already own, and it protects you against a much wider range of outcomes.

When is escrow the wrong thing to buy?

Escrow is the wrong purchase when you already own the code, which describes most companies who commission a mobile app. It was designed for a customer licensing software they’ll never own, from a vendor whose business could fail, and it solves the problem of reaching code that belongs to someone else. If your development contract already assigns the intellectual property to you, the answer is holding the copy yourself, in a repository under your own organisation, updated on every release. That costs nothing beyond the hour it takes to set up.

Three situations do justify the expense. The first is a vendor who genuinely won’t hand over the source, usually because the app is built on a reusable framework they license to other clients. The second is a procurement requirement, where a customer of yours insists on escrow before signing and the cost is part of winning the deal. The third is the mirror image, where you’re the vendor and offering escrow removes an objection that would otherwise cost you contracts.

Outside those cases the money buys reassurance rather than protection. RapidLabs has picked up plenty of apps whose owners held a signed contract and a folder of source code, and the recovery still took weeks, because account access, backend credentials and the release process were the parts nobody had secured. Deciding whether to keep the code you inherit is its own question, and our piece on rewrite versus refactor for a mobile app works through it.

What to put in the contract instead of hoping

The strongest protection for a mobile app is ownership arranged correctly at the start, and it costs almost nothing next to any escrow product. Enrol in the Apple Developer Program and the Google Play Console under your own company, then add your development partner as a team member rather than the other way round. Create the repository organisation in your own name and invite the developers into it. Own the backend project, the analytics account and the crash reporting account, and make sure someone inside your company can sign into each of them today.

Then write the operational details into the agreement rather than assuming them. Ask for build instructions a new engineer can follow on a clean machine, a documented release process, and a named list of every third-party service the app depends on with the account each one sits under. Require that any self-managed signing keystore is stored somewhere you control. If you want escrow on top of that, buy the tier that verifies the deposit builds, because an unverified deposit is a promise rather than a safeguard.

RapidLabs inherits apps for a living, and the recoveries that go smoothly are never the ones with the best contract. They are the ones where the client could still sign into their own developer accounts. Escrow answers a narrow question about code ownership, and it was never designed for a product that reaches its users through two app stores you don’t control.