In spite of plenty of advance warning from Twitter, we got caught by the Twitpocalypse bug.

For the 2.0.1 release, we had tested our software extensively. I actually wrote an emulation layer on top of the code that reads data from Twitter that added a large number to every ID read from Twitter. This testing uncovered several bugs which were fixed and incorporated into the MGTwitterEngine open source code.

Unfortunately, this testing didn’t take into account that the library we use to parse the data (YAJL) includes a range check that ensures signed values, which are allowed by the JSON specification, will fit into 32-bit storage. The “YAJL Error 3″ is that library telling us that the range check failed.

In hindsight, I should have fed the parser some large unsigned integers. In the wonderful world of software development, we call this a brain fart.

How did we respond?

Unfortunately, the Twitpocalypse occurred on Friday evening, just as my wife and I were heading out for a high school graduation. I quickly shot off an email to Twitter asking a few questions (I had mistakenly thought that there were problems with data being returned by an authenticated connection.)

After a couple of hours of iPhone email and SMS, it was clear that we were going to need do a new release. We had a critical bug that affected thousands of users. And our fear was this submission would take longer than normal: many developers are submitting 3.0 updates.

Life officially sucked at this point, and the graduation ceremony was memorable for all the wrong reasons.

After getting a few hours of fitful rest, I opened up Xcode on Saturday morning and started looking for the problem. It took just a few minutes to find the bug and another few minutes to fix it. Our concern at this point was getting the update to users.

Apple saves the day

In spite of it being the middle of weekend after a busy week at WWDC, we were able to get in touch with Apple Developer Relations. Our contact was able to expedite the approval of the application.

To say that this was a relief would be the understatement of the century. The update for the free version started showing up in iTunes on Sunday evening. The paid version was updated on Tuesday morning.

What can we learn from this?

Developers are human. We make mistakes. It’s interesting to note that Loren Brichter and Buzz Anderson, fellow developers whose skills I hold in high regard, were also affected by the Twitpocalypse. It really does happen to the best of us.

It’s also interesting to see that Loren and Buzz reacted in the same way I did: by fixing the problem ASAP. In Loren’s case, that meant finding a hotel with WiFi in order to distribute his update. Buzz released a new beta in a matter of hours.

In my experience, these brain farts are problems with easy fixes. It’s something like checking for invalid bounds, getting a Boolean state wrong, or something else of that nature. It’s not a complex problem: it’s an oversight.

The problem, therefore, is not how fast we can react to fixing critical bugs, but how fast the App Store reviewers can react with an approval.

As a device that’s constantly connected to the Internet, the iPhone taps into a stream of data that is unpredictable. Data in “the cloud” can change at any time, and web applications naturally adapt to these changes with a quick deployment strategies. Those of us who are building client applications on top of this network infrastructure need the ability to adapt quickly, too.

Security issues are another area where a quick response is a requirement, not a luxury. If I discover something that puts a user’s private data at risk, it’s my responsibility to fix the problem as quickly as possible. Time spent in a review queue is time spent being exposed to a flaw.

At the same time, we shouldn’t blame Apple for these delays in reviewing applications. In the year that they have been selling our products, the App Store has been more successful than anyone imagined. It’s clear to me that reviewers and others involved in the approval process are overwhelmed by this success.

How can we fix it?

Fortunately, I think there’s a simple way to solve this problem for all developers selling products on the App Store. The inspiration for this solution will be obvious to anyone who’s used Apple’s Developer Technical Support (DTS.)

When you purchase an ADC membership, you are given a number of “incidents”. These DTS incidents can be used when you have a problem that can’t be solved through documentation, support forums or hours and hours of debugging. It’s for the hard stuff, and usually involves getting an engineer at Apple involved to understand and fix the issue.

As a developer, I’m very careful to use these incidents wisely: they are a last resort. There are some years where I don’t use them at all, those are the good years.

A similar system could be put in place for critical bug fixes on the App Store. If every developer was given one or two “prioritized reviews,” it would act as insurance for the brain farts. You’d have a way to raise a flag and say “I need special attention for a critical bug.”

If another developer has a critical bug, I have no problem with my review process for a feature release taking a little longer. And since prioritized reviews would be a scarce resource, they won’t be open for abuse because developers will think twice before using them.

Because it’s not a matter of if you have a brain fart that leads to a critical bug, it’s a matter of when.

Before I get into the actual prediction, let me say that I’ve come to this conclusion by looking at Apple as a business, not as a supplier of shiny gadgets for our technolust. As much as we love the things they make, their goal as a corporation is to make the stockholder’s happy. They do that by selling lots of products. We’re just a means to that end.

A lot of the speculation regarding the netbook says that it provides functionality in the price gap between a $200 iPhone and a $1000 MacBook. While that’s true, it misses the point.

Apple would rather sell you another device in addition to the ones they already sell. They’re not interested in cutting into (presumably healthy) MacBook sales with a netbook. Likewise, selling a bigger touch device could cut into iPhone sales: keep your crappy cell phone and buy the netbook to throw in your purse or backpack.

One of the things that saved Apple was a simplified product line based around professional and consumer uses. Does it really make sense to have more than one consumer-level device for laptop computing? The MacBook already kicks ass in that department: having another device in that category just muddies the water.

