Every Apple-Adjacent Developer Should Know…

Liz Marley
Jul 25, 2017 · 8 min read

I was dining alone for lunch the other day. And rather than stare at the adjacent parking lot, I chose to stir up a conversation among my community of iOS and Mac developers by tossing a question into a Slack channel. I got some great responses which I plan to follow up on (and a few I’ll choose to disregard). I got the expected punch list of APIs and keywords to read up on, interleaved with an unexpected trove of hard-won wisdom. I’m re-inspired to hone my craft.

I’ve edited and reorganized the chat log a bit for clarity and public consumption, but most are pretty direct quotes. If you contributed to this conversation and don’t mind being credited (or would like any other changes), please let me know?

Shipping a .0 release I did engineering work for feels like a good milestone to me. Almost 2 years on the code side now. Wondering what weird gaps I have in my apprenticeship. What do you think “every Apple-adjacent developer should know”?

The responder chain. How to use Instruments, the Memory Graph Debugger, and the View Debugger. How to create and use frameworks instead of building a monolithic app. How to use Git. How AppKit and UIKit both still rely on dynamic Objective-C. How to localize. How to make UIs accessible.

Eek! That’s a lot at once. When I jumped in the deep end a couple years ago, I hoped it was an especially good time to do so, because everyone was flailing about in Swift, and we could all learn together. The reality is, as noted above, that I still need to understand a lot about Objective-C.

I thought I could get by with only minimal Git. My day job uses Subversion. But the latest beta of Xcode is starting to nudge Subversion towards deprecated status. I better go figure out how to rebase and squash like everyone else.


So looks like you already know everything you need to know, @emarley. 😜

This comment came towards the end, but I’m putting it at the beginning, so you don’t run away in shame before reading to the end. I quite nearly took this comment sincerely at first — that this overwhelming list was really all stuff that everyone else in the conversation had already mastered. And I was a bumbling fool, having mastered so little in the past two years. But no, I heard later that there were quite a few topics mentioned that other people felt the need to at least brush up on, if not sincerely learn for the first time. I point this out so that you, dear reader, are also not frightened away.


The responder chain never gets covered well, in my opinion.

Hmm…the responder chain? Is that walking up the class hierarchy, and getting super's implementation if you don’t write your own? No, wait! first responder is a UI thing. What’s the front-most, most involved UI element to get dibs on the user’s tap or keystroke? Well, those are probably both worth reading up on…


Auto Layout. Like it or not, it’s here to stay, and folks need to work with it, in my opinion.

Auto Layout is a bit “Jekyll & Hyde” to me. First you’ve got this appealing GUI for arranging your views, with angry red lines to warn you when you’ve probably got it wrong. Then there’s the programmatic way to define all the same things, if text helps you think about the geometry more clearly, or you need it to vary based on other things happening in the code. Either one on its own is kind of okay. The terrible thing is when you mix them together and switch back and forth unexpectedly from one part of the app to the next.


How KVC and KVO work under the hood.

I suspect “Dark Magic” is not the answer he’s thinking of.

For that matter, how properties work under the hood.

I know about @synthesize and explicit getters and setters. Is there another hood under that?


Techniques for avoiding subclassing: protocols, delegates.

There’s another piece of advice here, that maybe seemed too obvious to the author: ‘Sometimes subclassing is a bad idea.’ The C++ data structures class I took in college was pretty heavy on sub-classing, so I need to check my impulses some.


Two philosophical things: 1) don’t fight the frameworks, and 2) don’t fight the frameworks, even if you’re sure you know better.

Oh good. Fighting the frameworks usually makes me uncomfortable. I worried I was just being too idealistic.

More philosophy: don’t create your own dialect of Cocoa.

Really, please don’t. Will you really really save more time coding in your favorite flavor than you spend teaching it to the next teammate, debugging the mess they leave behind when they quit rather than keep trying to learn it, and recruiting their replacement?


When to use direct ivar access and when to use accessors in Objective-C.

Accessors only, except for initializers, de-initializers, and getters. And maybe, in extremely rare situations, for performance. But I bet there are other performance bottlenecks you need to fix first.


Know when to be angry. You can’t be angry about everything. 😎

Learn how to recognize when you’re trying to be angry about everything.

Besides it being exhausting to always be angry, there are real people building the thing you’re angry about.


Keep modernizing your code, even old code. Don’t let warnings and assertion failures pile up. Cleanliness is job #0.

The only reason I don’t turn on warnings as errors is I comment out code a ton when working and end up with unused variables and it would just be annoying…But I hate warnings. I want to build clean.

So…if you not-so-hypothetically already have a big pile of warnings, what now? Burn them all down before you write any new code? Try to move forward without adding more?


