Once you have completed an early version of your app you are ready to test and deploy to a number of devices. When you are developing by yourself, you tend to overlook certain aspects of real world mobile use and hence a lot of bugs can be found initially. This is not a complete checklist but some of the common pitfalls I have overlooked in the past when sending an app out for testing. While testing on Test Cloud saves a lot of time in these scenario’s, I will share examples of how to test when using the Visual Studio emulator for Android or Windows. The iOS Simulator will have similar functions.
Make sure you test your mobile app when the network has dropped and times out all the time. It can cause a lot of interesting sequences.
In the emulator, you can simluate what type of network you have, including No Network.
4G and WiFi
Internal WiFi’s and 4G can have quite a few differences such as firewall blocks. What has slipped me up in the past is that an internal WiFi router was blocking certain ports that receive Push Notifications, whereas 4G didn’t have them blocked.
The emulator can simulate cellular activity for your network connection, however it doesn’t work well in actually simulating what firewalls may be in place. As such for this, debug to a real device and turn the Wi-Fi off.
Device Permissions and Capabilities
Not all devices have the same hardware capabilities and checks need to be made before each call. Device permissions can also be revoked at a later stage and need to be checked each time they are called even if you get them up front.
The emulator allows you to turn off hardware capabilities, you should do that while trying to load to your emulator to see what happens with hardware you need.
Also once the app is loaded and permissions were given correctly. For example on Android follow this:
Settings > Apps > (select the app) > Permissions
and revoke permissions as necessary.
Low memory, especially when dealing with images is a main cause of crashes. Make sure you correctly handle large image operations on low memory devices.
When selecting an emulator image to test your app on, I always select the lowest memory usage emulator image to simulate low end devices. If you are constantly testing your app with this, you are unlikely to experience memory issues with devices with more memory.
Sleep and Lock Screen
What happens when the phone goes to sleep or is backgrounded, then resumed, does it go back to the same place or does it need to logout and require a sign in again?
The emulator normally disables the sleep when debugging, hence when you are running your app, press the home key to background the app. The app is then backgrounded or goes to sleep. Then you just need to find and click on the app in the emulator again to see what happens when resume occurs.
Screen Sizes / SDK Versions
Even on iPhones, you need to check the smaller models to larger ones. The move to the iPhone 6 Plus actually requires more work because not all sizes should actually scale exactly, they should be smaller on a larger screen.
Emulators have an easy way to check with different screen sizes. While checking for each one can be extremely tedious, especially with Android, it is best to check a small, medium and large screen. For iOS do iPhone 4s, iPhone6 and iPhone 6 Plus. Android a 4″, 5″ and 7″, Windows a 4″, 5″ and 6″. With Android it is also best to try and get some API/SDK coverage tested as well. For example in your 4″ do it for somewhere between API 15-17 and 5″ do for API between 18-20 and the 7″ do an API 21+. It allows you to test numerous things at once.
You can also use the same approach with iOS and Windows. iOS and Windows are not nearly as problematic between SDK versions, but I have certainly come across issues, such as iOS 8.0 doing things visually different than iOS 9.0. Also Apple has the tendency to keep increasing security with each SDK released, hence testing with the latest SDK is always recommended.
Landscape / Tablet
Normally I just lock it to portrait for the first few releases as landscape can cause a lot of UI issues. If you support landscape, test each page on each screen size. Tablets are often landscape so you need to decide if locking to portrait at the start is a good idea.
Testing landscape on emulators is quite easy, my just clicking the rotate button.
Deployment to App Store
Once you have your initial user testing out of the way, its time to deploy to the App Store. While Android and Windows stores don’t have the pre-screening that Apple does, they will remove your app later if their automated systems determine the app violates their guidelines.
A solid list of requirements for each App Store can be found below.
Android – Core App Quality
Windows – Windows Store Policies
However some common misinterpretations or pitfalls include:
No Consumer Value
If an app is designed for employee use only at one company, then it won’t pass Apple’s review criteria, you will need to use an enterprise MDM.
If your app accepts payments from within the app it must use their in app payment mechanism. You can however get people to pay for a subscription or account to use your app, however it means you can’t have the user register or signup for the app, within the app. It must be with an external website, but then they could authenticate and use the app. You also can not link to that external registration page from within the app either.
If you want to show ads in your app, then you must use the app stores ad network and their special identifier system. No exceptions here.