But what if there was a device that could work in conjunction with your other Apple products? Something that extended their capabilities. Something that made each product better for a few hundred dollars.

Apple and their shareholders would love this: you’d buy the iPhone and the “netbook”. And eventually the MacBook. And maybe an Apple TV. And probably an iPod, too.

So what are some of the problems with the current hardware lineup?

• iPhone / iPod touch – Small screen, small keyboard.
• Mac – No touch screen, running Front Row prevents using your Mac for other things.
• Apple TV – crappy remote, no keyboard.
• iPod – Very small screen with no touch screen or keyboard.

So what kind of product could fill in these gaps? I call it “Front Row To Go.” Think of it as a second screen for the current hardware. Something that could:

• Display photos on a larger screen than on the iPhones and iPods. It would also be effective as an adjunct to iPhoto on the desktop: Microsoft’s Surface prototype shows how effective it is to display pictures on a horizontal surface that can be manipulated by multiple viewers.
• Provide a touch screen keyboard for the iPhone and Apple TV: a better input mechanism than hunting and pecking on chiclets. (Maybe this is the reason Bluetooth keyboards aren’t available for the iPhone.)
• Show movies on a larger screen: anyone who’s taken a transoceanic flight knows that looking at the iPhone/iPod screen for more than a couple hours can be quite tiresome. An added benefit is that the player’s battery wouldn’t be consumed by the display’s power needs.
• Provide touch input to desktop applications. Multi-touch is never going to happen on a vertically oriented display, so make a separate device that works horizontally. An obvious benefit to developers is that they don’t have to rewrite code: if it makes sense, multi-touch can be added to enhance current applications.

As with all other Apple products, Front Row To Go could obviously work as a standalone device. Sync your content onto the device and take it with you: no more dragging a laptop to a family reunion just because Aunt Bessie can’t see the tiny photos on the iPhone. Get your bookmarks and feeds from the Mac and surf the web using Front Row To Go’s version of Safari while you’re listening to music or watching TV.

As far as how these features would be implemented, that’s anyone’s guess. There might be an API for developers, or maybe it’s a closed system. The device might be able to play iPhone games or run multiple iPhone applications at once (much like the current Dashboard works in Mac OS X.) With a common base of OS X running throughout the product line, pretty much anything is possible.

And that gets to the real point of this essay: think about what Apple has learned from the halo effect surrounding the iPod (and now the iPhone.) If you have any doubt that this effect is alive and well, drop into an Apple Store on any weekend and take a look around: plenty of customers who are happy with one product and looking at others.

In my opinion, these consumers are the ones that Apple will target with a “netbook,” not the ones that are jonesing for a sexy little machine that fills a perceived gap in the product range. I hope I’m right, because I’d love to be one of those customers lining up to buy Front Row To Go.

I have been developing applications for the iPhone since it was released (using both the Jailbreak and official SDK.) My company is currently selling several applications in iTunes. I also have many years of experience with the underlying technologies on the device (Cocoa, the predecessor to Cocoa Touch.) I’d like to share some of my experiences and give you some pointers that will help get you started.

The first thing you need to know is that learning how to develop applications for a mobile device isn’t easy. But it’s worth the effort, ask any seasoned iPhone developer about seeing their work run on the device for the first time: it’s fricken’ amazing.

Get a Feel for the Device

Some of you may want to target the web with your application. If this is the case, you’ll want to start looking at a series of articles I wrote for A List Apart: Put Your Content in My Pocket (Part 1 and Part 2.)

Even if you’re going to be writing a native application, knowing how to develop web pages for Mobile Safari will be helpful. A product information website and other ancillary information about your app will work best when your new customers can view it on their device.

Working with the web is also a good way to start understanding how a mobile device is so much different than a desktop. Using HTML and CSS can be an excellent way to begin thinking about your application design and doing prototypes—we’ve used this technique in many of our own products.

After getting a feel for the web capabilities of the iPhone and iPod touch, you’ll want to look around the Apple Developer Connection (ADC) site for more in-depth technical documentation for developing web applications.

Which leads to our next topic…

Buy a Mac

There’s no two ways about it. If you’re going to develop iPhone applications, you’re going to do it on a Mac. The whole toolchain is Mac-only: you can’t do it in Visual Studio or Eclipse or anything else that runs on Windows.

Don’t think that this is some evil plan by Apple to make you use a Mac. It’s no more nefarious than Microsoft requiring Mac developers to purchase Visual Studio in order to develop Windows versions of our products.

Buying a Mac can be an expensive proposition: if you’re just getting started and on a shoestring budget, here’s some advice on doing it on the cheap:

1. Buy a used machine. A lot of perfectly good hardware can be found on Ebay. New models of the Mac Book Pro were recently introduced, so many people are selling hardware after they upgrade. This older hardware is perfectly fine for doing iPhone development: the apps you’re going to develop are small and compact and don’t need a lot of processor power to build and test.
2. Buy a Mac mini. Even though you’re buying new hardware, you’ll save money because you’re supplying your own display, keyboard and other peripherals. If you’re like me, you have plenty of this stuff lying around.

