As an example, we’ve been getting plenty of feature requests for Twitterrific that ask for features and capabilities that exist in other mobile and desktop software. That’s not surprising, since one of our early decisions with the iPad app was to trim the app down to its bare essentials.

Part of this had to do with schedule constraints. Sixty days was not a lot of time to build a product from scratch.

But a more important reason for paring back the design was to simplify the user interface. A new kind of user is about to be introduced to a computer that they can actually use: less interface is more as far as they’re concerned. We designed our iPad app with our families in mind, not the Twitter power user.

It turns out that our design intuition was pretty good:

The non-tech-savvy users want something simple, to push an icon and get your e-mail and go online. With the iPad, people don’t feel intimidated by it.

Mary Elizabeth O’Conner

To this technical-ninny it’s clear
In my compromised 100th year,
    That to read and to write
    Are again within sight

Of this Apple iPad pioneer.

Virginia

Even folks that have access to the latest and greatest technology are preferring the iPad over more complex devices. Initial statistics also show that the iPad has an older demographic.

Of course, 300,000 geeks like you and me don’t fall into that category. We’re the first ones standing in line at the Apple store, and the first ones to use all this cool new software. And we know all the things that apps “used to do”. And we want all sorts of other bells and whistles. And we’re wrong.

As a developer, you should be very careful about this early feedback for your app. Simplicity is the name of the game in this new world order. You don’t maintain simplicity by adding tons of features.

Two of the most requested features after the 1.0 release of Twitterrific for iPad were Instapaper support and photo uploading. If you think about these things, both have a high cognitive load. To use Instapaper, you need to know that:

• The service exists, and that you can signup for an account.
• That you can install a bookmark and use it to save pages from your browser.
• That these saved pages can be synced to your iPad using another application.

For photo uploading, you have to know how to do one of these things in order to “get a picture”:

• Use the camera connection kit to transfer photos, or
• Take a screenshot with a non-intuitive gesture (the power and home buttons), or
• Tap and hold on a picture in a web page and save it to an album, or
• Create events in iPhoto and sync them with iTunes

Ask yourself if you could explain any one of these things to your mother in less than 25 words. I know I can’t and I’m pretty good with this kind of stuff.

Of course, these are both useful features and we added both of them in subsequent releases. In the case of Instapaper, the feature doesn’t even show up in the UI until you go into the Settings app and add your account information. My mom will never see it.

Photo uploading is a simple button on the compose screen that lets you choose a photo from your library. Eventually, our mothers will figure out how to add things to the photo library and use that feature. But they’ll be happiest when a future device let’s us put a “Take Picture Now” button on that screen.

It’s very easy to get caught up in the excitement this new device has generated in the last month and a half, but the real thrill will be in a year’s time when people who’ve never used a computer will be telling you how much they love your app. And there will be a lot more than 300,000 of them…

Updated: Check out similar thoughts from my colleages: David Lanham and Gedeon Maheux.

First, let me congratulate you and everyone at Apple on the release of the iPad. From my dealings with your company, I know it wasn’t easy. Thanks to everyone for busting their asses: a lot of very complex puzzle pieces came together during those last 60 days!

I recently had an encounter with Bill Atkinson. I told him that “I haven’t had this much fun with a computer since 1984.” He laughed, said “Thanks!”, and went back to working on his iPad app. We, and many other developers like us, are completely smitten with this new device.

After owning an iPad for a little over three weeks, it feels like we’re dealing with something much bigger than that Mac we all got excited about over 25 years ago. I’ve been struggling to define exactly what that is: beyond the technical specifications like the beautiful screen with its large multi-touch surface. Those specifications define what the device can do, but not what it means in our lives. I want to understand the magic.

Last week, much of that meaning came into clearer focus at a birthday party for my brother, niece and nephew (April is birthday month in our family!) My wife had loaded our iPad with photos from a recent trip to see the desert wildflowers in Anza Borrego and my 50th birthday party from the week prior.

Predictably, people’s initial reaction was “Wow, that’s the new iPad!” But that quickly faded as I opened the Photos app and passed the device around. My family was more interested in sharing the photos than talking about the new technology.

I was particularly interested in how my mother, the quintessential technophobe, would react to the device. She picked up on things quickly and was flipping through photos in no time. It astonished me how the interface disappeared for her: at one point she subconsciously licked her finger before “flipping” to the next photo.

As interesting as it was to see someone non-technical use the device, the real eye opener was how several people could interact with the iPad at once. Much of my mother’s fear of computers was overcome because she was looking at the pictures alongside my sister-in-law who helped her out when she got stuck. Learning was organic.

