Ringtone apps

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?

Choices

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.

Release day

Unless your Internet tubes are broken, you’re probably aware that we released Frenzic for the iPhone today. It’s been a long time coming, but we’re all very proud of what we’ve accomplished—and very grateful for the great feedback we’ve been getting. As always it’s been a great pleasure working with Wolfgang Ante on this game.

But let’s go beyond all of this self congratulation and look at some of the details about how to coordinate your App Store release.

The first trick is setting your release date. As we all know, there can be some long wait times in the iTunes Connect queue. Indications are that the approvals are getting quicker, but it’s still an indeterminate value. And not knowing when your application is going to appear in iTunes means that it’s hard to coordinate press releases, website updates and other things that are dependent on having an product for sale.

The way to handle this is surprisingly simple: when you add or update your application in iTunes Connect, set the release date far into the future. Then, once you’ve been approved, you can update the release date to coordinate with PR. We knew that Frenzic would show up in the App Store on November 19th. But we didn’t know exactly when.

So what does it mean to “show up” in the App Store? iTunes is a worldwide enterprise so the date and time on your wall clock doesn’t mean much. There are timezones that will see November 19th before you do. Since Frenzic stores scores with unique ids and timestamps on its website, we collected some data that provides insight on how applications are deployed on iTunes.

The first scores started coming in just before midnight GMT on the 19th. The bulk of the traffic was coming from throughout Europe, although there were also some scores from Australia. As far as the listing in iTunes is concerned, we first saw it appear in the UK store. It then appeared in Sweden and Austria: this was not an exhaustive search, merely one of convenience (we have employees in these countries.)

The most important thing, of course, is getting the iTunes link for the product. This link is used throughout the site on buy links. We needed this information before doing a website deployment.

Happily, the link that showed up in the UK is also the same one that’s used in the US (we assumed it would be, but were reluctant to a deploy until we were sure.) You can get the link by control-clicking on the product icon in iTunes and selecting “Copy iTunes Store URL”. The resulting URL looks something like this:

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=296581959&mt=

Unfortuately, the only way to know this URL is by having it show up in iTunes. It would be nice to have this information ahead of time, and if you agree please submit a duplicate for ID# 6386452.

Updated November 19th, 2008: Thanks to Derek Del Conte there is a way to get the application ID. Just click on App Details in the “Manage Your Applications” list. The “Apple ID” can be used to create the link.

Another option for the purposes of deployment is to use a URL with the product name:

http://www.itunes.com/app/Frenzic

This format generates a redirect to the iTunes product URL. Unfortunately, it has been buggy in the past, so use it sparingly.

Finally, I’ll leave you with some eye candy. Wolfgang has posted some screenshots of Frenzic throughout its development:

  • The first prototype that we ever played on OS X. This is what got everyone at the Iconfactory hooked.
  • The game screen. The first pass at this used the same color scheme and contrast as the desktop version. That was a bad idea: put this screenshot in Photos and take it outside and you’ll see why.
  • The scores list. There is an art to making table views look nice. Both Wolfgang and I are lucky to work with some very talented designers :-)

So give Frenzic a try and if you like it as much as we do, tell your friends. Thanks!

Cooking with gas

One of the great things about the NDA being lifted is that a lot of great books about iPhone development are finally being published. It’s about time: for many months the top search hit on this site has been iphone app development. A lot of new developers need guidance.

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!

The final test

During the early days of iPhone software development, there were no mechanisms for doing beta tests. Those of us on the bleeding edge were developing apps with very little peer review and beta testing.

Luckily, I have friends who are a lot smarter than me. And we banded together with one primary rule: you don’t talk about Fight Club. Despite the NDA, we were determined to test each others applications.

This was accomplished by distributing unsigned applications amongst the group. Each member of the group then signed the app with their own developer certificate and installed it with Xcode. We all got pretty good with the codesign utility because it was so exciting to see each others work.

But this essay isn’t about reminiscing. It’s about telling you how to test the applications you upload to iTunes Connect.

If you’ve submitted an application to the App Store, you know that sinking feeling of not being able to test your final build. The binary that gets signed with the “App Store” distribution mechanism cannot be run on your test devices: you can’t be sure that the final bits you send to Apple are complete.

But there’s a simple way around this problem and it’s called codesign. The same application we used for our pre-Ad Hoc beta testing can also be used for a final test on your App Store submissions.

The first step is to create your distribution build for the App Store. For this example, we’ll be using the Frenzic application and putting it into build/Distribution-iphoneos. After the build completes, make the ZIP file archive immediately. Put it in a safe place so you can upload it to iTunes Connect after you finish your final test.

Now verify that you’re dealing with the right application. Go to the build folder and issue the following command:

$ cd build/Distribution-iphoneos
$ codesign -d -vv Frenzic.app/Frenzic

You’ll then see a verbose dump of the signature in the application:

Executable=/Users/craig/Projects/FrenzicTouch/build/Distribution-iphoneos/Frenzic.app/Frenzic
Identifier=com.iconfactory.Frenzic
Format=bundle with Mach-O thin (armv6)
...
Signature size=4331
Authority=iPhone Distribution: The Iconfactory
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Nov 12, 2008 1:46:07 PM
...

The most important part of that output are the lines beginning with “Authority”. It shows that the “iPhone Distribution” certificate for The Iconfactory is being used. This is what Apple needs, but it’s also the thing that keeping you from running the app on your test devices.

So let’s change it.

The first thing you need to do is define an environment variable that gets the correct version of codesign_allocate (the one in /usr/bin doesn’t currently support ARM):

$ export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate

If you forget to do this, you’ll see this error message when you try to sign the binary:

codesign_allocate: unknown architecture specification flag: -a armv6 6720

Now you can sign the application using your own certificate:

$ codesign -f -s "iPhone Developer" -vv Frenzic.app/Frenzic

The -s parameter should be the same value as the Code Signing Identity > Any iPhone OS Device setting in your Xcode project. The -f parameter tells codesign to force the replacement of the signature. As the command executes, you’ll see the following output as the signature is replaced:

Frenzic.app/Frenzic: replacing existing signature
Frenzic.app/Frenzic: signed bundle with Mach-O thin (armv6) [com.iconfactory.Frenzic]

After you’ve re-signed the app, you’ll see that I am now the authority. But you probably already knew that:

$ codesign -d -vv Frenzic.app/Frenzic Executable=/Users/craig/Projects/FrenzicTouch/build/Distribution-iphoneos/Frenzic.app/Frenzic
Identifier=com.iconfactory.Frenzic
Format=bundle with Mach-O thin (armv6)
...
Signature size=4302
Authority=iPhone Developer: Craig Hockenberry
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Nov 12, 2008 6:35:06 PM
...

Now you can move the updated application onto a test device and make sure that the final build is OK. Everything except the signature is the same: if there’s a missing file or something that’s messed up, you’ll be able to find it before the QA engineers at Apple do (and with 10 day turnaround times, that’s a very good thing.)

Once you’re happy that everything looks good, upload the ZIP file you created earlier to iTunes Connect and crack open a beer. As you’re enjoying that beer, take a look at the codesign man page for more information on this essential utility. Or write an essay for your web log :-)

Updated July 2nd, 2009: Note that this procedure can also be used if you are beta testing. This is particularly helpful in cases where you’ve upgraded to an iPhone 3GS and the Ad Hoc .mobileprovision file for the beta contains the UDID for your older device. Many developers have hit the 100 device limit since the release of the new phone, and can’t add devices into a new .mobileprovision file. You’ll be able to test the beta releases after signing the code with your own certificate. The only case where this won’t work is when the app being resigned uses the keychain.