Original URL: http://www.theregister.co.uk/2010/04/16/does_apple_code_translation_ban_everthing/

Steve Jobs bans all apps from iPhone (or thereabouts)

Code translation verboten. Whatever that means

By Cade Metz

Posted in Phones, 16th April 2010 17:25 GMT

You could argue that the new Jobsian SDK bars developers from writing any application for the iPhone - unless they possess some sort of savant-like ability to think solely in Objective C.

The much-discussed software development kit for the upcoming iPhone OS 4.0 says that native applications must be "originally written" in Objective C, C, or C++, forbidding developers from using any sort of "translation or compatibility layer." If you take this legalese to its logical extreme, it rules out just about anything you can think of.

If you sketch out the idea for an application on a loose piece of paper - or simply dream it up one afternoon while sitting on the living room couch - don't you then have to convert it into Objective C? Do Apple's translation layers include ten fingers, a laptop keyboard, and some very hard thinking?

Apple as Hal

Apple, an artist's representation (artist unknown)

And what if you take an application that was already written in some other language for some other platform and rewrite it for the iPhone? Is that a translation too?

"Translation could mean many different things to many different reasonable people that read the agreement," says Jeff Haynie, CEO and co-founder of Appcelerator, the Silicon Valley startup whose Titanium development platform was sucked into the vortex of controversy surrounding Apple's new legalese. "What about ported apps? Was Yahoo! Messenger originally conceived and written for the iPhone? No, it was originally a desktop app."

It's no surprise then that Steve Jobs' latest effort to raise the walls around his garden has been met with a fair amount of digital hysteria. The world o' web pundits is guessing that the SDK will bar everything from Adobe's Packager for iPhone - a means of, yes, translating Flash script for the handset - to Appcelerator's Titanium to the multi-platform game development kit Unity3D and beyond. Well beyond. Adobe platform evangelist Lee Brimelow even told Apple to "Go screw yourself," arguing that the company is banning applications from its marketplace "solely [Yes, his emphasis. -Ed] because of what language was originally used to create them."

But as it stands, all we have are a few Jobsian sentences slipped into a licensing agreement. "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," are the famous words, "e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited."

They could mean almost anything. And in the end, it doesn't really matter what they mean.

You can use OpenGL. Except you can't

You might also ask if those words forbid something like OpenGL, the industry standard graphics interface that, well, Apple officially recommends to developers. When you write a shader with an OpenGL script, you're not coding in Objective C. And what about XML? asks blogger Alex Blewiitt. JSON? Macros?

We could go on. But we won't.

The long and the short of it is that those few Jobsian sentences don't mean anything at all. Whatever Apple says elsewhere in the SDK, it also reserves the right to bar applications from the iPhone App Store for any other reason it might dream up. The real test of Apple's new policy will come when developers actually start submitting applications. "It doesn't really matter what the legal wording says, because they can always change it," says Haynie. "What really matters is what Apple's intention is...

"What it comes down to is how Apple will accept or reject applications. And that hasn't changed. Apple has always had the ability to reject any app, based on many things that are not even written in the terms of services. Now they're rejecting apps that have 'pad' in the name."

Apparently, Steve Jobs has hinted the new SDK language is an effort to prevent anyone else from establishing a de facto standard platform on top of his own tools - and to ensure that when Apple introduces new APIs, developers adopt them tout de suite. "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," Jobs supposedly said, in a priviate email exchange.

And now that's the standard take among the fanboi elite. "I imagine Apple is interested to ensure that developers always have access to tools that leverage their technology as it evolves. The most effective means to reach this goal is to have just one source for developer tools. Ultimately it is the customer who wins, as they will have access to applications that take advantage of the latest and greatest features of their devices," John Muchow, then man behind iPhoneDeveloperTips.com, tells The Reg.

"As Apple releases, or otherwise makes available new features in current/future versions of the iPhone OS, they are the only ones in a position to provide tools and documentation that align with the technology at the time the technology becomes available."

Fine. Jobs can do whatever he likes with his SDK. And though the change has surely ticked off any number of developers - well beyond Adobe - he can afford to tick them off. Developers aren't likely to depart the platform over the language - at least not in large numbers - and even if they did, there are plenty of others to pick any slack. The iPhone is in the hands of too many people and will reach too many more.

