Voices that Matter iPhone: Aaron Hillegass and Joe Conway on the lifecycle of an iPhone app

Aaron Hillegass and Joe Conway of Big Nerd Ranch kicked off the Voices that Matter iPhone conference in Seattle this weekend with an overview keynote detailing the lifecycle of an iPhone app from a developer's point of view. The two are trainers and consultants for developers working on iPhone apps, and they laid out how an iPhone app is made, from start to finish, giving tips and suggestions to the developers in attendance on how they've developed their own process.

Read on to learn the steps they take at Big Nerd Ranch in making an iPhone app, and both how and how not to perform them.

Hillegass and Conway started off their talk by performing a few comedy sketches of clients that they had decided not to work with -- warning flags for developers who might be approached about working on an iPhone app. "Dreamer guy" was a potential client who walked up to them with little more than an idea, and no actual time or money to make it happen. "Ad guy" wanted an app made quickly and without any guidance, "web guy" wants an app of his website "but, you know, monetized on the App Store." And so on down the list -- "enterprise guy" makes developers sign agreements before realizing your app isn't secure enough for the company, "clone guy" and "future recipient of a C&D guy" are both interested in making less-than-original apps, and "desperately seeking cool" guy really wants to make an awesome app, but can't really give direction or ideas as to how to do that. Hillegass and Conway laid out all of the traps for developers to look out for even before they actually started putting together an app in code or design.

After those sketches (which the developers chortled at knowingly) and a quick break to "invoke iPhone blessings" like "May your app always get good reviews" and "May your app never get rejected" with their fellow developers, Hillegass and Conway began describing the actual process of making an app. It all begins with a definition: developers need to create a statement described as "[Differentiation] [solution] for [audience]" -- for example, a "Well-desiged eBook reader for students," or a "fun budget tracker for the homeowner." Hillegass also recommended that developers make a use case list, actually sit down and think of when and where and how the app would be used, and then consider that throughout the design process.

Next up is the mockup stage, which involves creating the look and feel of the app even outside of the iPhone. There are a number of tools available for this, said the presenters, from sketchpads to stencils to actual iPad applications. The goal here is not only to lay the app out, but to pare it down to the minimum necessary features. Hillegass pointed out that Apple was extremely good at this, even with hardware: they left the floppy drive out of the iMac, the FM radio out of the iPod, and the USB port out of the iPad. Even though people thought they needed those things, Apple decided that they didn't, and as a result, the products were more targeted and eventually more successful.

At Big Nerd Ranch, they then go from a UI mockup to a code mockup, charting the in-code models, values, and controllers in a program like Omnigraffle. They also chart out the data in the application, where it'll be stored and what it's called. That information gets shared with everyone working on the app in documentation, and it also helps later, they said, if the app ever gets ported to another platform, like Android or Blackberry.

This is also where BNR plans out the analytics for their apps -- developers can build in information gathering that will keep them updated on how users use their apps, how they perform, and if there are any bugs that need to be fixed. Some companies even use apps to collect survey information behind the scenes -- the guys described one movie studio app that they worked on that allowed users to choose a film's character in one section, and the company then used the information about which character was chosen to decide what to base their next movie on.

They also talked about estimating -- if a developer is designing an app for a client, it's important to keep the client updated on when it should be done. But Hillegass cautioned care here. He said that the more time you spend estimating, the better your estimate will be, but if you spend all your time estimating when you'll get done, you'll never actually get done. So it's better to guess longer when necessary -- the in-house rule at BNR is apparently "add one and increase the unit of time." So if a developer tells them it'll take him five days to implement a feature, they add one and increase days to weeks. "The client hears 'six weeks,'" joked Hillegrass.

The process of coding was described as a cycle -- implement a feature, put artwork in, get feedback from the client, fix the bugs, and move on to the next feature. Conway made the point that there was another cycle between the client and the developer -- responsiveness, he said, equals money, so if a developer needs feedback from a client or vice versa, the faster the response, the more quickly things get done.

The guys made an interesting point about children being the best beta users they've ever seen. They suggested that developers just hand their apps to children and see how they do with it -- "if they can use it, or even understand it, that's great," said Conway.

A slide came up on the screen about marketing, and both Conway and Hillegass admitted that they knew nothing about marketing apps. They did know that you should have a description and screenshots on the App Store, that you'd need a website, preferably with a screecast, and that testimonials helped. But as developers, they stay away from marketing, even though they understand how important it can be. "Marketing -- it's crucial," said Hillegass. "And now we'll move on." Localization got a quick mention as well. Hillegass actually said that procrastination is better if developers want to try localizing their apps worldwide -- the longer devs wait to change the language of their app, the less changing they'll actually have to do. Once all of that is laid out, developers can move on to deployment. This varies widely from app to app, but if there are web services necessary, Hillegass and Conway recommended services from Amazon and Google, and they also cautioned that Apple's actual app submission time was often unpredictable. Developers don't always know exactly when their app will be available on the App Store.

Finally, the guys spoke a little bit about all of the various reasons that apps got rejected from the App Store. Among the reasons for rejection was that "Duplicating Apple's APIs (current or future" -- Conway said that developers had sometimes gotten their app rejected from the App Store even without a reason, and then a few months later discovered that Apple was actually releasing their functionality as an official feature. Airplane mode was another common reason for rejection -- an app must work and function even without a network connection, so if a new app is opened up in Airplane mode and doesn't work, it will likely get rejected.

Hillegass and Conway ended their presentation with a quick plug for their site and services. The keynote was obviously targeted at developers, but it did provide a nice broad introduction to the way that an iPhone app comes to fruition.