Test and publish app releases
Use this guide to move from an app request to a public release. Treat each stage as a checkpoint: complete the required inputs, test the build, prepare the store listing, and submit only when the customer-facing experience is ready.
Release lifecycle
- Gather the accounts, identifiers, content, and brand assets required for the app.
- Submit the app requirements through the project’s established request or support process.
- Grant the required Apple and Google account access through role-based invitations.
- Build a release that can be tested.
- Configure push notifications when they are part of the app configuration.
- Test the app and resolve the issues found before submission.
- Confirm that the website, stores, products, payments, and other customer-facing content are ready.
- Prepare the App Store and Google Play listing information and images.
- Upload the release to each store.
- Respond to the review outcome sent by Apple or Google.
- Confirm that the approved version is available in the intended store.
Apple and Google control their own review requirements, timing, and approval decisions. A completed build does not guarantee approval or publication.
Prepare the app requirements
Before a build can begin, prepare the information and resources that apply to your project:
- A Google Maps API key, if your app uses Google Maps.
- A Google Play Developer account.
- An Apple Developer account.
- Device identifiers when iOS testing requires them.
- The final app name and bundle or package identifier.
- Brand assets, including the home-screen logo, home background, app icon, and splash screen.
- A valid privacy policy that customers can access from your website.
Provide the app requirements
Use the app request form to provide the required information. Confirm the app name and brand assets before the build starts, since changes to store-facing metadata or visual assets can require another build and review cycle. The home-screen logo, home background, icon, and splash screen are the priority assets; configure additional Dashboard imagery as needed to complete the experience. If you do not provide replacement assets, default visual assets can remain in the app.
Include the project and app names, the app types you are requesting, and working links to the logo and any screenshots or other assets you want considered. Identify the Apple and Google developer accounts you will use. Provide access through the invitation steps below; do not send passwords or account credentials. Before requesting publication, make sure the project has real business and store content for reviewers to evaluate. For in-app Marketplace App images, see Marketplace App resources. For screenshots shown on the App Store or Google Play listing, see Update store listing images.
Keep access secure
Grant developer-account access with provider roles and invitations. Apple access depends on the account type: an individual account can invite people to App Store Connect, but the account holder must manage Certificates, Identifiers & Profiles. Organization accounts can use the eligible Apple Developer team roles. Do not send passwords, recovery codes, API keys, or two-factor authentication codes in a ticket, chat, email, or document.
For the account roles, certificates, and access details needed for app publishing, see Grant developer account access and Apple’s account-role guidance. If you manage iOS certificates yourself, use the Apple Developer Certificates, Identifiers & Profiles portal for the current process.
Build and configure the release
After the requirements are complete, create a build for testing. Keep an eye on the project communication channel in case the build team needs a missing asset, identifier, or configuration detail.
Configure push notifications
If your app uses push notifications, complete the notification-provider configuration before final testing. Some app configurations use OneSignal.
- For a single-app configuration, provide the email address that should receive the provider invitation and accept it in the provider account.
- For a configuration with separate customer, business, and delivery apps, create or use the required OneSignal account and grant access through its invitation workflow.
Use the provider’s role-based access controls in either case. Do not share provider credentials.
Test before public submission
Test the app before you upload it to a public store. Check the experiences that customers will use, and resolve functional or content issues while the release is still a test build.
Review the generated build on an emulator or a compatible physical device. Confirm that the app opens, the main screens and navigation work, the app name and branding are correct, images load without placeholders, and a real store and its content appear as expected. Test the customer flows that apply to your app, including sign-in, maps, notifications, and payment when configured. If you find an issue, correct the app settings or content that you can access. Create another build and retest only if your account permissions and project configuration allow you to do so; otherwise, contact your project administrator or Ordering.co support through your usual channel to coordinate the next build.
You can demonstrate and test an app before it is publicly listed. For iOS, use registered test devices when appropriate or TestFlight. Register the UDID for each test device in Apple Developer before creating a device-specific build. Apple Developer Program and Enterprise Program members can register up to 100 devices per product family per membership year; see Apple’s device overview for the current limit and exceptions. Public store submission is a separate stage and makes the app available to store users after approval.
Confirm the customer-facing content
Before you submit a release, review the content that a store reviewer and a customer will see:
- Stores: Keep active stores representative of a real operating business. Remove active demo or test stores.
- Products: Include enough product information for the experience to look and work as intended. You can update the catalog after publication when needed.
- Payment methods: If you offer a payment method such as Stripe or PayPal, confirm that it is configured and working before submission.
- Pending changes: Consider whether a pending custom change should be completed first. Changes made after publication can require you to submit a new app version.
Prepare store listing information
A store listing includes the app name, description, and screenshots that potential customers use to evaluate the app. Prepare final, accurate listing content and follow the current requirements in each provider’s console.
For the image workflow and store-specific guidance, see Update store listing images. For Google Play phone screenshots, use JPEG or 24-bit PNG files without an alpha channel and follow Google’s general minimum screenshot dimension of 320 px. Other device types, including tablets, Chromebooks, and Wear OS, have additional size, aspect-ratio, or count requirements. Check Google Play’s current preview-asset requirements for every device type you support before upload. Google may display the screenshots best suited to the viewer’s device, so the upload sequence does not guarantee the order every customer sees. You can use an image-composition tool such as Placeit or another tool that meets the store requirements. Apple and Google can change their listing requirements, so verify the requirements that apply to your app immediately before upload.
Upload and respond to review
When testing and listing preparation are complete, upload the build and its metadata to the applicable store:
Store review
Apple and Google review the submission and send the outcome to the email associated with the developer account. If a provider identifies an issue, review its message, make the required correction, and submit a new build if the provider requires one.
Confirm publication
After a provider approves the release, confirm that the published version and its store listing are available as intended.
FAQ
How long does publication take?
The lifecycle includes project preparation, building, testing, listing work, store submission, and a provider-controlled review. Its duration depends on the completeness of the inputs, the changes needed during testing, and Apple’s or Google’s review process. Do not plan a launch around a guaranteed review date.
Do apps need to be in the stores before they can be tested?
No. Test builds let you validate the app before public store submission. Use the testing path that fits the platform, then publish only after the app and its customer-facing content are ready.
Where can I get help with a release step?
Use your normal Ordering.co support channel and include the relevant app, platform, release stage, and any store review message. Never include account credentials or authentication codes.