Mobile App Release Pipelines: Signing, Store Review, Staged Rollouts, and Forced Upgrades

Introduction

A mobile release does not end when the build finishes. There is a chain of steps between the code on a developer machine and the version a customer installs from Google Play or the App Store. Each store has its own signing model, upload rules, review flow, release controls, and update behavior.

This guide walks through that chain from the point where a release build is prepared to what happens after it reaches users. The Android and iOS sections are kept side by side where the differences matter, especially around signing, store review, staged rollouts, and forced upgrades.

Quick Answer

Think of a mobile release as a sequence, not a single upload: prepare the release, sign it, create the store artifact, upload it, pass the store review, release it to a controlled audience, watch what happens, and then expand the rollout or ship a fix. The important part is that “approved by the store” and “available to every user” are not always the same thing.

Key idea Android and iOS both let you control how an update reaches users, but they do it differently. Google Play uses percentage-based staged rollouts for app updates, while Apple’s phased release is a seven-day schedule for automatic updates. Users can still manually download an iOS update during a phased release.

1. Release Pipeline Overview

The full release path can be summarized like this:

The exact terminology differs between Google Play and App Store Connect, but the responsibilities are similar. You need a release-ready artifact, a valid store record, a successful upload, a review outcome, a release decision, and a plan for what to do after users start installing the update.

A useful way to think about the pipeline is to separate the work into three parts: the artifact itself, the store review, and the rollout decision. Signing belongs to the artifact. Review belongs to the store.

2. Prerequisites for App Submission

Before the first upload, there are a few pieces that need to exist on both platforms. Some are technical, while others are store-side setup. Getting these ready early avoids a common situation where the build is finished but the store config is not.

Android

• A Google Play Developer account and an app record in Play Console.
• A stable application package name and release version information.
• A release signing setup. For Google Play releases using an Android App Bundle, the bundle is signed with an upload key before upload, while Google Play App Signing handles the signing used for distribution.
• Store listing and App content information, including the declarations and access details that apply to the app.
• A privacy policy and other required declarations when they apply to the app, such as ads, target audience, content rating, and sensitive permissions.
• A tested release build with release configuration and debuggable disabled.

iOS

• An Apple Developer Program membership and access to App Store Connect.
• An App Store Connect app record before the first build is uploaded.
• A Bundle ID that matches the app being built.
• Distribution signing: a distribution certificate and an App Store provisioning profile, or Xcode-managed signing.
• Version and build numbers set in the app bundle.
• Store metadata and any required compliance or review information before the version is sent to App Review.

The small detail that causes many first-time submissions to fail is that “the app builds” and “the app is ready for submission” are different checks. Store records, metadata, signing, versioning, and declarations are all part of the release.

3. App Signing and Release Artifacts

Signing is the point where a build becomes a release artifact that the platform can trust. Android and iOS both use cryptographic signing, but the roles of the keys and profiles are different.

3.1 Android signing flow

For a Google Play release built as an Android App Bundle, keep two keys separate: the upload key and the app signing key. The upload key is used by the developer to sign the AAB before it is uploaded. When Play App Signing is enabled, Google uses the app signing key to sign the APKs generated for users.

1. Open the Android project in Android Studio and select Build > Generate Signed Bundle / APK.
2. Select Android App Bundle and click Next. Select the application module.
3. If you do not already have an upload keystore, click Create new under Key store path. Enter the .jks file location, keystore password, key alias, key password, validity period, and certificate details, then click OK.

Android Studio - Generate Signed Bundle / APK

1. Select the new keystore, enter the key alias and passwords, choose the release build, and generate the signed AAB. Android Studio places the resulting bundle under the module's build/outputs/ directory.

Android Studio - Build Variants and release build selection

1. Upload the signed AAB to Google Play. With Play App Signing enabled, Google keeps the app signing key and uses it when creating the APKs distributed through Google Play.

What the developer is actually signing

The developer signs the Android App Bundle with the upload key. Google Play then takes over the distribution-signing step when Play App Signing is enabled. This separation also means a lost upload key can be reset without replacing the app signing key.

Configure the release signing configuration

For projects where the release signing configuration is stored in Gradle, Android recommends keeping passwords and other sensitive signing information outside the build files. A common approach is to keep the values in a separate keystore.properties file and reference them from the signing configuration. The release build type can then use that signing configuration.

