A mobile app is ready for production when the business can prove that its important user journeys work, its data declarations match the product, and named people can release and support it. A feature-complete build is not enough. The missing work usually sits around accounts, failed payments, support access, store submissions and the handover after launch.
For a South African business appointing mobile app developers through Galactic Digital’s development services, the useful approval question is simple: can we describe what will be tested, who signs it off, and what happens when a real customer gets stuck? If the answer is vague, the app is still in a build phase, regardless of the planned launch date.
Use a release decision, not a launch date
Set a production decision only after each item below has an owner and evidence. Evidence can be a test record, a screen recording, a signed acceptance result, a configuration export or a confirmed store submission. The point is to make a release repeatable when the app needs an urgent fix later.
| Release area | Approve production when | Hold the release when |
|---|---|---|
| Core customer journey | A real user can complete the main job, including confirmation and an expected failure path, on the supported devices. | The happy path works only with ideal data, a developer account or a stable office connection. |
| Accounts and access | Registration, sign-in, password reset, logout and account deletion or its documented route have been tested where the app provides them. | The team cannot explain how a customer regains access or how an administrator removes access. |
| Payments and orders | Success, cancellation, decline, duplicate submission, refund route and customer communication have named owners. | A payment can be taken without a reliable order state or support process. |
| Personal information | The data map, vendors, retention decisions and store disclosures are reviewed against the released build. | The privacy notice or store form was copied from an earlier app without checking SDKs and integrations. |
| Release control | The business owns the store accounts, production signing access and a documented rollback or hotfix path. | One supplier login is the only route to publish or repair the app. |
| Support | Customers have a support route, and staff can see the information needed to investigate a report without asking for unnecessary personal data. | There is no owner for incidents after the launch announcement. |
Start with the journeys that affect money, access and trust
Write the five to ten journeys that matter most to the business. For a booking app, that may include selecting availability, paying, receiving a confirmation, cancelling and getting help. For an internal field app, it may be sign-in, offline capture, sync conflict and device replacement. Each journey needs a known expected result and at least one awkward case.
Do not accept a statement that a screen has been tested. Accept a result instead: a customer who loses connectivity after submitting a booking sees a clear state, and the back office can tell whether the booking exists. That is a product and integration question, not just a mobile interface question.
Device coverage should follow the people who will use the app, not the devices available in the development studio. Android’s architecture guidance asks developers to account for different screen sizes, densities and form factors. Record the actual phones, operating-system versions and network conditions used for acceptance testing, then decide what the supported range is. A native versus cross-platform decision still matters here because device capabilities, offline behaviour and platform-specific work can change the test scope.
Check store requirements against the release build
Store declarations are product work. Apple requires App Store privacy details that cover an app’s practices and the practices of third-party partners whose code is integrated into it. Google Play’s Data safety section asks developers to disclose collection, sharing and security practices. Review those declarations after analytics, crash reporting, payment, authentication and messaging SDKs have been selected, and again before each material release.
On Android, the target API level is also a release constraint. Google’s current Play requirement says existing apps must target Android 15, API level 35, or higher to remain available to new users on devices running an Android version higher than the app’s target level. Treat this as a checked build setting, not a note in a proposal. Platform requirements change, so confirm the current requirement in Play Console and in the official documentation before submitting.
On iOS, TestFlight gives a business a practical beta route before App Store release. Apple says TestFlight lets teams invite users to test app versions before they are released. Choose testers who can exercise the app’s real workflow. A colleague who already knows every workaround is useful for regression testing, but is poor evidence that a first-time customer can use the product.
Make POPIA a scope item, not a footer link
POPIA applies to the processing of personal information by public and private bodies in South Africa. The responsible party remains accountable for lawful processing. This article is not legal advice, but a development scope should name the information collected, the purpose, the systems that receive it, the retention decision, and the person responsible for reviewing the privacy notice and operational process.
That list is especially important where an app uses location, identity documents, health information, account data or employee records. It also helps prevent a common release mistake: the app changes, but the privacy statement and store declarations do not. Ask the developer to identify every production SDK and server-side integration that can receive customer data. Ask legal or privacy advisers to review the business’s obligations where needed.
Agree the operational handover before approval
A release has two parts: publishing the binary and running the service after people start using it. Before approval, the business should know who owns the Apple App Store Connect and Google Play Console accounts, who receives expiry and policy notices, where production configuration is kept, who can rotate credentials, and who approves an emergency update.
Ask for a short handover pack containing:
- the source-code repository and the business’s access level;
- the production environment, domains, API endpoints and third-party account owners;
- release steps for Android and iOS, including the person permitted to approve production;
- a list of monitored failures and the route from customer support to the technical team;
- the acceptance criteria used for the release and known limitations that were consciously deferred.
This is where a vague brief becomes expensive. A mobile app development brief should make ownership, integrations and acceptance tests clear before estimates are compared. The launch checklist uses the same discipline at the other end of the project.
A compact approval meeting agenda
- Walk through the core journeys on the agreed devices and accounts.
- Review failed-payment, lost-connection and account-recovery behaviour.
- Compare the production SDK list with the privacy notice, Apple privacy details and Google Play Data safety answers.
- Confirm store ownership, production access and the emergency-contact path.
- Record any deferred item, its risk, its owner and the date it will be reconsidered.
The meeting should end with a decision: approve, approve with recorded constraints, or hold. “Nearly ready” is not a release status.
When to involve a development partner
Bring technical input in before a launch date is announced when the app depends on existing business systems, customer data, payments, offline use or a new operational process. Those dependencies shape the build, the acceptance tests and the support model. Galactic Digital builds websites, web applications and mobile products for businesses in Cape Town and across South Africa. If you need a release plan that connects the mobile app to the systems behind it, start a project conversation with Galactic Digital with the journeys, integrations and owners already listed.
Sources
- Guide to app architecture, Android Developers. Accessed 19 October 2026. Supports the need to account for Android device configurations and form factors.
- Meet Google Play’s target API level requirement, Android Developers. Accessed 19 October 2026. Supports the Android 15, API level 35 requirement stated above.
- TestFlight, Apple Developer. Accessed 19 October 2026. Supports the description of beta testing before App Store release.
- App privacy details, Apple Developer. Accessed 19 October 2026. Supports the requirement to disclose the app’s and integrated third parties’ privacy practices.
- Play Age Signals overview, Android Developers. Accessed 19 October 2026. Supports the description of Google Play’s Data safety disclosures.
- Information Regulator services, South African Information Regulator. Accessed 19 October 2026. Supports the South African POPIA context; obtain legal advice for a business’s particular processing activities.
Featured image: Media multitasking by William Iven licensed under CC0 1.0.