Mobile App Handover: Protect Access and Future Updates

Brand article supplied by Saglotech. Originally published on 20 October 2026.

The app works on the developer's phone. The demonstration looks convincing. Your team is ready to launch. Before signing off, ask a different question: could your business maintain and release the app if the original developer became unavailable?

A mobile app handover is more than a source-code download. It brings together business account control, build instructions, release access, operational support and a clear record of what has actually been delivered. For South African businesses commissioning Android and iOS apps, agreeing these items early can prevent a difficult supplier change later.

Separate contractual ownership from practical control

Clarify the ownership and licensing terms in the project agreement, with appropriate professional advice where needed. Do not assume that paying an invoice automatically answers every question about third-party components, pre-existing code or ongoing service subscriptions.

Practical control is a separate check. Your business may have an agreed right to use the code but still lack access to the repository, hosting account or store listing. Conversely, an account login does not establish the intellectual-property terms. Keep the contractual record and the technical access register together, but do not treat one as a substitute for the other.

List the systems involved: source repository, app stores, backend hosting, domain, database, messaging provider, analytics, crash reporting and any payment or mapping services. Identify the account owner and operational contact for each. Record renewal responsibility without putting secrets into the register.

Establish business-controlled store accounts

Decide which legal entity will publish the app and complete the platform's current enrolment requirements. A supplier should not quietly become the permanent owner of the publishing relationship simply because it was easier to start there.

Apple documents distinct App Store Connect account roles. Use the platform's role-based access to assign responsibilities rather than sharing one person's login. Review the access needed for the actual work, and retain an authorised business contact who can manage the account.

Ask the developer to demonstrate where the app listing, release history and relevant account contacts are managed. Do not request passwords in email. If an app is already published under a supplier's account, discuss a formal transfer assessment; eligibility and dependencies must be checked rather than assuming a transfer is a simple button press.

Verify the source repository and a repeatable build

A repository should contain the delivered project, not an old prototype that cannot produce the current release. Ask the team to identify the version corresponding to the accepted build and to document required tools, dependencies and configuration. Keep private credentials outside the source code.

Arrange a clean-build demonstration. A suitable technical person should follow the written instructions in a fresh environment, using authorised access, and produce a test build. Record anything that required an undocumented local file, a personal account or assistance from the original developer.

The purpose is not to make a business owner become a software engineer. It is to establish that the work can be maintained by another competent team. A screenshot of a successful app screen cannot provide the same evidence as a reproducible build and a documented release process.

Understand signing and release access

Android applications use digital signing. Google's app-signing documentation explains the distinction between the app-signing key and the upload key when using Play App Signing. Have the developer document the arrangement actually used for your app and the authorised recovery process.

Do not ask for secret keys to be placed in a public repository or ordinary project document. Instead, confirm where sensitive material is held, who can use it and how the business would recover access. Different distribution arrangements have different implications, so a generic statement that “Google keeps everything” is not enough.

For each supported platform, identify who can prepare, approve and submit an update. Confirm that these responsibilities remain workable during staff leave or a supplier transition. A release process that depends entirely on one person's laptop is an operational risk even if the first launch succeeds.

Include the backend and external services

Many apps depend on services that are not inside the mobile application. A booking app may rely on an availability database and an administration portal. A delivery app may use mapping and notifications. An online store app may depend on the ecommerce system's product and order data.

Ask for a simple dependency map showing the app, backend, administration tools and third-party services. For each connection, explain what it does and what users experience when it is unavailable. Include separate test and production environments so support staff know where it is safe to experiment.

Confirm billing ownership and spending alerts for metered services. Avoid quoting an ongoing monthly total unless the assumptions are clear. Usage, supplier pricing, support arrangements and future feature changes can all affect costs. The handover should identify what must be monitored, not pretend those costs never change.

Accept complete journeys, not isolated screens

Choose representative tasks and perform them from start to finish. A customer should be able to create an account, complete the agreed task and recover from a realistic error. Staff should be able to find the resulting record and carry out their part of the workflow.

For a hypothetical booking app, test making a request, changing an available slot, receiving the intended test notification and finding the booking in the administration area. Also test a lost connection and an unavailable slot. Do not use real customer accounts or charge a real payment method merely to make a demonstration look complete.

Keep a list of known limitations, outstanding defects and agreed exclusions. Distinguish a defect against accepted requirements from a new feature request. Both may deserve work, but the commercial and delivery decisions are different.

Agree how support starts after launch

Name the support contact and define how issues are reported. Useful reports include the app version, device, steps taken, expected result and actual result. Avoid sending screenshots containing customer information to a general group chat.

Clarify the warranty or defect-correction terms, maintenance scope, supported platforms and update responsibilities. Store-policy changes, operating-system changes and new business requirements can create work beyond the original build. Confirm how that work will be assessed and quoted instead of assuming that “support included” covers everything indefinitely.

Common handover questions

Is a source-code zip enough?

No. The code must correspond to the delivered app and come with workable build, configuration and release instructions. Access to dependent services matters as much as the download.

Should every employee have administrator access?

No. Assign the access each person needs and maintain an authorised recovery route. Broad shared access makes it harder to establish responsibility and safely change suppliers.

Can another developer maintain the app later?

That depends on the code, documentation, agreements and account access. A clean-build and handover review provides better evidence than a general assurance that the project uses a popular framework.

Make handover part of the app brief

Include these requirements before development begins, not after the final invoice. Review our mobile app planning guide for the wider project decisions. Saglotech's mobile app development service can help scope a practical Android or iOS project; schedule a consultation to discuss the app, its dependencies and the handover evidence your business needs.

Original article: Mobile App Handover: Protect Access and Future Updates — Saglotech