My niece also discovered some of the games I had on the device. One, Abca, was a hit because many people could play it at once. I’ve always played the game by myself and was surprised at how much fun it was to have other people guessing words simultaneously. A group of people transformed the software into something no developer had ever expected.

All of this led to the revelation that we’ve begun a new age of “communal computing.” The desktop revolution centered around empowering individuals: this new revolution will extend that empowerment to groups of people.

The iPad was naturally passed around amongst the partygoers. Many people interacted with it during the evening, and I lost track of who had it at any given time. And therein lies a fundamental problem.

My iPad has a lot of personal information on it: email, business documents, and financial data. When you pass it around, you’re giving everyone who touches it the opportunity to mess with your private life, whether intentionally or not. That makes me uneasy.

It’s hard to fault Apple for this shortcoming. The secrecy of the project undoubtedly limited the amount of group interaction your designers and engineers would experience with their new creation. The social aspects of this device is probably just as much as revelation to them as it is to me.

I can envision several ways to solve this problem: either with a traditional login screen or with something new like folders that require a passcode to open. I have no doubt that your designers can find something elegant that gives me peace of mind as I share my iPad with friends and family.

Thanks for your time and consideration,

Craig Hockenberry

Updated April 30th, 2010: I filed Radar #7922808 for this issue and it was marked as a duplicate of Radar #7584426.

And then one day it dawned on me: an iPhone toolbar with an action sheet is like a menubar with menus on the Mac desktop (turn your phone upside down and there is even some visual similarity.)

After investigating some of the design patterns for NSMenu and NSMenuItem, it was clear that this would work well on a mobile interface as well. My implementation is a subclass of UIToolbar named IFActionToolbar.

In it’s simplest form, you attach a list of items to one of the toolbar’s bar button items:

@interface MyViewController : UIViewController
{
  IBOutlet IFActionToolbar *toolbar;
  IBOutlet UIBarButtonItem *barButtonItem;
}

...

@implementation MyViewController  

...

- (void)viewDidLoad
{
  [super viewDidLoad];

  IFActionToolbarActionItem *actionItem = nil;

  NSMutableArray *actionItems = [NSMutableArray arrayWithCapacity:3];
  actionItem = [[[IFActionToolbarActionItem alloc] initWithTitle:@"One" target:self action:@selector(firstAction:)] autorelease];
  [actionItems addObject:actionItem];
  actionItem = [[[IFActionToolbarActionItem alloc] initWithTitle:@"Two" target:self action:@selector(secondAction:)] autorelease];
  [actionItems addObject:actionItem];
  actionItem = [[[IFActionToolbarActionItem alloc] initWithTitle:@"Cancel" target:nil action:NULL] autorelease];
  [actionItems addObject:actionItem];
  [toolbar attachActionItems:actionItems toItem:barButtonItem];

  [toolbar update];
}

The IFActionToolbarActionItem is just a simple wrapper object that associates a title with a target and action. These action items are used to automatically construct the action sheet when the user taps on barButtonItem. If you’ve ever constructed an NSMenu using NSMenuItems, this will feel quite familiar.

Additionally, the toolbar supports an -update method. This method calls the assigned delegate to enable or disable toolbar buttons, set the image for the toolbar item, change the title of the action sheet, hide or show items in the action sheet, and define the cancel or destructive buttons in the sheet. Again, similar in pattern to how NSMenuItems are maintained.

Any time you call this update method, the UIToolbar is configured automatically. It makes it much easier to reflect the state of your controller in the view.

I’m not going to spend too much time discussing the inner workings of this class: the picture of a sample project is worth a thousand words.

One thing I would like to caution you about: don’t get too carried away with enabling and disabling items in the action menu. In our UI testing, we found that changing the list too much was confusing for users. It’s like the “adaptive menus” used in Microsoft Office: it’s very difficult for a user to adapt to your interface if it’s constantly changing. Just because you can doesn’t mean you should.

Again, I hope this code is useful in your own iPhone projects. Enjoy!

In particular, this post addressed a problem that every iPhone developer has encountered: any kind of settings or form UI is a pain in the butt if you follow Apple’s sample code. And, of course, this is exacerbated because these essential interfaces aren’t very fun to code. For both Twitterrific and Frenzic, it’s been a frustrating experience: I wanted to fix how this standard UI was created and maintained.

The motivation

Before I start talking about what I did using Matt’s concepts and code, I’d like to discuss the need for settings in an application.

There are some people who think that settings should only be in the Settings app. There are others that think they should only be within the application. I can honestly see how both groups are right, but what both sides fail to realize is that it’s often a matter of context.

