When you’re faced with difficult circumstances whilst coding, it’s often more productive to skip over the troublesome section, perhaps implementing some hack, and then return to it later when circumstances change. Usually these sections of code are marked with the word TODO and Xcode will add a nice little marker in the class overview for you.

TODO with class overview

However, all too often, these TODOs are forgotten about and become part of the production code! Now new features take precedence and allocating resources to repay this technical debt is the lowest priority. The problem is that TODOs are not obnoxious enough — they are merely shy, easy-going residents that are too easily ignored.

It is for this reason that I (and many others) use #warning instead of TODO. I call these “intended warnings” because the developer has added them. Each warning will present itself to you every time you make a build (but still allow the build to pass), so it’s much more obvious. However, this isn’t an ideal solution either for two main reasons.

Firstly, Consider the project that has 20 intended warnings… Are you going to notice when an unintended warning appears? If you’re working in a team, you don’t want your teammates to commit an unintended warning either.

Secondly, many developers prefer to set the “Treat warnings as errors” flag to Yes, meaning that these warnings would actually fail the build.

Thankfully, GCC (and now LLDB) is very configurable when it comes to deciding what triggers a warning, what doesn’t, and which of these warnings are promoted to errors. Using this configurability, we can treat intended warnings as genuine warnings, whilst unintended warnings will get promoted to errors. To do this, all you need to do is add the following custom warning flags in your project settings:

Custom warning flags

Settings -Werror promotes all warnings to errors, and then -Wno-error=#warnings demotes any #warning directives back to warnings. Therefore, only unintended warnings will be promoted to errors!

Finally, what happens if you have an undesired warning that you really can’t remove right now (because, perhaps, it lives in a third-party library). In these situations, I recommend suppressing the warning (to pass the build) and add your own #warning instead (which won’t fail the build).

If you work in a team, I also recommend adding your initials to the warning to make it clear that this warning is your responsibility to deal with ASAP.

- (void) yourMethod {
#warning ALD Suppressing deprecated method until this library is updated.
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
    //use deprecated stuff
#pragma clang diagnostic pop