If you’re having a hard time justifying the hardware expenditure, remember that you can run Windows or any other x86 based OS on this machine.

The only thing to keep in mind as you’re buying hardware: make sure that the Mac has an Intel processor. The development tools won’t run on the older PowerPC processors.

The good news is that once you buy the Mac, all the development tools are free. Think about all the money you spent buying Visual Studio and MSDN and you’ll feel much better about spending a thousand bucks for the hardware :-)

So how do you get all these free development tools? Read on…

Join Up and Download

There are two things you’ll need to do before you can start writing applications: sign up for ADC and register to become an iPhone developer.

Neither of these things costs money. Everything is free until you want to put your code onto the device. At that point, you’ll need to pay $99 to get a certificate that allows you to sign the binary and put it on the device.

The first step is to create an Apple ID; it’s an email address that you’ll use to access the developer site. You may already have one for your iTunes account. These pages guide you through the sign-up process.

Once you have an application that you want to test on a device and distribute on the App Store, you need to apply to the iPhone Developer Program.

After you have the keys to the ADC kingdom, there is a wealth of additional information available…

Sit Back and Watch Some Movies

Before you start diving into coding, I highly recommend spending a few hours watching the “Getting Started Videos” in the iPhone Dev Center.

(Note: if the links on that page are grayed out, it’s because you’re not logged in yet. Sign in using the Apple ID that you obtained above.)

As I said earlier, I came into iPhone development with a fairly extensive background in the technologies used on the device: even so, I learned a lot from these videos. Make sure you take advantage of this valuable resource.

And make sure you do it before rushing off and hacking on code…

Start Playing

If you’re like me, you’ll want to start playing around with code as soon as possible. The best way to do this is with the excellent sample code that Apple provides on its developer site.

(Note: Again, that link is behind a login, so you’ll need an Apple ID before you can download the samples.)

Since you’re new to iPhone development, it’s likely that you’ll have some problems going beyond a simple build and run of the projects you download. (If you’re having problems running the sample projects, make sure that you have “Simulator” selected in the drop-down menu at the top of the project window.)

When you start to get confused by Xcode or the syntax of Objective-C, you’ll want to move onto the next step…

(Note: I said “when”, not “if”. Trust me on this.)

Crack a Book or Two or Three

You’re lucky that there are a lot of great books about iPhone development available now. It’s a luxury that those of us who worked on iPhone apps during the NDA are very jealous of :-)

If you’re just starting out, I’d highly recommend Beginning iPhone Development: Exploring the iPhone SDK by Dave Mark and Jeff LaMarche. The best thing about this book is the step-by-step approach it takes to working with Xcode, Objective-C and the iPhone APIs. They’ll lead you through the basics and you’ll be building your own apps in no time at all.

As you get more comfortable with the tools and AppKit/UIKit frameworks, I’d recommend you take a look at Erica Sadun’s iPhone Developer’s Cookbook: Building Applications with the iPhone SDK. This book presumes a bit more knowledge about the SDK, but is a very handy reference both to the official and unofficial APIs. (Go ahead and play with the undocumented features, but do not use them in an application that you want to put on the App Store.) You may want to read my in-depth review of this book.

Since you’re going to be working with Cocoa Touch on the iPhone, you’ll also want to start thinking like a Cocoa programmer. Every great iPhone and Mac developer has nothing but wonderful things to say about Cocoa Programming for Mac OS X by Aaron Hillegass. Don’t be misled by the “for Mac OS X”—you’re going to be working with classes and design patterns that are identical on both platforms. You’ll also have a Mac that you’re using for development, so building the samples and test code isn’t a problem.

If you have previous development experience with C, C++ or Java, you’ll want to read this mailing list post by Erik Buck that enumerates some of the difficulties that you’ll have coming up to speed with Objective-C and Cocoa. Make sure to take some time and read the replies to that post: many of the people commenting on that post are fellow developers whose work I hold in high regard.

And while we’re talking about Erik’s writing: there are a lot of experienced Cocoa developers waiting for this book. You won’t need it for awhile, but you will need it.

As you’ve probably figured out by now, this whole learning process is going to take awhile. I’d also be remiss if I didn’t mention that there is a pretty steep learning curve. I’ve built products in assembly code, BASIC, C/C++ on Unix, X11, Win32, Java and a whole bunch of other technologies. Objective-C and Cocoa weren’t the easiest to pick up, but they’re definitely the ones that I plan on sticking with. Try not to get discouraged: once you “get it” developing with this language and framework is a joyous experience.

Other Resources

I’ve been coding long enough to remember a time when we didn’t have the Internet as a source of information. Thank God those days are behind us: here are some online resources that I use often:

• cocoabuilder.com There are two mailing lists where other Cocoa developers and Apple engineers hang out: Cocoa-dev and MacOSX-dev. The archives for both of these lists can be searched using CocoaBuilder: extremely handy when you come up against a problem that someone else has already solved.
• cocoadev.com A wiki that is maintained by the Cocoa developer community. This is the first place I look when I need to learn some new part of the framework. As an example, check out this entry about the string class.
• cocoadevcentral.com A beautiful site maintained by Scott Stevenson. So many great tutorials and links to other sites and blogs that focus on Cocoa development. Spend some time exploring those links and you’ll learn a lot about our developer community.