If you’re working on a simple application with simple needs, relying on the infrastructure provided by the SDK is fine. You may have some additional support load for users who have problems finding your settings, but that’s a reasonable tradeoff for saving development time. Sophia Teutschler’s Groceries app is a fine example of where the built-in settings shine: I turned off the Marker Felt font several months ago, and I haven’t touched it since.

In the case of Twitterrific, there were three main reasons why we built the settings into the application:

1. We could not split the settings between two locations. From a user’s point-of-view, it’s incredibly confusing to have an application’s configuration in two places. This would have happened if we had put the account settings in the application and everything else in the Settings app.
2. Some of the settings are things that people will change on a fairly frequent basis. For example, the dark theme works best at night, while a light theme is better during the day. Leaving the app to make these types of adjustments is inconvenient.
3. The Settings app can’t handle preferences that are “dynamic.” An example is a vibration setting for the notification: there’s no way to make this appear on an iPhone but not on an iPod touch.

The solution

I’ve taken the basic concepts that Matt presented in his article and extended them to create a pixel perfect replica of what you see in the Settings application. Instead of configuring applications using a property list, you do it with some very simple code in a view controller. (Domain-specific languages, such as those found in Ruby, were an inspiration for the methods used in this code.)

And if you’re not doing settings, the classes are still very handy for making user input forms. They were used in all of the search forms used in the new version of Twitterrific.

To give you a quick taste of how it’s used, here’s a complete implementation of a table view controller that presents a single group with a text field and a switch control. In just six lines of code:

- (void)constructTableGroups
{
  NSMutableArray *cells = [NSMutableArray array];
  IFTextCellController *textCell = [[[IFTextCellController alloc] initWithLabel:@"Text" andPlaceholder:@"Placeholder" atKey:@"sampleText" inModel:model] autorelease];
  [cells addObject:textCell];
  IFSwitchCellController *switchCell = [[[IFSwitchCellController alloc] initWithLabel:@"Switch" atKey:@"sampleSwitch" inModel:model] autorelease];
  [cells addObject:switchCell];
  tableGroups = [[NSArray arrayWithObject:cells] retain];
}

The real beauty of this code is that it’s incredibly easy to change. Settings and forms tend to evolve over the lifetime of a project, so using these simple declarations for the table view layouts makes it much simpler to adapt to new requirements. If I need to change the switch control shown above into a choice list, I can do it in a couple of lines of code.

So without further ado, here’s the source code in a sample project. The code is well documented, so you shouldn’t have any problems figuring out how it all works. Start by looking at the RootViewController, then take a look at the SampleViewController, followed by the SampleAdvancedViewController. If you’d like to incorporate this code into your own project, just grab all the classes with the Iconfactory prefix (“IF”.)

The license

Previously, I’ve released source code on this site without any licensing at all. This time, I’m going to try something new. You can do anything you want with this code with one requirement: you need to give the Iconfactory some link love in your product.

For more details on the licensing terms, check out the Licensing.rtf file that’s included in the sample project. If you can’t abide by this restriction, please get in contact and we can try to work something out.

I hope this code saves you as much time as it has saved me. Enjoy!

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.

Splash screens hurt the user experience from a purely psychological point-of-view. They don’t change the launch time of your iPhone application at all, but it looks and feels longer.

But there’s a problem: you can only specify one Default.png file to be displayed at launch time. Unfortunately, applications can have many visual states which you’d like to show as the code is loaded. In the case of Twitterrific, the list or detail view can be active and they have no visual commonality.

So what are the current options?

Some people have suggested that you have a single startup image (like the list view in Twitterrific) and use a Core Animation transition to the actual state the user was last in. This would work, of course, but it has a major flaw: it increases the amount of time needed before the user can actually start using the application (they need to wait for the transition to finish.)

Another option would be to show a blank screen. I tried this, and my first thought was that the application had crashed. Not acceptable.

Why not replace the Default.png on-the-fly? As Tom Insam notes, you can’t modify the application bundle: doing so breaks the application signing and will leave you with code that won’t run.

So that leaves us with splash screens. The user knows the launch is in progress, there are no jarring visual changes, and it’s the quickest way to get to an active state.

Of course, there are mechanisms to have multiple startup screens. You can see it in the Clocks app: the world clocks view has a different startup image than the stopwatch view. Another example are the new chrome-less Safari pages that you can put on the home screen: these apps take a snapshot of the current screen at exit and display it at the next launch.

Apple should expose this functionality to third parties. If you agree, please submit a duplicate for Radar ID# 5872097. Until that happens, please excuse our splash screen.

As a way to celebrate the lifting of the NDA, we bring you some very special source code. To wile away the time between our product submission and the launch of the App Store, my buddy Anthony Piraino and I worked on this very special treat. Something that will be familiar to all developers who have had to keep their mouths shut since March 6th, 2008. Just compile the source code and install it on your device. Typing pleasures await.

