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).
Or am I misreading this? Any iPhone experts have opinions about what this means?
What I'm curious about is what Adobe is that makes binaries much larger than the size it would be if it was in ObjC. As an example, the binary for Trading Stuff (only picked on because it is free) is 14.1MB. Thats rather ridiculous; I don't think I've ever come across an app written in ObjC for the iPhone that was 1.4MB.
And looking at the reviews for Trading Stuff, it doesn't seem like the app performs very well. Of course, that could be due it being written poorly. But, my initial inclination is to think otherwise.
I really don't see the point of this. It just means less applications and less revenue for Apple.
Meaning, I doubt Apple will suffer much from developers declining to code for it.
I've shipped about 9 iPhone titles over the last 2 years, and my 2 biggest gripes had become #1 the App Store submission process -- which they finally improved significantly a few months ago -- and #2 that I was forced to produce and master so much iPhone-specific code & rituals. Rather than more reuseable/leverageable technology like HTML, Python, Java, Unix tools, etc. In other words, I was becoming a share-cropper.
So they seem to have improved #1, but now much worsened #2.
Makes me more glad I've stepped away from it recently, despite my love for the device as an enduser.
[1] With the most obvious side effects being not allowing a "code once, use anywhere" environment to gain popularity and being a direct shot at Adobe (CS5's release is only a few days away).
UPDATE:
Actually, the guys in the office just informed me that everything that used to be true is not anymore. Sorry, everything I wrote is probably wrong as of this morning it seems. Wow. Even more reason to just use Objective-C.
MonoTouch, which is the Novell/Mono team's rather fantastic port of C#/.Net to iPhone, compiles down to native code and apparently that was OK with apple to begin with. Unity3D which is a popular 3d framework for many platforms including iPhone (Where it runs a lot of games) was available before MonoTouch and is Mono based.
Assuming the OP is correct in the "new developer license agreement" statement (e.g. the relevant section is entirely new or changed) the "Originally written in Objective-C, C, C++ or JavaScript" is worrisome. It technically invalidates MonoTouch. Even if MonoTouch is hard translating code to One of the blessed languages before compile, you didn't write it ORIGINALLY in it.
And love or hate Mono, .Net, C#, etc etc. the fact is that it brings iPhone development to a larger audience which is (IMHO) overall good for the iPhone app world.
I seem to recall Adobe was demoing a similar system a few months back - which would compile down a Flash app to native code in more or less the same way as MonoTouch does. I guess it's entirely possible that Apple is targeting this in their change, but unlikely as this wouldn't allow you to run downloaded flash. It would simply let you download Apps from the store which were written for Flash, but since they'd been translated to native runtime probably wouldn't be the battery hogs that apple seems to fear.
I've been watching Apple long enough to think this may not be a case where they're targeting a specific person/company, rather ... it's future leverage. If they run up against something they don't like (there are obviously lots of things like MonoTouch and more coming along) sometime in the future they now have a clear one liner to point at for "VERBOTEN". They may still however work happily with companies like Novell to produce a grey-area inhabiting MonoTouch.
UPDATE: For the record, the MonoTouch FAQ (http://monotouch.net/FAQ) states very clearly "MonoTouch is delivered as a static compiler that turns .NET executables and libraries into native applications. There is no JIT or interpreter shipped with your application, only native code. ". Obviously this distinction used to pass the test.
Unity is very successful in the iTunes store, with at least 1 game in the top 10 developed with it.
Adobe CS5 would be great because of their authoring tool, and no matter what your views on Flash are ... that's what the approval process is advertised for ... to remove crap from the app store, and I'm pretty sure you can write optimal apps on top of Flash.
What the fuck are they thinking? If this is not a mistake, couldn't they announce this sooner, before all these companies waisted time on developing their products?
This is just proof that having your business relying on a company that thrives from locked-in, proprietary platforms is a really stupid idea that should be taken with caution.
And again, how can I recommend an iPad to my mother or other less technically-inclined people? What stops them from locking those users out of their own device they paid for, if such a thing becomes aligned with the interests of Apple?
(of course if you don't mess with the binary after compilation, the language could be identified in many ways, but you can as well change the result to look like whatever you want)
Nope, you can tell. Especially if you have the tool itself on your desk when you try to develop a test (as Apple will surely be buyers of). If it doesn't look like Objective C, C++ or C in its call parameters, flow, etc, they'll "know" well enough to hold you up in their queue process until you "send screenshots of the source"
The boilerplate code technique (where C code is generated) can even be detected (although has more false positives).
The Adobe sourced Flash binaries are supposedly trivial to tell, and I'd expect MonoTouch etc to also have that issue.
Beyond that there’s a legitimate need for this particular clause and that’s to prevent vendors who would market poorly written tools that create buggy applications.
So the question isn’t “does Apple have the clause” it’s “will Apple use the clause against legitimate developer tools like Adobe Flash or monotouch”. Until they do I don’t see a need for criticism.
Why would a developer or a company invest money and time in those tools, only to give the iTunes approval process yet another reason for rejecting his app?
It kills these businesses, even if Apple might decide to look the other way in the approval process.
I was also starting to wonder when I'm going to see apologetic views on this, as is customary for anything Apple does :)
Second, if you're a hobbyist you aren't going to buy a $2,000 framework and if you're a business $2,000 isn't that much for a software lic. I don't see the cost being prohibitive here unless, as I said above, Apple makes it clear they will ban these frameworks (at which point it's all moot anyway)
Here's a developer who just got his iPhone app made with Flash CS5 approved just this afternoon: http://twitter.com/james_eberhardt/status/11850738164
All of these languages can relatively easily call one another (even on the iPhone). As C++ is a huge deal in the game world, lots of shops just went pretty much straight C++.
XCode is just using clang to analyze/gcc to compile then signing it with Apple signing programs.
If I'm not mistaken, the entire app toolchain was inspired by the "open toolchain" created by the original jailbreakers before there was a native app api.
Apple is practically killing all tools that would make cross-platform development bearable.
To be frank, as an employee of a tools vendor which sells an IDE (Delphi) whose language is not one of Objective C, C or C++, this is pretty scummy - a low blow.
(I speak for myself, not for the company. of course.)
Let's say you have limited developer resources and can only develop an app for one platform, most would choose the IPhone due to its large install base.
Number two -- and I think this was more of a bonus not the main purpose -- is a blow against cross-platform toolkits.
