Skip to content

Category: Objective-C

Keep your debug toolkit handy but hidden using conditional compilation

When you’ve been working on an app for a while, especially as it gets large, you often start to include snippets of code in the app that have been useful for debugging your app in the past. Such debugging code may be as simple as log statements, to as complex as adding full screens to your interface, activated by controls that you add to your interface for debugging only.

Such tools become an integral part of your debugging environment; you don’t want to throw them out. But do you really want to ship those in your app? It makes your app bigger and slower. You could comment them out before you release, but after a marathon debug session, do you trust that you’ll comment out again all of the debugging tools you enabled?

How can I keep my debugging addons, but ensure they aren’t in the version I deploy to the App Store?

There is a way: you can use a feature of Swift called conditional compilation to enable debugging code on your debug build. If you still have Objective-C code, you’re still in luck: a similar feature called preprocessor macros can provide the same functionality.

When is a Bool not a Bool?

This is a silly question — or rather, it should be a silly question — but it’s going to bite you sometimes when you integrate Objective-C and Swift code together (*cough* UIKit).

You will try to use what you think is a Bool from an Objective-C API, and suddenly you’re getting this compile error:

Cannot convert value of type ‘ObjCBool’ to expected argument type ‘Bool’

This is a Boolean value; why can’t I use this @($^ thing as a Bool?

Normally the standard types play nice between Objective-C and Swift. But Bools are an unusual case that require a non-obvious solution.