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.

Vote for virtualization

In this election year, there is an issue facing Macintosh developers. Ask yourself the following:

How can you develop new products for Leopard when you need to have Tiger installed for supporting your legacy applications? How easy is it to test a new feature on Mac OS X 10.4.11 when you’re running 10.5? How quickly can you reproduce a bug on 10.4.10 if you’re running 10.4.11? Can you run Xcode versions 3.0 and 3.1 at the same time from /Developer?

We all know the way to get Apple’s attention regarding our issues is to submit bugs. So now is the time to vote for virtualization. If you agree with the following, please copy and paste this bug report and submit it so that it becomes a duplicate of Bug ID# 5812840.

Summary:

A Macintosh developer’s ability to produce world-class products is inhibited by the lack of desktop virtualization.

Steps to Reproduce:

  1. Create a virtual machine using VMware or Parallels on your desktop.
  2. Try to install Mac OS X on this virtual machine.

Expected Results:

You should be able to install and run any version of Mac OS X on this virtual machine as long as the host is a Macintosh.

Actual Results:

The installation does not work.

Regression:

This ability has never existed, but ever since the arrival of virtual machines in Mac OS X, developers have dreamt of being able to do this.

Notes:

The ability to run multiple versions of Mac OS X has many benefits for a Macintosh developer and for Apple:

  • Being able to run any version of Mac OS X in a virtual machine makes it much easier for a developer to create features for both older and newer versions of the operating system. Many developers need to support their existing applications on the current platform, while at the same time developing new applications for an upcoming version of Mac OS X. For example, developers would like to have virtual machines that would allow Tiger and Leopard to run at the same time. The benefit to Apple is that there will be many more applications available at each new OS launch because the barriers to developing on that new OS are much lower.
  • Developers constantly need to test their products on various versions of Mac OS X. If a customer reports a problem on 10.4.11 and the developer is running 10.5.2, there is a significant amount of effort required to bring up a system that allows investigation. The result is that many problems are ignored or deferred. With virtualization these barriers are removed and fixing bugs becomes much easier. The benefit to Apple is higher quality software for the Macintosh platform.
  • Apple often releases beta versions of development tools that are not compatible with older versions. One such example is the current Xcode 3.1 release—it cannot be run simultaneously with the 3.0 release. This creates a situation where a developer working on iPhone applications cannot work on their current Macintosh applications at the same time. Again, developer productivity suffers and the availability of products for both of Apple’s platforms is affected.

Virtualization is currently being made available for the Mac OS X Server product. We respectfully ask that Apple make the same features available in the desktop version of the operating system.

Update: Several people have written to inform me that you can run Xcode 3.0 and 3.1 side-by-side. While this is true, I have heard that there are some problems. We all appreciate the excellent job the developers at Apple do with Xcode and the other fine tools we work with, but there will always be growing pains as these tools advance. Virtualization would lessen the impact of change on our development environments.

More brain surgery…

Now that I’ve covered some of the technical issues with background processing for iPhone applications, let’s take a look at why it’s a bad idea from the user’s point-of-view.

Assume that Apple changes their mind about background processing tomorrow–anyone can do whatever they want in the background. All the naysayers rejoice, and in a year’s time they’ll be asking Apple to remove background processing.

Why? Same reason as always. The iPhone requires a fundamentally different approach to user interaction. Something that goes way beyond the obvious things like the multi-touch interface.

If you can have a background process running on your iPhone, what is that process going to do when it detects a state change? What happens with a buddy comes online, or a new piece of data is available, or when a long running calculation is completed?

You’re going to want to notify the user, right? Again, “desktop thinking” makes this sound like a simple thing. But it’s not.

The iPhone is going to attract network aware applications like moths to a flame. In a year’s time there will be hundreds, if not thousands, of applications using the Wi-Fi and EDGE connections. You’ll likely have several of them on your iPhone: let’s say you have five.

You now have five independent sources for notifications. How do you let the user know which one is which? One might say, “make the sound different.” Another might say, “make something flash in the status bar.” Someone else might say, “make the phone vibrate.” Or even, “put up an alert box.” A truly sick individual might say, “Do all four.”

Can you see where I’m going with this? Your phone soon becomes a fricken’ pinball machine as multiple applications fight for your attention. With 24 notification permutations for every application, things will quickly get out of hand.

The desktop has evolved several mechanisms for notification: bouncing Dock icons, bezel windows, menubar icons, and things like Growl. These mechanisms all work together because they can share a common screen without unduly overloading the user.

But on the iPhone, you have a limited area and associated mechanisms for getting the user’s attention. In effect, it creates a notification bottleneck.

This notification bottleneck forces the user to work when figuring out who needs attention. First they have to recognize the notification by sound, feel or sight (or a combination of those senses.) Then they have to navigate to the recognized application, which may not be easy given the phone’s current state. Finally they need to deal with the source of the notification. Now imagine doing all this frequently: the network will end up being a constant source of distraction.

