Don’t Panic Just yet!
Novell hasn’t made any official comments yet on the new Apple iPhone Developer Agreement. I’m not sure if it’s technically covered by the NDA or not, but until Novell is in a position to make an official statement, I decided to write up something to keep some of the people up to date who are asking about it.
Here’s the source from the agreement:
APIs and Functionality:
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).
First of all, we need to understand what Apple’s true intentions are regarding this change to the agreement. Are they trying to prevent things like Adobe Flash’s new iPhone compiler, which could introduce a bunch of non-standard interfaces (not UIKit based) to the app store? Are they trying to prevent inefficient or poorly designed intermediate application layers from slowing down peoples’ devices?
If something like this is the case, MonoTouch should have good reason to stand, given that it binds the native UI’s and performance is great. Novell is currently trying to figure out what Apple’s intent is with this new agreement. Only once this is known, can they make a proper assessment of the situation. There are some others reaching out to Apple as well on the same issue. I believe Novell has some contacts within Apple who were excited previously about MonoTouch (although they could not officially endorse it), so hopefully this gets us some more disclosure on the issue sooner than later.
In the meantime, here are a few points floating around that we should consider:
- Apple is notoriously selective in enforcing their rules, so depending on their intent, they may be perfectly fine with monotouch continuing on, but stopping others (*cough* Adobe Flash)
- There’s some wiggle room in the current wording of the agreement for MonoTouch:
- MonoTouch does not technically “directly link against” Documented API’s
- “Originally written in…” is pretty vague. That could mean ‘Hey, I wrote my app in Obj-c then I rewrote it in c#’ (Yes, I know this is a stretch)
- MonoTouch’s main entry point is entirely written in C, so technically, it was “Originally written in C“
- MonoTouch compiles down to a native binary and there are some steps that are going to be taken to make MonoTouch apps have very little evidence that they were created with MonoTouch. It’s going to be difficult for apple to enforce this rule in such a case.
- Unity which has some parts of mono in it, has been used for several very successful games. Apple would be shooting themselves in the foot, although they could technically enforce this rule for MonoTouch but let Unity slide.
- Apparently every game produced by EA on the App Store would be in violation of the terms due to the fact they use Lua for scripting.
- The new agreement does NOT cover iPhone OS 3.2 and earlier. You can still compile apps for those OS versions under the old agreement without issue. Apparently all Developers must accept this new agreement by April 22nd. The agreement itself does not specify a particular version, so it seems all versions may be affected.
- The new agreement does NOT appear to affect Enterprise Distribution
- There’s another note in the agreement (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.”… This could mean that any apps using any third party libraries or frameworks (think anything using Tapku, or Three20, and the list goes on) is in violation of the new agreement. Can Apple really remove all of these apps too?
- TechCrunch reported (http://techcrunch.com/2010/04/08/adobe-flash-apple-sdk/) that Unity has stated they have a great relationship with Apple and expect nothing to change.
So the verdict is right now is simply: keep the status quo, and don’t panic until we know that the sky is actually falling. In the meantime, the MonoTouch team is pushing ahead with binding the 4.0 API’s and are quite excited about it.
Let’s not draw any conclusions until the dust has settled!
Programming language racism? I think it’s about time the EU and other market authorities do something about Apple’s policies
I don’t see the “wiggle room” in the wording as useful because Apple can fix it to clarify their intent, so it just boils down to what their intent actually is…
Interesting, when i saw the news user license agreement the first thing i thought was in how monotouch will be affected. Hope we can still use it under iPhoneOS 4.0
Thanks a lot for the insight in this article, hopefully more details will come from Apple soon.
The wording is a bit ridiculous. The e.g. portion isn’t backed up by the rest of the paragraph. Before the e.g. it states that only code written in c/c++/JS may link directly to the documented APIs. You can write a bridge or an adapter in c/c++/JS that link directly to those APIs then use your bridge/adapter with other code with that wording. That’s effectively what Flash-to-iPhone and Monotouch are.
As for the e.g.; what do they define as a compatibility or translation layer. If I *do* write a bridge or an adapter for my own app have I violated this agreement?
Given the financial viability of doing business in the app store, I think Apple is just opening themselves up for lawsuits.
As for 3.3.2, if I want to publish two apps, I can’t put the common code into one library?
Developers need to get this vague wording changes now, if they don’t want issues later.
There’s no wiggle room here. It’s perfectly fine to draw conclusions
“Applications must be originally written in Objective-C, C, C++”
I don’t think Apple can get more clear than this. This is referring to the application the developer publishing the app is writing.
“Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited”
Yes this bans MonoTouch.
“MonoTouch apps have very little evidence that they were created with MonoTouch”
Well, now you’re just trying to hide what you’re doing while actively breaking the terms and risk the consequences. This is going into blackhat territory, might as well just write apps for a jailbroken iphone.
[...] over this little clause in the new iPhone developer SDK terms is erupting all over the internet: 3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and [...]
@Apphacker
I’m just presenting some ideas from around the community about this topic. This is simply dumping some thoughts down on paper.
“Applications must be originally written in Objective-C, C, C++”
This may seem clear, but the reasoning behind it is not. MonoTouch compiles down to the same native binary that Obj-C does. So what’s the intent of apple restricting the ‘original language’? This is the real question.
“Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited”
I guess you can argue that MonoTouch is a translation layer. This is probably the hardest point to argue, except that those terms are pretty loose.
“MonoTouch apps have very little evidence that they were created with MonoTouch”
The point here is that, if there’s very little evidence of any difference, why would apple care about monotouch? Again, what’s the intention here? I’m not suggesting that if the intent here is to kill MonoTouch, that we try to keep using it against their will. Just saying there’s not really a logical reason for them to want to ban MonoTouch given that the native binary is really indistinguishable from something made strictly in Obj-C
All this is conjecture – if Apple do enforce this then as it’s been pointed out, all the EA games will have to go from the appstore. Apple will most likely have some silent agreements with firms (not Adobe) to let offenders through.
After all Monotouch forces you to buy an Apple Mac to develop on, you can’t develop on a non-Mac platform without a lot of .csproj file manipulating (or maintaining two sets of project files). That’s not the case with Adobe.
@Jon
“This may seem clear, but the reasoning behind it is not. MonoTouch compiles down to the same native binary that Obj-C does. So what’s the intent of apple restricting the ‘original language’? This is the real question.”
In the context of the license, their intent is moot. The developer must adhere to the terms spelled out in the license, not what they perceive the intent to be.
“The point here is that, if there’s very little evidence of any difference, why would apple care about monotouch? Again, what’s the intention here? I’m not suggesting that if the intent here is to kill MonoTouch, that we try to keep using it against their will. Just saying there’s not really a logical reason for them to want to ban MonoTouch given that the native binary is really indistinguishable from something made strictly in Obj-C”
As an outsider it would appear that either:
A) They can only ensure their new features (multi-tasking, background audio) work by some Obj-C type magick, so building with anything else is dangerous.
B) They really want to ensure that Adobe doesn’t get to play on their phone, and everyone else (Monotouch, Unity etc…) are just collateral damage.
@Jon
I don’t understand how it can not be clear to you. It’s not ambiguous. If you didn’t compile your application in xcode using the official SDK then you are violating the terms. You can not write your app in C# without violating the terms. You can not use MonoTouch without violating the terms. You said it yourself “MonoTouch compiles down to the same native binary that Obj-C does” <— this violates the terms.
In the end, it's up to you. If you think you're right, invest the time to build your app, post it to the app store, see what happens. If it gets shut down, you've just lost a ton of work and effort when it was clear to everyone else that using MonoTouch was a risky idea.
I think part of what needs to be defined is whether the “translation layer” is being actively translated on the device, or in MonoTouch’s case, where it was translated ahead of time. I know the main reason why Apple didn’t want Flash in the browser, is that it would allow you to circumvent the App Store.
If there’s translation happening *at runtime* then you can get code onto the device by downloading it and executing code that wasn’t a part of app that went through the approval process. Maybe they got wind of plans at Adobe to have something like a Flash Games app where users could download games inside that app and pay Adobe instead of Apple. That would be a direct attack on the App Store and the phrasing may be in defense of that attack. Those games would be the “translation layer” and those apps would not have been compiled to C, C++ or Objective C. If the intent is to prevent that kind of circumvention, then users of MonoTouch/Unity shouldn’t be worried since the code that gets submitted to Apple was compiled to C++ and no additional translation is occurring.
However, if the intent is language-lock in so that developers can’t easily have large portions of the code shareable between Android and Windows Phone 7 (what a dumb name for a product) then they could use the phrasing to block MonoTouch. If this is the case, then Apple is going to piss off a lot of people.
Look man, I own a Nexus One and I think it’s awesome. You should make apps for Android. You guys are in denial about the iPhone/iPad developer sdk terms. Good luck.
Unfortunately I think @Apphacker is right – there really doesn’t seem to be much ambiguity in the wording. It’s pretty clear what it’s saying, even though why it’s saying it isn’t clear at all.
Also, developers need to agree to it by April 22 to maintain access to the provisioning portal, so ultimately all versions of the iPhone OS *will* be affected.
Just on the off-chance Apple haven’t succumbed to a rabid dose of Not Invented Here Syndrome I think Novell (not a little easily-ignored company after all) should broach the matter at the highest levels to explain why this clause as worded isn’t in Apple’s interests.
@Apphacker: The Android ecosystem has its own blend of incompetence and evil just like everyone else. Developers from my country (like the Swiss) are unable to sell paid apps on the marketplace, whereas developers from other countries can sell them to Android users here (and in Switzerland), ensuring that not only are we prevented from making a profit through the default channel, but by the time that ever changes (if it does, which I doubt at this stage) a huge advantage will have been given to others by Google’s indifference/incompetence. I really like the Android API but frankly Google can get stuffed.Currently I’m planning to split my efforts between iPhone OS and WP7.
@Apphacker @Ryan @Kevin Daly
It doesn’t matter how ‘clear’ the license is. My point of intent remains. Apple has shown us time and time again with the app store approval process that just because some ‘rule’ might exist, doesn’t mean they enforce it the same for everyone. So, just because their agreement says something, even if we agree that there is violation of the agreement, it does not mean that apple will choose to enforce the violation either at all, or consistently.
I’m not suggesting that’s a great bet to base your business on. I’m just suggesting the door isn’t closed and locked up tight just yet. We have to wait and see what companies like Novell (MonoTouch), Unity, EA, Titanium, etc. end up saying about their relationship with Apple.
Apple is notoriously so fickle and inconsistent that I don’t think it’s time to throw in the towl just yet
Unfortunately, this entire article is nothing more than wishful thinking. Apple’s intent is clear (lock-in) and spending any more time developing with MonoTouch is just a digital Russian roulette. Developers spending valuable resources on developing with MonoTouch sure better have a backup plan for when the other shoe drops.
This is why I would rather spend my time developing for other, more open platforms.
It would indeed be interesting to see what would happen if Microsoft enforced Visual Studio as the only development platform for Windows 7. The outcry would be gigantic.
To get around the Apple License with Monotouch, just compile your C# application to C using the proper compiler switch and then use that output to build your app. There’s no violation.
@Sheffield That still violates the agreement since the code must be “originally written in”. Your code would still be originally written in C#. Unenforceable, more than likely, but still in violation of the terms.
My employer is doing some multi-platform work for a large customer right now. The iP(ad/hone/od) stuff is being delivered with Monotouch. Personally, I’d hate to go to the customer’s legal department and say “well, we’re violating the developer agreement for deploying to the app store but we probably won’t get caught and Apple might not enforce it.” Worst case, for us, it seems we just make it clear they can still do internal deployments with their enterprise license but they can’t send out anything consumer-facing.
@kevin well you can always provide an .apk file on a website or use a non-android app store and have users install the app from there. Unlike the iphone, on an android device (except for the piece of shit AT&T Backflip) you can get apps from anywhere.
Sorry meant non-”android marketplace” app store.
I think Adrian is on the money here. Apple runs the risk of taking MSFT’s place as the “reviled monopolist” (not that I think they care). I have found it uncomplicated to develop for Windows and haven’t even put out a MonoTouch app yet. If it turns out for the worst, at least all I lose is the $400 dollars and not a lot of coding time.
Only that Apple is no monopoly and neither do they aspire to be one. I find Apple easy to understand as they simply go where there is money to be made and they dont care about the rest. So you always know where you have Apple.
Given how resource-conastrined these devices are I think you should use the manufacturers SDK on each.
A desktop-computer has the power to handle the overhead. But not these small consumer appliances.
How do Apple get away with these things ? You cannot name your product with the word Pad because of the iPad (yet you may have got your app already out there before the iPad came along). You cannot write an app. that may be seen to compete with anything of Apple’s and now you cannot use tools that sit on top of Apple’s API’s. You cannot use the lowercase “i” because Apple think they own it and now even though you could (until now) write apps. with the likes of MonoTouch, you cannot write anything without using their tools.
If Microsoft did any of this you’d have lawsuits from the EU, anti-trust, anti-competitive lawsuits, all round bad news for MS.
I’m absolutely stunned that Apple have so far gotten away with all this as they are far far worse than Microsoft ever were.
First, I’m afraid there’s a lot of wishful thinking going on here on the part of MonoTouch developers — and I am one.
It is clear that iEvil doesn’t want cross platform mobile products. That is clearly what this new clause says. By the way — all you Objective-C bigots: READ THE TERMS. YOU WILL NOT BE ABLE TO WRITE DOWN *ANY* PART OF YOUR APP IN PSEUDOCODE, nor will you be able to sketch some code outlines before you go to your keyboard. The code must be written in C/Objective-C/C++ to START WITH. Writing preliminaries in sketch or pseudocode and then using your own brain to translate that to C/C++/Obj-C actually violates this agreement.
Have fun.
Just means I will be sending more customers of my niche applications to WM7 and ‘Droid. I have 8000+. It’s not many by Apple standards. But how many guys like me does iEvil think they can send to ‘Droid?
Monotouch guys: PLEASE PLEASE PLEASE speed up MonoDroid.
MonoTouch may be OK.
It seems like Apple’s motive is to discourage technologies that abstract away phone specific API’s and make it easy for developers to write once and compile/deploy on multiple smart phones. It makes sense for Apple to do this since iPhone is the market leader, and most apps would need to target iPhone first before other smart phones, so why make it easy for them to be ported to other smart phones, and thus eroding Apple’s huge lead in the number of apps?
Adobe’s Flash is such technology, but MonoTouch, as I understand, is not so much an abstraction but a C# wrapper around Cocoa Touch API’s; developers still need to learn Apple specific API’s. I suspect that Apple’s may be only targeting the write-once technologies, and different alternate development methods may get different treatments in terms of the enforcement of the rule.
James, you are correct about MonoTouch not being an abstraction layer. You still develop your UI using Apple’s Interface Builder and your code references platform specific classes. A Flash app would be very different, they would not be using the native controls (and if they’re really nice to devs they may have abstracted out some of the platform-specific code, like accessing the address book, getting GPS coords, etc) so the developer gets to code on PC without any apple dev products & then deploys to multiple mobile devices. The user would end up with a slightly disjointed experience since the UI’s of the Flash apps would look so different. I can see why Apple wants to block that for UI consistency as well as platform stability (if the “leaked” Job’s email is accurate). MonoTouch is very much married to CocoaTouch and is only a thin wrapper around the APIs, it just provides the dot net classes and the C# language that make coding for the phone so much better than Objective C (closures, LINQ, WCF, auto-memory management). But with Apple, who knows how Nazi they’re going to be with enforcement.
[...] (Screenshot above from this blog post.) [...]
[...] (Screenshot above from this blog post.) [...]
http://www.micromixx.com/3411/new-iphone-gizmodo-4g-scoop-and-preview/
Seems to me, Apple is trying to make impossible to develop non-verifiable code. This is quite important if they want to keep the platform free of viruses.
You are all know how many viruses exist on Windows platform – just because the platform is widely used. Same might happen with iPhone/iPod/iPad, and this is what Apple afraid of.
MonoTouch Article – What does iPhone OS 4.0 mean for MonoTouch?…
Thank you for submitting this entry – Trackback from MonoTouch.Info…