Apple recently launched another great resource: Developer Forums. It’s currently in beta, but is still an excellent place to ask fellow developers questions about iPhone SDK topics.

But wait, there’s more!

You’ll find a lot of iPhone content on this site. Here’s proof.

To save you some time, here are some quick links to some of the more popular essays on this site:

Memory management issues (part 1.)

Memory management issues (part 2.)

How to run a beta test.

Extracting information from crash reports.

Final release testing.

What to expect on release day.

Debugging with customer backups.

How to deal with expired certificates.

And, of course, source code for you to use in your own projects:

[REDACTED]

Fancy UILabels

Or just have fun with:

Lights Off

And if you aren’t already completely bored with me crapping on about the iPhone, there are videos.

Conclusion

I hope this information has been helpful and gotten you started in the wonderful world of iPhone development. Don’t forget to subscribe to this site’s RSS feed since I have a lot more I’d like to write about :-)

Good luck!

Lately, I’ve been thinking about ways to make higher prices more palatable to customers. Several discussions at Macworld kicked off these thoughts, and a recent tweet by Justin Williams made me realize that a lot of you could benefit from these ideas. Hopefully, this short essay will help us all make it through the App Store gold rush.

The first thing to do is think about a “Lite” or ad-supported version of your application. Let customers find out how great your work is by giving them a free copy.

Based on our dealings with Apple Developer Relations, there are two basic rules you need to follow when making a Lite version of your product:

1. The product must be fully functional. The application must stand on its own and be useful.
2. The user should not be inundated with “up-sell” reminders. Showing BUY NOW every 5 minutes is the quickest way I know to get rejected by the App Store.

The hard part, of course, is how to limit functionality. For many games, it’s pretty easy: you just limit the number of levels the user gets to play for free. A similar technique can be used for applications that track data by limiting the number of records that can be added.

But there are many applications that don’t fall into these neat categories. One such application is our own Frenzic. Due to the game’s open-ended nature, there’s not much we can do to set “levels.” Until there is some kind of demo mechanism on the App Store, we’re stuck with advertising, good reviews and word-of-mouth.

Free applications that are supported by ads are also a viable alternative. We’ve seen a steady stream of sales with Twitterrific because customers that use the free version know exactly what they are going to get for their $10. The main consideration with this approach is thoughtful integration of the ads into the user’s activities. Annoying a user with ads is a good way to get deleted from the home screen.

Using this model, some people will never buy your application. And that’s OK, and maybe even better, because you’ll make your money back over the long term. I was not surprised when Shazam started showing ads. They spent a lot of time and money developing their application and back-end infrastructure. When millions of people are using your product and seeing ads every day, that revenue can be substantial and easily pay for development costs.

Another thing I’ve noticed is that iPhone applications that have a tie-in to a Mac desktop product can command a higher price. If you have group of users who already love what you do on the desktop, selling those users mobile functionality is easy. Take a look at Things and OmniFocus as examples: the desktop versions of these apps sell for $50 and $80, respectively.

The iPhone version of these products sell for $10 and $20. From a customer’s point-of-view, that’s not 10 times more expensive than the typical ringtone app. Instead, it’s a small price to pay for mobile access to their desktop data. Conceptually, the 20-25% fee is just another upgrade cost.

Finally, you should take a look at vertical markets. I love the prices for Medical applications in the App Store. There are a lot of apps with price tags over $10 (some are even over $100.) Again, the customer for these apps is not thinking so much about cost, but rather of the value provided.

When businesses start to see the capabilities that an iPhone applications gives a distributed workforce, vertical markets could become quite lucrative. You may only have hundreds or thousands of customers, but if you’re earning hundreds of dollars from each of them, that’s a viable business.

In closing, I’ll pass on a small reminder that an Apple employee gave me during Macworld: the App Store has only been live for a little over six months. Last month’s 25 year anniversary of the Mac should also remind us that this new market for our products is still in its infancy. Yes, it’s a wild ride at the moment, but if you think about your costs, customers and revenue streams, I think you’ll enjoy a very long journey.

As an iPhone developer who’s been in the App Store since its launch, I’m starting to see a trend that concerns me: developers are lowering prices to the lowest possible level in order to get favorable placement in iTunes. This proliferation of 99¢ “ringtone apps” is affecting our product development.

Unlike a lot of other developers, I’m not going to give you suggestions on what to do about this: you and your team are perfectly capable of dealing with it on your own terms. Rather, I’d like to give you some insight into how these ringtone apps are affecting my business.

Both of our products, Frenzic and Twitterrific, have been quite successful in the App Store. Frenzic is currently in What’s Hot and Twitterrific appears in both the Top Free and Top Paid Apps for 2008. We also won an ADA at this year’s WWDC. It hasn’t been easy, but we’ve learned what it takes to make a kick ass product for the iPhone.

The problem now is funding those products.

We have a lot of great ideas for iPhone applications. Unfortunately, we’re not working on the cooler (and more complex) ideas. Instead, we’re working on 99¢ titles that have a limited lifespan and broad appeal. Market conditions make ringtone apps most appealing.

