Rainblog

Apple’s new amended developer agreement for iPad/iPhone development has been generating lots of talk over the past few days. Everyone has a theory as to why Apple chose to ban third-party development environments, ranging from a grudge match with Adobe, to multi-tasking issues, to a deliberate attempt to make Cory Doctorow’s head explode. OK, I made the last one up. No one’s saying that yet, but we shouldn’t rule it out.

In correspondence with Greg Slepak, Steve Jobs essentially gives his papal blessing to the theory put forward by John Gruber, which hints that while there’s some truth in the official line that cross-platform tools deliver inferior user experiences, it’s really about Apple maintaining a lock on the market. A market where developers can target a meta-platform over and above Apple’s mobile devices is one that Apple can’t control. That’s a threat to Apple’s business model so they’ve seized the chance to try and cripple the meta-platform from the outset.

Even without Jobs’s endorsement, it’s clear that Gruber’s probably right, but he doesn’t spell out all the implications. Apple’s move doesn’t just target the meta-platform; it also targets competing platforms, such as Android.

Consider a world where cross-platform tools such as those offered by Adobe were permitted by the Apple SDK agreement. If you’re developer X, you build your application using those tools, and release it for all the possible mobile platforms simultaneously. Now Apple’s mobile platform is just another platform. Sure, developer X’s shiny new application is available on iPhone, but it’s also available on Android and who knows what else. There’s no compelling reason to choose an iPhone if you want to run developer X’s new app.

The problem gets worse if Apple allows cross-platform tools in principle, but rejects apps submitted if they don’t measure up to their expectations of quality (which would be the case if Apple were serious about rejecting cross-platform tools in order to guarantee the best possible user experience). Developer X submits their new killer app, and Apple rejects it because the scroll bars work the wrong way or it doesn’t multi-task nicely. Developer X shrugs and says “At least I can sell it on the other platforms.” Now the killer app is available on rival platforms … but not on Apple’s. That’s a disaster from Apple’s point of view.

Developers have limited cycles. If they can use a cross-platform tool, then putting in so many man-hours of work will let them target all the platforms supported by the tool. But if Apple won’t let them use a cross-platform tool, then the man-hours needed to bring a product to market on all the platforms just doubled: they need to develop and test on Apple’s environment, and on the cross-platform tool. If the developer can’t afford to make that investment, they need to make a choice: develop for Apple’s platform, or for the other guy’s?

What Apple is counting on is that they currently have the most attractive platform. If developers have to choose to target only one, Apple hopes that it will be the iPad/iPhone. That can also become self-reinforcing: if more and better apps are available for Apple’s platform, the platform becomes more attractive. If developers have more experience working with Apple’s tools, they’ll be less likely to develop for other platforms using other tools. Apple is trying to use its early lead and Section 3.3.1 to starve the competition.

This isn’t about Adobe. They’re just collateral damage. What’s really at stake is dominance of the mobile platform, and Apple is using everything in its toolbox to ensure that it, and no one else, comes out on top.

Apple doesn’t want to be first among equals. Apple wants to be first. Period.

One of the things that used to drive me crazy about working on Windows boxes was that there were so many different ways to do the same operation. In most applications, copy and paste was done with control keys: Ctrl-C, Ctrl-V. But the indispensable putty followed the X-Windows model: left-click copies, right-click pastes. The equally useful Trillian used a hybrid; left-click copies, Ctrl-V pastes. And I never did quite figure out how to copy and paste in DOS boxes, but I think it involved the entrails of a chicken and a signed authorization from the Pope.

Any time you find yourself doing the same basic operation four different ways, something’s broken.

Which brings me to the iPod/iPhone.

I finally cracked and bought myself an iPod Touch, as a replacement for the elderly Palm Zire 71 that I’ve been carrying everywhere for the last six years. The Zire, incidentally, still works fine, but for a variety of reasons I felt it was time to move on. I’m now in what you might call the ‘honeymoon period’ with the Touch, if by ‘honeymoon period’ you mean the span of weeks in which you discover that your new bride is an incredibly flexible contortionist who has read every page of The Perfumed Garden, but also smokes foul-smelling cigars in bed and wakes up at four every morning to sing baritone arias from German operas at the top of her voice. In short, there’s good news and bad.

