Mobile app handover checklist

A complete handover lets another authorized team build the app, prepare an update, operate its services and understand the known risks. Start with an inventory of repositories, supported platforms, backend services, store listings, account owners and release responsibilities. Distinguish an agency staff change from transferring the app to another legal account: the latter has provider-specific procedures. Set an acceptance exercise before collecting files, so the handover is tested against an operational outcome rather than the size of a delivered archive.

Provide the exact source revision for the current release, dependency lockfiles, required tool versions and build instructions. Describe configuration names and how an authorized person obtains values through the approved secret store; do not put credentials in a public repository or handover email. Include native projects, build-time assets and private package access where required. On a clean authorized environment, produce a release candidate and identify every undocumented dependency encountered. A successful build on the departing developer’s laptop is not enough.

Check Apple and Google’s transfer requirements for the app’s current configuration before promising a completion date. Apple distinguishes transferring a store record from exchanging the actual source and build assets. Google also identifies associated reports and service arrangements that need separate attention. Keep account holders involved and use named access rather than shared personal passwords. Document signing arrangements, upload access and recovery ownership. Revoke old access only after the receiving team has verified its own access and the necessary dependencies.

Consider an app that uses a separate backend for customer login and a service for push notifications. Transferring its store listing does not prove that the receiving team can administer either service. Map the app identifier, backend deployment, notification credentials and account-recovery process separately. Have the receiving team build a candidate, sign in with a controlled account and receive a test notification on an authorized device. If any step depends on the former team’s personal account, record that dependency and resolve it before declaring the transfer complete.

Include API contracts, release notes, supported-device policy, known defects, crash-reporting access and the current incident path. Explain database and API compatibility when older app versions remain in use. Record how to disable a risky feature or recover a backend deployment, and which actions need business authorization. Store test instructions with the source and distinguish provider test environments from production. Keep the list of recurring services and their renewal owners accessible to the business, not hidden in an individual developer’s billing account.

Ask the receiving team to follow the documentation without relying on unwritten instructions. They should locate the current source, build the candidate, access the correct store project and prepare the intended distribution step. A real public release is not necessary merely to prove account access; use an agreed controlled route. Record missing items, accepted limitations and accountable owners. After resolution, rotate or revoke superseded access as appropriate and retain a dated handover record.