Cocoa Controls: Who are you? What do you do?
Nick Lockwood: My name is Nick Lockwood, I live a double life:
By day I’m head of iOS development at a digital agency called AKQA in London.
By night I’m an open source library factory and aspiring indie App Store developer.
I also somehow find the time to sleep, raise a daughter and spend more time than I should do on Twitter.
CC: What’s on your iPhone’s home screen?
NL: Gosh, how embarrassing.
I’m an app addict, particularly games, so my phone is a mess of stuff jumbled in no particular order. I once tried to bring some semblance of sanity by grouping apps into folders by genre, which made things much worse. I now cannot find anything except by using the search function. My home screen is a cautionary example – don’t be like me.
In case you’re wondering, the 1,969 notifications are unread emails in my inbox. I haven’t quite figured out “inbox zero” yet. The 57 notifications in Social are unread LinkedIn requests from recruiters, because no, I’m not interested in the junior designer position that you think would be perfect for me after misreading the 10-year old copy of my CV you found online somewhere.
CC: How, why, and when did you become an iOS developer?
NL: I’ve been a Mac developer for about a decade, as the legacy of ancient apps on my horribly outdated personal website will prove.
I originally got into Mac programming via REALbasic, having graduated from AMOS Basic on the Amiga (and before that, BBC Basic on the BBC Model B).
REALbasic doesn’t have a huge amount of commercial demand in London so I got a job as a front-end web developer instead and became quite passionate about standards-based client-side JavaScript application development whilst continuing to develop Mac apps in REALBasic in my spare time (and not making any money from it).
I mostly ignored the original iPhone (a big-ass phone with no 3G or GPS – meh ;-)) but when the App Store revolution happened in 2008 I immediately realised that this was the future and started teaching myself Cocoa, with a bit of help from Beginning iPhone 2 Development by Dave Mark et al.
As AKQA started doing iPhone projects, I moved from building web sites to native apps and finally managed to unify my day job with my hobby.
CC: What’s one mistake you’ve made that you won’t make again?
NL: I initially tried to do the web-app thing and my first (and indeed only) indie app Rainbow Blocks was built as a full-screen JavaScript application running in a native web view, but after the first few releases I became increasing frustrated with the weird glitches and performance problems of having a long-running web-view application.
It was just about tolerable on iOS 3 when apps had a fairly short running time and any problem could be fixed by pressing the home button, but when multitasking was added in iOS 4 I was inundated with complaints from people who found that the app had frozen (usually due to a CSS3 transition race condition leaving them with a blank screen) and who had no idea how to fix it (pro tip: most users have no idea how to kill a frozen app on iOS – they usually end up deleting it and reinstalling from the App Store).
As I watched HTML5 consistently failing to keep pace with native apps in terms of quality of both apps and development tools, I realised that the open web revolution was either dead or in a coma and it was time to “go native” full time.
I migrated the iOS version of Rainbow Blocks to fully native code in 2011 and haven’t looked back.
CC: What’s the best decision you’ve ever made with your software development career?
NL: Going mobile and going native, but we already covered that.
I think the second best decision was to start releasing stuff for free on Github.
I’m not one of those “information wants to be free” hippies – I don’t have any qualms about charging for my work – but I also recognise that developers generally place a low value on source code because when they see it they tend to think “I could have written that myself, so why should I pay for it?”
I think the sweet spot with software is to charge for apps but release reusable libraries for free – it serves as a great shop window for your work, and the spirit of sharing code and avoiding the need to reinvent the wheel benefits us all. I’m not saying that there isn’t money in middleware, but it’s a hard job to make serious money selling components.
I find that publishing the libraries that I write forces me to test and document them properly, which saves me from those “wtf?” moments when I need to use them later and can’t remember how they worked. I also get the benefit of a thousand eyes on the code looking for bugs instead of just my own.
CC: What’s your favorite open source component? Why?
I like writing code more than I like reading documentation, so whilst I recognise that there are some amazing libraries out there, I actually use very few of them.
Probably the project I’m most impressed with is Chameleon by the Icon Factory guys. If you haven’t seen it, Chameleon is basically a complete reimplementation of UIKit for Mac OS – it’s a phenomenal achievement. When I update the Mac version of Rainbow Blocks to native code I will almost certainly use Chameleon so I don’t have to build everything from scratch using the nasty AppKit APIs. The only downside is that is doesn’t support nibs.
CC: Your component iCarousel is the most popular project listed on Cocoa Controls, and one of the most popular Objective-C repositories on GitHub. What was your original motivation for writing it? Have there been any unexpected benefits to you, personally or professionally, from writing it?
NL: I had a need on a particular project for a CoverFlow-like control that could display arbitrary views instead of just images. None of the solutions available at the time could do that. When I’d written it I realised that it could easily be extended to support additional layout styles, and feature-by-feature it grew into what it is now.
In terms of benefits, I can directly attribute several lucrative contracts that I’ve worked on to people having found me through iCarousel. I never expected that when I released it.
CC: Do you have any suggestions to other iOS developers on how to best build beautiful, fluid, reusable components?
NL:
1) Don’t set out to build reusable components. Just write good code that solves the real problems that you have on your own project.
As long as you follow best practices like KISS and separation of concerns, you’ll find that your classes are inherently reusable. If you reuse a class on more than one of your own projects successfully then it’s probably a good candidate to turn into an open source component.
I’ve often violated this rule myself and set out to make something reusable and invariably I’ve ended up with something that either doesn’t solve the problem I originally wrote it for, or which nobody else wants to use.
2) Resist complexity. Don’t ever add stuff you think you might need unless you need it right now. Learn to say “no” to feature requests. A component that solves 80% of the problem domain and is simple to use is much better than one that solves 100% but is too complicated.
3) The best components work right out of the box. Don’t force people to read the documentation before they begin. Good design is about making choices, and even if features are configurable you should choose sensible defaults that will work for most users.
Over time, iCarousel has grown into something fairly complex, but as long as you set up your data source you get a working CoverFlow implementation with zero config. Some of my other libraries (e.g. iRate, iVersion) require literally no configuration at all to do their thing, you don’t even have to reference them in your project.
CC: What else should we know about you?
Right now my preferred communication medium is Twitter. Bear this in mind if I’ve not responded to your bug report for 6 months and you want to know why (did I mention that I have 1,969 unread emails in my inbox?).
I like good coffee, but I’m not interested in talking about it.
I don’t like sports.
See all of Nick’s projects on Cocoa Controls
Have a suggestion for whom we should interview next? Let us know at [email protected].