Software Survival

I just finished reading an oddly named book by someone you’ve probably never heard of – I loved it so much I’m writing this site’s first book review.

Ken Kocienda is a talented developer. He’s also a lucky one: he worked at Apple during the years when the Mac was reborn and the iPhone was created.

If you’ve ever opened the web browser in your pocket or typed a text message on a piece of glass, you’ve used his seminal work. Ken was directly responsible for two important parts of the original iPhone: a fast and efficient web framework and a keyboard that was both virtual and predictive.

Ken is also a great storyteller. His experiences during these formative years provide great material for this narrative. But more importantly, he extracts lessons from these tales that can be applied to our own efforts.

In short, Creative Selection is a study on how great products evolve that inspires the reader.


I first learned of Ken’s work during a presentation at WWDC 2014. A Strategy for Great Work showed that in addition to doing interesting things, he also took the time for introspection and learning from the work. I immediately followed him on Twitter and eventually discovered our mutual admiration! (That, in turn, led to the advanced copy I’m reviewing today.)

This talk, along with the ones that preceded it, feel like a formative process for the chapters of the book. The video linked above will give you a very good idea for the tone of his latest work, but there’s also an important difference.

Ken no longer works at Apple.

The end of presentation in 2014 alludes to this situation: not being able to talk about certain things is a fact of life in Cupertino.

I found Ken’s new freedom most intriguing when he focused on other people’s contributions to the secret projects. Every developer knows that a success involves many different talents and personalities. And with Apple’s penchant for secrecy, we never hear about these team interactions.


The collaboration between Steve Jobs and Jony Ive is not only well known, it’s well understood. I think this is because industrial design is much more concrete and easier to interpret in the formative stages.

Steve had another important collaborator, but that relationship isn’t as well understood. Creating software requires abstract decisions and a more opaque process. How do you make a button on a piece of glass?

When you look at the Wallabies from Ken’s desk, you can see where the hardware is headed:

iPhone Prototypes from Ken Kocienda's desk.

When you think about what was on those screens, things get more complicated.

This book changed my view of Scott Forstall because it gave context to his work. Ken’s account breaks down the approach and shows how important Scott’s leadership was to Apple’s success.

Having Steve Jobs as a boss for your entire professional career would not be easy, but Scott handled it with great success. Even when that powerful mentor was asking for skeuomorphism.

The hardware would be lesser without Jony, and Ken shows that the software would be lesser without Scott.


If you’re a developer, you’ll find some passages a little slow going. That’s because you know too much :-)

As a great storyteller, Ken endeavors to make the topic as widely understood as possible. To achieve this he turns to analogies in cooking, sports, and the movies while describing the process of creating software.

While we may not need this high-level view, there is an important group that will benefit: our families. If you’re like me, you’ve struggled to explain what you do at that keyboard all day.

We all love our iPads and Kindles for reading, but I’m really glad I have a printed copy of the book to share with the people I love.


I’ve avoided spoilers in this review, but I’ll end with one story that touched me. When asked about the most important thing in development, I always answer with one word: empathy.

Ken links this concept, along with the combination of good taste, the philosophy of Immanuel Kant, and a discussion of atoms by Richard Feynman, all while explaining the choice of a QWERTY keyboard layout.

These complex factors enable a personal connection between people. Imagine being the developer whose choices led to the ability to send a quick message saying “Just landed.” Informing a loved one of your safe arrival transcends the importance of any line of code.

That is work to be proud of and we’re lucky Ken has taken the time to share it with us all.

A Tribute to iBeer

Today’s a big day for app developers.

In the lead-up to today’s event, I spent some time digging through my old purchases. After launching the App Store app, tap on your profile in the upper-right corner, then tap on the Purchased menu of your account page. After spending a few hours scrolling down, you’ll see your first apps!

One of the apps was something called “Carling Tap” – and I had no recollection of anything by that name. A little bit of research helped me remember that the app was formerly named “iBeer”. This hiccup with the name not only paused my scrolling: it also got me thinking about the importance of this early app.

Many of the apps on that first day, including my work with Twitterrific, were adaptations of desktop apps. Things like AIM, NetNewsWire, and Solitaire had many advantages on mobile, but in retrospect, they weren’t a sign of what lay ahead.

Even though it was a gag, iBeer gave us a real glimpse of our future. It was the first app that was spatial. The function of the app was determined by where it was in your world. It could not exist without you.

Since then we’ve seen many other apps take advantage of this unique characteristic of mobile devices. Ocarina made it beautiful. Ride sharing leveraged it for efficiency. Pokémon GO made it fun and communal.

Now we’re heading towards a future where all apps will be spatial. One can only imagine how that will turn out, but it’s likely that the accessories will be fun.

System Fonts in CSS

About three years ago, I wrote a piece on how to get system fonts in CSS. The San Francisco fonts had just been released and getting them onto a web page wasn’t obvious or easy. A recent tweet reminded me that I needed to update this information.

In my original post, I proposed the idea of a generic system font:

The “system” generic family name doesn’t currently exist, but I’d encourage browser manufacturers to adopt this technique.

Apple agreed and made a proposal on the CSS mailing list. Over the next few months that proposal evolved from being called “system” to “system-ui”. (Once upon a time, Windows used a font called “System” that could have caused a conflict.)

At the end of the day the CSS Font Module was updated and there was an official way to render text just like the operating system.

As every web developer knows, getting a feature into the spec is one thing and getting it into the browser is quite another. Luckily the adoption of system-ui has been quick. Both Chrome and Safari support it fully on a wide variety of platforms. Only Mozilla and Windows are lagging behind.