Before commencing any new iPhone development, we look at the numbers and evaluate the risk of recouping our investment on a new project. Both developers and designers cost somewhere between $150-200 per hour. For a three man month project, let’s say that’s about $80K in development costs. To break even, we have to sell over 115K units. Not impossible with a good concept and few of weeks of prominent placement in iTunes.

But what happens when we start talking about bigger projects: something that takes 6 or even 9 man months? That’s either $150K or $225K in development costs with a break even at 215K or 322K units. Unless you have a white hot title, selling 10-15K units a day for a few weeks isn’t going to happen. There’s too much risk.

Raising your price to help cover these costs makes it hard to get to the top of the charts. (You’re competing against a lot of other titles in the lower price tier.) You also have to come to terms with the fact that you’re only going to be featured for a short time, so you have to make the bulk of your revenue during this period.

This is why we’re going for simple and cheap instead of complex and expensive. Not our preferred choice, but the one that’s fiscally responsible.

I’m also concerned that this “making it up in volume” approach won’t last too much longer. With 10,000 apps in the App Store, it’s already a fricken’ cat fight to get into one of the top 100 spots. What’s it going to be like when there are 20,000 apps? Or 100,000 apps? Volume is going to get split amongst a lot of players, hopefully the number of devices/customers will increase at the same rate.

We’re not afraid of competition. In fact, we welcome it as a way to improve our products and business. The thing we’re hoping for is a way to rise above the competition when we do our job well, not just when we have the lowest price.

I’ve been thinking about what’s causing this rush to the 99¢ price point. From what I can tell, it’s because people are buying our products sight unseen. I see customers complaining about how “expensive” a $4.99 app is and that it should cost less. (Do they do the same thing when they walk into Starbucks?) The only justification I can find for these attitudes is that you only have a screenshot to evaluate the quality of a product. A buck is easy to waste on an app that looks great in iTunes but works poorly once you install it.

Our products are a joy to use: as you well know, customers are willing to pay a premium for a quality products. This quality comes at a cost—which we’re willing to incur. The issue is then getting people to see that our $2.99 product really is worth three times the price of a 99¢ piece of crapware.

