Why do native apps crash?
If you have been using smartphones and apps, you must have experienced an app suddenly closes. You didn’t want it to close but the it closed all of a sudden — this is called a crash. This can happen to both system installed apps like Mail, Maps, Gmail etc to developer apps installed from app stores.
In native app whether iOS and Android, crashes are very common. From Ray Wenderlich
App crashes are like death and taxes — they happen. But it’s up to you how to handle them!
Also, Android crashes more than iOS largely because of its humungous device matrix and support for older OS’s. Not to say don’t use Android but prefer devices with latest OS’s or ability to upgrade. Case in point Lollipop is more stable than iOS8.
As a tester/developer how do we tackle this? First lets categorize crashes into two broad areas.
Uncontrollable or external
Network variance — New age website developers are terribly unprepared for variations in network. Browsers have been helping them tackle this problem but in the app world we have consider various networks 2g/3g/4g LTE/WiFI etc. Crash scenario: That async request that you used to make to fetch cart details might have only taken 2 secs on desktop with WiFi/ethernet but it could take 15 secs on low 3g network.
Spotty Network connection — The user may be driving, walking around or cellular data provider might be having a bad day and their connection is flaky. Crash scenario: You make a network request, wait for the data to come back so you timeout and make another request but now the original request came back first!
Device fragmentation — Most obvious hassle for any mobile department is to tackle the ever exploding Android and iOS device numbers. Every manufacturer, every supported size, every price range, every size, every country, every carrier will add one more dimension to Matrix. Crash scenario: You code for the best of the breed devices in your market but your users in China may be using your app on a device that has very low RAM that can barely load your entire app.
System level interruptions — Notifications, alerts, phone calls, buzz from another app all are interruptions to your app that must be handled gracefully. Crash scenario: You get the happy paths right and show a confirmation popup for an action, that has a learn more button. Everything is good if user navigates in that direction but there comes a phone call and as soon as that’s finished your app state is invalid and you crash.
API/backend problems — The entire backend for many modern native apps is a REST API. They come with their quirks and problems. And usually they are fatal for your app. This is a deep topic a post on this later.
Controllable elements
- Secondary entry points — If we consider opening the app from the list of apps as the primary entry point to our application. We still need to consider various other entry points including -
- Already opened app — this is an app resume, we should remember app state and present it to user. If your app give real time data, yo may have to do a refresh before presenting. Crash scenario: To present a view in your app, you create objects and pointers and show it to user, they use the app but now they switch to a different app. And when they later come back, this view may be outdated or memory reclaimed by OS hence any action will crash
- Opening app from notifications — This would mean no splash screen, no other navigation but straight up serving the intent of the user. Crash scenario: Your app requires GPS permission and for users who don’t opt-in, you ask them again at startup or default. When serving a notification screen, you forget the default option.
- Memory management — In general websites do not have to worry about memory leakage, threads, deadlocks and other low level problems but for apps especially iOS these are still real concerns. Java has automatic memory management but iOS is only catching up and swift shows promise with ARC. Crash scenario: You open a view for a filter dialog but when exits you don’t close the view, you just leave it to leak. This happens at several other places in your code and all of a sudden you are leaking memory running in background. So the next time you open the app, OS will decide to shut you down without warning.
- App code — this is code that we deploy to app stores. We have full control over it and theoretically speaking we should be able to handle the rest of failures with this but considering all above elements that is so freaking hard! Crash Scenario: Any usage of your app :D
So next time you see a crash in your apps — please be a little tolerant and try to empathize :)
Sources
