Randomize

Apple has been getting a lot a grief this week for changing their iPhone / iPad SDK Section 3.3.1 to say the following (emphasis added):

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

I’m mostly agnostic about this, or at least I have three separate horses in this race:

• I’m a .NET developer by trade, so any tools that bring C# and VB.NET to another platform is awesome for me (I’ve long forgotten good ol’ C++ since college, and Objective C offends my sense of good use of punctuation).
• I’m an art photographer on weekends, so I live and breathe Adobe Lightroom and Photoshop.
• I’m a Mac fanboy. I switched out of curiosity when Apple moved to Intel, and I now own 3 Macs, 2 iPhones, and now an iPad (aka “Precious”).

Apple has a dozen reasons for their change in policy, including:

• Platform innovation – the desire to not allow third parties to weigh down the progress of a new, fast-moving platform with slowly-released, feature-limited translation layers.
• More developers in the Mac ecosystem – keeping developers on the Mac means more developers owning Macs and learning Cocoa and Objective C. Apple is betting that the incentive of the iP* market is strong enough to pull developers over. And once developers are there and learn the OS X / Cocoa / Objective-C world, writing apps for the iPad’s big brothers (Macs) isn’t much of a leap.
• Old rivalries – hitting Adobe where it hurts after Adobe’s half-hearted support of Apple’s devices over the last decade or so, and nipping in the bud Adobe’s product, which would only create a world of neutered Flash-tastic garbage on the App Store.
• User experience – Flash sucks. Touch screen or not, it’s best uses are video, virtual farming, and obtrusive advertising. The bugs, security issues, privacy issues, non-native UI, performance… who would wish that on users? (Granted, HTML5 has limits, including poor tool and browser support, even from Apple’s own web development tools and desktop browser.)
• Streamlined application review – Apple’s Stalin-like grip on application approvals requires them to probably have rooms filled with software developers looking through submitted applications, running them through lints and unit tests and human code-sniffing to separate the wheat from the chaff. I support that dedication to protecting their application marketplace, though (sidebar) I do think that App Store being the only way to install applications is anticompetitive and should be challenged in court. But if they are going to keep the bad apples out of their App Store basket, they need to be reviewing clean code in familiar, XCode-native languages.

But I think there’s a point that’s being missed in the debate:

Apple’s overall requirements can be met as long as what you submit to them is clear, non-obfuscated, commented C, C++, or Objective Code.

In other words, “originally written” is really none of their business, so long as the code they receive is straightforward and “looks like” someone did write it in native C, C++, or Objective C.

Code translators have been around for decades. It used to be relatively common practice (sorry, been out of the *nix dev space for awhile) that “compilers” for oddball languages (and some common ones like COBOL and Ada IIRC) were merely pre-processors that spit out C or C++ code for cc/gcc.

Granted, code converters traditionally produce slop code. They add redundant and silly code to flatten abstractions. They lose the original comments and variable names. They require libraries whose only purpose is to make the native APIs more accessible to the other language. They don’t necessarily make the best decisions.

But there’s no reason someone couldn’t come up with converter for, say, C# to Objective C. Rather than trying to hide the Cocoa Touch APIs behind a feature-limited set of Adapters, it should expose Cocoa in as native a way as C# can muster, so the developer has to learn the “zen” of Apple development. Thus, they stay “close to the metal,” but can continue to use a more familiar language (no +this, -that yuckiness).

This is a tough problem for some would-be contenders like Adobe Flash, since their development tools abstract the hell out of the platform so much, but would allow for a wider developer audience who don’t want to have to learn a new language, new IDE, and new base libraries all at once.

MonoTouch, from what I can tell, goes two steps too far. Hiding NSString and NSArray and the like is one thing, but trying to expose the Cocoa Touch APIs with shims that look like the .NET BCL creates the exact sort of situation I think Apple is trying to avoid. And, at least from what I can tell, it is a true compiler and produces bytecode, not code that can then move into the Apple toolchain. On the plus side, they do use the UIKit, so in the look-and-feel department, users can’t tell the difference.

If someone created such a converter, it shouldn’t be called a compiler or a cross-compiler, it would be more of a pre-processor, a very fancy macro language. In the end, it’s just inline function magic and syntactic sugar that allows C# developers to wade into Mac developer pool rather than being required to jump in head-first. (I think garbage collection and the nuances of the type system would be the hardest parts of C# to reproduce in clear Objective C, but I don’t think it would be impossible. But I digress.)

Like I said, Apple gets what they want:

• Developers are working directly with the APIs, even using another language. When Steve Jobs gets on the stage and talks about some new feature of CoreGraphics, developers won’t be sitting there wondering what part of System.Graphics he’s referring to.
• Developers still need a Mac with XCode to compile for simulations and tests on non-jailbroken devices.
• Apple still wins the moral victory over companies who would only offer a neutered, watered-down platform, especially companies like Adobe, who have a habit of only grudgingly updating their applications long after Apple has put old APIs out to pasture.
• Users win, since there’s no translation layer to hinder performance, and applications won’t be giving them an unfamiliar, buggy, non-native, “not quite right” experience.
• Apple retains the ability to effectively and efficiently review code coming in from developers, rather than getting cross-compiled binary crap from Adobe Flash, or 100 layers of abstraction from something like MonoTouch.

But most of all, developers aren’t locked into their current tools. A quality code translation means developers can take off the training wheels and start up XCode any time they want. Since they would still be using the “real” Cocoa Touch APIs, they wouldn’t be shackled by someone else’s outdated or incomplete interpretation of those APIs.

Apple needs to understand that a quick jump and a tight lid isn’t the only way to boil a frog.

Speaking as a developer myself, it hasn’t been the Cocoa framework that has kept me from developing for the iPhone, or having to learn XCode, or having to learn Objective C. The non-starter for me has been the combination of starting all three from scratch! I don’t have that sort of spare time, I have 100 other obligations and hobbies and personal projects.

The same goes for projects at work. I’d love to create a quick iPad-native version of some of the intranet tools I’m responsible for. There are probably hundreds of projects around the company that could make use of a mobile device like the iPad for data collection, but nearly always in offline-only environments. But no combination of projects has the time for me to jump off into the deep end, I need to be able to exploit the tools and knowledge I have in the .NET world to produce working applications with minimal overhead.

Give me the ability to tinker in C# and MonoDevelop and then test the generated code in XCode, however, and I might actually have time to learn Cocoa. Once I’m comfortable, I might even switch to Objective C, since I enjoy learning new languages (we programmers are masochists), and once I do that, I’d probably want to fire up XCode rather than compiling from the command line.

Hopefully someone will show Apple what a high-quality O-C or C++ translation would look like. Ideally, Apple’s code-screeners wouldn’t even know the difference. And that’s how everyone wins.

(Footnote: If Adobe would create a Flash compiler that compiles to HTML 5 and JavaScript that runs on WebKit and add some XCode-compilable stubs to manage state and browser windows, they too would be able to meet the letter of Apple’s law. But since that would prove that HTML5 is just as capable as Flash, I’m not going to hold my breath.)

(Edit: I wan’t aware of Unity3D except by name, since I’m not a game developer, but it appears their product does produce real Objective C converted from C#. From what I can tell, it still puts developers behind a shield that protects them from direct API access, it’s one step closer to something Apple should allow. Especially for games, where there’s not much use for native UI widgets, thus limiting the impact on user experience.)

(Edit 2: Apple’s approval of Opera is also a weak but good sign that they aren’t against bending their own rules, since Opera doesn’t use WebKit and has its own JavaScript interpreter.)