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.

iOS 7 Background Updates

When Apple releases iOS 7 this fall there will be a few features that capture users attention immediately: the newly designed flat UI, AirDrop, Siri improvements, and an updated Camera + Photos interface. ¬†While all of these are welcome improvements, the features that I’m most excited about are the background update capabilities.

Background updates will allow applications to update their content when the app is not running. This means that when the user opens Mailbox his new email will be waiting for him, and he won’t have to wait for it to load. When he opens Twitter he won’t have to pull to refresh and he’ll automatically be taken to the most recent tweets. And when a friend shares a Youtube video with him it can automatically download in the background so it can begin playing immediately upon the user clicking the notification.

This may not sound like a major feature, but it has the potential to improve user experience across nearly every single application on the phone. Weather, stocks, sports scores, driving directions, media, and more can all be kept up to date and made accessible immediately whether online or offline. In a world where data and services live in the cloud, and people interact across multiple devices, background updates will allow the phone to always contain the freshest content personalized for the user.

From a product development perspective, I strongly urge developers to wow their users via creative uses of background push. Apple gives developers the option to check at certain intervals for updates if they expect updates frequently (though they’ve built intelligence to optimize for battery life, usage patterns, and connectivity), or the option to push updates to users only when they become available, in the case of less frequent updates or in response to events. From this point forward, if an app icon is badged, I’m going to expect to see some new content the second I click to launch. Away with the expectation of web latency and onto the era of responsiveness becoming the norm.