Cross MonoTouch off the list
Published by marco on
Apple presented the iPhone OS 4.0 late last week. The new version includes hundreds of new API calls for third-party developers, including long-sought-after support for multi-tasking. The changes extended to the licensing agreement for iPhone developers, with section 3.3.1 getting considerable modification, as documented in the article, Adobe man to Apple: ‘Go screw yourself’ by Cade Metz (The Register). That section now reads:
That doesn’t sound too good for Adobe, which had planned to allow direct compilation of iPhone applications from Flash in CS5. And it doesn’t sound too good for MonoTouch either, which allows developers to write iPhone applications using the .Net framework and the C# language. The license for iPhone 3.2 prevented applications from using interpreters or virtual machines, but both CS5 and MonoTouch steered clear of those problems by compiling directly to iPhone OS machine code.
The new wording in section 3.3.1 seems to be Apple’s attempt to exclude these technologies with about as much subtelety as a five-year–old making up new rules during a game he invented. The official response, MonoTouch and iPhone OS 4, is understandably upbeat: they’ve already invested way too much time and effort to give up now. Their optimism that “[a]pplications built with MonoTouch are native applications indistinguishable from native applications” (whatever that means) seems suspiciously desperate since MonoTouch applications are written against the .NET framework in the C#-language, which means that they are most certainly not “written in C, C++, and Objective-C”.
Maybe the MonoTouch project will continue to be able to build iPhone applications that have a hope of being accepted by the iPhone App Store. But the rewording of section 3.3.1 puts the power to discontinue support wholly in Apple’s hands. Developers would be silly to get on board with MonoTouch now without a far more explicit show of support from Apple. MonoTouch is putting on a brave face and promises that “[s]upport for iPhoneOS 4.0 on MonoTouch will be arriving soon.”
A typically well–thought-out article, Why Apple Changed Section 3.3.1 by John Gruber (Daring Fireball) details what the new wording means for Apple. And the answer, as usual, is control. It “makes complete sense” from Apple’s perspective of “ruthless competitiveness”. Apple is using the popularity of its platform to force developers to only spend time developing for Apple’s platform instead of for multiple platforms simultaneously.
“Flash CS5 and MonoTouch aren’t so much cross-platform as meta-platforms. Adobe’s goal isn’t to help developers write iPhone apps. Adobe’s goal is to encourage developers to write Flash apps that run on the iPhone (and elsewhere) instead of writing iPhone-specific apps. Apple isn’t just ambivalent about Adobe’s goals in this regard — it is in Apple’s direct interest to thwart them.”
There are aesthetic arguments to be made that cross-platform applications sully an operating system. There are very few of them that are truly well-integrated—and those that are take a tremendous amount of time, patience and versions to get that far. On the OS X platform especially, it’s incredibly easy to spot applications that were made exclusively for OS X and those that were ported from another operating system. It’s truly like night and day. Preferring native applications, however, is a good deal different than banning non-native ones. As a C# developer with a large library of code I’d like to use, I can no longer assure clients that an iPhone application is easily achievable—not without spending a lot of time and money learning Objective-C, the XCode toolset and the Cocoa APIs. Jobs and Co. would argue that I have no business developing applications for a platform without an intimate knowledge of its APIs, but that’s philosophical until they see the end-product.
Simply banning a procedure for building applications because the end-product may be unsatisfactory seems arbitrarily iron-fisted. Apple has always reserved the right to determine which Apps show up in the App Store and which do not. (As of this writing, Apple has been “evaluating” Opera Mini for the iPhone for almost 20 days.) That’s why Gruber’s analysis probably does get the real reason right: Apple’s doing it because (A) they can and (B) they retain more control and (C) most of their users don’t care one way or the other and (D) there are enough iPhone developers willing to follow Apple’s rules and make mountains of money for Apple.
Backing up this impression is an actual, honest-to-God response from El Jobso, as documented in the post Steve Jobs’ response on Section 3.3.1 by Greg Slepak (Tao Effect), where Jobs says that “Gruber’s post is very insightful” and goes on to say that Apple prefers native applications because:
“[…] intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”
As discussed above, though such layers may produce sub-standard apps—and often do—one does not necessarily follow from the other. That is, Jobs is merely hand-waving, arguing that a decision made for cut-throat business reasons was made in the interests of quality. There will always be developers writing bad software with Apple’s tools and there would have been developers writing insanely great software using CS5 or MonoTouch.
Apple actually already had what could be considered a user-friendly and customer-oriented program in place: They were able to reject bad applications individually. Is Jobs arguing that cross-platform tools were creating so many bad applications that Apple was losing profits just from the time and effort involved in rejecting them? Or does Jobs fear the flood of Flash-to-iPhone applications descending on Cupertino with the advent of CS5?
Maybe Apple will bow to pressure and modify the section again—it wouldn’t be the first time a company tried to get away with something and had to backtrack. In the end, though, Apple can do what it wants with its platform—and it plans to.