There’s nothing worse than building an app that you’re proud of, submitting it and then finding it failed because of something simple that could easily have been avoided. To help make sure your app has the best chance of passing we have collected a few of the more common issues that we see to give you a head start on the process. All of these guidelines are aimed at creating a better user experience for your customers and hopefully making for a smoother process for you as a developer.
Links to other app stores
This is an easy thing to miss but is a factor in about one third of failed submissions. Apps that link to other app stores are not permitted on Amazon. To ensure a consistent experience for users, we test for these links and will alert the developer if found. To correctly link to Amazon within your app, please visit this page.
App functionality does not match its description
It may seem obvious, but an app not functioning as described is a significant factor in one in five submission failures. This can be a result of a feature highlighted in the description not being available, or failing and either showing an unhandled error to the user or causing the app to crash.
If your app relies on external assets, such as remotely hosted video files or data feeds, you should make sure all required resources are available and working as expected before submitting your app for testing as their absence often leads to these types of failures.
Call or SMS interrupt
If the app does not correctly pause, preserving state, when an incoming call or SMS arrives, or details are lost once the user has read the message or disconnected the call, then the app will fail testing.
In-App Purchasing Failure
If an app uses the Amazon In-App Purchasing API, our review process requires that the In-App Purchasing SKUs are available before the app is submitted in order to test them. The descriptions have to be accurate – leading or trailing spaces, additional special characters, or incorrect case can trigger a failure even if the expected item is available.
In addition, make sure that the SKU name in the Mobile App Distribution Portal matches the SKU in your app’s purchase request. If your app tries to purchase a SKU that’s not in the Distribution Portal, the in-app item purchase will fail. Remember that SKUs are case sensitive.
The icon in the app package needs to match the supplied icon for the catalog. This directly relates to the user experience and the first impression when an app is installed. If the icons don’t match then the user may find it hard to find the app they just installed and rate your app poorly.
Force close on launch and other stability issues
Believe it or not, about one in 20 apps fail to even launch during initial testing. Others crash repeatedly in general usage. Stability can either exhibit as a Force Close message, an Application Not Responding condition or the app simply returning the user to the launcher screen. We also see apps that don’t crash but simply display a blank screen and never proceed.
Incorrect device targeting, poor memory management, referencing APIs that are not present on the device, or making assumptions about the SD card path, among other things, can cause stability issues.
We test on real devices with current firmware and encourage developers do the same, if possible. Once an app is live we strongly recommend you regularly check the Crash Reports in the Distribution Portal to ensure any scenarios not identified in testing are not impacting your users.
If our review process identifies significant usability issues during testing, we will fail the submission. As most developers want users to enjoy their experience, this is becoming less of an issue over time but it still contributes to failures.
Examples of things that would be flagged here are:
- The display of the app is inverted or does not react as expected on rotation.
- Images are distorted, blurred, overlapped, obviously pixilated or stretched.
- Text in the app is cropped, blurred or unreadable.
- Some (or all) controls on the touch screen do not respond in a timely manner.
Suggestions for ways to manage text and graphics for different devices are discussed in the “Screen Layouts and Resolutions” document on the Distribution Portal.
To help protect your users we look for potential leaks of passwords and other data that should be secure. For example, you should not transmit or store any sensitive information, such as password, in plain text –or write them to the log in your production build.
If your app relies on a data connection to function, you should always ensure that you test and handle various network conditions. These include (but not limited to):
- No connectivity
- Unreliable or intermittent connectivity
- Consistent but degraded (low bandwidth) connectivity
If your app will be downloading data over a WAN connection, we would recommend that you notify the user and ensure they are aware of that. The “Data Transfers and Mobile Networks” article has more information about how you can handle it.
Forewarned is forearmed
Testing your app against this list will help you avoid some of the most common issues we see. Reviewing the general guidelines available at the Distribution Portal will help you understand the testing process.
The philosophy behind our testing process is to ensure your users have a good experience with your app. No developer likes to be told there’s something wrong with their app, so I hope this list helps you prepare for a great submission, and I look forward to seeing your app fly through testing into the store.