Year: 2008

Dear Steve,

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?

A friend of mine recently commented that native Twitter applications are the new flashlights. It’s true, but it shouldn’t come as a surprise: consider the number of web apps that proliferated before the advent of the native SDK.

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.