Value a clean Xcode console. Anything that appears in there is (in the ideal case) something you need to pay attention to, and there shouldn’t be anything else.

Again, what do you do with the noise you’ve already got? And is there a way to stifle the gratuitous chatter from Apple frameworks that sometimes springs up in the middle of beta season?


Try to avoid adding dependencies on frameworks found on Github or elsewhere.

Free code is only free if your time spent maintaining compatibility with it is free. Also consider the odds that it will get updated with the next OS update.

Minimize the amount of public API. (In Objective-C, put in the .h file only what is actually needed.)

I pair this with the previous comment, because it feels like the other direction of the same street.


Minimize state — strive for immutability as much as possible. But don’t take this to the extreme of going down the React rabbit hole.

Brent Simmons said don’t credit him for any of his comments except for this one, since he likes trolling Casey and Jamie.


Know how to read the documentation. Lots of people I’ve seen come new to the platform jump to Stack Overflow immediately, when glancing at the Overview section of a class’s documentation would have had their answer in the first sentence.

Sometimes Apple has nice documentation beyond just the class references—a bit of guidance on how to put the various classes together in common ways, like the new drag-and-drop for iOS 11. Unfortunately, those seem to only be in Swift now.

I was just about to install Dash, and then there was that kerfuffle where it was off the App Store. Looks like it’s back now.


Big one: understand reference counting, even if you’re writing all-ARC or all-Swift.

As they say, counting and cache invalidation are two of the hard problems in computer science. Reference counting is kind of combining the two, and I’m really glad I can entrust it to the computer most of the time.

+100. One thing that can still get you into trouble is cycles. (And block/closure captures which create cycles.)

Have you seen the new memory graph stuff in Xcode 9? I almost want to chase some memory bugs just to try that out. Almost.


Understand the difference between escaping and non-escaping blocks in Swift.

Also captured self in blocks. Understand when they are, and when they are not. (dispatch, enumeration, vs. completions, etc). Understand when an NSURLSession runs, the completion, and/or delegates may not come back on the main thread. So if you are doing UI in the callback, make sure you put those on the main thread.

Also, please don’t call your weak and strong self welf and strelf. They sound like something from Tolkien. They might make cute kitten names, though.


Understand locking. When to use it, and when something like a serial queue might be better.

I know what both of those are. I’m not sure why I didn’t think of them as solutions to a heavily overlapping set of problems.


Learn to recognize when you’re being clever, and how to back out of it, and why you should.

Never be clever. The future will make you look stupid.

In American English, ‘clever’ is (always?) a compliment. In programmer English, it has this interesting extra connotation, that makes its balance of praise and insult depend heavily on tone of voice and whether you must maintain said code.


Coding is hard, let’s go shopping.

Can’t go shopping. Busy worrying about the planet after that big chunk of Antarctica fell into the sea.

In case you don’t know the reference, there was a Barbie several years ago who said the horribly stereotype-reinforcing line “Math is hard, let’s go shopping.” I’m glad Mattel has since come to their senses, and I enjoy having Game Developer Barbie on display in my office.


A good working knowledge of GCD is critical.

GCD for me, to this day, still stands for Global Cool-Down (recovering Warcraft player)

For me, “GCD” can only be said in the French accent of Bertrand Serlet. That was one of my first WWDCs. The slides showing trains driving in and out of the station are etched in my brain. That probably doesn’t count as “a good working knowledge,” though.


I can think of two books that should be required reading. The Pragmatic Programmer: From Journeyman to Master and Code Complete. (I’ve seen a copy of Code Complete in the office, and wouldn’t be surprised Pragmatic Programmer is somewhere around here too.)

I thought I had a hard copy of Code Complete in my office, but I don’t. I do have Writing Solid Code.

Also worth reading, definitely. I have Writing Solid Code in my office too.

(I still haven’t read Pragmatic Programmer.)

I’ve been meaning to re-read Pragmatic Programmer for a couple years now.

See, all these smart people I’ve been taking advice from are still working on taking their own advice too!


I find it interesting how many of the tips I’d classify under “maintenance and continuing to move forward”.

As I said at the beginning, I was expecting more of a syllabus of technical concepts. But I think the more philosophical points are what we’ll still point back to when Swift is passé and we have moved on to the next new thing.


All of this would be a great blog post.

I don’t know anyone with a blog. 😎

Nobody does. — somebody with a popular blog

me either…oh wait. —somebody else with a blog well worth reading

I will summarize it all in a blog post as a way of starting to process it into a form I can take action on. —me

Liz Marley

Written by

levels up her people skills

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade