So if you’re anything like me you get a lump in your throat and a cold sweat every time you are about to hit the “SUBMIT” button in iTunes Connect and release your latest creation upon the world.
Usually about five minutes later the voice in the back of my head starts whining “What if we missed something?” And then you don’t get any sleep that night.
Well, everything compiled just fine. Everything seems ok. And if there are bugs, well that’s what updates are for, right?
Nope. That’s not good enough these days when your users give you 30 seconds to make an impression before your hard work gets uninstalled from their device. There is no margin for bugs or crashes and you won’t get a second chance.
XCode’s LLVM has some powerful options that can improve the quality of your code going out the door and improve your chances of making it past the 30 second mark.
So powerful in fact we can only use them sparingly.
OK, go ahead and click that large friendly Static Analysis button! Go on, I’ll wait…
OK, no warnings, awesome, looks solid right?
Wrong. Let’s do it again and let XCode off the leash, like a Schnauzer with a Chainsaw twice it’s size …
Chainsaw aka. the LLVM 4.2 compiler has a bunch of insanely useful Compiler Warning Flags that can scan all of your code and point out potential errors. We’ve talked about one for @selectors before, take a look at what other flags we have available!
These are just some of the more useful of these Warnings Flags in the Build Settings, which start off ENABLED = NO. Now we’re going to enable these (or even more if you are brave), just this once, and re-analyze our app again …
What?! Over a thousand warnings???
Ok relax, XCode is trying to be helpful, it’s just not all that smart.
That’s also why most of these flags are turned OFF normally, 90% of these warnings are going to be dead wrong. You can’t code on a day-to-day basis with all this noise, which is why we can’t leave it set like this all the time.
NO app will get a clean bill of health here. Even a brand new project will complain about the applicationDidFinishLaunching: function because you didn’t use the ‘application’ variable passed in. Even after discarding bogus warnings like this, that still leaves 10% or about a hundred warnings that are legitimate concerns.
While there is nothing technically wrong with empty functions, unused variables or weak pointers, they are often indications of less-than-optimal code: Unfinished TODO’s, refactored code, obsolete or dead code, old design patterns … and that’s exactly what you are really looking for in this exercise:
Like Criminals, Bugs often leave a trail of evidence behind them that can lead us straight to them.
Yeah, that last bit really sounds awesome in your head because it was in a bold font. Anyways, of the hundred or so legit warnings, you’ll probably find less than a handful of actual bugs.
But you will find bugs. And you will have a more robust app after you fix them.
Is it worth looking through a thousand false warnings to find a couple of real, legitimate bugs?
Absolutely.
About the Author
