An Interview with Nick Lockwood

In this interview, I talk to leading iOS developer Nick Lockwood about his open source contributions, his development workflow, and the educational resources he’s found useful in mastering the SDK.

Nick Lockwood is a leading iOS developer and author of many popular open source projects, including iCarousel, iRate, and FXBlurView.

Nick recently authored the book iOS Core Animation: Advanced Techniques, published by Addison-Wesley, and we’ve provided an excerpt from Chapter 5 along with this post.

I first picked up a programming book when I was 12 years old. I don’t recall the name of the book exactly—something like “Basic Programming on the BBC Micro”—but it was a pivotal moment in my life.

I studied electronic engineering and then computer science at university. The former was interesting but not especially relevant to my later career; The latter taught me the fundamentals of data structures and algorithms, which has proven quite useful.

After graduation I created my company Charcoal Design, selling simple Mac games and utilities written in REALbasic. That didn’t really make any money so I did some freelance web development to make ends meet.

My first real job was as a front-end web developer, which initially didn’t seem to have much to do with programming at all, until JavaScript really came of age and front-end web development became a proper software engineering discipline instead of just being about who knew the most esoteric IE 6 CSS bugs.

I saw that the iPhone was going to have a profound impact on the mobile web when it was first released, but I didn’t really think much of it. In the UK, basically nobody bought the 1st gen iPhone – it was too expensive and we already had pretty good (and much smaller) feature phones.

That changed overnight when the iPhone 3G shipped. I got my first iPhone in July 2008. And bought Beginning iPhone 2 Development so I could learn to program it. I had dabbled with Objective-C on the Mac already, so I picked up the basics fairly quickly. I wrote Rainbow Blocks as an HTML5 app running in a full-screen UIWebView (I was still more comfortable with jQuery than UIKit at that point) and released it as open source.

I then caught a lucky break because the company I work for got the opportunity to build an iPhone app for one of our clients, and as the only one with any iPhone experience, they gave it to me to build. I’ve been a full-time iOS developer ever since. I’ve also since rewritten Rainbow Blocks as a closed-source native app.

Like many programmers, I have a character flaw that makes me always try to solve the general case instead of the specific requirement. This causes me to abandon almost every project I start because I get bogged down trying to solve a problem that is only tangentially related to the task at hand.

Like many programmers, I have a character flaw that makes me always try to solve the general case instead of the specific requirement.

My hard drive is littered with half finished (or barely started) projects that would have been the next big thing but will never see the light of day. But I found that open source is a bit of an antidote to this problem. If I pull out those useful bits of code, document them, and stick them on Github, then I can still salvage something valuable from my abandoned ideas.

Also, gradually, as I have built up a library of reusable components, I’ve found that building apps has become like assembling lego bricks. Instead of “That will be too complicated” I find I can answer most feature requests with “Aha! I have a library for that”.

As I have built up a library of reusable components, I’ve found that building apps has become like assembling lego bricks.

As for why I share them? It’s not particularly an act of philanthropy. I get a huge personal benefit from doing so, both in terms of actual feedback (bug reports, fixes and pull requests) but also recognition. My open source is a shop window for my services as a developer.

I feel a lot of pressure to maintain my projects, but I expected that – it’s part of why I released them in the first place. I’m not very good at self motivation and I work better when I’m under a bit of external pressure, so by releasing code to the community I know they will drive me to improve it.

The trickiest part is knowing when to say “no” to features and pull requests. It’s difficult when someone has spent several hours adding something to one of my libs to say “thanks but no thanks”, but I have to do it for the sake of avoiding feature creep that makes the library worse overall.

I submitted a few of them to sites like CocoaControls or Binpress and offered them as answers to Stack Overflow questions like “How can I make a control like coverflow” or “How can I prompt users to rate my app”. iCarousel won the Binpress mobile development contest in 2011, which probably helped its popularity a bit.

These days I mostly just post a “look what I made” message on Twitter and let it grow from there.

I’d never really done anything with Core Animation prior to iCarousel. It was kind of my “Hello World” project for the Core Animation framework. That was back in 2011 though – I’ve done quite a lot with it since!

