Killing our enthusiasm

Dear Steve,

I am an iPhone developer. I love Cocoa Touch—it’s an amazing piece of engineering. I’m having great success with the products I’ve written (one of them even won an ADA at this year’s WWDC.) Sales through iTunes are great and well above my expectations.

And despite of all this, I’m feeling ambivalent about developing new applications for the iPhone.

Of greater concern is that I’m not alone: many of my colleagues are starting to feel the same way. To illustrate, here are some thoughts from people whose work I respect and admire:

Steven Frank – Panic (Transmit/Coda/Unison)

Fraser Speirs – Connected Flow (Exposure)

Wil Shipley – Delicious Monster (Delicious Library)

Brent Simmons – NewsGator (NetNewsWire)

You should also be aware that much of the discontent is being masked by the NDA that’s currently in place. I, and many others, do not want to anger Apple and there are no forums to voice our concerns privately.

As you’ve seen throughout your own career, great engineering is not driven solely by financial rewards. Woz didn’t write Integer BASIC by hand because he thought it would make him rich. Andy Hertzfeld’s and Bill Atkinson’s work on the original Mac wasn’t motivated by greed.

Great developers create amazing software for love as much as money. Take away the artistry and craftsmanship and you’re left with someone pumping out crapware for a weekly paycheck.

I have worked on many different platforms throughout the years: the most important benefit to working on the Mac is the vibrant community of developers. The high quality of Mac applications is due in large part to great developers being able to learn, compete, innovate, and share in a common success. This camaraderie sustains the love for the platform.

I was hoping the same would be true for the iPhone. Sadly, it’s not, and that makes this new platform really hard to love. I’m trying to stay positive in spite of recent developments, but I’m finding my attraction to the iPhone fades a little bit each day. I think it’s important that you know that.

Thanks for your time,

Craig Hockenberry

P.S. As I was writing this essay, Jason Snell and Dan Moren posted some articles at Macworld about the App Store and NDA. The disaffection is starting to spread outside the development community.

Update October 1st, 2008: Thank you.

Lights Off

There was a time when I would have never considered jailbreaking my iPhone. That was a time before I saw Lucas Newman’s and Adam Betts’ groundbreaking application for the iPhone: Lights Off.

It’s a simple game. It’s simple code. And it demonstrated what was possible for the rest of us outside of Cupertino. I was hooked. Big time. Seeing Lights Off at C4[1] was an inspiration for pretty much everything I’ve done on the iPhone since.

As a result, I feel compelled to document this historic piece of software. And what better way to do this than with source code that works on the iPhone 2.0 software. The archive also includes a Jailbreak folder that contains the original source code that worked with version 1.0 of the iPhone OS.

Do not look at this code for tips on how to design iPhone applications correctly. Rather, it is a testament to the curiosity and coding instincts that were required for developing sophisticated software without any documentation or headers. I purposely made as few changes as possible while porting to 2.0: FileMerge can be used to see what’s improved since Jailbreak and you’ll see plenty of compiler warnings.

Since Lights Off is inspired by Tiger Electronic’s game Lights Out, it doesn’t feel right to release this via the App Store. You will have to build and install it yourself; no exceptions. If requested, I will remove this project from the site, so get it now.

Now who will be the first to reach line 212 in puzzles.plist?

Note: If Apple feels this information is crossing over the NDA line, I’ll be removing this essay and the accompanying code. It’s probably a good idea to save it for reference. Hopefully they’ll realize that college students and other developers learning about the iPhone will find it helpful.

Nike – iPod

Having just presented a talk at C4[2] about the human factors involved in developing touch-based applications, I find it rather ironic to see the Nike + iPod integration move into the latest iPod touch.

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.