Errors, Warnings, & Leaks

Just do it all again?

Get It Try It

There's nothing quite like going through one's catalogue of 70+ Cocoa applications and getting them not only lean and mean, and otherwise perfect, and then making sure the code generator doesn't emit warnings, no matter how trivial. All developers want that (save perhaps the 'lean and mean' part, which we've illustrated amply in our 'software review' section). Those labours reward with a feeling of pride and accomplishment.

As icing in the cake, one then proceeds by running leaks on each and every module, to make sure there aren't any memory holes anywhere.

(As a way of comparison, one of our favourite apps, AppKiDo, leaks over a megabyte already on startup. Not acceptable.)

Grinding through a leak hunt doesn't have to be a trivial exercise. Cocoa memory management doesn't have to be difficult, as it's been laid out in a consistent and straightforward fashion. Most of the time there's no room for leaks.

(Apple's flirtation with automatic garbage collection is not something we ever latched onto, our belief being that if you don't know how to manage memory, you don't know how period.)

But sometimes things seem to leak anyway, and the output from leaks can give you some pretty obscure clues as to where to begin hunting. Sometimes those leaks can be easy to find - if they're in your own code. Things start getting dicey when, as is often obvious, they're not in your own code at all, but in one of your 'dependencies' - one of Apple's own frameworks. Plugging those leaks is more difficult, as you can't change the erring code, but have to try to swerve past it.

But it can be done. It's not easy, but it can be done.

And, when you get that far, you have a nigh-on perfect release, far better quality-wise than a lot of products out there, and it's truly 'Miller Time'.

This is something we've held to for most of the past ten years.

But then Apple will come along with an OS update and you start all over.

Errors

Errors are of course a showstopper. Nothing will run if there's an error. Why and how can there suddenly be errors? This is mostly down to errors in the configuration file. How do these errors creep in? They creep in because there was an error in the previous version of Xcode, and you needed to do a bit of magic to make things work, but by the next version of Xcode they've corrected their error, and so your workaround no longer works.

The latest version of Xcode, for example, and for the first time in the history of that application, nixes the relative paths it's used since its inception. So ~/ no longer works, even though it's Xcode who, once upon a time, put that ~/ in there in the first place.

Xcode's also had a bout with external proprietary frameworks, requiring a rather involved workaround, and, when finally fixed, all project files had to be manually corrected as well.

Not fun. But after that things should work OK. Now all you have to do is...

Warnings

Microsoft had a cute way of handling warnings, as they told us themselves. Their compiler had four warning levels. The lowest level was essentially worthless - it objected to nothing. The highest level was worthless too - their own header files couldn't make it through.

We naturally took the next highest level, the highest level that actually worked. (When it comes to event-driven programming, you should always take the highest possible level.)

But how about Microsoft? No way! Microsoft built their OS with a lower level. (Think about that: they chose, to build Windows, the warning level right above 'no warnings at all'.)

Trying to generate as many warnings as possible is essential even on Apple's OS. What is not fun is to see where warnings suddenly pop up for a new OS version. Apple have a bad habit of changing the underbody to a long-established API - and they do so in the least constructive way possible.

We've now seen no less than three (3) procedures for dealing with drag-drop operations. The first, the earliest, comes of course from NeXT. That procedure worked well for dozens of years. (It still would.) Then someone at Apple came up with a new method. So all legacy code, going back twenty years or more, suddenly generated warnings.

That time, it turns out, the procedure now used was actually rather cool, and left more of the crunching in the frameworks and less in the client app, and it could work very fast, so despite the additional bulk, it was a win.

Then they decided even that procedure wasn't good enough, so they changed their code yet again - and started issuing new warnings once more.

Code that's worked flawlessly for the entire lifetime of the OS now has to be reworked all over the place because someone somewhere inside One Infinite got a brilliant idea - not an idea that coexists with all that legacy code out there from one end of the globe to the next, but an idea that will replace all that legacy code. In hundreds upon thousands of source code files everywhere.

Not to speak of quirks like header search flags, which they suddenly introduce, only to deprecate them for the next release. As if they can't make up their minds what they want.

Dark Mode. Yes it was a grand idea, and yes, their version works better than most, but couldn't they have done it without requiring ISVs everywhere to go back into old code once again and root around? When will the next change come?

Leaks

And the leaks. Oh let's not forget the leaks. Or that grand feeling when taking a complete system build of 70+ projects that have passed every last test - no warnings, no errors, no leaks - and building them on the new system? Where do all those leaks come from all of a sudden?

Sherlock wouldn't hesitate. If your code demonstrably did not leak on the previous OS version, and if your code has not been changed, and if it suddenly leaks now, then what, exactly, has changed?

The answer is elementary.