I hope they give selected developers early units, so they can make some apps iPad-ready from the day 1. Apps like Tweetie, Facebook, Instapaper, Evernote, and top 50 apps.

Otherwise the initial user experience with iPad (at least till June) will be boring.

marco:

Either I’m missing something, the initial iPad apps are going to suck, or we haven’t yet been told that iPad-native apps won’t be available for some period of time after the iPad’s launch.

We have strong incentives to port our iPhone apps to the iPad quickly and completely so they’re ready for sale on day one. As soon as people start getting iPads, they’re going to want apps for them, and they’ll quickly realize that the experience of running an iPhone-native app on an iPad really sucks. Any iPad-native apps in the store on day one are going to receive huge advantages in publicity and ranking that could last months, and any apps that wait too long will lose favor among iPad users and may be abandoned for competing alternatives.

The problem, of course, is that before day one, we won’t have iPads ourselves for development and testing. This wasn’t a problem for iPhone development: by the time the SDK was released, we had all been using iPhones for many months. We knew how iPhone apps should look and behave, and we could test our apps on our iPhones during development for three months before anyone could sell apps to customers.

But we have very little guidance on how iPad apps should behave, and if we want our apps to be in the store at its launch, we have to do the majority of development without ever running our code on a real iPad (or even having used one).

This leaves a few possibilities for developers:

1. Develop the entire app without using a real iPad, submit the binary to Apple, and have it available on day one. But, having never run it on a real iPad, the app will probably have a lot of issues, and it will get panned in reviews for being buggy while you wait in the very long app-review queue for your updates.
2. Get an iPad on day one, rush home, test the app, iron out any little bugs or inopportune design choices, and submit it to Apple. This doesn’t really give much more of a testing and design advantage over option 1, and you’ll still be stuck waiting in the app-review queue for weeks as every other developer does the same thing.
3. Wait for initial app submission until after you’ve tested extensively on a real iPad. You’ll have the best release, but you will have missed the launch window, which could cost you dearly in revenue and market share. And even when you finally submit, the app-review queue will still be bogged down with people who took the first two options, delaying your presence even further.

All of these options are terrible. Not only are they bad for developers, but they’ll be bad for Apple as initial reviews ding the iPad for the first batch of sloppy native apps.

This is one reason why I suspect there’s something we haven’t been told yet: I don’t think anyone’s iPad-native apps will be available on day one. My best guess is that the iPad will be released with only the built-in apps and iPhone-native app capability. After a few weeks or months, as the SDK gets another revision or two and everyone has solid, universal (iPad and iPhone) apps submitted and (hopefully) pre-approved, the iPad App Store will officially open. This could happen sometime closer to WWDC in June.

I hope it goes something like this, because I don’t want to have to choose between those options.