The most common iOS crashes, including SIGABRT and EXC_BAD_ACCESS, come from a small set of causes: failed assertions, unwrapped nil values, memory access errors and main-thread hangs. We'll explain what each crash means, what triggers it and how to fix it.
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.
What is SIGABRT in iOS?
SIGABRT is a signal that terminates an app when it calls abort(), usually in response to a failed assertion or an uncaught exception. It's one of the most common crash types in iOS apps and one of the most misread, because the signal name doesn't describe the cause.Common causes:
- Uncaught Objective-C exceptions. A call to a method with an invalid argument, a dictionary access with a nil key, or an out-of-bounds array access in Objective-C raises an NSException. If the exception isn't caught, the default handler calls
abort()and the app terminates with SIGABRT. - Missing IBOutlet connections. When a storyboard or XIB references an outlet that doesn't exist in the view controller class (because the outlet was renamed or deleted without updating the interface), the app crashes at load time with SIGABRT.
- CoreData constraint violations. Saving a managed object that violates a uniqueness constraint or a required relationship validation in CoreData raises an exception that becomes SIGABRT if not handled.
- Main thread checker violations. In debug builds, UIKit updates from a background thread trigger SIGABRT. In release builds, these manifest as visual corruption or hangs rather than crashes, but the root cause is the same.
How to debug it: read the crash log's exception reason field, not just the signal name. The reason field contains the actual NSException message, which names the class and method that raised the exception. That's where to start, not the SIGABRT itself.
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.
EXC_BAD_ACCESS
EXC_BAD_ACCESS is a memory access exception that occurs when the app tries to read or write to a memory address it doesn't own or that no longer exists. It's the iOS equivalent of a segfault.Common causes:
- Accessing a deallocated object. In Swift, this most often happens with unsafe code or when a weak reference is used as if it were strong. In Objective-C, it's more common: a delegate, callback or notification handler fires after the object it references has been deallocated.
- Force-unwrapping a nil optional in Swift.
let value = optionalValue!whenoptionalValueis nil produces a fatal error that surfaces as EXC_BAD_ACCESS (or sometimes EXC_BREAKPOINT). This is the most common crash type in Swift codebases. - Buffer overflows in C or C++ code. If your app uses native code through the NDK or a C library, writing past the end of a buffer produces EXC_BAD_ACCESS. These are harder to debug because the crash may appear far from the actual bug.
- Race conditions on shared memory. Two threads accessing the same object simultaneously without synchronization can produce EXC_BAD_ACCESS when one thread reads memory the other is in the process of deallocating.
How to debug it
Enable Address Sanitizer (ASan) in Xcode's scheme settings. ASan detects memory errors at runtime and points to the exact line that caused the access violation, which the crash log alone often can't do.
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.
The signals agents need to fix iOS crashes
A stack trace alone leaves an agent guessing. Luciq registers signal handlers inside the app, so it captures native crashes like SIGABRT as the process dies, together with the gestures, view state and memory context before them. Companion explains the crash, and Autopilot can open an accurate fix.