A developer's guide to staged rollouts for the Amazon Appstore

Staged rollouts are a release strategy that allows you to gradually deploy your app update to a subset of users before making it available to everyone. Instead of pushing the update to all users at once, you can select the percentage of users who receive the update in stages. For instance, the update might first be available to 5% of users, and gradually increase the rollout to 10%, 20%, and so on until it reaches 100%.

By releasing the update to a small portion of the user base initially, you will be able to quickly identify and address any unforeseen bugs or compatibility issues before a widespread release. Implementing a staged rollout will also provide you with valuable real user feedback in order to fine-tune the app based on user responses and behavior. In addition, staged rollout mitigates the risk of preventable large-scale app failures. If critical issues are identified, you can halt a rollout before it impacts a significant number of users. Lastly, you can closely monitor diagnostics for app performance, server load, and network usage during each stage to ensure optimal updates.

• 10,000 unique downloads minimum: Staged rollouts are only available when the live version of your app has had at least 10,000 unique downloads in the past three years on the Amazon Appstore. The 10,000 minimum establishes enough volume for the staged rollout data to be meaningful.
• Rollout audience: The rollout is applied to randomly selected users who have downloaded your app and prospective users with eligible devices based on your app’s requirements. Users will be from the countries that you have selected for your app to target.
• Appstore certification: Amazon Appstore tests and approves your app when you initially begin a staged rollout and if you edit a staged rollout. No testing or approval is required from Appstore to increase the staged rollout percentage.
• AAB/APK files: Metadata from the live app version will continue to be displayed to the staged rollout recipients (for example, the description, images and multimedia, availability and pricing, device support options, and more). Users will receive only the AAB/APK file in your staged rollout. Staged rollouts is limited to Android AAB/APKs only and is not available for web apps.
• Content rating cannot change: You cannot change the content rating of your app in a staged rollout.

1. Testing and QA: Thoroughly test the update before the initial rollout. Consider using Live App Testing (LAT) with beta testers or an internal testing group to catch potential issues early on.
2. Define release goals: Determine your objectives for the staged rollout. Consider factors such as testing new features, validating performance improvements, and assessing user feedback.
3. Start with a 1-10% rollout: Start with 1-10% of the total user base, and if everything goes well, gradually increase the percentage in subsequent stages.
4. Monitor performance: Use analytics tools to track the app's performance during each stage. Pay attention to crash reports, app responsiveness, and user engagement metrics. Compare this data to the app's previous version to identify any anomalies.
5. Iterative improvements: Based on the feedback and performance data, iterate and release updated versions as needed (see Halting a staged rollout below).
6. Monitor server: Keep an eye on server performance and scalability during the rollout to ensure that the infrastructure can handle any server side updates.
7. Rollback plan: A rollback is the process of reverting to a previous version of an app after an update has been deployed. Having a rollback plan in place is crucial, in case a critical issue occurs that requires an immediate reversal of the update (see Steps to Rollback a staged rollout below).

1. To start a staged rollout, follow the same initial process for adding an upcoming version of your app on the Developer Console. To start a staged rollout, select Review & Submit > Staged rollout.

Even with meticulous planning and testing, unexpected issues may arise during the rollout process. In such cases, knowing how to halt a staged rollout promptly can prevent potential negative impacts on user experience and protect your app's reputation.

Common issues:

1. Critical bugs: Severe bugs that significantly impact the app's functionality, stability, or security warrant an immediate halt to the rollout.
2. Performance issues: If the app's performance degrades substantially after the update, stopping the rollout becomes essential to prevent a negative user experience.
3. User feedback: Pay close attention to user feedback during the rollout. If multiple users report similar issues, it might be necessary to halt the deployment for investigation.
4. Server overload: Unexpected server overload due to a high volume of app requests can negatively affect app performance. Halting the rollout can alleviate the strain on servers and prevent further issues.

Steps to halt a staged rollout:
If you want to make changes to any of the tabs (including replacing the AAB/APK file), you must halt the staged rollout by selecting Halt staged rollout from the staged rollout menu and then select Edit staged rollout:

1. Go your staged rollout version in the Developer Console (see View details of your staged rollout).
2. Click Staged rollout, and then select Halt staged rollout. In the Halt staged rollout dialog box, click Halt.
3. From the same Staged rollout drop-down menu, select Edit staged rollout.
4. Once the tabs are editable, you can update your AAB/APK file (perhaps replacing it with one that fixes some issue you detected). When you're ready to resume the staged rollout, you'll see an option to "Resubmit and resume staged rollout."
5. Your app will need to go through testing and approval again just as with the first version of your staged rollout.
6. Once approved, users who were already targeted for the staged rollout (and who downloaded a previous AAB/APK ) will get the new version of your AAB/APK when you resume your staged rollout. The Appstore never reverts versions of AAB/APK’s that users already downloaded to their devices.

To "rollback" the version used in your staged rollout, you halt and edit your staged rollout; then you replace your APK with your original APK (but with a higher versionCode) and submit the new version to all your users.

Steps to rollback a staged rollout:

1. Go your staged rollout version in the Developer Console (see View details of your staged rollout).
2. Click the Staged rollout button, and then select Halt staged rollout. In the Halt staged rollout dialog box, click Halt.
3. From the same Staged rollout drop-down menu, select Edit staged rollout.
4. On the App Information tab (which is now editable), replace the staged rollout APK with your original APK. Make sure the versionCode is higher than the versionCode in the previous staged rollout APK.
   Important: Users will only get an updated APK if the versionCode of the new APK is higher than the versionCode of the APK they have installed.
5. Click Save to save changes on the App Information tab. Although you could resubmit the APK to resume the staged rollout with a new APK, in this scenario, we will abandon the staged rollout workflow and publish the app to all users directly.
6. Click Submit App. By submitting your app, you will be publishing this version out to all your users. Your app will need to undergo testing and approval from the Appstore. In the submit app dialog box, click Submit to confirm that you want to publish your app. You should see a message that says "App Submission Successful."

A staged rollout ensures a consistent release of updates for your customers. This approach helps gather valuable feedback, identify and fix bugs, and reduce risks associated with large-scale deployments. Keep in mind that a successful staged rollout is just the beginning. It is essential to continuously listen to your users, collect feedback, and iterate your app further.

• Release Your App Update in a staged rollout
• Staged rollout FAQ
• 7 developer best practices for app updates