I also worry that this low price point for applications is going to limit innovation on the platform. Sure, apps like Ocarina and Koi Pond are very cool and very cheap. But when are we going to see the utility of the platform taken to another level, like when spreadsheets appeared on the Apple ][ and desktop publishing appeared on the Mac? (It could be argued that Safari has already accomplished this, but I still think there is a third party idea that will be just as transformative.)

It would be great if the killer app for the iPhone cost 99¢, but given the numbers above I can’t see it being very likely.

Thanks for your time and attention. I hope this information has been helpful.

Best regards,

Craig Hockenberry

Updated December 12th, 2008: David Barnard shares some numbers and experiences from selling his App Cubby products. Of particular interest are the difficulties in measuring the effectiveness of our marketing efforts. With no feedback other than raw sales, it’s hard to know if your advertising dollars are well spent.

Updated December 23rd, 2008: It looks like this is going to be the first thing new iPhone and iPod touch owners are going to see on Christmas morning. You and your team have worked so hard to make a device with such great potential: why is this happening?

Personally, I welcome this competition. Seeing the work of other developers whose work I respect and admire acts as an inspiration. Looking at how other developers tackle a problem domain often adds insight into solving similar issues with my own code. In other cases, it shows me how I don’t want to implement a feature (without the need to prototype.) In short, competition will make Twitterrific better.

(I’m particularly disappointed that Ed Voas has decided to go back to work at Apple. I’ve been an admirer of his work since the days of Aaron and the Appearance Manager. From what I’ve seen with Tweetsville and his blog entries about its development, it’s clear that his decision is a loss for everyone working on the iPhone platform.)

Of course, this competition is also good for users. The most obvious benefit is that applications will evolve and improve more quickly as developers learn from each other and try to outdo the other guy.

But there is a more subtle benefit. There will always be more than one way to solve a problem: a developer’s personal preferences will inevitably seep into the implementation. Having many choices for a Twitter client means that developers don’t need to create a “one size fits all” solution. In essence, users get to choose a developer whose preferences match their own.

(And please do all developers a favor: tweets like “twitterific sux, twhatever rocks” do absolutely nothing besides make our skin even thicker than it already is.)

Making Choices

One of the most fascinating things about these native Twitter applications is the variety of user interfaces. In spite of all these apps using exactly the same API at Twitter, there are many different user experiences. It’s all about developers making choices.

I’ve wanted to write about what led to the user experience in Twitterrific for quite awhile. It’s been only recently that where we’ve been and where we’re going have gelled to a point where I can express these thoughts in an essay. So while tryptophan was coursing through my veins, I started to look back on our past choices and think about where I see things going in the future.

John Gruber’s recent essay on iPhone-Likeness is a definitive manifesto for iPhone development. If you haven’t read it, go do it now. If you have read it, go read it again. And again: you can’t call yourself an iPhone developer until you’re read that fireball at least three times.

If you’re still to fricken’ lazy to read that link, here’s what I like to call Gruber’s First Law of iPhone Development:

Figure out the absolute least you need to do to implement the idea, do just that, and then polish the hell out of the experience.

In a word, strive for one thing in your iPhone application: simplicity. Both in terms of functionality and beauty.

From the very first day, we tried to do this. And it turns out that “doing as little as possible” was one of our greatest challenges. (I’m using the plural pronoun here because the interface design was a team effort.)

To achieve this goal, you have to find the “nut” of your application. The thing that defines what you’re working on. Even more targeted than John Geleynse’s “application definition statement.” Something that you think of each time you start up Xcode, or every time you answer a customer email, or when you’re planning features for a new release.

(As an aside, if you haven’t seen John’s talk at WWDC 2008 yet, do yourself a favor and download “Session 351 – iPhone Application User Interface Design.” I guarantee you’ll get something out of it, even if you’re an experienced iPhone developer.)

For Twitterrific, our core function is reading.

The core function is not managing your Twitter account. Nor is it being a general purpose tool to exercise every nook and cranny of the API. It’s primary function is not to acting as a surrogate for SMS messaging.

Twitterrific is all about reading what other people are doing, thinking, or experiencing. Even its secondary function, posting tweets, is related to reading. The posting interface functions as a way for you to give your followers something interesting to read.

Good Choices

Reading as a core function manifests itself in several aspects of the application:

• The list of tweets is designed to be as compact as possilble. The stream of information is much easier to read when there is more of it visible. This meant keeping navigational elements to a minimum.
• The detailed view, with larger text and less surrounding information, was designed to be read while in motion. Small fonts and compact presentation is problematic when your trying to read on a train or other moving vehicle. Navigational elements in this context are also larger and therefore easier to hit.
• Simple navigation: it’s very easy for these elements to get in the way of reading. From the beginning, Twitterrific was designed to work with one hand using the thumb as the primary input. Pulling the device out of your pocket and checking your tweets should be quick and not require two hands.
• Tweets often contain links to other items you want to read. The mini-browser allows these links to be opened and read as quickly as possible.
• Making it easy to read things later. Links in tweets sometimes point to things that you’ll want to read or watch outside of the confines of a mobile device. To this end, we used Favorites as a way to pass information between the mobile and desktop platforms.
• The main problem we found with pure web interfaces to Twitter was the inability to persist data. The cellular data network isn’t always available and reading tweets should not be impacted by network outages.
• We go to great lengths to maintain a reading position between launches of the application. Since we’ve found that reading Twitter on a mobile device is done in “fits and starts”, keeping the reader’s location in a consistent state is very important. It’s not an easy feature to get right which could explain why Twitterrific is currently the only app that tries to do this (and our own implementation could even use improvement.)

Imperfect Choices

Of course, we didn’t get everything right. At one point, my partner Talos Tsui suggested that we add the ability to follow and unfollow users from the iPhone UI. I argued that this felt too much like “account management” so we decided to not implement the feature. In retrospect, Talos was right: following is how you control what you read and needs to be a part of the application. We’re going to fix this in an upcoming release.

Other design choices were based on the current state of Twitter. At the time Twitterrific was being developed, Twitter was having some major scaling issues. Availability was sporadic and users were only allowed to access the Twitter API a total of 30 times per hour (regardless of which application they were using.)

This limitation played a factor in many of our design choices. Our concern was that users on the desktop would consume all the available API calls and then not be able to view tweets on their iPhone. We could have implemented a more readable view of the user’s archive (after you click on the @screen_name.) Instead, we display a web page—and don’t use any API requests. The latest round of native applications benefit from Twitter’s success in dealing with load. They don’t have to be so stingy with the API and they’re better off for it.

One of the best features of Tweetie is the ability to follow “in reply to” links. At the time we were developing our client, these links were notoriously inaccurate. I had made a suggestion to the Twitter developers on how to improve this, but it hadn’t been implemented yet so we decided to defer the feature. Now that the API supports setting reply IDs, Twitterrific (both iPhone and desktop) and other clients are making the links more reliable and threading features are much more attractive.

Future Choices

And that leads into what I see happening in future versions of Twitterrific for the iPhone. If you’ve been paying attention to this essay, you won’t be surprised to learn that these features will benefit the reader.

As I just mentioned, threading features that allow a reader to catch up on conversations are now possible. Tweetie has the right idea here, but we think the user interaction model is wrong. I’m all for competition, but I’m not going to tell how we plan to make it better. Loren Brichter and others will have to wait :-)

Search and trends are also recent additions to the Twitter API that weren’t available at the time we did our initial development. (Summize was available as a third-party API, but hadn’t been purchased by Twitter yet.) We often use these features to see what people are saying about our products: Frenzic, xScope, IconBuilder, Twitterrific. It makes sense to use search as another way to provide entertaining and informative content for us to read.

Another area where we see room for improvement is filtering tweets. There is literally a flood of information coming from the people we follow, so making it easy to extract things like replies, direct messages and favorites from the main timeline will be helpful for the reader.

Finally, we see a need to keep the “reading point” synchronized between the desktop and the mobile device. We currently find it cumbersome to switch between clients because they have no way to let each other know where the reader is in the timeline. We’ve requested that the developers at Twitter provide a way to exchange metadata between clients. iPhone applications usually work best when they are an adjunct to the desktop application. Treating the device as a satellite and providing it with metadata will improve the user experience for all Twitter clients.

