Release & store operations

Treat a white-label app as a maintained product, not a one-time store upload. Each brand has its own identity, credentials, listing state, market availability, and approval lifecycle.

Who does what

AURA runs the release process for you — builds, store submissions, resubmissions, and rollout — provided the following stay current on your side:

• Store accounts and legal standing. The developer accounts are yours: agreements, fees, verification, and company details sit with your organisation, since Apple, Google, and Huawei contract with you, not AURA.
• AURA’s access. Signing certificates/keys, API access, and authorised users granted to AURA on those accounts. Release work stalls the moment this access lapses or is scoped too narrowly.
• Brand and listing content. Copy, screenshots, support/privacy URLs, and any market-specific content AURA needs to build and submit the listing.
• Release approval. A nominated approver on your side to sign off staging acceptance and each production rollout.

Payment gateway ownership is a separate concern — see Third-party payment gateways for that boundary.

Before submitting

• Confirm the app name and bundle/application ID are unique and final.
• Confirm the listing clearly represents your organisation and customer proposition. Similar apps with duplicate content can receive additional store scrutiny.
• Complete privacy, data-safety, account-deletion, and age-rating declarations against the actual enabled features.
• Verify support, privacy, terms, and marketing URLs in production.
• Test signup, sign-in, payment, panic, tracking, cancellation, notifications, phone/device paths, and account deletion on release builds.
• Test every launch language and target country.
• Verify production API, payment, analytics, push, and deep-link configuration; a successful staging build does not validate production credentials.

Track each store separately

Maintain a release record per platform rather than a single “released” status. At minimum track:

Store review times vary. Do not coordinate marketing or customer migrations around an assumed approval date.

After release

• Run a production smoke test that does not create an unintended live response.
• Confirm analytics, crash reporting, push notifications, deep links, and support routes.
• Monitor signup, subscription activation, and callout failures by app version.
• Keep older supported versions and forced-update policy explicit.
• Review store agreements, certificates, API keys, fees, and account contacts before expiry.
• Repeat acceptance testing when shared app capabilities or store requirements change.

Use the white-label go-live checklist for final production signoff.