I think stay sharp in the tech industry, you have to be in a constant state of uncomfortableness. If you think you know everything and/or aren’t always trying something, you’ll lose your edge fast as your ability to notice trends and adapt atrophies, and when the Really Big Disruptive thing happens you’ll be unable to find your legs.

It’s easy to be a little uncomfortable - constantly asking yourself “what’s under this?” and “how does this work?” is the healthy curiosity you need that will save your bacon when production inevitably fails at 4 in the morning. Better understanding the systems you work with is a good habit that pays dividends.

However, it’s not enough to know only the systems you’re paid to know. Your company may have been on the bleeding edge once, but is it now? How would you know if you’re missing out on some really helpful tools or technologies? This can be a drawback with working on Unix-like systems - they’re stable, effective, and boring, but that means new concepts take a while to shake out everywhere (if at all), and with the variety of systems it’s easier to cling to POSIX tools like a life preserver. If you think of how long it took for the boolean type to end up in C, you know that you can go a long time with niceties folks using other systems take for granted.

Once a year I try to take a quick spin in an ecosystem I’m totally unfamiliar with, and for the holiday break this year (truncated to just a few days for reasons I can’t get into) I decided to take a look at the Apple Developer ecosystem.

I Should Cocoa

Now for the longest time I’ve kept away from the NextSTEP stuff (Cocoa, Objective C, etc.), and stayed within the comfort zone that is the Darwin core (UNIX/BSD).

You can treat a MacBook Pro like a really pretty terminal emulator for years, and you’ll probably be fine (I certainly managed, and I know many people who have also done the same). But ignoring all the other parts of the ecosystem means I’m not able to play with the fun graphical bits of my computer, or sell premium egg timer apps in the App Store.

Swift

What I wanted to learn first was the Swift programming language. I’ve heard Swift grouped in with Go and Rust as a next-generation systems language. The basic syntax and control flow isn’t crazy, but I’ve not done a whole lot with it besides basic Hello World stuff. I need to wrap my head around how they’ve extended enumerations (“it’s like C, but flexible” sounds a little terrifying), and I’ve had some problems with the documentation (which I’ll get into below).

Xcode

Of course, using the Apple ecosystem pretty much requires Xcode IDE. While it’s using LLVM under the hood, I imagine trying to do all the wrangling for apps without Xcode is an exercise that’s only worthwhile if you’re doing app work full time (and even then, it looks like Xcode is the well-worn path). As a Vim die-hard, it was a little hard letting go to work in Xcode, but it turns out that a lot of the behaviour that I’ve augmented Vim with (via plugins) is out of the box functionality with Xcode. The playground was pretty neat, and handy for learning Swift, as it continually executes and displays the output to the side.

My main problems with Xcode are the screen clutter (I’m used to just a few terminals displaying what I need) and how it consumes so much of the system resources that it basically runs standalone on my older Mac. The refactoring tools are really good, but their only appears to be out-of-the-box support for Objective-C and Swift (although I suspect this could be extended). Problems aside, after several days I found myself enjoying Xcode, and I’m wondering how to get some of that functionality into Vim.

After getting my feet wet with Xcode and Swift, I figured it was time to build an iPhone app. I’ve seen enough 12-year-olds hawking their apps, so I figuring that this should be a cakewalk. However, this is where my Unix background slams into the wall. I’ve done a lot of OO-programming, but I don’t often work with the UI (often sticking with HTML output, which is easily manipulable in a terminal). I managed to get an app partially done, and with any luck I’ll find the time to finish it and drop it in the App Store.

Objective-C

I was still hitting some mental roadblocks while trying to get a basic application out the door, and at this point I figured the problem might be with the documentation in Swift. I still like Swift, but after looking at the API docs I still couldn’t see how everything would fit together, and there was too much “give you the fish” and not enough “teach you how to fish.” So that’s when I decided to take a look at Objective-C, which I figured might be the Rosetta Stone to me grokking how to really work with the built-in frameworks.

Jumping into Objective-C seemed to be the trick. I forget where I heard the anecdote, but there’s a line of reasoning that the C-style languages have survived this long because the documentation has to be more in-depth. Objective-C may be a superset of C, but to use its power requires learning a lot of new syntax and behaviour. That said, the docs were a lot meatier on the how-and-why.

A bite from the forbidden fruit

It’s worth bringing up the bit about “diminishing returns.” After working with any system after 10 years, digging deeper and deeper into its guts, the work you’ll put in to better understanding better yields less and less reward. Spending a few days learning more about macOS has been more beneficial than if I’d spent my time reading some GNU coreutils source code. It’s easy to get a little over-specialized, so it’s good to spend a few days a year getting outside of your comfort zone.

I’m still a big believer in open systems - if you can’t fix it yourself, you don’t really own it. And that’s where I get uneasy after spending some time in the Apple ecosystem. It’s a walled garden, but a really good walled garden. There’s a lot of thought put into the interfaces of their frameworks, and they’re solving real problems instead of continuously re-inventing the wheel. It’s not hard to make a simple program that looks good. After getting a whiff of the Kool-aid, I can confirm it smells mighty delicious.

I’ve taken a quick look at GNUStep, and while it addresses the Cocoa aspect, it says right on the tin that they’re not striving to be an operating system. In classic bazaar fashion you’re expected to cobble together the parts yourself. But having looked at the macOS experience a little more deeply, I can see a big part of the appeal is that macOS supplies you with decent default programs. Tools, docs, and frameworks right from the start, and for many people they will happily use these Good Enough defaults. An open-source operating system using the Linux kernel, GNUstep, and good default programs seems like a great idea - I wish I could be the person to start something like that, but I think that’s a project for someone with some time.

• Apple