One of the glorious things about the Palm was the ease of syncing the device with your desktop. You sat it on its cradle, you pushed the button, it ground away rather slowly, and you were done. There were quirks but, by and large, Palm really delivered on the promise of no-brainer bidirectional syncing.

The iPod is a different story. To coin a phrase, “how may I sync thee, let me count the ways”.

Generally, syncing data from Apple’s built-in applications - Address Book, Calendar etc - is simple. You hook up the iPod, and iTunes syncs things for you. It’s when we move on to third-party apps that the insanity kicks in.

Two apps that I added to my iPod immediately were SplashID and SplashMoney. I’ve used them so long on the Palm that there was no question that I’d buy the iPhone versions when I made the switch. They both sync wirelessly with the desktop: you start the desktop app, then open the corresponding app on the iPhone and press the sync icon. Pretty straightforward.

I also knew that I wanted OmniFocus on my iPod. I’ve been using it on the desktop for a while, so the idea of seamlessly syncing to-do lists to a portable device was very appealing. OmniFocus actually offers a bunch of ways to sync. You can do it in the cloud, through MobileMe or WebDAV or you can do it over wi-fi in the same way as the Splash apps: the desktop app runs as a server, and the iPhone app connects to it.

I’m an outline junkie, so I had to have an outliner. Until Omni Group delivers OmniOutliner for the iPhone, the best game in town looks to be CarbonFin. The way you sync with the CarbonFin iPhone app is as follows: you sign up for their Outliner Online website, which lets you upload outlines from your desktop in OPML format. When you hit the sync button on the mobile device, it pulls your outlines down from the web. A bit clunky, but it works.

A few weeks back Hog Bay Software were giving away copies of WriteRoom for free, so naturally I grabbed a copy. Like CarbonFin, WriteRoom offers a website-based syncing method, with the interesting quirk that you actually use your Google username and password to log in. It also offers syncing over a local wi-fi network. In this case the iPhone app acts as a server, and you use Safari on the desktop to connect to it. My first thought when I realized this was “Awesome, my mobile device is running a web server.” My second was “Wait, what the fuck?”

GoodReader uses a similar mobile-device-as-server model. It also offers direct web download. And it supports USB-based sync, using a separate desktop application that you have to download from a partner site. Most of these methods are more or less straightforward, but each one is presented and documented in its own way.

Finally, there’s Kindle for iPhone, which uses something called WhisperSync, Amazon’s proprietary name for what appears to be another web-based syncing model. Amazon figures you don’t need to know the details and they’re right, but it’s a little unnerving because you don’t know exactly what it’s doing and when. Is this book on my device, or is in the cloud? Amazon thinks you shouldn’t need to know or care, which is fine if you live in a world of permanent ubiquitous connectivity, but may prove problematic in real life.

So, half a dozen apps, a dozen ways of doing things. And here’s the real kicker: remember that one-touch sync that Palm had? You can forget about that. To sync my new iPod, I need to start iTunes and SplashID and SplashMoney and OmniFocus on the desktop, fool around on a couple of websites, and then run all the corresponding iPod apps, one after the other. As the man said, this ain’t rock’n’roll, this is genocide.

In an ideal world, there would be one method by which all apps (including third-party apps) could sync their data over USB, one method by which all apps could sync data over wi-fi, and one method by which all apps could sync data through the cloud (Apple would want to make this MobileMe, I would want it to be possible to use a private WebDAV server instead). Instead of having to manage each app individually, there would be a single uniform interface where the user could kick off a synchronization. But in bizarro iPod world, everyone is free - or obliged - to invent their own way of doing things. The result is anarchy.

My feeling is that Apple dropped the ball on this one. I haven’t read the developer documentation, but the sheer number of different approaches taken by the third-party developers argues that they never offered the necessary underpinnings that would allow uniform solutions. For a company that has long prided itself on promoting ease of use by design, that’s a pretty grievous failure.

Suddenly, the Windows copy-and-paste clusterfuck seems modest by comparison.