(You’ll need to install Twitterrific from the App Store to get the full user experience. But you’ve done that already, right?)

Besides being a fun inside joke, this very special application also shows an important aspect of iPhone development: URL schemes.

As we’ve seen many other times, the needs of a mobile user are very different than those of a desktop user. On the desktop, tight integration of several application domains makes applications like Coda a joy to use.

On the phone it’s better to focus on one task. From what I’ve seen, the best iPhone applications do one thing and do it well. Supporting URL schemes in your application makes that single task more attractive to other developers and users. It leads to what my friend Daniel Jalkut has aptly called the “Un-Coda-fication” of iPhone apps.

The benefit for a developer is obvious: it minimizes the scope of an application and the attendant memory footprint. You could write your own Twitter update code using a NSURLConnection, or you could use one line of code like this:

[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"twitterrific:///post?message=EASY"]];


There is a less obvious, but equally important benefit when you look at URL schemes from a user’s point-of-view. Since your application’s scope is limited to one task, users will depend on it when they want to perform that task. Even if that task is in the context of another application.

An example of this is sharing photos. Users know that the Camera application takes pictures and that the Mail application sends messages. You don’t see a camera button in Mail; you see an “Email Photo” button in your Camera Roll. The user’s first task it to take a picture and the next task is to mail it.

Since we’re not Apple, we can’t achieve the high level of integration between the Camera Roll and the Mail application. But we can use URL schemes to accomplish much the same thing.

I worked with Fraser Speirs and Ian Baird during the development of Exposure and Cocktails so that their applications could support a “Post to Twitter” button. Clicking on that button initiates a workflow that lets the user share what they’re looking at on Flickr or what kind of drink they’re enjoying. Leaving their app/task and launching Twitterrific makes complete sense.

If you’d like to include a “Post to Twitter” button in your own application, all the code you need is in the postToTwitter: method in the very special application mentioned above. If you want to handle your own URL scheme, take a look at application:handleOpenURL: in the application delegate. Be careful about validating inputs: you don’t want malicious URLs to do bad things.

Not to dampen your enthusiasm, but please be aware of a couple of limitations with URL schemes. First, there is no way to know if a URL scheme is supported or not (rdar://problem/5726829). Currently, the best you can do is to performSelector:withObject:afterDelay: then openURL:. If the selector gets called you know that the URL failed to open. Also, be aware that deleting an application can sometimes leave the URL registration database in a state where it no longer recognizes a scheme (rdar://problem/6045562). This only happens when two applications support the same URL scheme, so you can avoid the problem by using a unique scheme name. Please use the Radar bug ID# for a “me too” bug report if this becomes a problem in your own application.

Now let’s enjoy our newfound freedom to discuss the iPhone SDK and the first of many sample code releases on this site!

Update October 1st, 2008: As Jonathan Rentzsch and Thomas Ptacek point out, URL schemes can be an attack vector for your application. Pay particular attention to the code in -application:handleOpenURL: in your application delegate. If you find any vulnerabilities in my code, please let me know so I can update this essay. Thanks!

Update October 7th, 2008: Once your application supports URL schemes, it’s likely that you’ll want to provide a bookmarklet in Safari. Here’s the one we use in Twitterrific:

javascript:window.location='twitterrific:///post?message='+escape(window.location)

The hardest part about doing this is guiding the user through the setup process. Joe Maller came up with a simple solution that lets the user get the Javascript into their bookmark list. This was later refined by Alexander Griekspoor. Make sure to view the source on these pages for additional hints and installation instructions.

If you agree that this setup process is too difficult for end users, please submit a duplicate bug for Radar ID# 5935641. Thanks!

Update February 4th, 2012: UIApplication now provides a -canOpenURL: method that lets you check if there is an application installed that supports the URL scheme.

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. 

There’s no denying the physical beauty of the award or the cool prizes that accompany it. But in this “day after” the thing that I’m finding most rewarding is the outpouring of support and congratulations. The six weeks of eating, sleeping, and breathing [REDACTED] preceded by months of digging through class-dump and respondsToSelector output was far from easy: but it’s all worth it.

From everyone here at the Iconfactory, all we can say is thank you. It means so much.

Unfortunately, we’re still under NDA and have been advised by Apple not to share screenshots. We’re all anxious to show off our work, but we need to respect the wishes of our new partner.

If you’re here at WWDC, you can get a look at the UI on the panels on the third floor. There are also some photos from last night’s event that hint at what’s about to come. For those of you wondering about the photo I took before going on stage last night: my big fat finger was over the lens on my iPhone—a great example of why ergonomics in your application is important.