Ok, so a new clause in the Terms of Service for Apple’s newly announced iPhone OS 4 is understandably causing some consternation around the internet:
“3.3.1 … 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).”
The common understanding is that this is a shot across Adobe’s bow, but also aimed at people creating emulation environments. Potential justifications for this could include performance concerns (given the new multitasking feature in 4), wanting to avoid shovelware ports from other platforms with no iPhone-specific features to make their platform stand out, or sheer bloody mindedness and wish to tie developers directly to their APIs to minimise the chance that they’ll deploy on competitors machines.
As a general principle, I don’t like this sort of thing – telling developers what they can and can’t do is stifling. But, I had to take away one positive from it – a company telling people to use native code, instead of the opposite which I’ve seen too much of lately. In recent years, the likes of Microsoft have insisted that developers use their intermediate VM layers to deploy on some devices (XNA, Windows Phone 7) – regardless that these environments have about 20 years less maturity (in terms of libraries and existing code) than what I already have in C & C++. Having them tell me that no, despite all these great battle-tested libraries that I’m used to using, instead I have to use comparatively immature ports and replacements of varying quality, just because they tell me so. That drives me nuts – sure, let’s throw away and re-invent hundreds of functioning & tested libraries just because…well, just because! They’re old and we’re new and awesome! Hmm.
So while Apple telling developers what they can and can’t use is still very wrong from a point of principle, I’m actually glad that someone is championing native code for once, rather than pushing a VM environment. I’d prefer they didn’t mandate anything at all, but I can’t deny a certain urge to fist-bump when native code was the one to get the seal of approval, after getting the impression from other companies that they’d rather no-one had access to the underlying workings of the machine. I like native code, there’s a certain purity about it – and maybe it’s like a sad old gear-head going on about how great the old V8′s used to be, but I don’t care 
Mostly it’s about my frustration with being forced to discard perfectly good native libraries and look for / build replacements for no good reason.
PS For the record, OGRE on iPhone isn’t affected by this new ToS because we’re 100% native, baby.
[edit]For those pointing out that C# and such eventually run on native code anyway – that’s not the point. The point is that on certain devices – XNA and Windows Phone 7 – you simply cannot use libraries that were not written in .Net originally, meaning that years worth of dev libraries are inaccessible and need to be (pointlessly IMO) rewritten in .Net. And yes, this is exactly the same as Apple are doing here (but in reverse), if you interpret it in the strictest sense that you’re only allowed to use code written in Obj-C, C and C++. I’m just taking a perverse delight in the fact that it’s C/C++ libraries from the last 20+ years that are on the winning side for a change, instead of being the ones that are excluded (which frankly I’m completely sick of).
April 10th, 2010 at 11:17 am
For me it’s a step backwards. I sometimes cannot understand reasoning of companies like Apple or Sony. Instead of opening the platforms a bit (and thus allow more developers to create games => more profits for everyone) they tend to close it.
I’m glad OGRE isn’t affected.
April 10th, 2010 at 11:26 am
Oh, absolutely. If I didn’t make it clear enough in the post – this is a bad move by Apple. But, I think the same thing about XNA and Windows Phone 7 – the restrictions on developers there are enforced by lack of technical provision rather than a legal ToS, but the practical situation is much the same.
All limitations are bad, I’m just taking some solace that it’s native libraries that win for a change.
April 10th, 2010 at 11:30 am
“PS For the record, OGRE on iPhone isn’t affected by this new ToS because we’re 100% native, baby.”
But what about section 3.3.2?
“3.3.2 — An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).”
Wouldn’t banning plugins and non apple frameworks/apis have a bit of an impact on Ogre for the iP(hone/od/ad)?
It is good to see c/c++ being promoted though.
April 10th, 2010 at 11:34 am
“Wouldn’t banning plugins and non apple frameworks/apis have a bit of an impact on Ogre for the iP(hone/od/ad)?”
Nope, because everything is statically linked on the iPhone anyway
Plugins are effectively selected at compile time.
April 10th, 2010 at 11:54 am
“JavaScript as executed by the iPhone OS WebKit”
Grind that metal! ;D
To me it obvious why apple do what they do. They want to a) stop flash because then no one would buy app store apps if they could play a billion crappy little flash games. b) stop emulators, since if you had one you’d never have to buy another appstore game again.
It all makes sense and I don’t blame them but it’d be insane if this messes up stuff like Unity (also they need to delete at least 150000 apps NOW)
April 10th, 2010 at 2:22 pm
If I understood it correctly, if you want to script a game with Lua or Python, you are still screwed.
April 10th, 2010 at 7:39 pm
Don’t get too happy about fascists picking on someone else.
Your time will come.
April 10th, 2010 at 8:23 pm
Plus, more amateur coders don’t know how to write in unmanaged code, even I’m no good at it despite being a full-time programmer. If you can take the easy route to achieve the same result, you will. I’m not saying it’s right by any means, it’s just the ease of development that appeals to the developers.
Personally I’d rather learn Obj-C if I were to regularly develop in that environment.
April 11th, 2010 at 7:34 am
Read this: http://blogs.unity3d.com/2010/04/10/unity-and-the-iphone-os-4-0/
Unity uses c# for scripting on the iPhone – and in the blog post they write: “..Our current best guess is that we’ll be fine…”.
Let’s wait to see how this plays out.
April 11th, 2010 at 11:26 am
@Kriss: at the risk of repeating myself a THIRD time – I don’t think this is a good thing AT ALL, and I’m not ‘happy’ about the situation – I disapprove entirely of developer restrictions of any kind. As for “your time will come” – my time has *already* come, with the likes of XNA and Windows Phone 7, and *that* is my point. For once, a crappy restriction enforced by a platform holder favours native code from C/C++, compared to that being excluded as has become de rigeur lately. That doesn’t make it a good thing, but it is a kind of ‘balance’ in a perverse sort of way.
@Kezzer: Sure, developers should be able to choose the tools they want for the task in question. Although a developer than never learned how to compile & run code to a native platform without the training wheels of a VM is missing a fundamental part of their education IMO. My point is mostly about how much mature & tested code you’re forced to ignore when you can’t use native libraries. New coders often don’t care about this, they’re often unaware of the rich legacy previous generations of programmers have left them and think they can reinvent everything themselves in a better way anyway – and they’re usually wrong
@Assaf: frankly I hope Unity (and everyone else) don’t end up being affected, because I think the situation sucks. Still, this is my small rant that for once native libraries aren’t the ones getting the finger.
April 11th, 2010 at 11:54 am
And can I just say – it’s ironic that some people are saying ‘boycott Apple and their language naziism!!’, when the alternatives such as the Android SDK (Java) and Windows Phone 7 (.Net) also have restrictions on bypassing them, although Android I hear has improved recently.
April 11th, 2010 at 12:30 pm
I take solace from the fact it affects flash. Might stop people using it in all kinds of inappropriate situations. It seems crazy to me that instead of people developing for up to date browsers, and instead of users using up to date browsers, they shove a flash plugin in and fill up the cracks with swiss cheese.
There is no way I see unity surviving it. Nor apps which use Lua or other languages for scripting. Not without change to the ToS. You’re missing the rest of the clause too, it says that only apple’s APIs may be used. So not only can you not use any other language to interface with apple’s code, you cannot interface with other code.
I’d be worried about Ogre on the iPhone too.
?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).?
April 11th, 2010 at 12:32 pm
Sorry, I think I mis-interpreted that. They’re saying all APIs that you do use must be documented, I read Documented APIs as meaning Apple’s own APIs.
April 11th, 2010 at 12:34 pm
And documented I presume means open and accessible.
April 11th, 2010 at 3:00 pm
Unfortunately the rules are a bit vague and everyone is just guessing on what Apple really means. For example the “Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited” sounds like Ogre’s render system, since apps use Ogre as a compatibility layer to the iphone api. That really sounds like the kind of thing Apple are targetting, anything which makes it easier to write non exclusive apps.
Maemo still sounds like the best alternative.
April 11th, 2010 at 3:27 pm
Yeah, they do appear to be trying to stop cross-platform development generally so the interpretation is tough. “Documented APIs” refers to Apple’s own APIs rather than others such as GL though, and it’s easy (in fact, recommended) for you to write your own ObjC/C/C++ code to target the Apple-specific APIs and embed OGRE in the viewport only. The vast majority of OGRE doesn’t talk to Apple APIs at all, and the difference is that we don’t actually ‘wrap’ them like other full-platform systems do – we do enough to let you get rendering if you don’t want to do this yourself, but we’re completely compatible with dropping in to a ObjC, iPhone-specific app structure as much as any other platform-specific app structure. So I still think were on safe ground here – developers can specifically target Apple APIs themselves with their own ObjC/C/C++ and still drop in OGRE to help with the rendering and not be in breach of these terms, I believe. It’s one advantage of being a rendering component and not a complete platform wrapper.
April 11th, 2010 at 7:20 pm
this is all about language lawyering. ogre is MIT now, right? just dl it, change the boilerplate in the code and rename your ogre copy to “my-very-own-3d-library-which-is-NOT-AN-API”. problem solved.
April 12th, 2010 at 12:32 am
But what is Ogre then since it’s not a documented API? I would have thought that puts it in the “private” API category complete with “must not use or call”.
I can’t imagine them wanting to stop code reuse like that though.
April 12th, 2010 at 7:05 am
Haha – and with this post we get more insight to the man behind Ogre. Your blog, vent how you like! :0)
April 12th, 2010 at 9:10 am
@blankthemuffin: no – all it basically means is that you have to call the ‘Documented APIs’ (ie Apple’s) directly via ObjC/C/C++ and not via a wrapper. It doesn’t mean you can’t use helper libraries (like OGRE) for other purposes, it just means that your code must be calling Apple’s API directly from these languages. Basically, they’re saying you can’t use full platform wrappers / bridges, which luckily is not what we are. Like any utility library we can sit alongside 100% iPhone-specific app code and still provide value because we’re not built on the assumption that we always hide or wrap the platform.
The reasoning is that Apple want’s developers to target iPhone features specifically, not as a simple port via a wrapper. They want you to code for their platform and not just do a vanilla port of the same stuff that you also send to other people’s platforms. They don’t like that wrappers rarely exploit the individual defining features of the platform – because why would you buy an iPhone over a cheaper alternative if they both felt the same? Personally I think it’s a sledgehammer to crack a nut, and they could achieve what they want by telling people they have to adhere to the HID rules and that they have to use platform-specific implementations when implementing feature X/Y/Z, giving apps a device-specific feel which is what they want. There’s no reason middleware like Unity can’t allow apps to keep 90% of the core common and then have 10% which is specifically targetted per platform to give the iPhone version Apple’s desired look’n'feel.
But I think this isn’t about practicality for Apple right now. I think they want to make a statement – that they don’t care about having the most apps and the most developers, they want developers who dedicate significant resources specifically to their platform. This isn’t great for developers business models, but it’s potentially good for Apple – this is like a console exclusive (but without the sweetener for the developer). I actually think Ogre gets away with it because of a technicality of the way we’re written, rather than us being necessarily compatible with Apple’s preferred vision – they’d rather have an engine that only targetted iPhone I’m sure. I suspect that if Apple don’t let Unity off the hook the way they are, that Unity can figure out a way around it so they’re technically compliant – they already had to do this once with the change from JIT to AOT compilation.
April 13th, 2010 at 1:38 am
The captcha actually says ‘unity to’ – strangely enough.
That, and the observation that native code is called unmanaged code on the other side of that fence, was all it took to make me post this silly comment. :p
I also applaud that they want native code, regardless of whatever it otherwise means.
April 23rd, 2010 at 5:06 am
I don’t think this issue was ever “native” code. The issue was, from what I understand, adobe compiling a program from language X into language A which would make the program language ‘native’ in concept. Assuming it worked as intended (And as cool an idea it is, I doubt it.) the application would be just the same as if you coded it in C# or whatever for the apple system.
So tell me, when will apple ban the use of any text editor besides apple’s all holy IDE which only runs on an uber-special $15,000 dollar system? >.<
June 12th, 2010 at 6:09 pm
Here’s a not-officially-confirmed update on the Lua-on-the-iphone thing:
http://www.appleoutsider.com/2010/06/10/hello-lua/
Apparently they are allowing it again.
February 16th, 2011 at 3:10 pm
Has anyone taken a look at Airplay SDK?
Allows x-platform C/C++ development for all major mobile OS’s. Develop, debug, deploy and sign even iOS apps entirely in a PC/VisualStudio environment.
I think Ogre3D will make its way to Airplay pretty soon.