Inverting the Golden Cage, or a Gift to the Barbarian Hordes at Apple’s Gates.

Note: this post is obsolete.

The now-infamous iPhone / iPad SDK Section 3.3.1 reads:

“3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. 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 (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).”

Now consider how it doesn’t read:

“Applications may only run on hardware sold by Apple and must not be marketed for competing platforms. Applications concurrently ported to non-Apple platforms through an intermediary translation or compatibility layer or tool are prohibited.”

Apple’s competitors could easily smash open the gates intended to keep cross-platform software off the iPhone: by enabling their own platforms to run unmodified Cocoa Touch projects.

There are two basic ways of achieving this end.  One is to fully re-implement the iPhone run-time environment and user interface.  This approach promises to be expensive, unpleasant, and doomed to abysmal failure.  Anyone attempting such a thing would run the risk of being bled to death by lawyers, not only Apple’s, but those of the feral patent trolls preying on it – some of whom might prefer your tender skin to the toughened hide through which they presently suck their nourishment.   There is, however, another way:  code translation.  A hypothetical translator able to convert perfectly ordinary Cocoa Touch source trees into Something Else, consistently and reliably, would spell the doom of the Golden Cage as we know it.  This Something Else ought to be an intermediate representation from which one might produce code for competing pocket computers – perhaps with some graceful feature loss, in the case of well-defended Apple-proprietary features.  (Once your lawyers succeed in prying these treasures out of Mr. Jobs’ strong hands, your programmers can flip a bit and gracefully un-lose the features in an instant.)

That such a feat could be achieved is not in question.  There is nothing mathematically impossible about it, nor would it be especially difficult given several months of an enthusiastic Common Lisp programmer or two.  The far more interesting question is how Apple would react.  Would they attempt to formally prohibit all cross-platform development targeting the iPhone and iPad?  If they do so, they will have at last picked up Microsoft’s torch, and may well pay a heavy price at the hands of government regulators.  The more I think about this, the more attractive this situation seems from the standpoint of Apple’s competitors.  Mr. Jobs would be forced to choose between admitting defeat and being prodded into unquestionably monopolistic behavior reminiscent of the Evil Empire, chancing a “Ma Bell” fate for his kingdom.  For this reason, Adobe (or anyone else who stands to profit from Apple’s demise) ought to seriously consider funding such a project.

You read it here first.

And finally:  once Apple is dead, will a thousand flowers bloom, or a thousand cesspools?  Once the “class genius” has quit the school, who will the D-students crib from?  Might they even contemplate cracking open their virginal schoolbooks?  One way or another, we’ll find out…

Edit 1:

Who said anything about 100% compatibility with arbitrary Cocoa Touch code?  I completely agree that such a thing would require Herculean labors.  But there is no need for it.  All the experiment would call for is a tool enabling programming in some reasonable subset of Apple’s API (perhaps with “comments” containing annotations to help guide the translator.)

Edit 2:

What led anyone to think that the purpose of the hypothetical experiment is to help cross-platform developers?  The real object would be to push Jobs towards explicitly banning ports, which may turn out to be legally-actionable monopolistic behavior.  Did anyone really think that yet-another cross-platform toolkit, however slick, could kill Apple?

This entry was written by Stanislav , posted on Wednesday April 28 2010 , filed under Hot Air, ModestProposal, NonLoper . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

