Have you ever had an app crash on you right before an important meeting or when you needed it most? Chances are you have, and I know how frustrating that can be.
Users, especially the younger generations, are relying more and more on apps these days, even more than on mobile websites. The convenience of using apps to handle your daily life, work, and business is too great to pass up. This makes a stable app vital to keeping user retention high. Bottom line is — if your app crashes and you’re slow about fixing it, you may lose a loyal user.
We can’t prevent or foresee every bug or issue, but what we can do is find ways to mitigate problems — like properly writing and managing code, being less reliant on 3rd party libraries, managing memory, etc.
Find out what the most common reasons for app crashes are and what you can do to fix them.
Why is my app crashing? The 5 most common problems
1. Poor usage of UI components
To keep users engaged, app developers rely on a feature-rich UI with fast transitions and load times. On the back end of that, incorrect usage of UI components on the background thread, for example when updating UI components with data received from a network call on the same thread, can cause crashes.
In most cases, it’s a good idea to split these threads so that each one is independent from the other. The only disadvantage would be if both threads need to get the same data over the network, which may cause some data consistency issues if the data changes quickly. Keeping UI components in sync with the corresponding data source is important to avoid such problems. A common issue with the UITableView component comes to mind. It can get tricky to update the tableview and its datasource in the right order so that you don’t get errors like index out of bounds.
Another problem that may pop up is simultaneous computation done on the main thread. The most common case is calculating/processing UITableViewCell or UICollectionViewCell sub-components (e.g. subviews) when scrolling up and down.
Additionally, developers need to be careful when displaying large or high resolution images. When images are transferred from the server via request, they need to be resized so that they look nice on the screen. The same thing happens with scaling videos incorrectly — apps get slow and the user experiences freezing and/or lagging.
2. Bad network management
As developers, we like everything to run fast and smooth. But the real world is different. Mobile networks are prone to dropping in and out, WiFi signal strength fades as you move away from the router. If you overload the memory and phone with network requests via API calls and process all of these data objects (e.g. unmarshalling) your app will become sluggish if you’re caching old objects.
Apple Networking Documentation lists the following as reasons for network problems:
- An overloaded or broken network link can exhibit packet loss. If a link loses enough packets, it may be difficult to establish connections across that link, and performance may fall to a tiny fraction of what you would expect.
- When a network link becomes saturated, routers on either side of that link buffer the traffic to avoid losing data. This adds additional latency. It is not uncommon to see latency measured in whole seconds over heavily loaded DSL connections.
- Captive networks (often used in hotels, coffee shops, and other public places) may intercept your software’s HTTP requests and provide a login page instead of the expected data.
- Firewalls between the user and the destination may block connections on all but a handful of ports.
- Firewalls that perform network address translation (NAT) may not allow remote servers to connect back to ports on the user’s computer or other device.
- Third-party firewall software may block your software’s outgoing connection requests for minutes at a time while waiting for the user to grant permission to open the connection.
So how do you handle network requests and manage data from those requests and not cause crashes? Apple recommends following their guidelines for avoiding network trouble:
- Batch Your Transfers, and Idle Whenever Possible
- Download the Smallest Resource Possible, and Cache Resources Locally
- Design for Variable Network Interface Availability
- Design for Variable Network Speed
- Design for High Latency
- Test Under Various Conditions
3. Storing too much data in memory
Due to consumer demand, with HD videos and images now a must-have, app developers need to be very conscious of how data is stored.
Stuffing a watermelon through a straw isn’t impossible, but it could take ages to accomplish. You’ll probably end up breaking the straw before you get any of the watermelon through. The same problem can arise when storing data. Storing too much data in memory, for example, when working with images and videos, importing massive amounts of data in a batch or capturing data in a batch may lead to memory warnings, insufficient memory crashes, and slow response time.
4. Faulty SDKs and libraries
Third party libraries are a godsend for developers and startups alike. There are so many components you can simply plug in and integrate into your code that it’s difficult to consider doing it from scratch.
When you use libraries from GitHub and other sources, you expose yourself to serious problems – security, performance, and lack of control. Imagine a shield of armor as an app, and libraries from 3rd party sources as the plates or components of the armor, If there’s a chink in the armor, which translates to an app that leaks user data or causes crashes – you’re losing user loyalty and by proxy, losing money.
Of course, 3rd party libraries have their place, and it’s up to developers and software architects to implement the app idea properly and minimize risks involved with libraries. To give you some understanding of what risks I’m talking about, ai.type, a popular emoji keyboard for iOS was responsible for leaking 31 million people’s data with a user’s contacts also potentially included in the leak.
5. Optionals, Reference cycles, AVFoundation
Incorrectly utilizing optionals while working with Swift is common among beginner programmers. Many junior developers use ‘force unwrap’ on optional properties, which is generally frowned upon in the community. Chances are they’ll lead to a crash at some point, so it’s best to avoid force unwrap optionals as much as possible.
Also related to memory management, reference cycles can be the bane of a developer’s existence. They slow the app down over time and may crash it when they’re in place because objects will stay in memory, hence increasing the memory footprint.
AVFoundation is the framework that’s used to work with all kinds of audio and video, including controlling device cameras, processing audio, and configuring audio interactions. Because this framework handles images, video, and audio, it can be both powerful in a skilled hand and dangerous in a novice’s hand. Use it incorrectly or fail to optimize and test properly, and you’ll be bogged down in angry customer feedback and crash reports.
Takeaways: What We Recommend
A crashed app is a frustrated user, and that equals lost money. If you strive for your business to succeed and your app to launch and become popular you should make sure to find out why your app is crashing and solve those issues.
The reasons I mentioned in this article are some of the most common and could function as a checklist for a developer or architect. By going through this checklist, you can diagnose the most frequently occurring reasons app crash and mitigate problems down the line.
A good crash reporting tool works wonders for keeping track of crashes and errors, but investing in good software development and testing is probably the best preventive measure against crashes.
As the famous American inventor and politician Ben Franklin once said, “An ounce of prevention is worth a pound of cure.”
Cover photo created by dashu83
