App crashes are a developer’s worst nightmare. Though it happens to everyone at one point or another (yes, including the top apps), it is still unbearable.
There’s no other way to say it: The cold harsh truth is that mobile apps’ quality and performance impact the bottom line. It’s what will make users decide to come back. Crashes, especially of the repeated kind, drive the uninstall numbers high and drive your users to run away.
Fortunately, it’s not solely up to the gods. There’s plenty you can do to minimize this phenomenon: from familiarizing yourself with the most known and common causes for mobile app crashes to making sure you’re even aware of your own crashes, you can make your app more stable with a relatively small investment.
A crittercism research has found that not only do 47% of apps crash over 1% of the time, but 32% also have a crash rate of over 2%. If that sounds excessive, it probably should.
Now let’s be honest: Everybody bugs. We know that for a fact. But statistically speaking, knowing almost half of the apps out there are so susceptible to unhandled bugs is somewhat daunting. And it also means that bugs aren’t unique to new-comers. No, they happen to old-timers, big and small, as well. So whether you’re established or brand new, a long-timer or a first-timer, you must make sure that your app does not only supply the content users crave, but also provides a frustration-free environment. Therefore, making it crash-free (or at least crash-low) should be at top of your priority list.
Image source: Crittercism
“My Name Is… And My App Sometimes Crashes…”
At Crashers Anonymous we have a saying: “Grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference.”
And the first step, as with everything in life, is to first acknowledge you have a problem. Yes, from time to time, your app crashes. Like I said, it happens to everyone. Now let’s start making amends and asking for everyone’s forgiveness.
The Courage to Change the Things I Can
First, let’s understand what’s really going on behind the scenes. Before we discuss prevention, it’s important to name the main reasons for app crashes:
- Memory and Processing Issues – Not having enough memory for the app to function
- Connectivity Problems – Poor connections that are leading to instability
- SDKs Issues – 3rd party tools interfering with the app are known to be a potential crash causers.
- Device Diversity – Since there are so many different devices, and there’s no one single standard, it’s not uncommon for an app to crash only on a specific device type.
So far it’s all very clear. The big question is what can you do to make sure your app performance is optimized and it functions correctly?
Crashers Anonymous meetings are held every minute of every day…
Careful Management of Memory & Processing
You’d be surprised how much this issue pops up. You see, like everything in life, the device’s memory is also finite. You don’t have endless resources, far from it. So you should do your best the avoid using too much memory. “If only it were that easy, “ you must be saying to yourself. Well, sometimes it is.
Use caching whenever possible. Find where in your app you’re using the most amount of data, or holding the biggest data structures, and see if everything is absolutely necessary. Profile your app to see if you’re leaking memory – that’s just memory you could have had and are wasting away. A shame, isn’t it?
Group your network requests and fetches, but keep them small enough to not overload the device. Play with it a little bit until you find the right message size. Better yet, make it configurable.
Prioritize – maybe you can dispense with some data or features to save memory when it’s already low?
Be strategic here, and make sure you are leaving enough memory for your app to run without lagging.
Never Block the Main Thread
The UI thread is always a delicate one. Not just in mobile. You want to give users the best experience possible, making every little gesture feel fluent with immediate feedback.
Mobile apps that don’t adhere to that are declared “unresponsive” by the OS and often result in ANR (Application Not Responding) crashes.
You can avoid these by moving heavy processing (such as image loading, network fetches, filesystem accesses and so on) to run in background threads, thus maintaining a consistent flow of the UI, always responsive to a user’s touch.
Never assume “it’s so small and tiny, the UI thread can definitely withstand it” – what happens on your devices in your testing environment may not resemble what really happens to real devices out there. When there’s doubt, remove it and move the operation to the background. But be wise – no need to overload with many context switching as well.
Know Thy Crashes!
The 12-step program of Crashers Annonymous makes it imperative for you to acknowledge your bugs and crashes. This isn’t achieved by going around, saying “I’m sorry” to everyone, it’s achieved by finding the bugs and fixing them. You must be aware of the very real possiblity that you may not know all possible scenarios of your apps. Which is why you should include some sort of crash reporting inside your app.
You can do it yourself, or rely on existing tools. Tools such as Crashlytics, Crittercism, and Arca are brilliant for monitoring your app crashes. Generally speaking, crash reporting tools are a great way to get real-time information on your app’s behavior and the experience users are getting.
And don’t forget – it’s not all your code. Using 3rd party tools (“SDKs”) are a great way to speed up the development process and get great features quickly. But if everybody bugs, so do SDKs. SafeDK’s In-App Protection takes crash reporting to the next level – not only telling you which of your 3rd party tools crash the party and how much, but also give you the ability to deactivate them on the spot.
You should test your app on as many devices, platforms, manufactures, generations etc. as possible. That way you can make sure you’re compatible. Not with all, but with most. The harsh reality is that there are so many different devices and platforms out there, that you’re bound to miss more than a few. And that’s okay. You should aim to be compatible with as many as possible, but know your limitations.
This is the part of “things I cannot change and the wisdom to know difference”.
And it’s not just because you can’t really test on every possible device out there. Sometimes you need to accept that some users have bad devices. Low on memory, slow functioning, busted screens, you name it – they’ve got it. If they’re only a small percentage of your users, you may need to choose not to devote the resources and time to fix their issues. Aim to have as many of your users having the best experience. You probably can’t satisfy them all.
How does one afford testing on such a variety of devices, you ask? Well, I’ve learned lately about many mobile app testing services and device farms that are very affordable. These services will be very helpful in testing on an array of devices in multiple geos. Save your money elsewhere, not in testing.
Make a Crushing App, Not a Crashing One!
App crashes are a big source of frustration for both app developers and users. While not all crashes can be foreseen ahead of time, some can. For those that managed to slip into your release, don’t let them fester and pester. You can learn of your crashes using crash reporting tools. Detect them, learn them and fix them.
Not sure how to fix them? Well, try/catch should be your new best friend. Your mentor in this journey for crash sobriety.