Apple app police anoint un-Flash code translation

Murder by Jobs

"We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform," Jobs wrote, calling this the number-one reason for banning Flash from the iPhone. "This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms.

"Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms."

Like Unity, Adobe's iPhone Packager does not convert code into Objective C. It converts it straight into machine code. But unlike Unity, it bypasses Apple XCode IDE as well.

Appcelerator's Haynie argues that Adobe crosses a line his company doesn't. "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."

Adobe says this still takes advantage of Apple's APIs. But Haynie questions whether Adobe is missing certain software tweaks by compiling code on its own. "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," he argues.

If Apple tweaked its thread scheduling underneath an API to better handle multitasking, he says, Adobe iPhone packager 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 explains. "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."

The same might apply to Unity — though the company says "it’s easy to drop into Objective-C code to access fresh APIs." Unity's Helgason calls this "the best of both worlds."

In any event, neither Unity nor Titanium can take advantage of brand new Apple APIs unless Unity and Appcelerator specifically update their kits to do so. Haynie argues that when Apple introduces new APIs, he and his team work as fast as they can to accommodate them, but there's will always be a gap.

And yet Apple appears to have no problem with either Appcelerator or Unity. It certainly appears that — as so many suspected — Jobs was merely interested in keeping translated Flash for the iPhone. In the wake of the SDK change, Adobe announced it had ceased development of its iPhone packager.

That said, the unwritten rules of the App Store could change at any time, and Unity is working on a contingency plan should Apple start banning apps built with its kit. This "plan B" involves switching all development to C++.

"We are working on a solution where entire games can be created without any .NET code," Helgason says. "In this proposed scenario, all the scripting APIs will be exposed to and can be manipulated from C++. This is of course not ideal as there are thousands of code examples, snippets, and extensions created by the community that can no longer be copied into your project, .NET assemblies can’t simply be dropped in, and C++ is more complex than JavaScript or even C#. But honestly, it’s not as bad as one might imagine."

Well, it's certainly not as bad as Adobe's plan B for the iPhone packager. ®