If it's not intuitive and good-looking, iPhone owners simply won't use it. Applications that are text-heavy tend to create too much cognitive load, while apps that use a combination of images and sparse text are much more manageable. Take a look at Flixter's movie listings, that cram all the relevant information you need about a movie right next to its cover image, creating a rich list that requires very few taps to access information about a given movie.

Novelty games might earn some quick cash, but durable apps tie together a suite of services. For instance, there's RunKeeper: A GPS-enabled exercise tracker app that's been downloaded 150,000 times since August. "iPhone apps are going to become commoditized. Successful apps will have deep integration with Web, social Web, and business outlets," says Jason Jacobs, Founder and CEO of FitnessKeeper, the company that makes RunKeeper. "We want to build a Web-based community tracking data, get brands involved, get races involved, and get plugged into a broader ecosystem."

Some companies build iPhone apps to simply check off a box in their marketing strategy, but successful apps present users with real power. Ebay and PhoneFlix are two perfect examples; eBay lets you buy and bid on real-time auctions and check on items you're selling. PhoneFlix gives you full access to your NetFlix account, letting you edit your queues, search for movies, and review films you've already seen. Contrast that kind of functionality with what's offered on Mint.com's iPhone app: It's a static snapshot of your accounts, without the graphs, interactivity and category-editing that makes Mint's full site great.

If you've programmed in C, then learning the iPhone software development kit, or SDK, should be easy. Ross Boucher, who daylights as a developer at a small Bay Area Web dev company called 280North, is an Apple alum who worked on the iTunes store. In his spare time, he developed iReddit, the official app for social news site Reddit just released this month.

The app is written in a language called objective C--essentially the only language used on the iPhone, and the same language used to code for the Mac. "You can code parts of the app in javascript, too, like iReddit's Web-page viewer function has been coded," Boucher says, "but about 90% of iReddit is in objective C." Other smart phone platforms use the Java programming language.

iPhone users use Apple's built-in apps--Mail, Safari, SMS and Phone--more than any others, so they've developed an intuitive understanding about how to find and manipulate functions on the screen using lists and graphic icons. Trying to work against an iPhone user's intuition is sure to breed frustration. Case in point: TwitterTrend, which logs the popularity of keywords in Twitter posts. The opening screen provides users with a blog-like keyword map, where larger words receive more mention like in a tag cloud. But that's disorienting to users who expect information displayed in lists and iPod-like menus. A better choice would have been a real-time bar graph for each popular term, with more data about each term becoming visible without tapping. A better example is the WebMD app: enter your gender and age, and voila--you get a map of the human body, where you can tap on the body part that's giving you problems.

Apple starts developers off with a surfeit of pre-made code. "When you see the taskbar at the bottom of an app, and the nav bar at the top–those are built-in system objects," Boucher says. "The list function that you see in iReddit is just a modified version of list in Mail; that's also standard." Even more complex tasks, like viewing a webpage inside an app, can be accomplished with Apple-built shortcuts. "iReddit makes use of an object called UI-webview, which allows you to view an external webpage inside the app, without having to open up Safari," Boucher explains.

Some apps get by beautifully without ever using 3G wireless or Wi-Fi. WeDict houses its entire database within the iPhone application, meaning you can use it even when you're not connected.

Apple provides an iPhone app simulator that any developer can use, once they sign up on Apple's site for free. To do real beta testing however, you'll have to pay a $99 fee. That registration will allow you to manually distribute your app to 100 iPhones to test by hand. All it takes to install a beta iPhone app is the device ID of a particular iPhone. The beta user gets a tailored version of the app--that is small enough to be emailed--and installs it by dragging-and-dropping it into iTunes.

Every app must pass muster at Apple. "The approval process is a bit of a black box," says Jacobs of FitnessKeeper. "There's some subjectivity in the process, so there's really no telling what will be approved." Time-frame is also unpredictable, with some apps taking just days to win approval and others taking months, and Apple doesn't let you make changes to your app once you've filed for review; if something changes, you'll need to fix it and re-apply. Once Apple gives the green light, however, a good app is off and running. "We went from concept to rev-generating in 35 countries in two months," says Jacobs.

Though approval is a crap-shoot, you may as well know the rules of the game. "There's no clear set of guidelines of what's acceptable and what isn't-- there's just a list of non-acceptable stuff," Boucher says. One point of contention for iPhone developers is the use of so-called "undocumented" APIs, or application programming interfaces. "There are a lot of APIs that aren't documented, but would work fine if you called them in your code," Boucher explains. "For example, there's no 'Maps View' API, so if you want your app to use a map, you have to write your own map system." Apple makes this restriction to prevent developers from toying with features that could change drastically in the future, or could expose parts of the phone they're not ready for people to use.

No matter how hard you work, your app may never meet Google-quality. That's because some developers get special treatment, says Boucher. "Take Google Mobile search, for example. It has this feature that lets you speak the search term. That feature uses the proximity sensor in the phone, that is an undocumented API. All regular developers can do is turn the proximity sensor on or off, but our software can't tell if it's been activated." he says. Most functions on the phone, however, are well documented and easy to incorporate: the accelerometer, multi-touch, and GPS all come with pre-built code.

Generating revenue comes easiest when you make several versions of the same app. "We started out as a paid app, and got 5200 downoads at $10 a pop. Then we released it for free and got 150,000 more," Jacobs says. "Now we have a free-ad supported app plus an ad-free premium version--so we have massive reach, but we also have a paid version that's more robust for users who are willing to pay for it."

One of the best things about the app store is the speed to market. But Boucher advises against rushing into development without truly studying the SDK. "It's important to familiarize yourself with all the available system objects, like the built-in nav bar. If you don't, you'll find yourself repeating work that's already in the SDK for free," he warns. You'll also miss out on crucial logic, he says: "You'll build something that users won't expect, and then learn that other apps use a different mechanism for doing the same task."

How to Build an iPhone App That Doesn't Suck

iPhone apps are only starting to reach the potential of the platform. So what does it take to build one that stands out?

If it's not intuitive and good-looking, iPhone owners simply won't use it. Applications that are text-heavy tend to create too much cognitive load, while apps that use a combination of images and sparse text are much more manageable. Take a look at Flixter's movie listings, that cram all the relevant information you need about a movie right next to its cover image, creating a rich list that requires very few taps to access information about a given movie.

Add New Comment

1 Comments