Apple locks down its platform just a little bit more

How much money is enough? “Just a little bit more”, said J D Rockefeller; and Apple is taking a similar line with respect to control of its mobile platform. It is no longer enough that all apps are approved by Apple, sold by Apple, and that a slice of any sales goes to Apple. It now wants to control how you make that app as well, stipulating the tools you use and prohibiting use of others:

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine.

On the face of it, bad news for third-party companies like Adobe, whose Flash to iPhone compiler is released tomorrow, Novell’s Monotouch, or Unity3D:

JavaScript and C# scripts are compiled to native ARM assembler code during the build process. This gives an average performance increase of 20-40 times over interpreted languages.

What is interesting is not only the issue itself, but the way debate is being conducted. I don’t know how Novell is getting on in “reaching out to Apple” concerning Monotouch, but as far as I can tell Apple introduced the restriction by revising a clause in a contract shown only to paid-up iPhone developers and possibly under NDA, then seeing if anyone would notice. Now that sparks are flying, CEO Steve Jobs is participating by one-line emails to a blogger referencing a post by another blogger, John Gruber.

Further, his responses do not altogether make sense. Gruber’s post is long – does Jobs agree with all of it? Gruber says that Apple wants the lock-in:

So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage.

Probably true, but not the usual PR message, as lock-in is bad for customers. How much are inkjet cartridges? I suspect Jobs was thinking more of this part:

Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy.

As it happens, I think Gruber, and by extension Jobs, is wrong about this; though it all depends what you mean by the output of a cross-platform toolkit. Firefox? NeoOffice? WebKit, as found in Safari? Jobs says:

We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

Well, we know he does not like Java – “this big heavyweight ball and chain” – but there are many approaches to cross-platform. In fact, I’m not even sure whether Jobs means technical layers or political layers. As Gruber says:

Consider a world where some other company’s cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.

The point is: we don’t know what Jobs means. We might not know until apps hit the app store and are approved or not approved. It is a poor way to treat third parties who are investing in your platform; and that was one part of the reason for my initial reaction: it stinks.

The other reason is that I enjoy the freedom a personal computer gives you, to install what you want, from whomever you want, and the creativity that this inspires. At the same time, I can see the problems this has caused, for security, for technical stability, and for user experience. Personal computing seems to be transitioning to a model that gives us less control over the devices we use, and which makes a few privileged intermediaries more powerful and wealthy than anything we have seen before.

In the end, it is Apple’s platform. Apple does not yet monopolise the market – though my local supermarket has iPods in all sorts of colours but no other portable music player on sale – and the short answer is that if you don’t like the terms, don’t buy (or develop for) the product.

As Apple’s market share grows, the acceptability of its terms will lessen, and protests will grow louder, just as they did for Microsoft – though I hesitate to make that comparison because of the many differences between the two companies and their business models. Having said which, looking at Zune and Windows Phone 7, Microsoft seems to like Apple’s business model enough to imitate it.

