Any time you have commercial software that gets distributed outside your organization it is the developer who is ultimately charged with troubleshooting that application remotely when something goes wrong. After more than a decade of writing software for one platform or another, I can say with confidence that if you are a developer and you’ve never experienced the frustration of problems with your software in the field, then you probably haven’t written an application that got installed and used. No matter how diligent we are in our development process, we simply can’t predict all the variables and factors that will come into play over the life of an application.
While getting fixes to your users quickly and efficiently is always a priority, I believe the unique ecosystem of the smartphone app market takes this directive to a whole new level. Users of your apps have a very visible and effective means of encouraging or deterring other potential users from downloading your applications: marketplace comments and ratings. If you go to your local computer store and pick up a copy of Microsoft Office, you are not going to find the testimonial of an unhappy user printed on the box. In contrast, pull up any commercial application in the Android Market, and you are going to see unfiltered user comments front and center.
As I’ve mentioned before in this blog, I work as a lead on a team that supports a vertical application for iPhone, Android, and WP7. Over time as our application has matured and gained market share across a wide variety of devices, I’ve learned a few things about supporting smartphone apps that I wish I knew from day one. Like so many things in the field of software engineering, there is no magic bullet that will keep all your customers happy all the time — but listening to your users, being empathetic of their troubles, and using the guidelines below make for a great start.
1: Crash dumps are your get out of jail free card.
As an Android developer, I get access to Google’s developer console. The console has a lot of interesting statistics about each application I have made available in the Market. Of all the information available to me, the crash reports are without a doubt the most important. In my experience, users are willing to let a single crash or force close slide. They are also usually willing to allow the OS to dump and submit the crash report. As a developer, I consider this a get out of jail free card. Every single day I log into the console, check for crash reports, and if I find one I work hard to get out a fix before someone gets annoyed and posts a nasty comment in the Market.
2: Provide a feedback mechanism within your application.
One of the things we discovered early on was that if you provide a feedback button in your application, users are likely to post complaints there rather than exiting your application and going to the Market app to do so. This is great news for you for two reasons. First, it keeps users from posting potentially damaging remarks about your application in the Market for all to see, and secondly, unlike posts in the Market which are for all intents and purposes anonymous, providing your own feedback button enables you to get the information you need to get in direct contact with the user reporting the problem or offering up a suggestion. What could be better than reaching out directly to your users? In my book, it’s a win-win scenario.
3: Build logging into your application from day one.
When your app misbehaves in the field, you’ll want a record of what the user was doing when this happened. You should always have a way in your application to turn logging on and off. All the major mobile platforms have light-weight logging APIs available, and for that matter, it’s not difficult to write your own if you prefer something more custom. Not having a way to create a log file that your user can turn around and email you is sloppy and inexcusable. Not only will the log file save your butt sooner or later, but you’ll find that you use it while developing and testing as well.