In many cases, you’ll also have to take backward compatibility into account — not every visitor has the latest & greatest browser. This CSS should cover all the bases:

font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI",
    "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans",
    "Droid Sans", "Helvetica Neue", sans-serif;

(For more information on what those font names mean, see Marcin Wichary’s article in Smashing Magazine.)

If you’d like to see how this new generic font-family works, here’s a simple page that can be used to test any platform.

This whole process has been fascinating for me to watch. What started as a simple idea ended up being discussed and implemented by dozens of talented engineers. The result is a web that’s better and easier for a lot of folks.

How Not to Do Accessibility

I’m 57 years old and my eyesight is getting worse every year. As a result, I have a newfound appreciation for the accessibility features that Apple builds into its products: they’re a lifeline for people who have problems worse than mine.

With such a unique and concerted effort towards accessibility, it’s surprising to see Apple ship a major OS release with a glaring usability issue. Yet that’s what we have in watchOS 4 when Bold Text is enabled.

I originally started using Bold Text at the suggestion of a friend and purely for aesthetic reasons. But as I used this feature, I found it also helped me read the information on my watch. It became an essential part of my user experience.

If you’re one of the lucky people who’s not using Bold Text on watchOS 4, you’re used to seeing clear and crisp icons for complications:

On the other hand, if you’re using Bold Text to help with legibility, you’ll find that the complication icons are fuzzy and sometimes impossible to distinguish:

What’s particularly concerning about this issue is the imprecise rendering has been around since I first reported it in watchOS 2.2 over two years ago!

(The gray part of the image above is a template for what should be rendered, the blue part is the what’s drawn on screen.)

It’s annoying when your assets aren’t displayed correctly, but the fringing artifacts in Clicker don’t affect its accessibility.

But now this problem has worked its way onto the most important part of my Apple Watch and makes it hard for me to tell what’s on its face. It’s time to either fix this damn bug or rename the setting Bold Text and Complications That Look Like Ass.

A New Way to Work

Up until the middle of last year, my iPad spent most of its time next to my comfy chair. I’d bring it into the office whenever I needed to test an app on the device, but for the most part it stayed in our living room for reading and browsing.

What changed? I added this to the home screen on my iPad Pro:

Linea Icon

Gedeon Maheux and Troy Gaul worked on Linea for over a year. What started as an internal tool for our artists, became something that has fundamentally changed the way I do development work.

A simple start

I’ve been coding professionally for over 40 years and have always kept a notebook near my desk. It’s an essential tool that lets me capture thoughts and ideas in a way that lists on a computer cannot.

As I started beta testing Linea, my trusty paper got used less and less. My first work with the app was doing a rough outline for a chapter in my book on color management:

Book Outline

There’s nothing here that you couldn’t have done in the standard Notes app. It took me awhile to realize that Linea has a superpower you don’t get with the built-in app…

Discovering layers for ideas

To be honest, I didn’t use my Apple Pencil much until Linea came around. The Notes app didn’t do anything I couldn’t do on paper, and drawing apps were overkill for my needs.

This all changed when I discovered the power of simple layers for managing ideas. A few pictures are worth a thousand words, so let’s go through the process with a recent example: the testimonials section of Linea’s website.

In our line of work, we often get a design with no guidance on how to construct it. Here’s what the original design comp looked like:

testimonial-comp

It’s our job to figure out how to make these designs look and work right. And Linea is a powerful tool for that task.

Start by breaking it down

The first step is to break the design into pieces. I did a rough sketch of what I wanted on Linea’s bottom-most layer:

Testimonial Outline

So far, that’s pretty underwhelming. What’s the big deal?

Well, we’re about to encounter one of the three hardest things in computer science: cache invalidation and naming things.

Another layer for names

This is where Linea really starts to shine. Because it’s a hard problem, your first naming choices are rarely the best. If you’re like me, it usually takes a few tries to get the right ones. When you use a separate layer for your names, they’re super easy to change without wiping out the lines of the underlying outline:

Testimonial Naming

Because selecting colors in Linea is so easy, I like to highlight important names. While debugging the page, the two states of the img elements had a matching CSS outline.

It’s also when Linea starts to feel like a miniature whiteboard on your desk. The Touch Eraser is one of those things that is so natural that you use it without breaking your train of thought.

A notes layer above all

After getting the names you want, it’s time to start building! This is when I create another layer for things I want to keep track of. Again, you can add or remove notes without destroying the work on the other layers.

Testimonial Notes

My two favorite things in CSS are animations and Flexbox layout. And as much as I love them, you’ll see above that I can never remember the names of the timing functions or container properties.

(If you’re a web developer, take a look at the #testimonials source code on the Linea website: the images in the .picker Flexbox animate just by changing the CSS class on the <img> elements. Simple and elegant.)

Helping us stay organized

I also have a bad habit of keeping my drawings around forever — a lot of thought went onto the page and it’s hard to it throw away. Linea’s project management makes it easy to keep track of the old work and keep my desk clean.

It was a pleasure to learn that other developers are seeing the same benefits that I have. My friend Gus Mueller has this to say:

“Linea has been my go-to app for sketching out ideas and solving visual programming problems since the day I started using it. It’s now an indispensable tool for my work.”

My iPad Pro is still a great device for reading in a comfy chair, but now it makes a daily journey to my office. If you’re a professional developer, I bet Linea will become a fixture on your desk, too.

I invite you to take a look at the product website to learn more.