If you only need to create a signed bundle for a release, the Generate Signed Bundle / APK flow is enough. If the project will generate release builds repeatedly, configuring the release signing configuration makes the process repeatable inside Android Studio.

Screenshot suggestion: Android Studio's Generate Signed Bundle / APK dialog and the release signing configuration are useful screenshots here because they show exactly where the keystore, alias, and release configuration are selected.

1. Future releases continue to be signed with the upload key before upload. If the upload key is lost, it can be reset; losing the app signing key is a much more serious problem for apps that are not using Play App Signing.

Do not mix up the two keys The upload key signs the artifact you send to Google Play. The app signing key is the key used for the APKs delivered to devices. Treat both as sensitive, but remember that they have different jobs.

3.2 iOS signing flow

On iOS, a distribution build is associated with the app's Bundle ID, an Apple Distribution certificate, and an App Store provisioning profile. Xcode can manage these signing assets automatically, or they can be created and selected manually.

1. Open the project in Xcode, select the app target, and open Signing & Capabilities.
2. Confirm the Bundle Identifier and Team. For the simplest setup, enable Automatically manage signing. Xcode can then manage the distribution provisioning profile used by the archive and upload workflow.

Xcode - Signing & Capabilities

1. If the project uses manual signing, create an App Store Connect provisioning profile in Certificates, Identifiers & Profiles. Select Distribution > App Store Connect, choose the App ID that matches the Bundle ID, select the distribution certificate, name the profile, and download it.
2. Back in Xcode, select the appropriate signing certificate and provisioning profile when using manual signing. Then choose a physical-device or generic iOS run destination and select Product > Archive.
3. Xcode creates an .xcarchive and opens it in the Archives organizer. Select the archive, click Distribute App, choose the App Store Connect distribution path, and follow the upload steps. App Store Connect processes the uploaded build before it appears in the account.

Xcode - Archives / Distribute App

Automatic vs manual signing

Automatic signing is the simpler option for most projects. Xcode manages the distribution provisioning profile when you use the Organizer archive and distribution workflow. Manual signing gives you direct control over which distribution certificate and provisioning profile are selected.

What the provisioning profile does

An App Store provisioning profile contains the App ID and a distribution certificate. The App ID used for the profile must match the Bundle ID of the app. The profile is part of the signing setup that allows the app to be distributed through App Store Connect.

Screenshot suggestion: Xcode's Signing & Capabilities tab is the most useful screenshot for this section. A second screenshot of the Archives organizer showing Distribute App makes the path from signing configuration to uploaded build easier to follow.

1. After upload, App Store Connect processes the build. The Bundle ID, version number, and build string are used to associate the build with the correct app and version.

Important distinction For App Store Connect, it is more accurate to think in terms of an uploaded build than a raw .app file. Xcode handles the archive, signing, export, and upload steps for the store workflow.

3.3 Version and build numbers

The practical rule is simple: make the customer-facing version understandable, and make the build identifier unique and predictable enough that the store can tell releases apart. On iOS, the user-facing version is controlled by the 'MARKETING_VERSION' build setting in Xcode, while on Android, it is defined by the 'versionName' field in the app manifest. Android uses versionCode to determine which version is newer. Apple uses the build string as the unique build identifier within the App Store Connect workflow.

4. Uploading the Build and Store Review

Uploading a build and getting it approved are separate events. A build can be technically valid but still fail the review step because the app or its store information does not meet the store’s requirements.

4.1 Android: AAB to Google Play

Once the signed AAB is ready, the upload happens in Google Play Console. The important part is choosing where the build should go: Internal App Sharing is for quick sharing, while internal, closed, and open testing are Play testing tracks. Production is the public release track.

1. Sign in to Play Console, select the app, and open the relevant area under Test and release.
2. Choose the destination for the build: Internal App Sharing for quick sharing, Internal testing for a small QA group, Closed testing for a controlled tester group, Open testing for a broader beta, or Production for the public release.

Google Play Console - Testing tracks

1. Create or edit the release for the selected track and upload the signed .aab. Play Console runs validation and shows errors or warnings that need attention.
2. Complete or confirm the store-side information required for the release, then save the release and submit it through the appropriate Play Console flow.
3. For testing tracks, add or configure the tester group and share the Play Store or opt-in link as required. For production, choose the rollout controls that apply to the release.
4. After submission, follow the release status in Play Console. Review, publication, and rollout are separate steps, so an uploaded bundle is not automatically the same thing as a production release.

Internal testing

Internal testing is intended for quick initial quality checks and supports up to 100 testers. Google recommends starting with an internal test before moving to closed or open testing.

Closed testing

Closed testing is for a wider but controlled group. Testers can be managed with email lists or Google Groups, and additional closed tracks can be created when separate groups need separate testing.

Open testing

Open testing makes the test version visible on Google Play and allows users to join the test. It is intended for a larger testing audience, so the app and store listing should be ready for that visibility.

Internal App Sharing

Internal App Sharing is separate from the normal testing tracks. It lets an authorized uploader quickly upload an APK or AAB and share a generated download link. The uploaded artifact is not part of the app's testing or production releases. Google re-signs Internal App Sharing artifacts with an Internal App Sharing key.

A single Internal App Sharing link can be used by up to 100 users, and the download link expires after 60 days. This makes it useful for quickly putting a build in testers' hands without setting up a normal testing release.

Screenshot suggestion: the Play Console Test and release area showing Internal testing, Closed testing, Open testing, and Internal App Sharing would make this part much easier to scan.

If an update is rejected Google says the previously published version of an existing app remains available. Fix the policy issue before resubmitting the rejected update. A rejection by itself does not remove the last approved version from Google Play.

4.2 iOS: upload a build to App Store Connect

After creating the archive in Xcode, upload the build to App Store Connect. Apple supports uploading builds with Xcode, Swift Playground, altool, or Transporter. In the normal Xcode workflow, use the Archives organizer and Distribute App.

1. In Xcode, select the archive in the Archives organizer and click Distribute App.
2. Choose the App Store Connect distribution path and upload the archive. Apple processes the build before it appears in App Store Connect.
3. Open the app in App Store Connect and go to TestFlight if the build is for beta testing, or select the build for the app version that you plan to submit to App Review.
4. For TestFlight, create or select an internal or external testing group and add the build to that group.

App Store Connect - TestFlight tester groups

1. For an App Store release, provide the required metadata and select the uploaded build for the version before submitting it to App Review.
2. Track the build and submission status in App Store Connect. A build can be processed, tested through TestFlight, selected for review, accepted, rejected, or waiting for a release action depending on its stage.

TestFlight: internal testers

Internal testers are App Store Connect users with access to the app. You can create internal testing groups and add up to 100 internal testers. Builds can be distributed to these testers through TestFlight.

TestFlight: external testers

External testers are people who are not App Store Connect users with access to the app. You can create external testing groups and invite up to 10,000 external testers per app by email or public link. The first build submitted to an external testing group must pass TestFlight App Review before external testing can begin.

TestFlight build status

After upload, App Store Connect can show statuses such as Invalid Binary, Missing Compliance, Ready to Submit, Waiting for Review, In Beta Review, Ready to Test, Testing, Rejected, or Expired. These statuses describe the build's state and are separate from the overall app status.

TestFlight builds are available for testing for up to 90 days. If a build expires, upload a new build for continued testing.

Screenshot suggestion: App Store Connect's TestFlight page showing Internal Testing and External Testing groups is a useful screenshot because it makes the two tester paths immediately clear.

One small but useful point: you can upload multiple builds for an app version, but only one build is associated with the version when you submit it to App Review. That makes the build-selection step worth checking before you click Submit for Review.

4.3 iOS app, submission, and availability statuses

App Store Connect uses different status groups for the app, the submission, individual items, and App Store availability. They should not be treated as interchangeable.

Common app statuses include:

• Prepare for Submission - the app record exists and is still being prepared.

• Ready for Review - required metadata is complete and the app is ready to be submitted.

• Waiting for Review - Apple has received the submission but review has not started.

• In Review - App Review is currently reviewing the submission.

• Accepted - the item has been accepted, although other items in the same submission may still need action.

• Pending Developer Release - Apple accepted the app, but the developer still needs to release it.

• Processing for Distribution - Apple is processing the app before it becomes ready for distribution.

• Ready for Distribution - the app has been accepted and is ready for distribution.

• Rejected - App Review did not accept the app.

• Metadata Rejected - the metadata was not accepted and needs to be corrected.

• Developer Rejected - the developer removed the app from review and can resubmit it later.

App Store availability has its own statuses, such as Available, Available on App Release, Processing to Available, and Not Available. This is why an app can be accepted by App Review without necessarily being immediately downloadable in every country or region.

4.4 Upload failure vs review rejection

5. Staged Rollouts and Release Management

A staged rollout is a safety mechanism. Instead of making the new version the normal update path for everyone at once, you release it to a smaller audience first and increase the exposure when the release looks healthy.

5.1 Android: staged rollouts in Google Play

• Staged rollouts apply to app updates, not the first production release of an app.
• You select a percentage of users for the rollout and can increase that percentage over time.
• Eligible users are selected randomly for each new rollout.
• You can halt a rollout and later resume it. Google notes that resuming a halted rollout affects the same set of users.
• A rollout can also be limited to selected countries when it is created.
• The selected percentage is a target for availability; it can take time for the full group to receive the update.

5.2 iOS: phased release in the App Store

• Apple’s phased release option releases an update over seven days.
• The schedule is 1%, 2%, 5%, 10%, 20%, 50%, and 100% of users on eligible devices with automatic updates enabled.
• Users are selected as a random sample for the phased release.
• Users can still manually download the update from the App Store at any time, so phased release is specifically about automatic updates.
• A phased release can be paused for up to 30 days, with no limit on the number of pauses.

5.3 Store availability vs rollout percentage

This is one of the easiest parts of mobile releases to misunderstand. A rollout percentage is not the same thing as the store saying “this version is available to exactly X% of all users, and nobody else can get it.”

• On Google Play, the staged rollout makes the update available to a selected percentage of eligible users. Google notes that it may take time for the full group to receive the update.
• On iOS, phased release controls the flow of automatic updates over seven days. Apple explicitly says the update can still be manually downloaded from the App Store during that period.
• Therefore, a version can be approved by the store and technically available while only a controlled portion of users receive it automatically.
• This matters for forced upgrades. If your app requires a minimum version that is still in a staged or phased rollout, you can create a bad user experience by requiring an update that the store has not made available to that user yet.

Practical rule for forced updates Do not make “minimum supported version” a blind yes/no switch. The app should also handle the case where the required version is not yet available to the current user.

6. Monitoring After Release

The release decision is not finished when the rollout starts. The next step is to watch whether the new version behaves normally before expanding its audience.

• Track the release status and rollout history in the store console.
• Watch production quality signals such as crashes, ANRs, performance problems, and user feedback.
• Compare the new release with the previous version before increasing the rollout.
• Keep backend changes compatible with both the old and new app versions while the rollout is in progress.
• If a serious issue appears, stop or pause the rollout where the store allows it and prepare a fixed release.

Google Play provides release information including installs, updates, performance issues, ratings, and rollout history. App Store Connect provides App Analytics and release status information. The exact dashboards differ, but the operational idea is the same: use store data and production signals before increasing exposure.

7. Forced Upgrades and Minimum Supported Version

A forced upgrade is an app-level product decision, not simply a store setting. The store provides update and distribution mechanisms, but your app still needs to decide when an old version can continue and when it must stop.

7.1 Android options

Google Play provides an official in-app update flow. There are two main user experiences: flexible and immediate.

• Flexible update: the update downloads in the background while the user can continue using the app. Your app then completes the update and restarts when appropriate.
• Immediate update: the update flow is designed for critical changes and requires the user to update and restart before continuing to use the app.
• Your app can also use update availability, staleness, and update priority to decide how strongly to prompt users.

The important limitation is that these flows still depend on the update being available through Google Play. A product-level minimum-version rule should therefore be combined with a safe fallback when the required release is not yet available to a given user.

7.2 iOS options

Apple’s App Store Connect documentation covers phased release, manual release, and the normal App Store update process, but it does not describe an equivalent store-provided in-app “immediate update” API. For iOS, a common product design is to keep the minimum-supported-version policy in your own service and let the app decide when to show a soft or blocking update screen, then send the user to the App Store.

This design also gives you control over exceptions. For example, you can keep an old version working for a period, then raise the minimum version only after the new version is broadly available.

7.3 Recommended high-level design

A simple design looks like this:

A useful server-side model can be as small as minimum_supported_version, recommended_version, and a platform-specific store URL. You can also add a release state such as rollout_ready or a date field if your release process needs more control.

7.4 Edge cases to handle

