How should we keep tab of our mobile application’s bugs? If you are, even remotely, involved with mobile applications, you have had to ponder this question. Bug monitoring is important because so many things can go wrong in a mobile app (connection, storage, drops, security…) it is impossible to code and test for all scenarios so you need to have a good strategy in place to capture what is going on with your applications.
However, there is no right way to go about it.
The approach I am going to introduce is not going to work for everyone and I am sure that, given other requirements, you could take a different route and be fine. So let’s me share some of our drivers and see if it applies to you:
- We need to know precisely which data is going in and out of the device given some of the information that is transmitted.
- We need to have a small a footprint as possible given some of the locations our users access our apps from.
- We already have in place a process for live issue-tracking on our web-based app.
If you share these drivers, you may find that many of the commercial apps out there do not fit this mold. Why not, one may ask? Why not use a tool that let’s you “analyze and troubleshoot your mobile apps in real-time”?
Well for us, there were a few key drivers:
- We already have our own, sturdy, issue tracker. We even use it to let customers send requests for help and support. It is full featured so the incentive to change and learn a new solution was low.
- Most of the commercial solutions we found involved adding a “single line of code”, similar to those used in site analytics. Given that we need to be sure of which data leaves the machine, this is a point-of-concern.
- We also do not know what happens once our data gets to the third-party server; will they curate it, aggregate it, resell it? Too many open questions!
- We value our customers and do not want to “steal” from them so it rules out any product that is “automatic”. See, when a vendor tells you they are sending you real-time data back from your device, it means the device is always broadcasting back so you are costing your customers money.
Customers pay for their data plans and we do not see the point of wasting bandwidth. People may claim that it’s just a few bites at a time; I hear this argument often. Yet, no one wants to agree to let me charge them a penny multiple times a day, for months on end without anything in return! All joking aside, the non-stop transfer is also a huge issue and drain when the device is not on a fast network which is a very real situation for us.
What we do specifically and how you can copy us:
- We include a js file that acts as the data collector on the device (We use PhoneGap so it makes life a bit simpler in terms of deployment but the principle would be the same for native apps)
- The developer can opt to track the bugs they want. When a bug happens, it is stored on local storage along with just a few data elements that include geo-location and connection information.
- We do not store the device ID.
- At the end-user request, the log is tranfered to our issue tracker via an API
- Once it reaches the issue tracker, the usual bug management workflow begins where we can review the problem, assign someone from the team to resolve the issue, and communicate back with the end-user for better customer service.
We are considering making part of the mobile issue tracking system open source (the js side likely) and potentially finding ways to make it affordable for developers to tap into our system. If you are interested, let me know. I would also be interested in learning how you approach mobile application monitoring.
And for a few screenshots:
This is what our team views once an issue has been transmitted.
And here is a large view of what it looks like on the mobile app. Notice that we leave it to the user to send the bug package to make sure we do not hit the data plan needlessly.