How to Fix the Top 5 iOS Crashes

Crashes are a headache for all parties involved. Mobile teams hate dealing with them and users hate experiencing them. 62% of users uninstall an app if they experience a crash according to a study by DCI. App instability can quickly lead to failure or at least be very costly. To help minimize your app crashes and the time it takes to address them, we’ve compiled the top iOS crashes and how to fix them. (Have an Android app, too? Here's how to fix the top five Android crashes).

‍

‍

SIGSEGV

The most common crash users run into on iOS is SIGSEGV. It amounts to about 50% of all crashes due to it being very generic. Broken down it is a signal (SIG) sent to interrupt the code when a segmentation violation (SEGV) occurs. This happens when your app attempts to access memory that has not been allocated by the program (or memory that has recently been freed).

There are two common causes for the SIGSEGV crash. First, any variable that has been deallocated then accessed from somewhere else. Debug this issue by making sure the crash si consistent and try to determine which object is being referenced after being deallocated.
Second, the crash also occurs in a low-memory situation where the device frees objects to make room for system resources, which can make it difficult to reproduce. Debug this by using a stack trace to go through the classes and methods to find out the deallocated object that’s being referenced.

A common cause is a dangling delegate or listener that has been deallocated.

‍

SIGBUS

Similar to SIGSEGV, SIGBUS is also a signal (SIG) that indicates a bus error. They are mixed up usually because they both attempt to access invalid memory. The main difference is while SIGSEGV the logical address is invalid, for SIGBUS the physical address is invalid. This happens when the address doesn’t exist entirely or when it has an invalid alignment.

This signal can be sent from most synchronous methods and often can be found when the code attempts to access a lock.

‍

EXC_CRASH (SIGABRT)

EXC_CRASH is an exception that basically means that the application terminated in an abnormal way. SIGABRT is the most common cause of the EXC_CRASH exception. It means that there is either an unhandled exception in the code or that somewhere in the code abort() is being called.
This is a fairly straightforward crash to debug. The best way to go about solving the issue is too get a stack trace of the crash and make sure it’s symbolicated to be able to correctly pinpoint the unhandled exception.

‍

EXC_CRASH (SIGKILL) 0x8badf00d

Another common cause of the EXC_CRASH exception is SIGKILL also know as the exception code 0x8badf00d. It indicates that due to a timeout, iOS has terminated the application. This could be due to the application taking too long to launch, terminate, or respond to system events. The most common cause of this kind of timeout is the app not handling a background task correctly.

There are a couple of ways to debug a 0x8badf00d depending on the issue. First aim to eliminate background tasks that could be causing a timeout. However, there could be other reasons for an 0x8badf00d crash. Looking at a full stack trace of the crash can help you pinpoint where the issue occurred, backtrace when the issue occurred and what caused it. Another useful way to help you debug is to check the network log of the crash. This will help you quickly diagnose any network request that took too long to complete and might’ve caused the crash.

‍

NSInvalidArgumentException

NSInvalidArgumentException is accompanied with the error message: “unrecognized selector sent to instance”. This is a good indicator of the issue, the “unrecognized selector” in this situation are classes exchanging methods that aren’t recognizable. This usually means that a method that isn’t recognized by an object is being called.

A stack trace can help you pinpoint where the exception is being thrown and possibly the cause behind it. In the most common cause look for an unrecognized selector. Make sure that your code isn’t referencing unrecognized methods.