UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

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.

BUILD THE ULTIMATE PORTFOLIO APP Most Swift tutorials help you solve one specific problem, but in my Ultimate Portfolio App series I show you how to get all the best practices into a single app: architecture, testing, performance, accessibility, localization, project organization, and so much more, all while building a SwiftUI app that works on iOS, macOS and watchOS.

Get it on Hacking with Swift+

Sponsor Hacking with Swift and reach the world's largest Swift community!

Buy Pro Swift Buy Pro SwiftUI Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS 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

Unknown user

You are not logged in

Log in or create account

Link copied to your pasteboard.