Stopping the crashes inside your app
|Hannah Levenson in Application Testing Wednesday, December 7, 2016|
If you are a mobile app developer (and we'll take a wild guess and say you probably are, or are at least linked to the industry in some way), then your apps have most likely been downloaded, used a bit – crashed – and then users deleted it.
We can confidently say this is the norm for many apps because:
Various market studies (like this one from Crittercism) have shown that 'most apps crash' – Almost half crash more than 1 percent of the time they’re in use, and a third crash more than 2 percent of the time, which is enough for people to abandon the app. More than three quarters would give a crashing app just one more chance before deleting it from their device. Just 16 per cent would give it more than two attempts.
That's a lot of pressure - apps that crash are in a sense, “useless” to the users. Users need an app to solve a problem or need that they have, and crashing apps are only adding another problem to the list.
Crashing apps hurt usability and will make a serious dent in user experience, which might result in a series of negative reviews on app stores. So, there is a lot at stake here.
The tragedy is that developers simply can't eliminate crashes completely – they will pretty much always happen. Even mobile market reports will say – if developers can get their app's crash rates under 1 percent, that is considered having a solid, stable app. No one will ask for 0 percent- even though we will always strive for perfection, right?
Why do crashes happen?
Crashes are unavoidable because there are many reasons why they happen, many of which are moving parts. However, one of the biggest reasons is poor memory management. Developers build their apps as if theirs will be the only thing running on a device. They often think they’ll always have all of a device’s memory and processing power at their disposal. When released into the wild, where apps must ‘compete’ among themselves, memory resources get depleted quickly, which can lead to apps crashing.
Knowing crashes will always be a threat, you can (realistically) try to get to under that beautiful 1 percent, and the best way to go about the path is by keeping crashes in mind when developing, analyzing the finished product, and tweaking it as necessary.
The problem is – most mobile app developers are still using the same analytics tools that were available when mobile apps first hit the mainstream. These tools, known as quantitative analytics tools, while providing extremely valuable, numerical information, only tell one side of the story when it comes to user experience and crashes. There are new tools available on the market today, which we call qualitative analytics tools. When used with ‘traditional ones’, they offer a complete picture of the app and its life ‘out there’.
Apps have moved on, analytics moved with them – and it is time developers moved, as well.
As you probably know already, quantitative analytics are all about numbers. Everything about your app that can be said in numbers, will be communicated through quantitative analytics, such as the number of app launches, times of day when the app is used, and in this case most importantly – how many times it crashed.
But the answer to one crucial question is missing, and there is no math in this universe that can answer that one – Why?
Why did the app crash? What was the user doing when it happened? Did he follow a particular sequence of events that led to the crash? Did he press too long on a button? Did he attempt to swipe left too many times? All these, and virtually every other similar question can be answered through qualitative analytics. With qualitative analytics platforms, there is typically a feature that helps answer these questions - user recordings. The name pretty much speaks for itself; these will allow you see exactly how users are experiencing your app, helping you get a better understanding of all the troublesome things.
If users are going about the app in a way different to what you had in mind, that can lead to a lack of understanding and frustration on their part. They might perceive various app’s elements as bugged or flawed, ultimately inching them closer towards tapping the uninstall button. Without knowing how your users use the app, you can’t really do anything about this reality. They can’t modify the interface, they can’t change their onboarding strategy, they are literally left in the dark.
Obviously, the best way to ‘turn on the lights’ would be to watch them as they use the app, which is practically impossible. The second-best solution, however, is very much possible – watching both recorded, and real-time, sessions of people using the app.
That way you can see exactly where the issues lie and will discover if different elements (for example social media account login button) crash the app, and in how many cases – which is a metric impossible to find through quantitative analytics.
If you don’t have user recordings, you probably would have to do a couple of things in attempt to understand the exact cause of a crash:
- Read through piles of text of crash reports (if users decide to send those in the first place)
- Read through user complaint emails (if users are bothered to send those in the first place)
- Read through online reviews of frustrated and annoyed people
That's a lot of reading. Worst part – that's a lot of *reacting* - instead of being proactive. You would also need to sniff through quantitative analytics – basically crunching numbers, a practice that can sometimes make it impossible to relate crashes with the real cause of the issue.
Here’s another example: it’s been established that many shoppers abandon their mobile shopping cart, for various reasons. Again – qualitative analytics can tell you why. Maybe they are missing a crucial payment service, or the registration page crashes the app for some strange reason when users try to add PayPal information. All these questions can be answered by watching recorded user sessions, helping you create a functioning, fun and engaging app with an overall better user experience.
Mobile app crashes are a huge turn-off, as they can make users quickly quit and uninstall the app. While it’s almost impossible to completely, absolutely eliminate crashes from apps, thankfully they can be reduced to an acceptable minimum, which is less than 1 per cent of the time users spend with the app.
This reduction can only be achieved by making sure the app is built properly, by effectively monitoring and analyzing app performance, and updating and tweaking it accurately to remove disruptive and poorly built elements. In today’s ultra-competitive mobile app ecosystem, quantitative analytics, which are usually used by developers to track numerical data, do not suffice. Yet when combined with qualitative analytics, you can get the full story on your app’s user experience.
Through quantitative analytics, you can understand when, and how often apps crash. But through qualitative analytics, by visualizing real user sessions, you can understand why it happens. Only then can you see the full picture and only then will you be able to boost your app to produce the ultimate user experience.
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.
Become a subscriber of App Developer Magazine for just $5.99 a month and take advantage of all these perks.
MEMBERS GET ACCESS TO
- - Exclusive content from leaders in the industry
- - Q&A articles from industry leaders
- - Tips and tricks from the most successful developers weekly
- - Monthly issues, including all 90+ back-issues since 2012
- - Event discounts and early-bird signups
- - Gain insight from top achievers in the app store
- - Learn what tools to use, what SDK's to use, and more