Of course, I’m an ex-Apple engineer, have been using the language for 20 years, and tend to write my own code. I’m also retired and doing it for fun, and there’s no management team telling me what I can and can’t do.

Here’s why:

- I’m one of those people who grew up coding assembly because high-level languages were too slow and too wasteful. When your memory is measured in bytes, not even kilobytes, every bit counts. Going from that to larger systems meant that ‘C’ already reduced the footgun count to an (relatively) easily manageable amount.

- Moving to Apple, all those years ago, I’d never used ObjC, but I quickly fell in love with it. It manages to hit the complexity threshold just about perfectly. It gives all the object-orientated expressiveness of C++ without the hideous complexity inherent within that language. Over the years it has added capability (ARC, autoboxing, generics, properties, closures,…) without sacrificing simplicity. You need to learn about a dozen new keywords over ‘C’ to know ObjC.

- As I said, I tend to write what I need, and personally I’m a fan of tightly controlled interfaces to framework code. I wouldn’t pass an NSNumber through an API call if it wasn’t supposed to be a generic number type. I’d take the boxing hit and pass a BOOL if that’s all the code coped with. I understand that if you use a lot of third party frameworks, you may not have that luxury, but I’m a fan of unit tests and fuzzer tests too :)

- These days, ObjC is surprisingly cross-platform. On Windows and Linux you can just use GNUstep pretty much directly, on iOS and MacOS it works well, despite Apple docs sometimes ignoring their ObjC tab, and even Android you can write the vast majority of your code in ObjC and then maybe use QT for the UI.

- I have code that I wrote a long time ago that I’m still using today, the language has stayed pretty stable, about the only time I had to change my code was for ARC, and that was all removing calls to -release and -autorelease. I wrote the database component that Aperture used, donating an object-relational framework I’d written for a previous project called Kaligraphy. The ‘KDatabaseMgr’ classes still live on. I don’t think Swift code is anywhere near as robust to change over the years.

- I actually just don’t really like Swift. I find it inelegant, overly complex for what I need, and it seems more like some academic project that squirmed its way out into the real world. There’s no internal coherence that (to me) is the signature of a well-designed language. In software engineering it’s trivial to make complicated systems, it’s making simple things that work just as well as the complex ones that is hard. Another reason to prefer ObjC over C++.

- The brackets were weird at first, but seriously, it’s just syntax. It’s not the biggest thing to get over. With the new(ish) property ‘dot’ syntax you don’t need them as often anyway. The operations

  Widget *ui = new Widget()   … and      Widget *ui = Widget.new 

- The self-documenting nature of ObjC code enhances its longevity. I can go back to my code archive over the years and the named parameter passing tells me what that code is expected to do, you’re not dependent on variable-names to communicate meaning. This is something Swift copied, but then meddled with to make more complicated. Sigh.

This list is off the top of my head, and I have to check out of my hotel in 30 minutes so I’ll stop. There’s more, but basically, for me at least, ObjC is the best coding language out there, bar none. I’ll happily trade the tiny fraction of times I’ve had a memory leak/crash for the rest of the benefits. I’m a fan of comprehensive tests, and a fan of focused, tightly coded frameworks with those tests. The thing that Swift is supposed to protect me against never really caused me problems….