Back to blog

How To Solve SIGABRT Error in Xcode

---

One minute your iOS app runs fine in Xcode, and the next it has hopelessly crashed with a cryptic SIGABRT error. What’s going on!?

Developing an iOS app can be a rewarding experience, but like any development process, it comes with its own set of challenges. One such challenge is encountering errors that might seem baffling at first glance.

The SIGABRT error is one such hurdle that many developers, both new and experienced, might come across. It’s essential to understand that while this error might seem intimidating, it’s just a way for Xcode to communicate that something isn’t right. With the right knowledge and tools, you can swiftly navigate and resolve it.

In this app development tutorial you’ll learn:

• How to solve the “Signal SIGABRT” error in Xcode
• How to use some of the debugging tools in Xcode
• What SIGABRT stands for, and what its causes are
• 3 approaches to find the root cause of SIGABRT

 

What Does “Thread 1: Signal SIGABRT” Mean?

The error SIGABRT stands for “signal abort”. It’s a signal that’s sent by iOS – the operating system – to a running app, which will immediately quit the app because of a runtime error. It essentially means your app has crashed…

To break it down further, think of your app as a series of tasks or ‘threads’ running simultaneously. Each thread is responsible for a specific job. When one of these threads encounters a problem it can’t handle, it sends out a distress signal, in this case, the ‘SIGABRT’.

The ‘Thread 1’ typically refers to the main thread where most of your app’s core functions run. When this main thread faces an issue, it’s a significant concern because it can halt the entire operation of your app. This is why understanding and resolving the SIGABRT error is crucial for a smooth user experience.

The problem with the SIGABRT error is that it’s too generic. Xcode is basically saying: “Look, your app has crashed, that’s all we know.” In most cases of the SIGABRT error, you get little information about what’s caused the error.

Before we go on, let’s discuss a few misconceptions and common pitfalls of SIGABRT:

• The SIGABRT error usually has nothing to do with the AppDelegate class declaration, even though it highlights that line in Xcode. The line is highlighted because it’s the first line of code of your app. Don’t waste your time looking in the AppDelegate class, unless you’re absolutely certain the bug is in there.
• The stacktrace is a list of function calls that lead up to the app crashing. That doesn’t mean the line of code that caused the error is anywhere in the stacktrace. It sometimes is, but in other cases, the stacktrace merely leads to the code that choked on a value you set elsewhere in your own code.
• Don’t stare yourself blind on a SIGABRT error. There’s a rational, logical cause for the error. It’s probably a bug in your own code, and there’s nothing wrong with that. Apps aren’t magic, no one is out to get you, and bugs never appear out of the blue. Don’t frustrate yourself with thoughts like “It ran fine yesterday!” – it always does, and now it doesn’t!

Now that we’ve established a baseline, let’s get to the first cause of SIGABRT.

Check Your Outlets

A common cause of “Signal SIGABRT” is a typo or bug in your outlets. Here’s what happened:

• You created a new view controller in Interface Builder, and set it up with a few UI elements like buttons and labels
• You connected these UI elements to your code by using outlet properties, which creates a connection between a property of your view controller and the UI element in Interface Builder
• At one point you changed the name of the initial outlet property and your app started crashing with a SIGABRT error

Outlets in Xcode serve as bridges between the visual components you design in Interface Builder and the code that powers their functionality. Think of them as electric outlets in your home; if the connection isn’t secure or if there’s a mismatch, things won’t work as expected.

Similarly, in app development, even a small oversight like renaming an outlet without updating its connection can lead to errors. This is because the system expects a clear path between the UI element and its corresponding code. When this path is broken or misdirected, the system raises an alarm in the form of the SIGABRT error.

When you’re using Interface Builder to create a view controller, your app will use the XIB file to generate the view controller’s UI when your app runs (roughly speaking). At this point it will also connect outlets from the XIB to properties of the view controller class.

If you’ve changed the name of an outlet property, your app can’t find it anymore. And because of that it will throw an exception. What’s causing the SIGABRT error, is not handling that exception.

Here’s what that looks like in Xcode:

See what’s happening? The property is called otherButton, but the outlet is still called button. At one point we changed the outlet – because the new name is better – and confused the app, which made it crash.

At the top of the stacktrace we also spot another clue:

