Never assume that your testers (yes, even your internal test team) know how to get an app onto a device. There are otherwise wonderful and intelligent people who believe that new app builds magically appear on devices without them doing anything. Chances are good that, like me, you are one of those clueless people in other contexts, so be patient, and over-communicate the procedures for installing. And don’t assume they will remove previous versions.
If your mobile application has an internal database, pay attention to when the database schema changes. If the schema changes, you will need to add code to upgrade the copy of the database that resides in the app’s sandbox. You also need to thoroughly test that update code with any and all publicly available prior versions of the app. Yes, it’s a pain in the tail.
Never assume that your users know what version of the app they are using, what version of operating system they are using, or even what type of operating system they are using. They are more likely to know they are using a Samsung than they are to know that the OS is Android. (On the other hand, knowing the manufacturer can be very useful when you’re dealing with Android issues!) You’ll also be lucky if they know which device model they’re using. Consider whether you can get some or all of this information from analytics reports before you release the app.
Never assume that the device has connectivity, not from a user support perspective, but particularly not from a code implementation perspective. Plan to handle the effects of intermittent connectivity on database functionality, external server syncing, and from a user interface perspective. Don’t just rely on the status bar to tel the user what’s going on and why something isn’t working.
Sam Herdman 