Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Friday 9 April 2010

More Apple Evil

Chris Double just pointed out to me the new iPhone development agreement terms that require an application's original source language to be C, C++ or Objective C (plus maybe JS running on Webkit). Basically they're outlawing compilers like Adobe's Flash-to-iPhone compiler, Innerworks' J2ME-to-iPhone compiler, the Mono iPhone compiler, etc. They're also forbidding compatibility layers that wrap Apple's APIs.

This is mind-boggling. There's no possible technical justification for this. It's pure evil. I'm not even sure why Apple would do this. Maybe to make it harder for people to write cross-platform apps that run on the iPhone?

The lesson for those companies that just got hung out to dry is simple: don't build on locked-down platforms.


Andrew Stephens
I saw this earlier and also wondered what Apple is playing at. I would like to see some clarification about what that clause actually means before jumping to conclusions but it certainly seems like they are deliberately screwing over other development environments. I was under the impression that the Adobe Flash-to-iPhone app-builder was officially sanctioned by Apple (I could be wrong about this) so it would be weird for them to include language in the license to shut Adobe down.
I suspect that the AppStore verification process is largely automated, so perhaps Apple's verification tools don't work properly on Apps that aren't compiled with XCode. But even then, apps should be considered on a case-by-case basis, not by the compiler used to build them.
Ben Basson
Maybe I'm missing something, but surely they can't actually enforce this. Even if there are tell-tale signs at the moment, the tools could just be adapted to hide them.
I recall reading an opinion piece that said that while Apple currently has a majority market share, they're getting worried about things like Android. If they lose the majority market-share position, they can still make a lot of money off high-end products (as they do with Macintosh), but developers will start trying to write cross-platform apps that work on all the major devices... if the App Store is filled with apps that are dull and clunky ports that ignore the iPhone's features in favour of cross-platform compatibility, and the available apps work just as well or better on other, cheaper platforms (Android), even more people are likely to switch to Android and hasten the iPhone's marginalisation.
OTOH, if the App Store requires all apps to be native apps while the iPhone is still the leader, it's much more difficult for developers to write cross-platform apps and thus the iPhone's App Store is more likely to maintain its lead.
So, yeah... evil.
Robert O'Callahan
Screwtape: yeah that's my theory too.
Ben: of course they can enforce this. This provision doesn't have to be automated. They can just ask the developers. Sure, the developers can lie, but if they get found out, Apple can potentially sue for breach of contract and can certainly ban the developer from the iPhone forever.
Screwtabe, Apple does neither have a majority market share in the cell phone nor the smartphone market. And that applies to both the US and the international market.
Simply the same as they were doing before - blocking interpreters.
The locked down model of applications on the iPhone OS requires that the developer (or some third party) can't change the application after it's been approved and put in the store. An interpreter allows you to run any code at any time, including malicious code.
It's a shame - I'd love the iPad as a Pharo development environment. That would so rock.
But "Evil"? Seriously? Apartheid South Africa's treatment of 20 million of it's citizens is sort of my low bar for evil, and frankly that's a bit higher than an SDK agreement for a device that I am not forced to own.
Robert O'Callahan
There are many kinds and degrees of evil.
This is not the same as blocking interpreters. Read the text. Various companies including Adobe were using compilers to translate code and not including an interpreter in the final app.
ROC: I honestly think it's part of the reason - it has the effect of blocking interpreters, and there's a defendable security angle there. Apple's nightmare would be a virus affecting their platform distributed via Apple's store. That would be a massive hit. Chris' take on this is the "anti-flash" angle but I'm not sure that's the really reason.
The other part may simply be quality - most of the cross platform UI systems I've seen are pretty appalling. Mozilla and Eclipse's SWT are the only two that have ever been even passable (it's been a while actually; do you guys still render down to native widgets?)
And yet another reason to switch your daily computer use to Linux...
Isn't the use of static analysis tools compatible only with these languages as part of the verification process a possible technical justification?
Or maybe the code needs to be human readable in these languages because the verification staff is skilled only in these languages?
I'm with you. My company had plans to create several iPhone/iPad applications in C# using MonoTouch and now we're going to have to go back to the drawing board. None of us really want to be forced to use Objective-C.
"Apartheid South Africa's treatment of 20 million of it's citizens"
Like what? Torture, rape, murder...
What's really your "low bar" on evil?
What's needed for you to considered it evil?
Robert O'Callahan
fqueze: my understanding is that you don't submit your source code to Apple when you submit your app to the app store, so that couldn't be it.
Edouard: they've already blocked interpreters, so that is simply not the reason.
The quality argument is bogus. Apple can and do already vet apps for quality, and they can reject apps that don't look or feel right regardless of the underlying technology. And from what I hear, they already admit thousands of low-quality apps written in Objective-C...
Our cross-platform UI support is a lot better than Eclipse's IMHO. We do not use native widgets. It's simply a matter of having done a lot of work on it.
Something else much more positive, did you see that google blog entry taking position in favor of Theora, it seems no Mozillian is talking about it yet http://google-opensource.blogspot.com/2010/04/interesting-times-for-video-on-web.html
This sounds very, very good.
I also noticed this inside the comments, from someone who works for google :
"Theora can already playback in real time on an iPhone 3GS at native screen resolution, 25 fps, without any optimizations except for the final YUV2RGB stage.
Hardware decode support is a red herring. I've brought this up many times with various organizations, and once you demonstrate that decoding on a portable can in fact already be done, they admit that it's actually a political issue. It's just a convenient excuse to hide the real reasons."
Zach Stein
Really easy to enforce... Just ask the developer for the sourcecode of their application and make it a term of acceptance. A lot of people wouldn't like that (as I wouldn't want to give a potential competitor with a history of borrowing others' ideas my sourcecode), but they could very well do that.
My macbook pro turns into a hot chunk of metal with Flash.
The os x compiler tools are opensource - both gcc and clang.
Webkit and jscore are opensource.
Thats good enough for me.