Terminating app due to uncaught exception ‘NSUnknownKeyException’, reason: ‘[<...> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key button.
What does that mean? The app is telling us at this point that the view controller is not key value coding compliant for the key button. This means that it cannot find the button property on the view controller. And that’s true, because we’ve renamed it.

iOS uses a mechanism called key value coding to inspect the properties a view controller has, so it can use those properties to reference UI elements it has created based on the XIB.

How do you solve the bug at this point? You can use 2 approaches:

1. You rename the property back to its original name
2. You remove the outlet connection in Interface Builder, and reconnect it using the new outlet property name

Quick Tip: Just as a changed @IBOutlet can cause “Thread 1: signal SIGABRT”, so can erroneously changing the name of an action, i.e. with @IBAction, cause the SIGABRT error.

Check The Stacktrace

In many cases Xcode won’t show you any helpful error messages for a SIGABRT crash. When that happens, it’s useful to know a few debugging commands, such as bt.

The stacktrace is akin to a detective’s notebook in the world of app development. When something goes wrong, it provides a chronological record of events leading up to the error. By examining this record, developers can trace back to the origin of the problem.

Think of it as retracing your steps when you’ve lost something. Each entry in the stacktrace represents a function or method call, and by examining these, you can pinpoint where things started to go awry. The ‘bt’ command is a handy tool in this investigation, offering a concise view of this record.

Xcode has an integrated debugging environment called LLDB. It’s what you see at the bottom of Xcode when your app runs, the Console or debug output area. You often see debug messages here, but did you know you can also use it to input commands?

Next time your app crashes, try typing help in LLDB. Like this:

You’ll see that many of the LLDB commands directly correspond to actions you can take with the debugger, such as setting breakpoints, stepping over lines of code, and inspecting runtime values.

One command is particularly useful. You can type in bt to see the current call stack (also called “backtrace” or “stacktrace”). This is a list of all functions that ran up to the current crash. This trace typically includes the function that caused a bug.

Here, check out the stacktrace of a typical Index out of range error. In the screenshot below, we’ve deliberately caused that error by getting index 99 from an array that only has 4 items. When the app crashes, bt can tell us which line of code caused the error.

Can you spot the following information in the stacktrace?

• The offending code is at line 21 of ViewController.swift, inside the viewDidLoad() function
• You can even see that we used the subscript “getter” of Array
• Before the crash a whole bunch of view controller-related function calls were made

Based on the information we got with bt, we can find the offending line in our code and fix it. Xcode already helped us in this case, by highlighting the error in the editor. In some scenarios you won’t have such luck, and then it can be helpful to use the bt command.

One last thing: you can inspect values at runtime with the print command. In the above scenario, typing print names would have produced this output:

([String]) $R0 = 4 values {
[0] = “Ford”
[1] = “Arthur”
[2] = “Zaphod”
[3] = “Trillian”
}

For printing complex objects, use po. Awesome!

Keep in mind that a stacktrace runs outside-in. The bottom of the stack trace shows top-level function calls, and the higher up the stack you go, the deeper the calls go in. The latest, most recent, deepest-level call is at the top of the stack.

Make an Exception Breakpoint

An exception breakpoint is triggered whenever an exception occurs in your code. Instead of specifying on which line the breakpoint is triggered, you instruct the debugger to halt code execution for exceptions.

Imagine you’re reading a book, and every time there’s a plot twist, you place a bookmark. These bookmarks help you quickly revisit crucial turning points in the story. In the realm of coding, exception breakpoints act like these bookmarks.

They automatically mark the exact point where something unexpected happens, allowing developers to pause and inspect the situation. By setting up these ‘bookmarks’, you’re essentially telling Xcode, ‘Hey, if something unusual happens, stop right there and let me take a closer look.’ This proactive approach can save a lot of time and frustration during the debugging process.

Exception breakpoints are useful for inspecting the code when an exception occurs. You can see which line of code threw the exception, and you can inspect values in your code at that point. Some exceptions are caused by bugs or invalid states of your app, so exception breakpoints are useful for finding and fixing those bugs.

Here’s how you can set an exception breakpoint:

1. Go to the Breakpoint navigator in Xcode, by using the tabs on the left
2. Click on the bottom-left +-button and choose Exception Breakpoint
3. Leave the default settings as-is (although they’re helpful to customize)
4. Run your code

When an exception is thrown, execution of your app halts. You can now use the debugger to inspect values, step through the code, and use LLDB commands. When possible, Xcode will take you to the line of code that caused the exception.

Keep in mind that an exception doesn’t necessarily crash your app! So, whenever the exception breakpoint is enabled, and an exception occurs, your app is halted. Halting code with a breakpoint isn’t the same as an app crash, so don’t let that confuse you.

For example, an exception breakpoint will get triggered by an Unsatisfied constraints exception, but that won’t crash your app. Use the exception breakpoint to gather extra information for the SIGABRT crash, and then disable it once you’ve solved the bug (until it’s needed again).

Conclusion

The SIGABRT error is quite cryptic, and can prove difficult to solve. Why can’t Xcode just give helpful error messages? Well, that’s a good question…

The short answer is that there are so many moving parts in iOS development that Xcode can’t always determine the cause of a crash. Xcode doesn’t know that you erroneously changed the name of an outlet. It only knows that in connecting the outlet, some code was invoked, and that caused an exception.

This means you’ll always see an error that’s as close to the root cause as possible. The best you can do is make lots of mistakes, decrypt lots of error messages, and get to know them better. And what you’ve learned in this tutorial, is how to find and solve the SIGABRT error!

Create Your App Now