15 Responses to “Inverting the Golden Cage, or a Gift to the Barbarian Hordes at Apple’s Gates.”

  • [...] This post was mentioned on Twitter by Felix M. Cobos. Felix M. Cobos said: "Loper OS » Inverting the Golden Cage, or a Gift to the Barbarian Hordes at Apple’s Gates." ( ) [...]

  • Zoe Azimuth says:

    Go ahead and write it. Writing about a hypothetical translator is cheap, actually it’s worthless. Why don’t you start the ball rolling instead of writing about it. Let’s see some decent CL code unless of course you don’t how to, then you’re just wasting everyone’s time.

    • Stanislav says:

      Zoe Azimuth wrote:

      > Go ahead and write it… Why don’t you start the ball rolling instead of writing about it…unless of course you don’t how…

      My time is worth something. Money, to be exact. To be paid in advance. If you have a credible desire to pony up, we’ll talk. Somehow, I don’t think that is what you had in mind.

      • Zoe Azimuth says:

        Judging by your meaningless blog posts and the number of them, your time can’t be worth that much. Here’s a suggestion, why don’t blog about the progress you’re making on this hypothetical translator–and really put your money where your mouth is.

        • Stanislav says:

          Zoe Azimuth wrote:

          >the progress you’re making on this hypothetical translator

          What makes you assume that I would like to write it?

          >…your meaningless blog posts and the number of them…

          885 days / 45 posts = 1 post per ~20d. avg.

          And best of all: nobody will ever force you to read any of it.
          There is plenty of other, less-meaningless Internet for you to enjoy. Go find it.

  • Jay says:

    Haha “Graceful feature loss” That is awesome.

    If you really want Apple to die, make absolutely awesome apps making the best use of the native features of the OS you’re using and don’t publish them on iPhone OS.

    • SJS says:

      I want *Adobe* to die.

      And after developing on and for the Microsoft platform, I want Microsoft to die as well.

      Oddly enough, making awesome apps that aren’t available in Flash or Win32 hasn’t killed those platforms yet, so I suspect there’s a problem with your thesis.

      All that being said, the point of the article is a good one. Let Adobe contribute some time and money to GNUStep or something instead of whining.

  • Adam Wright says:

    Erm, no. This won’t work. First, doing code translation for Objective C is basically impossible. For one, ObjC is a highly dynamic language, so a lot of flow control relies on runtime information. Two – it’s C damnit, with all the pointer aliasing difficulties this entails. One could write a C interpreter, or just reimplement the Cocoa libraries, but this isn’t going to produce results that run happily on e.g. Android.

    Perhaps more important, you can’t just translate the code – you’d have to port the entire Cocoa Touch user experience. The same Touch responses, the same UI widgets with the same dimensions and look and feel.

    This is all under copyright (and, bleh, patents), and nearly every iPhone app out there relies on a good integration with these native widgets and system conventions. Any that don’t are likely to contain virtually no actual Cocoa usage anyway, and could thus be ported without much effort to any platform. You seem to label this under “graceful degradation”, but if you’re writing *two* source trees anyway (one for the full experience, one for the degraded), why not just factor the common code out to C and have two system interface implementations, rendering the entire experiment pointless?

  • Chip Salzenberg says:

    Well, sure. And you can implement a Turing machine in vi, too. Just because you can, doesn’t mean the results will be fun.

    The relevant libraries are extensive, the details of behavior are vast and numerous… For anything other than a toy application I strongly doubt the result will be worth the effort.

    But I can’t tell you how to spend your free time. Knock yourself out. At the very least you’ll be able to draw crowds at Mac conferences.

  • Enlighenment says:

    I heard that Apple has a patent on “How To Be A Douchebag”.

  • overreaching says:

    You’re overreaching here Stan. My time is also worth money so I’ll only give you a few sentences.

    You’re right strategically about the consequences were such a translator implemented.

    The thing about it taking a couple of common lisp programmers a couple months is where the typical common lisp mindset creeps in: you know makes you arrogant, and what you don’t know you underestimate.

    Even a cursory examination of the likely target platforms indicates that there’s nothing like a clean mapping from iPhone widgets to native widgets. This means you’re going to be reimplementing all of cocoa touch, which means you’re back to reimplementing the runtime, which means replicating most of a software stack that’s been under continuous development for 20 years by mostly-unsung but frequently top-notch developers.

  • Jason Glow says:

    There’s no way Apple can police this. Companies are going to talk about developing in objective c and just continue using the same technology and pray they won’t get caught. This happens all of the time and Apple isn’t able to catch this. It’s not a risk I would take though.

  • Eas says:

    I’m sure that Apple would hate this, but perhaps not for the obvious reasons.

    It might make it easier for developers to port existing iPhone applications to other platforms. I’m sure they wouldn’t like that, but they’d still hold the advantage as having the best platform for running CocoaTouch apps.

    It might make it easier for developers to create new multiplatform apps that ran on the iPhone OS who would have otherwise avoided the platform. That sounds like a good thing for Apple, and again, they’ll be the best platform for such apps.

    The thing Apple would hate most, if this caught on, is that all those CocoaTouch apps running on other platforms would become a drag on the platform. As it is now, Apple sets the pace and direction of innovation. When they release new APIs, they can be sure that it’s available on new devices immediately, and spreads quickly through the installed base, both of which make it sensible for developers to adopt the new APIs quickly. If there are a bunch of developers who distribute their iPhoneOS apps on other platforms via a CocoaTouch comparability layer, then Apple looses influence. Those devs might still adopt the new API for their iPhone app quickly, and then wait for the translation layer to be updated to bring it to other platforms, but they may decide to hold off until the translation layer is updated, but that could take a while if the alternative platforms lack the necessary functionality.

    Of course, I have my doubts that it would ever get to that point. The WINE project has been working on translating the windows API for over a decade, and while the results have been impressive, its still pretty niche.

  • Perry The Cynic says:

    Interesting. So let’s say someone makes a Truly Magical translation device that lets some useful subset of iPhone Apps run on platform X.

    Apple sells iPhone hardware. For Apple to care about your scheme, lots of users must stop buying iPhones and buy X phones running iPhone Apps instead. If that happens, Apple can (a) loose their lawyers forbidding X from running iPhone Apps, leading to its doom (that’s your plan, right?). Or it could (b) drop the price of iPhones until iPhone+iPhone Apps is cheaper than X phone+iPhone Apps, adjusted for coolness and ecosystem lock-in (and lawyerly FUD, and patent threats, and…)

    Now normally you’d say that X phone might be some cheap HTC thing with razor-thin margins that Apple can’t undercut. Except now it has to run some meaningful iPhone App subset without totally sucking, which likely requires that X phone is more powerful than the iPhone it’s trying to replace. Apple’s pretty good at making phones now, and it’s got larger volumes. And a lock on the flash market, and on parts of the display market. Sure, X phone can try to target some older, slower version of iPhone, but then Apple just has to keep selling that older, slower version for a low, low price While Supplies Last. (Look up “price discrimination.”) Remember Apple’s hardware treadmill never stands still.

    And look what that’s accomplishing: Apple, by adjusting its price point, can pretty much decide how much business they lose to X phone. They can keep X phone in business but keep it from really hurting them. (Sound familiar?) And X phone is now critically dependent on Apple’s software stack. So company X is in a position where they compete for hardware margins with Apple while being dependent on Apple for continued software support; and they can’t win a price war with Apple because Apple has (a) lower unit costs given equal performance, and (b) $48bn+ in their war chest.

    Any takers?

    Take-away point: Apple cares about control over its software stack, and you can’t take that control away by emulating or cloning it, unless you can get third party developers to start using non-Apple software that Apple can’t control. Like Flash, say. (See?) Apple worries about third party developers making more money off another platform. That’s loss of control. So it will make sure they never do, even if that means lowering margins. At least that’s my bet. I’m also betting on developers going after the money, not principles. They’re farm hands, not philosophers. :-)

    — perry

  • [...] This post was mentioned on Twitter by Web Startup Group, James Williams, kicauan, Technojobz, VIP Emp and Startup and others. VIP Emp and Startup said: Inverting the Golden Cage, or a Gift to the Barbarian Hordes at Apple’s Gates. [...]

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">