But it's still unclear how far Jobs will go. Is he simply banning the likes of Adobe's Packager for iPhone, which bypass his XCode IDE entirely? Or is he also bringing the hammer down on tools like Titanium? It operates in very different ways. And Appcelerator is not Adobe.

Appcelerator objectified

Appcelerator's Titanium is an open source platform that lets you build native iPhone runtimes using traditional web development tools, including Javascript, html, and css. The idea is that seasoned web developers can build for the iPhone without learning Objective-C, and they can easily use the same code on other devices as well. The Titanium kit provides additional APIs for building native runtimes for Windows, Linux, and Mac desktops and notebooks as well as Google Android handsets.

When Apple released its new SDK, the general assumption was that Steve Jobs had barred Titantium and similar tools, such as PhoneGap. But Haynie is confident that his kit will get the Steve Jobs seal of approval. "We think - based on reading of the wording and our understanding of what it means - that we're in compliance," he says. "We believe that Appcelerator produces really high-quality native applications compiled with [Apple's] languages and technology. There's nothing about what we're doing that avoids that or preempts that or goes against that intention."

True, with Titanium, you're not coding in Objective C. You're coding in, say, Javascript. But the platform invokes Apple's Xcode IDE (integrated development environment), converts the code into Objective C, and then compiles it. "Effectively, what we're doing is machine-generating Objective C and then compiling just as the developer would do if they had originally written in the language," Haynie says. "We're not trying to bypass everything that Apple has set up to ensure quality and performance and things like that."

Titanium taps Apple's APIs. And when Apple introduces new APIs, as it has done with iPhone OS 4.0, Appcelerator works to roll then into its kit in time for launch. "If you bypass the layers Apple has produced, that could be problematic," Haynie says. "But companies like ours don't do that. We use the Cocoa threading system, so any optimizations Apples uses in their layers are going to work with platforms like ours...But if you're bypassing those layers or translating directly to [the iPhone's ARM processor], you're missing optimizations that Apple can put in their own software."

That ARM bit is an Adobe reference. Adobe's iPhone packager does not compile code into Objective C. It compiles directly into machine code. "The way the Packager works is that it allows a Flash developer to compile the ActionScript code down to native iPhone/iPad machine code, in the form of an .ipa file, which is the file that you submit to Apple for approval & inclusion on the App Store," the company tells us.

Adobe says this still takes advantage of Apple's APIs. But Haynie sees it differently, questioning whether Adobe is sidestepping certain tools by compiling code on its own. "Apple has a point here. Any optimizations or hooks they do in their own compilers from Objective-C or their own APIs would effectively be bypassed (inadvertently, probably) by Adobe's machine code generation," Haynie argues.

If Apple tweaked its thread scheduling underneath an API to better handle multitasking, for example, Adobe Packager for iPhone apps may not see the benefit. "Apple could technically optimize for this use-case without the need to get the developer to change code," he says. "They might emit specific ARM machine code to handle this...However, with Adobe emitting their own direct machine code, they would effectively render this optimization or change unaffected."

No Adobe love lost

Is all this just another attack on Adobe in particular? You at least have to wonder. Certainly, Flash is a bigger threat to become a "de facto standard platform" than a Titatnium or a PhoneGap. And for what it's worth: PhoneGap now says it has received confirmation that Apple has not banned its platform outright, though the company has declined to speak to us about the matter.

It's much more fun to think the SDK brouhaha as merely spat between Adobe and Steve Jobs, especially now that Adobe is threatening to, um, file a lawsuit. The enmity between Adobe and Apple goes well beyond the technical arguments. Steve Jobs has already barred untranslated Flash from the iPhone and the iPad, calling it "buggy," littered with security holes, and a "CPU hog." And at the very least, the CPU hog bit is fixable.

In any event, Adobe Packager for iPhone applications will be barred from the iPhone - and the iPad, also slated to use the iPhone 4.0 OS. Titanium apps? Yahoo! Messenger? That app you first drew on the back of cocktail napkin?

It depends how the man is feeling. ®