Skip to main content
Back to blog
Reprise

Your developer has stopped responding: taking over an app without losing everything

By ··6 min read
Linocut of unfinished weaving and its shuttle, with a teal thread continuing the existing weave.

An application can be taken over when its developer stops responding, provided you recover the access, data and rights needed to maintain it. Start by securing what your company controls, then audit the existing product before deciding what to keep or replace. The developer's absence alone is no reason to rewrite everything.

In the first week, find out who controls what

Whether a freelancer has become unreachable, an agency has closed or maintenance has simply stopped, appoint someone in your company to bring the records together. Collect the contract, invoices, previous correspondence and alerts. Record upcoming deadlines before requesting new features.

For each item below, record the account holder, administrator, payer and last successful sign-in. An invoice in your company's name does not replace tested access.

Domain and DNS
Domain registrant, renewal, registrar access and DNS settings.
Store accounts
Entity enrolled in Apple Developer and Google Play Console, account holder and App Store Connect roles.
Hosting and billing
Cloud accounts, administrators, payment method and renewal alerts.
Source code
Complete repository with its history and a copy under company control.
Backend and database
Server-side services, data access, a recent backup and a restore to verify.
APIs and subscriptions
Third-party services, API keys, licences, quotas and the payer for each subscription.
Usage analytics
Analytics account ownership, report access and available history.
Email sending
Sending account, verified domains and access to delivery errors and password-reset emails.

Ask the incoming team to verify backups in an isolated environment before touching production data. Then arrange to replace shared access and keys, service by service, checking the functions that depend on them.

What to request in writing

Send a formal request to the contact and address specified in the contract. List the items you expect, propose a response deadline and agree on a secure transfer method. Keep a dated copy of the request and replies.

  • The complete code for the published version, design assets and instructions for preparing and publishing an update.
  • An inventory of accounts, subscriptions, licences and services, including their holders and renewal dates.
  • Access or administrator invitations, backups and the restoration procedure.
  • Documentation, known incidents, work in progress and account transfers to arrange.

Request individual invitations rather than someone's personal password. If the app belongs to the provider's account, follow Apple's procedure in App transfer.

For Google Play, see Transfer apps. Associated services also need checking. Without cooperation, contact platform support with the evidence available, without assuming it can transfer the app.

The contract determines which rights to check

Read the provisions for source delivery, use, modification by a third party and the end of the engagement. Ask which components carry external licences. Holding a copy of the code does not establish the scope of the rights granted.

In Switzerland, the IPI distinguishes assignment of rights from a licence, which permits agreed uses. This is orientation, not legal advice on your contract. If clauses are missing or disputed, have the file reviewed before commissioning changes or publishing again.

Store deadlines continue to apply

For iPhone apps, Apple's Upcoming Requirements can prevent the submission of an update built with an old SDK. Separately, App Store Improvements provides for removing outdated or malfunctioning apps. These are distinct mechanisms.

On Android, Google Play's Target API rules distinguish update submissions from existing-app availability. An outdated Android target can restrict access for new users on newer devices, without removing the app from the entire catalogue.

Have the team review messages in both consoles and check the requirements that apply to your app. An app still installed on your phone does not prove it remains downloadable or that a correction can be published.

Take over in order of risk

  1. 1
    Secure access

    Identify account holders, preserve data and cover urgent renewals.

  2. 2
    Audit

    Match the code to the version in use, check rights and assess security, publication and dependencies.

  3. 3
    Stabilise

    Make an update possible, test essential user journeys and verify restoration.

  4. 4
    Evolve

    Decide on improvements and any partial replacement based on the audit.

The audit should produce decisions that can be costed, with remaining uncertainties recorded. Request a proposal that separates immediate continuity, stabilisation and improvements. Our guide How to compare mobile app development quotes in Switzerland helps you compare these scopes.

If the code is missing, first assess what can be recovered through the data, accounts and documentation. If part of the system needs replacing, plan the migration and service continuity. Keep the existing system until its replacement has been verified.

Prepare for the next handover

Open accounts in your company's name, with internal owners and individual access for the provider. Keep documentation of services, recurring costs, backups and publication somewhere your team can find it. Check that another person can follow the update procedure.

The next contract should specify rights, deliverables, access handover and end-of-engagement support, including its financial terms. At Appik Studio, co-developing the Le Temps app with its internal team illustrates the sharing of code, decisions and knowledge that prepares continuity, as described in our approach.

To discuss your situation, see our application takeover service or our mobile development and takeover offering. The first discussion establishes what is accessible and what needs clarifying before defining an engagement.

Sources and references

6 sources
ige.ch · developer.apple.com · support.google.com
  1. ige.chIPI, assigning rights and granting licences. Swiss guidance distinguishing ownership from permitted uses, without assessing an individual contract. Undated page, accessed 13 November 2026.ige.ch
  2. developer.apple.comApple Developer, Upcoming Requirements. OS and SDK requirements for App Store Connect uploads, distinct from removal from sale. Changing schedule accessed 13 November 2026.developer.apple.com
  3. developer.apple.comApple Developer, App Store Improvements. Review and removal process for outdated or malfunctioning apps. Undated page, accessed 13 November 2026.developer.apple.com
  4. support.google.comGoogle Play, Target API level requirements. 2026 policy distinguishes submissions, updates and existing-app availability by device, with platform exceptions. Accessed 13 November 2026.support.google.com
  5. developer.apple.comApple Developer, Overview of app transfer. Account-to-account transfers and checks for associated services. Undated page, accessed 13 November 2026.developer.apple.com
  6. support.google.comGoogle Play, Transfer apps to a different developer account. Account conditions and separate handling of services and reports. Undated page, accessed 13 November 2026.support.google.com
Back to blogGaspard Chevassus · CEO, Appik Studio