Software for Windows Phone 7 can only be developed in C#. Software for the iPhone can only be developed in Objective C, C++, C or JavaScript. Why then do I say the iPhone restriction is absurd, while I think the Windows restriction is fine?
In previous columns, I have praised Apple’s AppStore for reinvigorating the small retail ISV market, and the iPad for delivering the attention to a great form-factor, which has languished for half a decade. In this column and in my consulting business, I have singled out for praise Novell’s MonoTouch development stack, which marries the worlds of .NET and Cocoa Touch development. There are vastly more C# developers than Objective C developers, especially in the corporate software development world, and for in-house software, MonoTouch can provide significant flexibility for a company that isn’t sure about the wisdom or cost of a team dedicated to Mac-centric development.
Following the recent announcement of the iPhone 4.0 OS, two restrictive clauses in the new SDK license rapidly leaked out and became public knowledge. While the iPhone has always excluded interpreters and virtual machines, now programs must be “originally written in Objective, C, C# or JavaScript,” and “applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited.” Taken at face value, this would ban tools such as MonoTouch, Corona (a Lua development tool), and Unity3D (a game development tool) from being used for software sold via Apple’s AppStore. (Apps deployed internally within an enterprise do not seem subject to these sections of the license.)
The proximate cause for these new restrictions is clearly Adobe’s Packager for iPhone, which precompiles ActionScript 3 (a.k.a. Flash) projects into native iPhone applications, and is part of Adobe’s forthcoming release of Creative Suite 5. Apple has been very public in its frustration and disdain for the quality of the Flash player on OS X, and Steve Jobs has not given an inch on the prospect of a Flash browser plug-in in the iPhone or iPad.
There is a valid concern about overhead on mobile devices. On our desktops, we’ve gotten to the point where we can develop software in almost any abstraction the programmer cares for. You want everything to be an object, a mathematical function or an S-Expression? No problem! It’s become rare to find a domain outside of games where language overhead spoils performance.
On mobile devices, though, power is at a premium: Battery life is very important to the user experience, memory is constrained and resource consumption is not obvious to end-users (as anyone who’s “degunked” a family member’s machine can attest).
The Flash platform APIs are significantly different than the Cocoa Touch APIs. For instance, in ActionScript 3, it’s the work of a single function call to read the value of a pixel. In Cocoa Touch, one has to allocate a memory buffer, draw into it, and then read the bytes at the appropriate offset. Any decent programmer will keep that memory buffer and manage its life cycle (keeping it around as long if more reading is expected, freeing it when it’s not going to be used for a long time).
It’s not obvious how even a conscientious Flash developer could be as responsible; one reason why people have chosen Flash is precisely because it abstracts away such tasks. Similarly, Cocoa does not have built-in APIs for regular expressions. But here the efficiency equation is likely reversed: Very few developers will, on their own, write string-matching and manipulation code accurately and efficiently.
So while it’s accurate to say that libraries raise efficiency concerns, it’s not a one-way street. Developers use libraries for a reason, and Cocoa developers use third-party libraries all the time (such as for regular expressions!). And while executing syntax trees creates a bright red line when it comes to banning interpreters and virtual machines (a line that is crossed, incidentally, by lots of games, programmable calculators available for sale on the AppStore, and, ironically enough, regular expression libraries), there’s no such line when it comes to defining a “translation or compatibility layer.”
If a regexp library based on Perl’s regular expressions is legal, why not a string manipulation library based on .NET’s System.String class? Or .NET’s System.Collections namespace? At what point does a “library” become a “layer”? That’s a philosophical question, and while I’m as big a fan as anyone of epistemic debates about sorites paradoxes, I find they don’t go over well with clients trying to decide a development strategy.
Truthfully, though, there is an obvious line between the approved languages, other than JavaScript and the alternatives: explicit memory management. The iPhone implementation of Objective C doesn’t even support retain/release reference counting, much less a compacting collector. So by virtue of defending against inefficiencies, the iPhone demands that all applications must struggle with the single most error-prone and dangerous detail in software development.
In short, with no technical justification, Apple has forbidden modern languages and techniques, and thereby nailed open the door to memory leaks and vulnerabilities. This makes the iPhone significantly less appealing as a platform for corporate development. Windows Phone 7 just became a lot more attractive. Oh, and you can use Mono to program Android in C#, too.
Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.