• The device is offline and the app cannot fetch the latest policy.
• The required version is still inside a staged or phased rollout.
• The user is on a test build that should follow a different minimum version.
• The store link is valid but the update is unavailable for the current country or device.

8. Recommended Mobile Release Strategy

A practical release process can stay simple as long as each step has a clear purpose:

1. Prepare the release and verify the production configuration.
2. Sign the Android or iOS release artifact with the correct signing setup.
3. Check version and build numbers before upload.
4. Upload the build and complete the store-side metadata and declarations.
5. Submit to store review and resolve any rejection before trying to release.
6. Start with testing or a controlled production rollout where the store supports it.
7. Watch production behavior before increasing the rollout.
8. Pause or stop the rollout when the release shows a serious problem and ship a fix.
9. Raise the minimum supported version only when the required version is realistically available to the users you are going to block.

The main lesson A safe mobile release is not just “upload and publish.” Signing, review, availability, rollout, monitoring, and upgrade policy all affect what version a real user ends up running.

9. Common Problems / Errors

Most release problems fall into a few predictable categories: signing, version and build numbers, upload and processing, store configuration, and review.

9.1 Android

AAB is signed with the wrong key

With Google Play App Signing, the upload key and app signing key have different jobs. The upload key is used to sign the bundle before it is uploaded to Play Console, while Google uses the app signing key for the APKs distributed to users. If the upload key is lost or compromised, Google provides a process to reset the upload key without changing the app signing key.

What to check:

• Which key is configured in the release signing configuration.

• Whether the AAB is signed with the expected upload key.

• The certificate fingerprints shown in Play Console.

• Whether Play App Signing is enabled for the app.

Release cannot be created

Play Console can prevent a release from being published when there are unresolved errors in the release configuration. Check the Errors summary and resolve the reported issues before publishing. Warnings should also be reviewed because they may indicate release problems even when they do not block publishing.

Build is uploaded but cannot be used for the expected track

Make sure the release was created under the intended Play Console track. Internal testing, closed testing, open testing, and production are separate release paths, each with its own audience and purpose.

9.2 iOS

Build remains in Processing

After a build is uploaded to App Store Connect, Apple processes it before it becomes available for use in App Store Connect. If processing takes longer than expected, open the build details and review the reported status or messages.

Build shows Failed

A failed build has a problem that prevented App Store Connect from processing it successfully. Review the reported errors and warnings, fix the underlying issue, and upload a corrected build.

Bundle ID does not match

The Bundle ID in the uploaded build needs to match the app record and signing configuration used for that app. The Bundle ID is part of how App Store Connect associates a build with an app.

Wrong build selected for App Review

Uploading a build does not automatically submit that build for review. Before submission, select the build that should be associated with the app version and verify that it is the intended release build.

App is rejected during review

A review rejection is different from a build upload or processing failure. Read the rejection message, fix the issue identified by App Review, and resubmit the corrected version or submission.

10. Best Practices

A release process becomes much easier to manage when a few things stay consistent from one version to the next.

10.1 Protect signing credentials

Signing keys, certificates, and private keys should be treated as sensitive release assets. Keep the Android keystore and its passwords secure. For Apple platforms, protect distribution certificates, private keys, and the credentials used to access the Apple Developer and App Store Connect accounts.

10.2 Keep release and development configurations separate

Before uploading, verify the application or package identifier, version information, build identifier, signing configuration, release settings, permissions, capabilities, and other store-specific configuration. The fact that a debug build works does not mean the release configuration is ready to publish.

10.3 Test the actual release build

Test the same release artifact that you intend to distribute. For Android, Google recommends thoroughly testing the release version on target devices before distribution. This also helps catch issues caused by release-only configuration.

10.4 Start with a small audience

Use the platform testing tracks or staged/phased release controls to expose a new version gradually where appropriate. This gives you a chance to detect problems before the update reaches the entire user base.

10.5 Monitor before increasing distribution

Watch crashes, ANRs or hangs, performance issues, important user flows, version adoption, user reports, and backend compatibility before increasing rollout. Use the quality and release information provided by Google Play Console and App Store Connect together with your application monitoring.

10.6 Do not depend on the store as your only rollback mechanism

Mobile rollback is not the same as rolling back a server deployment. Once a version has reached users, some users may continue running it. A practical response to a serious issue is to stop or pause the rollout where the store allows it, fix the problem, and publish a corrected version.

