We analyzed 100 mobile apps and found 6 common reasons why apps crash!

People hate app crashes, especially when they slow down or freeze for a few seconds. According to a survey by Dimensional Research, 61% of users expect apps to start within 4 seconds, while 49% expect responses to input within 2 seconds. 53% of users will uninstall an app if it crashes, freezes, or reports errors.

Whether you’re targeting consumers or businesses, crashes are a real letdown. I spoke to a number of mobile developers and asked them what the most common crashes they encounter are. They came up with six common reasons:

1. Memory Management

Everyone I asked talked about memory management, and most apps start many threads that take up system memory. Sachin Agarwal, vice president of marketing at OpsClarity, said that programmers should write code as if their app is the only one in the app, and he suggested that when writing programs, they should consider making them "good citizens in the app ecosystem."

Memory issues aren't the same for all developers. "In iOS, you can just leverage Objective-C to handle a lot of memory issues," said Andrew Whiting, vice president of business development at Solstice Mobile. But there are trade-offs. "On Android, you have a much deeper level of control [over memory], and you can make it do exactly what you want, but it adds complexity."

"When we run into [running] out of memory in Java, we find that usually it's related to loading large images or processing bitmaps, etc.," said Jonathan Karon, senior software engineering manager at New Relic, which compiles common causes of problems in the Mobile SDK Technical Performance Report. "There are actually a surprising number that look like linker issues on Android, where a class can't be found, or there's an exception called an unclassified link." iOS apps, on the other hand, are often hit by NSInternalInconsistency exceptions, which occur when a developer changes an array or collection of data in one place while something else is reading a list of things there.

2. Software Lifecycle

The iterative application development process with frequent releases, which opens the door to bringing a minimum viable product to market and then improving it over time, is now very popular, but the traditional software lifecycle is further complicated by dependencies on operating systems and third-party APIs.

"If you look at the latest Android updates, there are a lot of app crashes," Agarwal said. "The OS itself is unstable or the OS is updated and the app isn't updated" or users don't download the new version, which "you can't control, and it speaks to a core development process."

The growth of mobile and cloud computing has increased the use of third-party services and their associated APIs, saving time and helping to bring applications to market faster, but they have their own set of problems.

"A lot of libraries have common problems," Whiting said. "They try to solve everyone's problems instead of being the best solution for anyone." For example, a given API might have performance limitations for a specific application.

APIs can also use tricky techniques, such as iOS method tweaking. Developers make modifications on top of original code (like Apple's APIs) when the original code isn't available. "You could call it one of the 'dark arts' of iOS app development," said Raman Bhatia, head of mobile at online travel agency Fareportal. "[But] if your app code is written a certain way, it can cause crashes."

APIs can cause other problems, too. "API latency, error rates, data bandwidth, API versions, and the number of API requests can all be small issues that can lead to big problems," Agarwal said. Then there are the APIs themselves, which require specialized tools to keep track of everything.

The API can also cause other problems, such as memory errors. "If you create an object that has been removed from memory before creating other objects, you would think that this is usually fine, but the important thing to note is that you don't know whether the subsequently created objects will need to reference the deleted object," said co-founder and developer Long Le. "Especially when you introduce third-party frameworks, it will be a problem. You can never be sure what they are cleaning up and what they are creating."

3. Inadequate testing

The need for testing is obvious, but getting adequate coverage, especially for the large number of Android versions and devices, can be challenging. While there are emulators, the performance constraints of software running on a server may be different than on a real device.

For example, if one thread of an application reads a database and a second thread tries to modify the same database at the same time, "it's a timing issue," said Wayne Carter, mobile infrastructure architect at Couchbase. "If they don't collide at the same time, then the problem doesn't appear and can be masked by the log description." Simulators are usually not the same as real devices.

Running different operating systems on different devices is a feasible solution, but this method is more expensive than the simulator. This requires a trade-off between budget and needs.

Testing should be done in conjunction with benchmarks against industry standards and user expectations to ensure that content is acceptable to developers and users. Testing should also be ongoing. Monitor performance and look for user feedback, then resolve issues as quickly as possible.

4. Network Management

As applications become increasingly dependent on the network, whether for data or third-party services, network management has become a source of trouble.

The main reason for crashes is when you are trying to retrieve data, submit something and wait for recovery and the app becomes unresponsive or hangs. Pravin Vazirani, vice president of operations, said that developers may make the Wi-Fi connection function very perfect, but problems may occur when users are in a bad network area.

A good way to handle network issues is to inform the user of the loss of connectivity and, if possible, offer the opportunity to perform other actions that may be of interest. If people understand the cause of a temporary condition that is beyond the control of the application, they are more likely to remain calm and not become annoyed with the software.

5. Error conditions and exception handling

Due to the complexity of mobile development, some errors are inevitable, whether it is unexpected API changes, memory issues that avoided previously detection, network connectivity issues, or even just slow data transfer speeds when transferring large files such as images or videos.

In this case, the best approach is to provide good error and exception handling, such as when the user enters incorrect data, or provides text in a text box instead of a numerical value, so that the application will not be accidentally tried and errored.

In any of these cases, a properly coded application will notice the unexpected situation and gracefully terminate the process or activity while notifying the user of the error. If you can keep the communication channels open, you'll have a better chance of retaining users.

6. Too much code

The best advice is to keep your app simple. Find plugins for a specific purpose, use them and write the necessary code. "The best and most bug-free code is the code you don't write yourself," said Felipe Laso-Marsetti, senior systems engineer at Lextech Global Services, an enterprise mobile development company.

Can you truly create an error-free application, especially in the first round? Probably not. However, you can pay attention to these sources of failure and do your best to create a strong exception handling mechanism.