Last month we wrote about the newest additions to the mobile testing matrix – Amazon’s Kindle Fire HDX line and version 3.0 of their FireOS. You already know that these new offerings will require additional mobile app testing, but what exactly should you focus on to make sure your app looks perfect on the new tablets and runs perfectly with the new OS?
To answer that question we went straight to the source. Mike Hines, an Amazon Appstore Technical Evangelist, sent us 10 guidelines to help you optimize your app.
On September 20th 2013, Amazon introduced a new generation of Android-based tablets. The hardware spec on these devices is pretty impressive, and there are a lot of new customer-focused enhancements we’ve added to the stock build of Android 4.2.2 (API level 17). We call our enhanced Android build FireOS 3.0, but developers should know that as far as apps are concerned, this is Android Jelly Bean.
While 75% of Android apps submitted to Amazon just work on Kindle Fire, and require no additional development, most developers would like to make sure that they are not in the other 25%! To help you make sure that your Android app is going to be in the 75%, we have collected the top 10 issues that cause apps to fail, and some guidelines so you can avoid them. 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.
1. New Device IDs
The single largest issue we see on the new HDX devices is usage of incorrect device IDs. We recommend that you use capability detection to determine which features to support and which layouts to use. This is much more likely to work on new devices, and should be easier to maintain.
However, if you have used specific device detection in your code, you should be aware that each of the three new devices has a new model number, and you will need to update your code with the correct Device ID list or switch to capability detection. You can find specifics on the Kindle Fire Device and Feature Specifications.
2. 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.
3. 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.
4. 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.
5. Icon Mismatch
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.
6. 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.
7. Poor Usability
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.
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.
9. Networking resilience
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.
10. Things to consider about graphics
The new devices now use Andreno hardware. If you use a development framework like Unity, Epic or other, please make sure that you select PowerPVR and Andreno options when building your apps!
You should check to see if your visual assets look good at the 2560×1600 resolution of the new 8.9” device. If not, you should supply 2560×1600 assets instead of letterboxing your existing content.
You can follow me on Twitter @MikeFHines