11. Performance & Security Considerations

11.1 Performance considerations

Test release builds

Performance testing should use a build that is representative of what users will receive. Android recommends using release builds for performance testing because debug builds can significantly affect measurements.

Check performance on real devices

Test the release on the types of devices you expect your users to have. High-end hardware may hide performance problems that are visible on lower-end devices.

iOS performance

On Apple platforms, use Xcode performance and diagnostics tools to investigate launch time, responsiveness, memory use, storage, energy usage, hangs, and other release-time problems.

11.2 Security considerations

Protect signing keys

A compromised signing credential can have serious consequences. Protect Android upload keys and Apple distribution credentials, and keep private keys out of source-controlled project files whenever the tooling allows a safer configuration.

Use secure communication

Use secure network communication for sensitive data. Android provides security guidance and platform mechanisms for secure communication, while Apple provides App Transport Security and related APIs for protecting network connections.

Protect sensitive data

Do not store credentials or other sensitive information in plain text. Android provides Android Keystore and the application sandbox for protected data and key material. Apple provides Keychain Services for storing small pieces of sensitive information such as credentials.

Consider app integrity

For applications where tampering or abuse is a concern, Android provides Play Integrity API and Apple provides code signing and App Attest as platform security mechanisms that can help establish trust between the app and backend services.

12. FAQ

Do I need a new Android keystore for every release?

No. For an existing app, you normally continue using the existing upload-key setup for future releases. Creating a new key without understanding the current Play App Signing configuration can cause signing problems.

What is the difference between an Android upload key and app signing key?

The upload key is used to sign the app bundle before upload. The app signing key is used by Google Play to sign the APKs that are distributed to users when Play App Signing is enabled.

Can I upload an iOS build directly to App Store Connect?

Yes. Apple supports uploading builds through Xcode and other supported upload tools. In the normal Xcode workflow, you archive the app and use the distribution flow to upload the build to App Store Connect.

Does uploading a build mean that it is available to users?

No. Uploading and distributing are separate steps. On Android, a build can be placed in a testing track or production. On iOS, a build can be distributed through TestFlight or selected for an App Store version and submitted for review.

Can I test an iOS build before App Review?

Yes. TestFlight supports internal and external testing. Internal testers are App Store Connect users, while external testers can be invited through TestFlight.

What happens if my iOS build fails processing?

Review the errors and warnings reported for the build in App Store Connect, fix the underlying issue, and upload a corrected build.

Can I immediately roll back a bad mobile release?

Not in the same way as rolling back a server deployment. Once a version has reached users, some users may continue running it. The practical response is usually to stop or pause the rollout where possible and publish a corrected version.

Why can a forced upgrade be a problem during a staged rollout?

Because store approval, store availability, and rollout percentage are not the same thing. If your app to update before the required version is available to them.

External References

• Android Developers - Publish your app: https://developer.android.com/studio/publish

• Android Developers - Sign your app: https://developer.android.com/studio/publish/app-signing

• Android Developers - Version your app: https://developer.android.com/studio/publish/versioning

• Google Play Console Help - Prepare and roll out a release: https://support.google.com/googleplay/android-developer/answer/9859348?hl=en

• Google Play Console Help - Release app updates with staged rollouts: https://support.google.com/googleplay/android-developer/answer/6346149?hl=en

• Google Play Console Help - Prepare your app for review: https://support.google.com/googleplay/android-developer/answer/9859455?hl=en

• Google Play Console Help - Enforcement process: https://support.google.com/googleplay/android-developer/answer/9899234?hl=en

• Android Developers - In-app updates: https://developer.android.com/guide/playcore/in-app-updates

• Apple Developer - App Store Connect workflow: https://developer.apple.com/help/app-store-connect/get-started/app-store-connect-workflow

• Apple Developer - Upload builds: https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds

• Apple Developer - Create an App Store provisioning profile: https://developer.apple.com/help/account/provisioning-profiles/create-an-app-store-provisioning-profile

• Apple Developer - Register an App ID: https://developer.apple.com/help/account/identifiers/register-an-app-id

• Apple Developer - Submit an app: https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-app/

• Apple Developer - App and submission statuses: https://developer.apple.com/help/app-store-connect/reference/app-information/app-and-submission-statuses

• Apple Developer - Release a version update in phases: https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases/

• Apple Developer - Manually release a version to the App Store: https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option