Finally, I’d like to point out some things that we don’t plan on implementing.

I’ve been very impressed with Tweetsville’s implementation for direct messages. It’s a very creative solution to the problem, but I think it falls outside our core functionality: it turns Twitter into a conversation, not reading.

It could be argued that conversations are a type of reading. Unfortunately both users must follow each other for the exchange to be meaningful. And mobile use of Twitter tends to be asynchronous (unlike the desktop, it’s not “always on”.) These things, combined with the limitations of text entry on the iPhone, indicate that other media are better suited for two people having a chat.

Another thing we’re consciously avoiding: adding features just because “the other guy is doing it.” We think long and hard before adding anything to Twitterrific. Then we prototype a user interface and adjust it accordingly. Then we make the feature the best it can be.

And if you wonder why we go to all this trouble, just remember Gruber’s First Law of iPhone Development. It takes more time, but we’re in this for the long haul. There will certainly be a period of attrition for Twitter applications, much like there was for the web applications, and having the best user experience is the only way we’ll thrive.

Addendum December 4th, 2008

Fraser Speirs has some very interesting thoughts on contexts for mobile computing.

Our application clearly falls into the “Type 1″ and “Type 2″ categories: and that’s a conscious choice we’ve made. You should make the same choice. It’s OK to go for a different context than we did, remember what I said earlier about applications taking on the personality of their developer?

Fraser also wonders why there aren’t a lot of “Type 3″ applications in the store right now. I think there are a couple of reasons for this:

• Everyone is still working on their first version. Catering to power users who need more extensive capabilities comes as applications mature. iPhone applications haven’t had enough time to evolve.
• The rush to a $0.99 price point doesn’t provide enough of a budget to fund additional feature development. Without a healthy revenue flow to pay back costs that have been incurred, it’s hard to justify new features (and additional costs.)

In my opinion, both of these reasons will dissolve over time. In the meantime, consider if/how your application fits into “Type 3″. Plan ahead.

Last week, Addison-Wesley contacted me saying that they wanted to mail a free copy of Erica Sadun’s new book, The iPhone Developer’s Cookbook. I guess that’s one of the benefits of having a web log that a lot of other iPhone developers read: I took them up on the offer since there were no strings attached.

To be honest, I wasn’t expecting to get much out of this book. After spending many months digging around in the bowels of the SDK, I thought I had seen it all. I’m happy to report that I was wrong.

If you’re an experienced iPhone developer, you won’t learn much from the beginning of the book: you already know about the application package, setting up Xcode, platform limitations, how UIKit uses MVC, and so on. If you’re new to the platform, this information will certainly be helpful and I found that it was presented clearly and concisely.

So what did I like about this book?

First off, there are the recipes. These short snippets of code show you how to do a lot of common tasks. Need to build some draggable views? Just look up the recipe “Dragging Views” and you have a few pages of pertinent information (including a brief introduction to UITouch.)

I much prefer this format over long, involved examples that are complete implementations. The recipes in this book act as a quick way to get up to speed and they help you find more detailed information in the Developer Documentation in Xcode. The recipe format gets you pointed in the right direction.

In going through these recipes I ended up learning some new things. For example, I didn’t realize that you can set the number of rows in a UIAlertView. Again, the short and sweet recipe format makes it easy to pick these things out.

There are also some clever recipes: I particularly enjoyed the one that added a UIProgressView as a subview to an empty UIActionSheet. A nice trick to leverage the existing UIKit classes in new and different ways.

But the real value of this book comes from Erica’s experience in working with the Jailbreak APIs. She goes where the Xcode documentation does not and lets us peek behind the curtains. (This book, in effect, summarizes a lot of the poking around she did during the early days of the iPhone.)

Personally, I will never use undocumented iPhone SDK calls. It’s just too dangerous: you risk not getting accepted into the App Store because you’ve broken the terms of the license agreement (section 3.3.1.) And even if you do sneak it through, what are you going to do if the unpublished API changes and breaks your app? You’ll have a hell of a lot of unhappy customers for the couple of weeks it takes to get a new version submitted and approved.

So why is Erica’s exploration into the undocumented side of the API so helpful? Because it shows us what Apple is using in their own applications. And if we need similar functionality, we can file enhancement requests using this inside knowledge.

As an example, there’s the page curl animation that is used in the Maps application. You won’t find it in the API documentation, but it’s there if you use @”mapCurl” or @”mapUnCurl” as the animation type. If you want to do that in your own app, write a Radar and let the developers at Apple know. Make sure to give them context for the enhancement request: tell them why exposing the API would make your app better.

Personally, I have written Radars for the inclusion of the UICalloutView class and UIToolbar customization functionality.

In summary, I highly recommended Erica’s book. If you’re a beginner, you’ll find code that helps get you started. For those of us who have more experience, you’ll find it to be a valuable reference for both public and private APIs.

If you’re planning to buy a copy, please make me rich with affiliate kickbacks at Amazon. Thanks!

Why? Because I see some serious problems with how our bodies will interact with this device and its software.

Note: These are first impressions. I obviously haven’t had a chance to use the product, so the implementation by Apple/Nike is just a guess at this point in time. I’ve heard that there are some special controls in this software that allow “eyes off” control: if that’s the case, then we’ll all learn something from that UI.

