Apple app police anoint un-Flash code translation

Though Steve Jobs has banned code translation on the iPhone and the iPad, the Apple App Store police continue to accept applications built with Unity and Appcelerator's Titanium, two dev kits that convert code from languages not explicitly approved by Jobs.

If there was any doubt that the primary target of Jobs' code ban was Adobe Flash, it's been laid to rest. Nearly.

Since Apple unveiled new iPhone SDK terms of service banning code "translation layers" — "only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs," it now reads — the company hasn't barred a single application coded with Titanium, which converts JavaScript and other web-happy languages into Objective C. "We've had every single app accepted — and there's been a lot of them — up to and including the launch of the iPhone 4," Appcelerator director of marketing Scott Schwarzhoff tells The Reg.

"In fact, we've had more apps accepted since this whole thing started on April 8, than before. So that puts it in the realm of several hundreds, if not thousands of apps accepted in the App Store."

Though Apple released the new iOS 4.0 SDK on April 8 — and began presenting the new terms of service when developers logged into the Apple Developer Center — it didn't begin accepting apps based on the new version of the OS until early June. iOS 4.0 was released on June 21, and the iPhone 4 handset — which uses the new OS — arrived in stores on June 24.

Schwarzhoff points to MTV Network's "Jersey Shore Yourself" and Bud Light and TribalDBB's "High Five League" as Titanium-built apps that have been accepted to the App Store since the SDK change. "The point is that no application has been turned down for use of the Titanium platform," he tells us.

The open-source Titanium is a means of building native desktop and mobile applications using traditional web-development tools, including JavaScript, Python, Ruby on Rails, HTML and CSS. The idea is that seasoned web developers can build apps for the iPhone without learning Objective-C, and they can easily use the same code on other devices as well. The kit provides additional APIs for building native runtimes for Windows, Linux, Mac desktops and notebooks, Google Android handsets, and BlackBerries.

So, with Titanium, you're not coding in Objective C, C, or C++. You're coding in JavaScript or some other web language. But the kit invokes Apple's Xcode IDE (integrated development environment) and converts the code into Objective C before compiling 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," Appcelerator CEO Jeff Haynie has told us. "We're not trying to bypass everything that Apple has set up to ensure quality and performance and things like that."

The company has not received official word from Apple that its kit falls within the rules of the App Store. But it seems the App Store police have given the company their implicit approval.

The situation is much the same with Unity, a platform for building games across multiple platforms. Based on Microsoft's .NET, Unity allows developers to code for the iPhone and other devices using JavaScript and C#. Asked if Apple had rejected any apps built with its kit, Unity pointed us to a recent blog post from CEO David Helgason.

"While we’ve had some reason to believe Unity using C# and JavaScript would be okay, Apple has not confirmed anything and in general very little information has been forthcoming. However, as of today Apple is still approving every game we know of and Apple has recently featured several excellent Unity games in the App Store," he wrote.

This is particularly telling because — contrary to previous reports — Unity does not convert code into Objective C. Unlike Titanium, it converts JavaScript and C# into "heavily optimized" assembly code, which is fed into Apple Xcode, the company tells us.

At the end of April, with his infamous "Thoughts on Flash" letter, Steve Jobs made it quite clear that the new SDK language prevented Adobe from translating Flash script for use on the iPhone. When the SDK was unveiled, Adobe was days away from releasing a new iPhone packager with its Flash Professional CS5 development kit.

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. ®