By John Gruber
Back in June, I didn’t think this would happen. I was wrong. There was never any question that this is a big market, the question was whether Apple wanted a part of it. The answer, clearly, is yes. The enterprise features announced today are serious and difficult.
The tools look awesome — far better and more advanced than what most Mac developers were expecting. Pleasant surprises include Interface Builder support and a full-fledged desktop simulator. And the API has a name: Cocoa Touch. (As suggested by Neven Mrgan on Twitter, perhaps we should start calling the iPhone apps “Safari Touch” and “Mail Touch” rather than “MobileSafari” and “MobileMail” when you need to specify the iPhone, rather than Mac, versions.)
The tools are, unsurprisingly, Mac-only. It’s a new version of the same Xcode and Interface Builder (and performance tuning) apps that Mac developers use today. This has the potential to do for Windows developers what the iPod did for Windows users — move them to the Mac.
The games that were demoed today look pretty cool. Reports from people in attendance are gushing. The unique control options — no traditional buttons but a 3D accelerometer and multi-touch screen — make the iPhone analogous to the Wii, in that it opens up new concepts in game UI design. This also opens the iPhone to a new market — those who don’t want to buy a handheld that doesn’t have cool games.
Apple’s 30/70 split with developers is steep, but initial reaction from the developers I follow on Twitter seems to be positive. Paul Kafasis of Rogue Amoeba told me via IM, “70%? That’s… that’s… livable,” which seems to sum up the consensus sentiment.
There is no option to circumvent the App Store. A developer cannot, say, make their iPhone app available for download over the web, and have users copy it over to their iPhone through iTunes by hand. The App Store does allow for free apps, with all hosting costs covered by Apple. But, I suspect, developers won’t be allowed to deliver a “free” app through the App Store which requires a registration or license through the developer’s own web store.
My question, though, is how will this be enforced technically? If developers can install on their iPhones the apps they’re working on, what will stop users from doing the same? I’m guessing it’s tied to digital certificates, but that’s just a guess. There must be something, though.
The reasons developers are willing to accept a 70/30 split are simple: convenience and exposure. Apps sold via the iPhone App Store will be far easier to register and install than apps are for the Mac. Once you’ve registered for an iTunes Store account, your credentials are saved. No credit card numbers to type in, no emails to wait for containing serial numbers. It looks as easy to buy these apps as it is to buy songs. And the exposure of getting listed in a store that’s available to every iPhone user in the world is tremendous. It’s like Apple’s Software Downloads web site, but with one-click Buy buttons.
The $99 fee for getting your app listed in the store is a no-brainer. A bummer, perhaps, for the student set, but I suspect it’s intended as a bozo filter to keep the process from being inundated with glorified do-little “Hello World” apps. (I’m almost certain even freeware apps require the $99 listing fee — although that fee is per-developer, not per-app.)
In short, what developers lose per-transaction from Apple’s 30 percent take, they can more than make up for in volume. This is going to be a gold rush.
Speaking of which, I’m not sure I understand this $100 million iFund for iPhone software development, but it sure is a lot of money. Presumably this is for startups with very big ideas for iPhone software.
Jobs was asked in the Q&A whether a VOIP app would be permitted, and he said yes, for Wi-Fi, but not for EDGE. Just how these sort of restrictions on EDGE use are going to be adjudicated and enforced aren’t clear, though. Given that Apple is emphasizing the location-aware features in the SDK, it seems as though access to EDGE must be at least relatively open. The restrictions are likely based on bandwidth needs, but that seems tricky to enforce once an app is out in the wild.