Learning iPhone Development

Every time I’ve started to work on a new project I’ve been fortunate enough to have the opportunity to learn a whole new set of technical skills. At Frogmetrics it was Python, Pygame, Maemo Linux, and the world of early stage mobile performance constraints. In the early days of JumpPost and Hyperpublic it was web development – Ruby, Rails, Javascript, server administration. As Hyperpublic’s data platform grew and we moved on to join Groupon it was higher performance/scale data processing tools like Storm, the Java ecosystem, and a variety of databases and data processing techniques. And this time around, as we’ve been getting started on Wildcard, I’ve picked up iOS development, in order to tackle the problem of creating the fastest way to interact with the internet on your phone.

So far it’s been good times. Apple has created a great platform that makes it possible for developers to create beautiful, fast, polished applications that live up to the promise and expectations created by all of the great apps you interact with every day. However, getting up to speed, getting comfortable, and getting confident with iOS development has definitely been a different process and different challenge than getting up to speed on some of the other mobile, data, and web challenges that I’ve tackled in the past – in particular, the process has been more isolating than usual.

Why is learning iOS development more isolating than web, api, or data processing based development? Because it is just as much an art as it is a science, and as many artists will attest – the creativity must come from within.

When you’re trying to learn science you can surround yourself by the reference material of a previous generation of scientists – in this case books, stack overflow posts, IRC channels, github repositories. The actions that you’re trying to take when you build a web application are largely mechanical. You read in a request, interpret it, load data from a database, and plug it into your response. The interesting code you write is your business logic, and you let the framework handle the rest. You can always piece this together via all the available reference material, and if you’re confused as to whether you’re doing it “the right way”, you can always fall back to your basic knowledge of the internet and databases (HTML, CSS, SQL). Failing to understand all of Rails doesn’t mean that you’ll fail to produce a web application that does what you need it to.

But when you’re trying to learn an art form, equal parts design, user experience, and engineering – and the bar for an impressive user experience is set really high – there’s nothing to fall back on. Implementing the business logic is still a requirement that should be fairly straightforward, but creating beautiful UI, custom controls and actions, transitions, and animations are not something you can follow directly from a blog post or stack overflow thread. Programmatically creating and keeping the UI up to date based on a series of gestures, user actions, and external notifications within the rules and frameworks that Apple has made available is not something you got experience with doing anything else. There are a series of great meetups, events, and a bulk of material available online and in print to try and teach you the basics, but when it comes down to implementing the experience that you want for your users, the reference material won’t help. You and your team are on your own.

That’s why I believe that a more effective way to learn iOS development is the mentor-mentee relationship. The ideal pairing is a developer with good fundamentals and a confidence that they’ll be able to pick up the basics of any technology, working closely with someone who’s gone through the trials and tribulations of learning the nitty gritty details, design patterns, various techniques for impacting the “art form” of iPhone development. I think pair programming is always a good idea when reasonable, however in an early stage startup it’s not always possible due to limited resources and developers needing to split responsibilities across skill-sets. However in the case of iOS development, I believe that as much pair development as feasible in the early days is the most efficient way to learn.

Now that I’ve gone through the struggles of getting myself up to speed over the past few months, I’d love to bring on an aspiring entrepreneurial engineer to work closely with me to own mobile product development at Wildcard. If you believe in our vision, and you see yourself as someone who wants to learn mobile development, and one day start your own tech company, then I believe this is a great place to learn. Please get in touch.