Mobile App Handover Checklist: What to Get From Your Developer

Start with an owner, access and evidence worksheet

An APK, IPA or store link shows a result. It does not tell you who can change the source, renew a service or submit an update. Use the worksheet below during a live handover, not just as a list of files to request.

“Owner” means the person or organization responsible for an asset. “Maintainer access” is the permission needed to do agreed work. Keep those separate. Document contractual rights to code and licensed materials separately too: repository access alone does not establish those rights.

For a new project, include these delivery expectations in the mobile app MVP brief. For an existing app, start with what is actually deployed rather than assuming the latest file in a shared folder is the release source.

Prove the source works away from the original laptop

Choose the exact commit or release tag being handed over. In a fresh working directory, an authorized maintainer should follow the documented setup using a test environment and fictional data. Record the required Flutter and platform-tool versions, dependency lockfile, environment configuration names, build variant and asset-generation steps where applicable.

The Flutter command-line reference documents commands such as flutter --version, flutter doctor, flutter pub get, flutter analyze and flutter test. They are useful checks, but the README must also give the project’s own build command and configuration. A project with flavors, generated files or native dependencies may need additional steps.

Do not solve a missing configuration by copying everything from the outgoing developer’s home folder. Document each required item, its purpose and its protected provisioning route. Include relevant source assets and generation instructions; exclude private credentials from the repository.

Ask the maintainer to record the source revision, tools, environment and output version. This proves the documented workflow is usable; it is not a claim that every rebuilt binary will be byte-for-byte identical. If the build fails, keep the cause and corrective step on the open-issues list rather than calling the handover complete.

Check who can sign and submit the next update

Building a debug app, creating a signed release and having permission to submit that release are different checks. Demonstrate the agreed release path without making an unapproved production change.

Google’s Play App Signing documentation distinguishes the key used to authenticate uploads from the key used to sign apps delivered to users. Establish which signing arrangement this app uses. A Google-managed app signing key is not simply a file to demand from a contractor. Arrange protected custody of the upload setup and document its recovery responsibility.

Flutter’s Android release guide explicitly warns against publishing the keystore and signing properties in source control. The handover worksheet should describe where authorized access is managed, not contain the secret values.

For iOS, Flutter’s release guide uses Xcode on macOS and the correct Apple app identity. Check the signing approach actually used by the project. Apple’s user-access documentation distinguishes individual and organization memberships and notes that certificate-related access can widen app visibility. Select appropriate permissions rather than assuming every collaborator needs an Admin role or a shared Apple Account password.

Inventory services, assets and operational decisions

List external services even when they are not visible on a screen: authentication, storage, notifications, purchases, crash reporting, advertising, email, domains and scheduled jobs. Mark anything unused explicitly. For each active service, record the environment, account owner, billing or renewal responsibility, access method and what stops working if it becomes unavailable.

Ask for configuration instructions, not an email full of production secrets. Use service invitations and scoped permissions where available. GitHub’s organization repository roles, for example, let teams assign access according to the work a collaborator needs to perform. Other account types and services have their own controls.

Include editable listing artwork, product text, third-party license records and the privacy-policy destinations the released app uses. Record who maintains accurate store disclosures when an SDK or feature changes. Identify purchase product IDs and configuration when purchases are in scope, without including payment-account credentials.

For local records or a backend, document the recovery and migration behavior you actually support. Use the local storage, backup and cloud sync worksheet when those promises are unclear. An exported report, server login or repository backup does not by itself prove that user records can be restored.

Run a small, concrete handover rehearsal

Consider a fictional reading-log app. Its agreed release saves a title and date, permits an edit and keeps the record after the app reopens. The rehearsal below tests operation and delivery, not whether new features should be added.

Flutter distinguishes unit, widget and integration tests. Ask what the suite actually checks. A green unit-test result does not replace checking an installed app’s full journey or the platform’s permission behavior.

Use a sandbox or approved test route for purchases, notifications and server writes. Do not test deletion, billing changes or a release against production merely to demonstrate access. Record the intended delivery state clearly: source delivery, beta availability, submission and public release are separate milestones.

Finish with a sign-off record and a safe access transition

Copy the following fields into a private handover record. Each row should say “verified,” “not applicable” or “open,” with evidence or an explanation. Do not include tokens, passwords, signing keys or production user records.

• App and release: Product name, platform identities, delivered revision and version.
• Recipient and owners: Receiving maintainer and the responsible owner of every active account.
• Build result: Environment, instructions used, resulting artifact and any missing steps.
• User-journey result: Agreed test cases, actual behavior and remaining defects.
• Release result: Protected signing access, authorized submission role and intended delivery state.
• Operational materials: Service inventory, source designs, licenses, recovery instructions and support notes.
• Open items: Issue, consequence, responsible person and agreed follow-up; do not silently omit a blocker.
• Access transition: Ongoing maintainer roles, any approved access-removal steps and when to verify them.

Confirm that replacement access works before removing access still needed for an agreed transition. Review unnecessary invitations and tokens through their owning services; if a credential was shared or exposed, agree on an appropriate rotation plan and check dependent systems. Account transfers, release changes and removal of access need their own authorized steps.

Moocsoft offers Flutter mobile app development. This worksheet gives a project discussion a concrete delivery target: an app someone can maintain, with known owners and a tested workflow, rather than an unexplained bundle of files.