Thank you

Wow.

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.

Brain surgeons

Unless you’ve been stranded on a remote Pacific isle, you’re no doubt aware of the current furor over third party iPhone applications not being able to run in the background. To be blunt, I’ve never seen so many experts without a fricken’ clue. If you haven’t written code using the jailbreak tool chain, your opinions on the iPhone SDK, based entirely on what you see in a simulator, just aren’t relevant. You might as well be explaining the nuances of brain surgery.

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

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

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

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

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

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

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

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

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

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

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

So you’re going to write an iPhone app…

Welcome! Many people arrive at this page while searching for information about developing iPhone applications. The ideas from this article are expanded upon in my book, iPhone App Development: The Missing Manual.

As we’re all waiting with bated breath for the release of the iPhone SDK later this month, now would be a good time to pass along some of things I learned while working on MobileTwitterrific. Read this now and you’ll save yourself some headaches when diving into the SDK.

Code reuse

Don’t expect to reuse much of your existing code. If you’re using a standard MVC design (which is pretty much inescapable if you’re using Cocoa) then about 2/3rds of the application will require major rework.

From my experience, your models and the infrastructure that support them can be reused without much effort. On the other hand, the multi-touch interface obviates the need for your existing views and controllers.

As an example, the code I use in Twitterrific to download the data from Twitter using NSURLConnection, parse the XML into an NSDictionary and store it in a sorted NSArray was largely copied without change from the desktop application. The controller and view code was all new.

Memory usage

There are some very tight limits on memory usage. You’re given approximately 64 MB of space to work with (about half of what’s available.) If you go beyond that, Springboard shuts you down unceremoniously. That combined with the fact that there isn’t any swap space where unused objects can go to rest, makes for some design decisions that you haven’t had to consider in the desktop environment.

For example, let’s explore how I manage the scrolling list of tweets in MobileTwitterrific. In the desktop version, each tweet in the list is an NSView, while on the phone each tweet is a UIView. The big difference is when these views are instantiated and freed.

On the desktop app, views are created whenever there’s a new tweet and they occupy space in memory until removed from the list. The views don’t have a very large footprint and the supporting infrastructure (NSTableView) works much more smoothly with real objects (rather than some sort of proxy.)

The iPhone, on the other hand, uses a UITableView. This subclass of UIView has delegate methods that ask for a view to display for each row in the table. Of course, you could instantiate a complete list of views and just use the row index to pull the view out of an NSArray. But think about this delegate design pattern a bit: it’s there so you have a chance to instantiate views when they are actually needed. If you have 2,000 names in your contact list, and are only displaying 8 at a time, why do you need to have 1992 views wasting memory?

Basically, you’ll find yourself being as lazy as possible when it comes to object allocation, and being as ruthless as possible when it comes to freeing those same objects.

NIB-less

Try to imagine developing a Cocoa application without Interface Builder. Try really hard. Really, really hard. Seems like a nightmare, huh?

Guess what? This nightmare will become a reality as soon as you start building your iPhone application. There are no NIBs. None.

I don’t think this is one of those “let’s skip it for version 1.0” design decisions. The process of unarchiving the objects in the NIB takes CPU cycles and memory: both things that are in limited supply on the phone. And, as I stated above, you’ll find yourself creating and destroying views much more frequently than you do in your desktop application. (And anyone who has tried to deallocate objects from a NIB knows that’s not so easy.)

Creating views, placing controls as subviews using NSRects, and then setting a bunch of properties isn’t the most glamorous coding in the world, but it’s the price you pay to run on a mobile device. Just be very happy you’re working in Objective-C and not some other crappy language, OK?

Another thing that us Cocoa developers have gotten spoiled with: bindings. You’ll find that all the normal KVC and KVO infrastructure is present, but it saves much less time when you have to establish all the bindings manually with code. If you’re like me, you’ll end up just targeting controls at methods and be done with it.

Complexity

The good news is that the user interface is much less complex. The bad news is that the user interface is much less complex.

If you have a rich desktop application with hundreds of features, you’ll find that it’s hard to pick what you absolutely need. Culling features isn’t easy, but it’s absolutely necessary.

One mental exercise that I’ve found useful is to ask myself “Will I need this feature while walking down the street or sitting in traffic?” Both are situations where there are significant distractions to the task at hand. Does the feature make it easier to interact?

Luckily, not having NIBs and bindings gives you some motivation to get rid of unnecessary complexity. When it’s not easy to add that view with hundreds of controls, you’ll think twice.

Look and feel

Don’t think that your desktop and mobile application will share any look and feel. There may be slight resemblances with regard to branding, but that’s about it. Does Safari look like MobileSafari? Sure it has the same icon, but…

While I was developing the look and feel of the MobileTwitterrific application, there were two areas which were problematic: display contrast and button placement.

Being able to read the display in all kinds of lighting conditions means you’re going to need high contrast. In your office environment, it may seem a bit garish to have a lot of dark elements on light backgrounds (or vice versa), but once you actually try to use these elements in the “real world” it makes complete sense.

This “real world” usage also makes you think about where to place controls. In one case, I placed two buttons too close to one another and found that when I used one hand to drive the UI, my thumb would often hit the wrong control by accident. When I was doing development in my office with the phone on my desk, I used two hands to control the UI and didn’t see this problem.

It’s likely that there will be a simulator in the iPhone SDK. Don’t believe for a second that you’ll be able to use this simulated device for all your development and testing. You have to literally live with the application.

That’s all for now. Let’s go back to waiting impatiently.

Put your content in my pocket

Sometimes it takes awhile to fulfill a promise.

One such pledge was made last century to my good friend Jeffrey (he was only a prince at the time.) I said that I’d love to write something for his fledgling mailing list: A List Apart. This past month, I finally got around to writing that piece: Put Your Content in My Pocket.

If you’re visiting this site for the first time, you might be interested in the original article that prompted our collaboration. I’ve also written some articles that explore some of the problems, performance and less than obvious features on the iPhone. For the hard core geeks, there are also some explorations into the specifications.

So enjoy your visit and please make sure to join in the discussion forum at ALA if you have any questions or concerns about my article. Thanks!

Postscript: I mentioned some nonsense in the article: here it is, the Eric Meyer Memorial iPhone Blocker.

Why stop at the Dock?

If the changes to the Leopard Dock are a good idea, shouldn’t Apple go all the way and do the same thing to the Finder? And then applications, too! Hell, I can totally see these windows flying around with Spaces and Exposé and Core OMFG!

The Finder of the future?

Forget about October, I’m stoked about 10.6! Let’s hope they add more reflections and transparency, too!