10 thoughts on “Apple locks down its platform just a little bit more”

  1. Firefox and NeoOffice argue against for your point. They suck.

    Besides, I think Steve’s greater point is a reference back to the days when CodeWarrior dominated Mac development. Apple would come out with new OS features and everyone would have to wait for CodeWarrior to support the feature set.

  2. I will concede several points that have been made over the last few days among the blogosphere;

    1. Apple is targeting Flash and attempting to eradicate it from the Internet.
    2. Apple doesn’t feel that large run-time layers such as the JVM and CLR belong on a mobile device.
    3. Apple wants to ensure that they have exclusivity to many mobile applications. By imposing the requirements, it will markedly increase the development costs for mobile application vendors that want to support several mobile platforms such as Android, WP7, Blackberry, etc… Since Apple is in the dominate position, these vendors will likely choose the platform with the largest user base and overall cache’.

    The *problem* I have is the manner in which this is being done. They seem to have decided that the “nuclear option” is a better approach than more surgical strikes. The collateral damage and fallout could eventually backfire.

    Another issue is that overly broad wording of this clause. Based on the wording, a C/C++ compiler (not GCC) targeting another platform could be made to target the iPhone, but *not* a Pascal compiler that could share the same code-generator and portions of their RTLs.

    Also, the wording is so broad in this section:

    “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)”

    Does this mean that I cannot create my *own* intermediate layer for abstracting certain OS functions? If I were to use C++, which cannot directly use ObjectiveC objects, I could not create a C++ object layer for the CocoaTouch framework for easier consumption by C++? What if I did something similar with raw C code? This is reaching down into how *I* choose to write my applications! Do they mean I cannot use a third-party framework that makes using some Apple API easier? Does Apple feel that their APIs are so perfect that they’ve take a Biblical stance such that “you cannot add or take away”?

    Next, how is Apple going to enforce this? By reverse engineering, decompiling, or “attempt to divine the original source code” for *my* code? Uh, sorry! I’d DMCA them in a heartbeat if they started doing that! They’d have no qualms about doing that to me if they felt I was doing the same to their code.

    Of course the pedants are going to simple say, “fine, nobody is forcing you to develop for their platform.” That is true, and I would not want it any other way. I think this post sums up my feelings on that point very well ( However, my point is that I see that *any* developer for their platform that is even using their tools (XCode) and is playing by the “rules”, can *still* run afoul of this clause! By simply using some internally or externally developed coding abstraction (ie. “an intermediary translation”) over any Apple APIs, they run the risk of drawing Apple’s ire. Simply calling a function that in turn calls an Apple API, is an “intermediate translation” in the strictest sense of that statement. This clause is so overly broad that to divine any “spirit” from it is bound to make many lawyers very wealthy.

    The pragmatist in me wants to view this clause as simply trying to exclude all the x-plat frameworks out there. However, I’ve been involved in way too many Intellectual Property disputes in dealing with patents and copyrights, that I know exactly how lawyers tend to view these kinds of things. I also know that it is a rare lawyer that truly understands both the legal/contractual aspects as well as the deeply technical. As long as Apple is the “golden boy” of the mobile space, they have an implicit “license” to behave in this manner.

  3. @Allen thanks for spelling out some of the difficulties in interpreting this clause, and its implications. I hope Apple will at least have the decency to clarify them.


  4. I really hope Apple will clarify and come to some sort of senses. I can empathize with the middleware aspect of it all. I really don’t like middleware. Application should be properly targeted for the platform, the UIs should be specifically tailored for the application at hand. That is why I often express I don’t like web UI:s, they abstract away the platform and the hardware and force the developer into a request/response kind of workflow.

    I guess it comes down to; if you think the platform is important and should shine; or if you think the function is more important and work decently across multi platforms. (if you neglect the broader points of freedom of choice how to create something)

    I think the platform should shine, with a specifically platform targeted code for the UI and with the business logic in platform independent code if you wish.

    That said, there are some really good middleware out there, such as MonoTouch and Unity3d (and many others for other platforms), that actually are better than Apples own creations. I don’t think it should be up to Apple to decide what tools are used to create something. If they really do this to get quality applications, then they _already_ have the tools to enforce that, they own, literally in all senses, the quality of the App store already. They are free to reject applications they don’t feel
    merge with the platform if they don’t believe the market will reject them fast enough. Perhaps a better rating system would benefit them as the customers would be better informed.

    There is absolutely no truth to the fact that applications would be of higher quality had they been written in C++/Objective C. Well there is one thing, I guess perhaps, as the level of entry is higher you potentially will lose a lot of developers that just don’t meet the bar. And perhaps that is what they hope for happening, just having the elite developers developing for them (the VB syndrome in reverse, a language for the masses gets the masses). So you will potentially have better written applications, but will they be as innovative? It fits with Apple’s elitist view of things.

    The other thing they might be aiming at is that they don’t want Adobe or Novell to have control over what innovation is happening on the platform, there is some merit to that, but again, there is no guarantee the developer will adopts your new API:s anyway, the only thing that is for sure is that no middleware will block it at least. But then again, middleware such as MonoTouch give complete access to the platform if you wish to, one of the finer strengths of the CLR/C# stack is that escaping the sandbox is easy, compared to java, you can if you wish, make the platform shine. And wouldn’t developer abandon a middleware that isn’t keeping up, giving that the API Apple add are actually APIs the developer wants to use? They best way to force middleware out is to innovate at a pace they can’t keep up with so people get fed up with the middleware, and at the same time developing your tool chain so that it is at leas as appealing as whatever you’re are using.

    And if they really want to decide this, and not win on merit, I hope alot of developers will abandon the platform. Because I doubt the users care either way or the other. They want quality in any way they can get it, but if no one is developing…

    I mean, heck, we do code generation in C++, but with a java and a ruby engine to generate boring stuff (from a DSL to C++ (or whatever language we need). That would not be acceptable any longer..

    I could just hear the outcry technobloggers and the media people would cause if this was actually Microsoft doing this and not Apple, but now it is Apple and the world is biased equally much to the good side of Apple as they are to the bad side of Microsoft, and this goes mostly silent so far.

    As someone mentioned what if Microsoft said iTunes may not run on Windows, it wasn’t written in X language, with X tool. And then when Apple complies, they reject the Application because it is too similar to Zune…. Would Apple’s iPhone been as popular had not iTunes been on Windows? Likely not, will the iPhone be as popular if they limit things, likely not.

    Would Apple’s MacOS be as popular among designers had it not been able to run Adobe CS? Likely not, would quite a lot of people switch if Adobe delayed launch of CS suite for Mac by 9 months each time? Potentially. Would it be good for Apple, no, would it be good for Adobe, no, would it be good for the end users, no.

    If you want applications to blend with your platform, they state that in your TOS instead, now it just sounds like you want to sell more Macs. (Which btw MonoTouch /Unity requires already, that’s how tight they integrate for being middlelayers, they are more like enhancers if you ask me).

  5. @Niclas,

    I was not trying to address all the usual “middleware” suspects, but rather trying to point out that through the course of the normal development process, some “middleware”, as you call it, is created. This is simply as an artifact of developing a well designed application. It is not created by some highly visible third-party such as Unity3d, Corona, or even MonoTouch, but by the development team creating the intended application itself. Many developers will create their own sets of libraries and frameworks as a way to better maintain and develop their own applications. This “middleware” is core to how they build their application(s).

    Suppose there is a third-party out there that creates Objective-C (or C or C++) libraries that provides a better encapsulation of some documented Apple APIs. Both these third-parties are locked out of this market because the developers for the platform are excluded from even using them.

    Of course, many will simply remain in denial and say, “Surely Apple would allow that!” However, a strict interpretation of the wording is so broad that it could easily be used by Apple as a hammer to smack-down any use of third-party libraries as they see fit. Especially if they start seeing these libraries show up on other platforms that provide similar functionality.

  6. @Allen

    Yes, I agree with you. My post was not to oppose yours, as I said, in my team we use alot of code generation techniques, it is just good practice (given that the first practice should be to ponder why you need to generate code at all). Any such generation would be illegal. Normally you external libraries for XML parsing, maybe a DI helper, some logger helper etc, maybe even a framework for UI metrics and crash dump handling, all that would be on the less legal side.

    But this isn’t about technical matters, apple isn’t doing this for its technical merits. It is doing this because it enhances their business model, and it does, they have already reached out to the media mongoles through the iPad, a protected disribution engine that can deliver news and media in a way that ressembles how it used to be delivered in a device that people already are accustomed to pay to use, and pay a lot.

    They want full control of their platform, they want to dictate and not be dictated by Adobe or anyone else. In the end, end users don’t care as long as their experience is good. They don’t care if we can’t use certain development techniques. There will still be enough developer willing to tap into the money flow of the iPhone enough to use whatever is provide and sell a bit of their soul.

    They have almost nothing to lose and a lot to gain. Again, they are Apple, not Microsoft, they are right to do this.

    I mean, look at all the crap apps on App store, I don’t want that, go Apple go. Problem is, it is the wrong way, morally, to go about this I think..

    This is actually one of Microsoft’s biggest problems, there are too many crappy applications out there, for a phone this is even worse, it isn’t the application that is crapp, the perception is that the Phone is crappy. Sony Vaio comes with so much bloatware that it reflects back to Windows being crappy.

    How do you keep both camps happy?

    You can try (Microsoft OEM style), or you can instead bet on the camp that is willing to invest more time as they will be more devoted. Raise the entry bar, raise the cost of starting development, make sure they need your platform to do so.

    Who will produce the most innovation, very hard to tell, but I am fairly sure the lowest quailty apps/experiences will not be in the Apple camp, the average score will likely be much higher which is probably more important than having the one off a hundred top score application.

    Again, end users and the market won’t come to the rescue here, because they don’t care. Question is, will FSF and all the other pro freedom speaker be as loud about this as they should if they are consistent, or are they under the Apple spell. Media is already under it, it will flare up and die quickly me thinks. I mean, they are doing this for quality, who doesn’t want quality, if I was the New York Times I surely would want New York times to look great on iPad and not like kindle on Mac…And while you’re at it, this firefox thing never really felt like an Apple experience, I want the red pill…

    Some might even be happy about it, if you think you are the elite developer shop you might even applaud Apple right now, squashing competiton for you, increasing your visibility on the App Store thus increasing your profit, what’s not to like? At least til the day comes when apple changes the play field again and it hits you without warning (not that Adobe wasn’t warned, but MonoTouch and Unity3d etc surely weren’t).

    I hope Apple comes to their senses and clear the FUD they spread.

  7. Forgot, why do you think they decided to change the TOS after the iPad and just days before Adobe CS5.

    I don’t think it is an accidental chain of events, spellbind media so you can release some dirt in your backyard.

    If it isn’t accidental, which I doubt, it is very skillful, a master mind.

  8. @Niclas,

    Sorry, I didn’t mean to imply that you were disagreeing with me. We seem to be in violent agreement ;-). I just wanted to remove the notion that “this only applies to those third-parties out there,” but rather every developer for the platform has to now be very careful. I think that if even the “by-the-book” faithful out there *really* understood the implications of this clause, they’d be a little more critical of its existence. The way I see it is that *every* application developed for the AppStore runs the risk of being the target of Apple’s legal ire. I mean everyone; not just the Corona, Unity3d, MonoTouch or Flash “heretics” out there. I could use C/C++ to create an application for the AppStore, then port it to Android (with some pain, I know) using some internally developed abstraction frameworks. Will Apple now say that I’ve violated their terms because I have an “intermediary translation or compatibility layer” in my code? Yikes!

  9. @Allen

    Yes I believe they could/would. They are looking for the lockin factor. They are betting (at least it seems) on that if people feel locked in, then they will be more devoted to that platform (they might even do everything in their power to make it even more successful than they would otherwise). All they have to do is make it compelling enough to join the platform, which it already is money wise.

    Anything that violates that lockin might lead to an App Store rejection, porting to Android certainly sounds like one such possible violation that this TOS would enable Apple to reject your app for, legally as you agreed to it.

    I guess that all turns around when Apple decides $100 per year isn’t enough, and Xcode, well you get basic version for free (well you need to buy a Mac first, and we are the sole supplier of that too). I don’t know, the clause they put there is open for so many bad interpretations that it will leave people not knowing what to think.

    There are already since a few months back, papers out that warns businesses to build/tie their business model on App Store, so far most have not listened, perhaps now they will think again, perhaps not.

Comments are closed.