The book wasn’t my idea; Pearson approached me and said they were doing a new digital-only mobile programming series and asked if I would be interested in writing about Core Animation. It seemed like it might be fun, so I said OK.

Because UIKit is so powerful, a lot of developers get a bit comfortable inside its confines and never venture beyond it. I think there’s a misconception that if you want to do anything fancy like 3D interfaces or masking effects then you have to drop down to doing everything with OpenGL.

I think there’s a misconception that if you want to do anything fancy like 3D interfaces or masking effects then you have to drop down to doing everything with OpenGL.

Many of the coverflow-like solutions that existed prior to iCarousel were written directly in OpenGL. It was quite a common thing that people wanted to do, but many developers simply have no idea that Core Animation even exists, or that it is a simple, high level API that can do these kind of effects easily without needing to work at the level of vertexes and shaders.

Many developers simply have no idea that Core Animation even exists, or that it is a simple, high level API that can do these kind of effects easily without needing to work at the level of vertexes and shaders.

The other thing I wanted to address with my book was performance. Performance is so easy to get wrong when you are dealing with a lot of images or vector drawing. I’ve seen many apps that judder and skip because developers just don’t understand how to use the power of threads and the GPU. A good understanding of how Core Animation works is crucial to getting good performance out of an app.

It’s aimed at intermediate readers, but it assumes no foreknowledge of Core Animation.

Yes, absolutely. In fact, one of the reasons I was so keen to do it was because of the learning opportunity. You never truly understand something until you have tried to explain it to somebody else. I found many new properties and features whilst researching the book, as well as clearing up many of my own misconceptions. I had to rewrite chapter 8 several times because when I wrote the examples I found that animations didn’t work the way I thought they did (despite the fact I’d being using them for years).

I’m actually pretty conservative when it comes to using productivity tools. I’ve tried a lot of things, but I rarely stick with them.

I provide Podspecs for most of my libraries, but I don’t actually use them. This is mainly because I hate static libraries – whenever possible I import the source files directly so that I can trace problems inside 3rd party components, and make fixes or improvements.

Whenever possible I import the source files directly so that I can trace problems inside 3rd party components, and make fixes or improvements.

Besides Xcode, I only use Tower (because Xcode’s git support is flaky and I don’t like using the command line), Photoshop (because I don’t trust designers to cut up assets), Resizer (for batch converting Retina images to standard def when I’m too lazy to redraw them), and SubEthaEdit (because Xcode has weird indenting rules for non-obj-C source files).

I actually rarely use 3rd party libraries. 90% of the libs I use are my own, and if I find I’m very dependent on a 3rd party lib, I’ll usually end up writing my own version.

I really admire Mattt Thomson’s work, but I just don’t get the obsession with using AFNetworking for every network file access task. Downloading a file asynchronously on a background queue takes one line of code. There’s certainly a lot more to interacting with web services, but mostly it’s highly specific to the service in question. I have yet to find any 3rd party network library that provides a substantial benefit over rolling a bespoke network stack, but maybe that’s just me.

I’ve been using Mantle lately, and I like the way it handles JSON property mapping, but I wrapped it in something similar to my own BaseModel library to reduce the boilerplate of specifying file paths for persistence, etc.

I can’t think of many 3rd party libraries that I’ve used on more than one project (SDWebImage, maybe), but I have a bunch of my own libs that I use in just about every app I write (StandardPaths, ViewUtils, BaseModel, AutoCoding).

That’s something I get asked a lot actually. I’d definitely recommend
Beginning iOS 6 Development (the latest edition of the book I learned from) and iOS 6: Pushing the Limits. It’s also worth watching as many of the official WWDC videos as possible. Matt Thomson’s NSHipster site is definitely worth reading. There are many other good resources out there too. Cocoa with Love, Cocoa is My Girlfriend, Cocoanetics, Ray Wanderlich, and Mike Ash’s blog are all worth checking out. All of that said, I tend to use Twitter more than any single source to stay on top of things.