If you’re still unconvinced, let me ask you one final question: do you want to get IM notifications while you’re making a 911 call?

A new kind of partner

While speaking with a writer from Business Week the other day, a thought occurred to me: the App Store radically changes the quantity and quality of Apple’s partners.

With the iTunes Store, Apple has partnered with a handful of media companies for recordings and video. And those partners are deathly afraid of online distribution. Developers, on the other hand, will number in the thousands (or much more.) We also embrace online distribution wholeheartedly.

We will ask for things a media company would never even consider. Expect there to be a learning curve for both parties involved in this endeavor.

Update: Daniel Jalkut points out that we have our own fears.

Thoughts on downloads

It occurred to me the other day, that the music industry and software developers are beginning to have a lot in common. The proliferation of digital content, both legal and illegal, has radically changed the way people purchase music. But to those of us who have been distributing our work via the Internet since day one, downloads are not a big deal.

Let’s take a look at how software developers do business and see if it sheds any light on the music industry and their period of transition.

The thing that drives software sales is the notion of “try before you buy.” Gone are the days where you walk into a computer store, scan the shelves for an application, purchase a disk to take home, and pray that it solves your particular problem. Now, every customer has the expectation that the application prove its worth before they hand over their money.

Gone too are the days when you walk into a music store. Unfortunately, the record industry hasn’t realized that this is a good thing. They’re still clinging to the notion that your purchase should be based on nothing more than a 30 second sample. Like software, you have to spend a little time with a song or album before you discover how much you like it.

Of course there’s a need to protect your work so that a potential customer will eventually make the purchase. People are lazy, so you need to find a way to create an incentive to buy.

Some software is distributed by leaving out features until a serial number is entered. A similar technique can be used with music. A great example is Team Love Records which made downloads available for the Rabbit Fur Coat album by Jenny Lewis with The Watson Twins. Every track could be freely downloaded except for one: the track getting airplay (“Handle Me With Care”.) This approach worked very well for me—I knew the hit track from the radio and found out that I loved the other tracks just as much. And, in the end, I was a happy customer.

A similar thing happened with Bob Dylan’s Love and Theft album. A friend of a friend of a friend got ahold of a leaked copy of the album. I found it interesting that a couple of the tracks had really crappy sound: someone made a “mistake” and encoded the tracks at 32 Kbps. You could follow along and get the gist of the song, but I was very happy to “upgrade” on the day of release.

Another approach we’ve taken in releasing our software is to provide additional benefits after a purchase. This can be access to support, a special website or even new features or content. The record industry has done the same thing.

A couple of recent releases come to mind: Cat Power’s Jukebox album and Neil Young’s Live at Massey Hall. The incentive with the Jukebox album was the inclusion of an extra CD with four additional songs. Similarly, the Live at Massey Hall package came with a DVD containing footage from the concert. Both were things I wanted, so the decision to buy was easy.

For artists that you love, getting a complete set of their works is important. If I had been given a free copy of the “basic” CD, I still would have “upgraded” to get all the songs and/or video.

Now, let’s look at one thing that works for software distribution, but isn’t going to work for music: the notion of a time limited demo.

We have a reliable clock, a local file system to record usage, and other mechanisms that make tracking relatively easy. Of course, these things can be overridden or disabled by dishonest users, but the vast majority of honest people make up for it. As developers, we have also learned to encourage users towards the purchase: making demands does not work. Pissing people off will turn them into pirates, not encourage them to buy.

A MP3 file doesn’t have mechanisms for tracking. And we all know how the attempts to add them with Digital Rights Management has gone over with consumers. That’s because it’s a system based on demands: you must be authorized.

Finally, the best thing for business is to make sure you have the best product available. That’s both the beauty and the challenge of any “try before you buy” system. Good products win, bad products are quickly forgotten.

I suspect that the root of the music industry’s problem is this: they have been able to produce sub-standard product for many years. I know there are many albums in my collection that consist of few great tracks along with a bunch of crap that I’d rather not listen to.

And the iPod, which makes single tracks viable because you don’t spend all your time moving physical media around, allows people will buy only the product they find interesting. If the music industry wants to make more money, they need to make something besides one big hit plus filler. Can you imagine buying a software product that had one feature you really needed and 99 others that were worthless? The value is in the whole, not the individual parts. If you make compelling albums, people will buy more music from the artists they love.

In the end, however, I suspect that the large music companies will end up in a similar position as the large software companies. They will have the blockbuster product/artists with a lot of recurring revenue from each new release.

But the most interesting part of this ecosystem will be the independents. The people who have a smaller, but much more loyal following. The people who listen closely to these fans and realize how important they are to their creative works. The people who feel the joy of a customer telling them they rock.

That’s the beauty of this thing we call the Internet: it’s a two way street. And all it takes is a web page to start that conversation.