Developer Console
Sign In
Sign In
Developer Console

IAP Best Practice - Improve App Startup Time

Calling In-App Purchasing (IAP) APIs on app startup can significantly increase the time it takes for the app to launch, resulting in a poor customer experience. As a best practice, the Amazon Appstore recommends making these server-side calls in the background to avoid delays when your app loads.

Avoid blocking the UI from loading

In Integrate the IAP API with your app, you are instructed to call getUserData() and getPurchaseUpdates() in the onResume() method to query a customer's entitlement status. These APIs require server-side calls to Amazon's back-end server. The first call is uncached and can take up to two seconds to execute, which can slow down your app startup time. Subsequent calls are cached and won't cause this delay.

To prevent startup delays, don't block your UI from loading while your app waits for a response from Amazon's servers. Instead, the Appstore recommends to use the last entitlement state that you have cached in your back-end server. This can be from the last time the user logged in or accessed the app, or from the last time Real Time Notifications was updated.

After you have received a response from getUserData() and getPurchaseUpdates(), query Amazon's Receipt Verification Service (RVS) to get the customer's current entitlement status. Doing this avoids synchronization issues. Cache the data you receive on your back-end server. You can then update your app's UI asynchronously to reflect any changes in the customer's entitlement status.

Architectural diagrams

Use these diagrams to help visualize what happens when making IAP calls while an app loads.

Typical flow: IAP calls block the UI from loading

This diagram shows the steps from app launch to app UI load when IAP calls block the UI from loading.

See typical flow description

Typical flow description

  1. The user clicks on the app to launch it.
  2. A black screen is displayed while the app UI loads.
  3. The app begins to start up. In onResume(), the app calls getUserData() followed by getPurchaseUpdates() on the UI thread. Loading is delayed by approximately two seconds. During this time, the user continues to see a black screen.
  4. The app calls RVS and checks entitlement status with the returned receipts.
  5. If the entitlement status is active, the app grants access to the customer.
  6. The app continues loading the UI by showing the splash screen.

In this typical flow, a customer sees a black screen for several seconds as the IAP calls are made, which gives the perception that app launch is slow.

This diagram shows the steps from app launch to app UI load, when the IAP calls are made in the background.

See recommended flow description
  1. Cache, or store in your back end, the previously used entitlement data for a minimum of 30 days.
  2. The user clicks on the app to launch it.
  3. The app displays the splash screen and loads the UI based on the cache data. The app does not check for entitlement data from the server.
  4. The app makes the getUserData() and getPurchaseUpdates() calls in the background. Loading the UI is not blocked.
  5. When getUserData() and getPurchaseUpdates() calls return, pass the receipts to your back-end server, which calls RVS to confirm the validity of the receipt.
  6. If the receipt is valid, synchronize your cache (or back end) with the new data.
  7. If needed, update or switch the UI to block or unblock the user from accessing content.

Last updated: Feb 02, 2023