Gruuuuubeeer! Why do you force us to listen to your reasoned, intelligent arguments explaining the odd language in the new iPhone SDK guidelines outlawing outside iPhone compiling methods, including .NET and Adobe’s own Flash-to-iPhone tools? If we follow Godwin’s law to its obvious conclusion, we can only say that you are a collaborator with enemy forces!
For those of you not following along, the story is this: Apple’s new SDK guidelines state, in no uncertain terms, that you can only use Apple tools to compile and submit iPhone and iPad apps. Nothing else is allowed. To many this is an affront to the general dignity of man and a call to arms. To others, and I suspect many others, it’s not a really a BFD.
Gruber writes:
IPHONE DEVELOPERS: No change. If you’re a developer and you’ve been following Apple’s advice, you will never even notice this rule. You’re already using Xcode, Objective-C, and WebKit. If you’re an iPhone developer and you are not following Apple’s advice, you’re going to get screwed eventually. If you are constitutionally opposed to developing for a platform where you’re expected to follow the advice of the platform vendor, the iPhone OS is not the platform for you. It never was. It never will be.
(And, in one sense, this is good news for existing iPhone developers: their skill set is now in even greater demand.)
He also points out “Microsoft’s mantra was (and remains) ‘Windows everywhere’. Apple doesn’t want everywhere, they just want everywhere good. The idea though, is to establish the Cocoa Touch APIs and the App Store as a de facto standard for mobile apps — huge share of both developers and users.”
In short, Apple is like a car repair place with an open hiring policy. Anyone can come in and become a car mechanic. Heck, you can even get rich doing it. But Apple Car Repair doesn’t want some dude walking in with a rubber wrench and weird screwdrivers stripping the heads off of oil pan screws and breaking more than he’s fixing. Even Steve Jobs, in an email to a developer, admits this. He writes:
We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
In short, if you don’t like his tools, get out of his garage.
The problem here is the ascription of malice to what is, in the end, a business decision. While you have plenty of tools for programming in Windows, you also have plenty of tools for programming under OS X. However, to allow a multitude of frameworks for mobile devices is asking for trouble, especially when Apple’s goal, in the end, is to offer a superior mobile experience on their devices.
Heck, even Windows Phone is limited to a few frameworks and tools. Whereas an operating system can survive some junk programs now and again, to have your phone BSOD is a horror. I actually experienced this on a long drive two weeks ago. I was running a navigation app and it crashed. The iPhone wouldn’t start up and I reset it, while driving, multiple times. Finally, I let it sit, charging, and after almost forty minutes the silver Apple logo disappeared and the phone booted. A phone is a device designed for 24/7 access (AT&T’s network notwithstanding) and letting just anyone come in and pound out some apps is a recipe for disaster.
As a corollary, this control also offers a superior experience for the consumer. Until the iPhone, I never purchased a single mobile app on Symbian, Palm, or Windows Mobile. Ever. Period. Now I buy apps like mad and am looking forward to apps on the iPad. I think this behavior is a massive step forward in a word where mobile programming was often relegated to second tier.
In short, learn Apple’s tools or hire someone who knows Apple’s tools. Just because you like Flash/.NET/C#/COBOL/Pascal/LOGO doesn’t mean Apple has to like it. As horrible as it sounds, Apple is doing this for your own good.