Mobile Development and the Support Burden
Thinking of selling a mobile application? You should be aware of the support burden of supporting an on-device mobile application. When you really think about it applications on mobile devices are the wild-wild west when it comes to their install base, hardware configuration, operating system, capabilities and current state. Android is by far the most fluid with Windows Phone 8 probably the most static.
In the last 2 years I’ve really gotten into Mobile Apps, both native at the start and now hybrid. I will save the Native verses Hybrid discussion for a latter time, but they both have positives and negatives when dealing with support for your customers.
It wasn’t until I started developing the mobile apps for Resgrid did I fully appreciate the support burden that can arise form mobile app development.
Resgrid is a cloud service company providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in 2012 by myself and Jason Jarrett (staxmanade). We have currently 2 hybrid mobile applications 1 one legacy native one that we are in the process of replacing.
In the last year I’ve also had the luxury of being part of enterprise grade mobile app development at Paylocity, which is a cloud service provider of payroll, human resources and time & attendance products and services. Both of those experiences have given me some great insight into challenges faced by companies supporting mobile applications.
So your only going to develop for iOS, seeming it’s Apple, they control everything and it’s all a known quantity. Well your first problem is that every phone is it’s own unique little snowflake, in addition that unique little snowflake varies wildly depending on where it is. For Apple, say you only do phones, and iOS 7.1+, that gives you the iPhone 5, 5S and 5C (pretty small right?). You still have a good size support burden.
Factor 1: The Hardware
Even with a hardware universe as small as the iPhone 5, 5C and 5S there are some drastic differences between the phones. Between those 3 phones there are 21 models. Check out this article from EveryMac that breaks down the hardware and usability differences between the 5,5C and 5S. So potentially in just those 3 phones you have 21 instances where you app could operate or act differently. That’s assuming a constant baseline of OS, installed apps, running apps, network, environmental conditions, accessories and user.
Although the newer phones high end phones have some good hardware spec they still can have some serious performance concerns. How many background tasks are running? Is there competition for the same resource? Mid range and cheap phones have pretty much barebones specs.
Factor 2: The Operating System
Operating System fragmentation is a huge issue. Up until iOS 7 the Apple iOS fragmentation wasn’t a big deal, but iOS 7 cannot be installed on older devices, like iPhone 3’s and older, first gen iPads’ etc. Here is a good article from December 2013 detailing the fragmentation issues on iOS and Android.
Factor 3: The Network
Can you hear me now? Ok sorry. This really is a huge issue. Most of our apps need to transmit and receive data. But how performant and error prone that process is can vary wildly depending on the network, the connection, signal strength and congestion. Just walking around my house on a cell connection I can get errors in my app sometimes, it’s not the apps fault or the backend service, it’s the network.
Factor 4: The Browser
This is more a problem that specifically affects hybrid applications, but it’s such a huge problem for mobile apps that it needs to get it’s own section. Mobile browsers pretty much suck. Some are far better then others, I think Mobile Safari is probably the best default browser. Sencha has a great article on mobile browser performance, the gist, mobile performance can suck especially on older operating systems and hardware.
I’ve found through experience that Android mobile browser is worse then iOS, especially on Android 4.2 and older. In one case I’ve seen something completely usable in an iOS 7 device and unusable on an Android 4.2 device.
Factor 5: Accessories
You design your app with swipe gestures, say to open a drawer menu, did you take into account the cases people have on their phone? An Otterbox Defender case adds a 1/4’th the depth of the phone lip before the screen, making it hard for people to swipe in from the sides.
Other accessories like screen protectors can fade out the screen or wash it out. Making text harder to read, or small details to be visible.
Factor 6: Environment
You wouldn’t think that environment can be a problem, oh but it can be. From a app details being washed out in the sun, to trying to get a GPS fix where your customers are physically using your app can impact perceived and actual performance and usability.
Based on the factors above support request and issues from even a single user can vary wildly. At Resgrid we’ve had the same user say the app’s performance is amazing over a cell connection and the next day (in the same area over the same connection) say the app is unusable. I’ve even had people that somehow got the Resgrid Responder app loaded on jail broken devices and sent scathing support emails when it wasn’t working.
There is a lot of upside to developing mobile apps, but you need to take into account all the form factors, hardware configurations, networks and usage scenarios to help prevent errors and user issues before then happen and to better support your users.