The first problem is the size. When I’m running, I want the smallest piece of equipment possible. The simple reason is that any mass acts as a pendulum as you move. Sure the new iPod touch is lighter than its predecessor, but it’s still bigger and heavier than its nano sibling. Bigger is certainly not better.

There’s also a problem with where this device will attach to your body. Because of the size and weight, it’s likely that you’ll need to use it on an armband or in your pocket. Both of these locations present problems with interaction. You can’t see buttons on a touch screen when they’re in your pocket. It’s also uncomfortable to operate an interface that is strapped to your arm: try to unlock, launch and use an application while it’s positioned on your upper arm. Now do it while you’re running.

Good luck finding the PowerSong button without looking, too. Unlike the Nike + iPod application on the nano, this and other operations can’t be done solely by feel. Being able to operate the device while running is essential: you literally don’t want to take your eyes off the road. This “eyes off” approach to interaction is why the new iPod touch has physical volume buttons and why it was the most popular request by customers.

Some may argue that this device will be fine in a more controlled setting such as a gym. But if you’re running on a treadmill, there is already plenty of feedback from the machine’s built-in sensors and monitors. You don’t need a sensor in your shoe.

But in either case, you’ll find the biggest interaction problem is that sweaty fingers don’t work well on a capacitance-based touch screen. The salts in your body fluids make it much harder for the device to recognize your input. If you don’t believe me, try dissolving a teaspoon of salt in a cup of water. Then dip your finger in the salty water and try using the screen. You’ll find touch controls are jerky and non-responsive. Now add some body movement and you’ve got a real interaction problem.

Sometimes a few simple buttons, and not a fancy multi-touch UI, is the best way to solve an interaction problem. 

The App Store in iTunes fails to address these fundamental differences between their latest offering and what has been offered previously (media.) There is so much potential here: iTunes could be a great way for developers to collect feedback and find problems. Instead, we get gems like these:

The icon to this App scares me so much… That I’m too afraid to install the App. That bird looks angry like it wants to peck my eyes out for even concidering [sic] to install the application.

If you are gullible enough to watch FOX “News,” then you are gullible enough to download this app and work for them for FOX for free– you already are in a way, just by watching. This would be a great app for those of you that like to monitor “ethnic” types when the nation goes to “Code Orange,” or, God forbid, “Code Red!” Make sure you have this app when you’re digging your bomb shelter or spying on your neighbors’ subversive activities.

What makes this worse is that flagging reviews as inappropriate content seems to have no effect. I have flagged reviews of my own products, and those of other developers, and nothing has changed. If Apple wants developers and users alike to take this system seriously, they must address this problem immediately. Yes, it’s tedious and costly to do this review, but with continued neglect this system will end up being like YouTube for software.

If you have doubts that this will happen, take a look at the most helpful review for Band. Users are already learning how to game the system.

Some have suggested that buying the app should be a requirement before leaving a review. I agree, but this will not completely mitigate the need to vet content. A large percentage of applications are free: the trolls will just download before going on their merry way.

If all of this wasn’t depressing enough for developers, I’ll leave you with my biggest disappointment: reviews are a one way street. I’m not one to feed the trolls, but many of the reviews I’m seeing would benefit from a “Just try this…” or “We’re working on that…” type of response. There’s not even a link to our support on the reviews page.

I remain hopeful that someone at Apple will see what’s going on and have the power to fix it. My only advice would be to act quickly: the longer you wait, the harder it will be to clean things up.

As someone who has been involved in iPhone development for the past six months, please let me offer you a healthy dose of reality.

Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh.”

The heart of the problem are the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements. Whenever that hardware is on, your battery life is going to suck. My 5 minute refresh kept the hardware on and used up a lot of precious power.

(Those of you under NDA with the iPhone SDK should take a look at the documentation for Core Location. After reading about how it should be used, you’ll understand why getting your location in Maps and similar applications is only done on an “as needed” basis.)

And right about now, you’re thinking “But I’ll be smart about how I use the hardware.” Sorry, bucko, but you’re the exact reason why we don’t have background processing in the current SDK. You’re living in your own little dream world.

What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There’s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding.

In my opinion, such a scenario is quite likely. As a satellite device, the iPhone requires contact with other machines to do interesting things. Periodically hitting the network is the primary reason that developers want to run in the background.

Some have stated that Apple is limiting innovation. My opinion is that they are helping us from collectively shooting ourselves in the feet.

It takes several months of actual iPhone development before you eventually realize that the iPhone requires a completely different mindset. Until that happens, you’ll make assumptions based on desktop experience, and that in turn will lead to a lot of bad designs.

For what it’s worth, I think Apple will address this issue in the future. I can imagine a solution based on a plug-in (bundle) architecture that lets your application do things when the phone decides it’s a good time (not when you decide it’s a good time.) If the radios go on because you’re checking Mail, then you get a “network active” notification and a chance to run some short-lived TCP/IP connections. If you take too long, you’d get killed, much like Safari does with Javascript that runs too long.

Do I expect such a sophisticated system to be available in a beta of version 1.0? Hell no. And neither should you.