Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the TidBITS Content Network for Apple consultants.

iPhone Developer Agreement Change Bans Flash-to-iPhone Compiler

Along with this week's release of the iPhone OS 4 SDK, Apple made a change to Section 3.3.1 of the iPhone Developer Program License Agreement. Previously, that section read:

"Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs."

After Apple's addition, it reads as follows:

"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)."

That additional verbiage appears designed to block the use of certain cross-platform compilers such as Novell's MonoTouch, which compiles C# and .NET apps for the iPhone, and Adobe's forthcoming Flash-to-iPhone compiler (there are actually four or five of these cross-compilers, not all of which will be affected). John Gruber explains the situation well at Daring Fireball, and his followup article "Why Apple Changed Section 3.3.1" makes some good points about how cross-platform compilers have seldom resulted in top-notch Macintosh applications. Read his analysis for details, and be sure to check out Steve Jobs's related comments in email to Tao Effect CEO Greg Slepak.

One aspect of the situation that John doesn't touch on is the legal firestorm that this change may engender. MonoTouch comes from Novell and Adobe has undoubtedly spent a huge amount of money on developing its Flash-to-iPhone compiler. Both companies have strong legal departments, and given that this change was made to a legal agreement, it seems entirely likely that we'll see these companies filing lawsuits against Apple for anti-competitive behavior.

However, it's important to remember that Apple isn't acting irrationally, as John notes:

"So from Apple's perspective, changing the iPhone Developer Program License Agreement to prohibit the use of things like Flash CS5 and MonoTouch to create iPhone apps makes complete sense. I'm not saying you have to like this. I'm not arguing that it's anything other than ruthless competitiveness. I'm not arguing (up to this point) that it benefits anyone other than Apple itself. I'm just arguing that it makes sense from Apple's perspective - and it was Apple's decision to make."

He's right. It would be nice to see Apple competing entirely on the basis of having the best products, but as Mac users know, the best product doesn't always win. Having been on the wrong side of that battle for 25 years, Apple isn't going give up any potential advantage in the brave new iPhone OS world.


Backblaze is unlimited, unthrottled backup for Macs at $5/month.
Web access to files means your data is always available. Restore
by Mail allows you to recover files via a hard drive or USB.
Start your 15-day trial today! <>

Comments about iPhone Developer Agreement Change Bans Flash-to-iPhone Compiler
(Comments are closed.)

James Bailey  2010-04-10 16:42
Are you suggesting that Adobe may have a contract dispute with Apple because of the language change? I find that hard to believe. I would be interested in some expert legal opinion on that
Adam Engst  An apple icon for a TidBITS Staffer 2010-04-12 07:44
I don't think it would be a contract dispute but instead some sort of lawsuit alleging anti-competitive behavior. And whether or not it would succeed is entirely unknown, though large companies often wave legal sticks at one another for a variety of strategic reasons.
laurence  2010-04-11 16:29
i for one am glad of this change. what companies like adobe and novell were doing was straight up opportunism.

not that this is wrong, but they were building a business on a loophole in the sdk agreement. apple closed the loophole, and now they're all upset.

if adobe had done what they should have done from the outset - supplementing dreamweaver to help people create native web apps - adobe would at once have made an ailing program relevant again, and created a product infrastructure that apple would not be able to cut off by modifying the sdk.

flash was semi-relevant under macromedia, but ever since adobe has taken it over, it's become increasingly bloated. it strikes me that adobe is trying to push flash to the degree that it is, in order to justify the outrageous sum they spent on acquiring macromedia.
Ed Wood  2010-04-12 18:23
Legally it may well be acceptable, morally, it stinks. Being competitive is one thing, letting your app writers spend time and money and then kicking the feet out from under them is more like politics than the apple I used to love. It demonstrates exactly why I have 3 Macs but no iPhone Or iPad The decisions on what apps to run on a purchased piece of equipment should be the owners, not Steve's
James Barrett  2010-04-12 18:39
Given the trouble that Flash gives web browsers, I'm *glad* it's not on the iPhone. And I just love how every Flash app I encounter seems to have it's own UI philosophy. Flash has been so buggy for so long, it seems that they're not interested in fixing it. Should I have any confidence that Adobe would do an excellent job on their flash-to-iphone translator? Should Apple have that confidence? Why would Apple want their phenomenal innovation shrouded under a muddy, bloated layer of mediocre middleware -- one that imposes another UI on top of the OS UI?
Jon Rosen  2010-04-12 19:29
There are other high level tools besides Flash for the iPhone. I was planning to use Revolution (RunRev) to create mobile apps. This is like saying you aren't allowed to program in Basic or PHP or some other language. There are plenty of people that have special expertise in some subject but don't want to learn or have the time to learn Xcode and Objective C. It simply isn't right. By the way, judging by the apps in the app store, using Xcode is obviously no guarantee of producing a quality app.
Danny Grizzle  2010-04-12 20:46
Yes, I think this is bad news for Runtime Revolution. It may threaten the company's existence if they have to refund a few hundred advance payments for RevMOBILE at $1,000 each. I am a long time Apple partisan, but Apple's war against Adobe is troubling. Adobe put on a good show today launching CS5. The suite of video tools made Final Cut Pro look old. Meanwhile, Apple has dropped the ball with a sucky Aperture 3 upgrade. I personally think the iPad is Apple's play for the Enterprise -- think and medical records. There's a lot of backlash over Apple control freak tendencies, though by and large I weIcome some degree of closed architecture if it insures the platform doesn't come unraveled the way Windows has under the crush of malware and necessary evil anti-virus resource hogs. If Apple keeps the campaign going against their own loyal developers, I'm afraid we're going to start seeing pictures of Steve Jobs turn up defaced with graffiti in the form of a Hitler mustache.
Apple's reasoning is based on the generally poorer look and feel of application generators but they have no evidence that the applications will have poorer look and feel. After all, if the applications are poor quality this should exclude them at the App Store. Adobe could always call it a framework generator, that is meant to produce code that is subsequently modified by a programmer and compiler using XCode.

John Clements  2010-04-13 15:30
I think Apple's new policy is unenforceable. What specifically is the meaning of "originally written in language"? To see what I mean, consider these three scenarios:

1) Developer writes C++ code.

2) Developer writes C++ code using a UI where clicks on certain buttons generate templates consisting of C++ code.

3) Developer writes C++ code using wizards that automatically generate templates after filling in certain fields.

4) Developer writes C++ code using scriptable wizards that take input from text files.

5) Developer writes C++ code using scriptable wizards that accept input from text files written in Ruby.

Hmm... where did we cross the line?