NEW: Nominations are now open for the 2019 Swift Community Awards! >>

Debugging with assert()

One level up from print() are assertions, which are debug-only checks that will force your app to crash if a specific condition isn't true.

On the surface, that sounds terrible: why would you want your app to crash? There are two reasons. First, sometimes making your app crash is the Least Bad Option: if something has gone catastrophically wrong – if some fundamentally important file is not where it should be – then it may be the case that continuing your app will cause irreparable harm to user data, in which case crashing, while a bad result, is better than losing data.

Second, these assertion crashes only happen while you’re debugging. When you build a release version of your app – i.e., when you ship your app to the App Store – Xcode automatically disables your assertions so they won’t reach your users. This means you can set up an extremely strict environment while you’re developing, ensuring that all values are present and correct, without causing problems for real users.

Here's a very basic example:

assert(1 == 1, "Maths failure!")
assert(1 == 2, "Maths failure!")

As you can see assert() takes two parameters: something to check, and a message to print out of the check fails. If the check evaluates to false, your app will be forced to crash because you know it's not in a safe state, and you'll see the error message in the debug console. You can – and should! – add these assertions liberally to your code, because they help guarantee that your code’s state is what you think it is.

The advantage to assertions is that their check code is never executed in a live app, so your users are never aware of their presence. This is different from print(), which would remain in your code if you shipped it, albeit mostly invisible. In fact, because calls to assert() are ignored in release builds of your app, you can do complex checks:

assert(myReallySlowMethod() == true, "The slow method returned false, which is a bad thing!")

That myReallySlowMethod() call will execute only while you’re running test builds – that code will be removed entirely when you build for the App Store.

So: assertions are like running your code in strict mode. If your app works great with assertions on – things that literally make your app crash if things are wrong – then it will work even better in release mode.

SAVE 20% ON iOS CONF SG The largest iOS conference in Southeast Asia is back in Singapore for the 5th time in January 2020, now with two days of workshops plus two days of talks on SwiftUI, Combine, GraphQL, and more! Save a massive 20% on your tickets by clicking on this link.

Buy Testing Swift Buy Practical iOS 12 Buy Pro Swift Buy Swift Design Patterns Buy Swift Coding Challenges Buy Server-Side Swift (Vapor Edition) Buy Server-Side Swift (Kitura Edition) Buy Hacking with macOS Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with Swift Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Beyond Code

Was this page useful? Let us know!

Average rating: 4.9/5