Twiiter

Twitter Updates

    follow me on Twitter
    Loading..
    Loading..
    « iPhone, iPad, Security, and Privacy. Oh my! | Main | New theme »
    Monday
    Apr122010

    Its all about the framework…

    Section 3.3.1

    There are a lot of posts right now about Flash and iPhone. It is pretty heated, a lot of people have very real amounts of time and money tied up in this. I am an iPhone developer, so I am not going to reveal anything covered under NDA, but the text of the relevant license changes has been widely disseminated. Based on my reading of the aforementioned text, I have a few opinions.

    In my opinion this is not purely aimed at Flash, but it is certainly precipitated by Flash CS5. I can't imagine Apple is happy about environments like MonoTouch, Unity3D, PhoneGap, Appcelerator, or Corona, but I am doubtful they would have changed the license in this way just to stop developers using those environments. Some of the people using those environments actually claim they approve of Apple blocking Flash, and are complaining that their tool of choice is merely collateral damage. I think that is very naive, Apple probably doesn't want these environments, they just weren't motivated to stop them until it was clear Adobe was going to pursue Flash apps on the iPhone despite Apple's wishes. They are not collateral damage, they are opportunistic targets that Apple decided to kill once they decided they would have to take action to stop Flash as an iPhone runtime environment anyway.

    The more interesting thing from my standpoint is that this makes it a license violation to include a language interpreter inside a game. If you aren't a game developer you might not be familiar with how large games are structured, but most games consist of a game engine, which is high performance code for doing things like rendering graphics, and an interpreter which runs the game logic (determining how sprites move, determining when to pop up in game text boxes, etc). This is how practically every commercial RPG works, as well as many (most?) other types of games. This affects major app store publishers, like EA, Gameloft, Tapulous, and ngmoco:). Looking at the top ten lists on the app store right now I see several titles that I know have embedded Lua interpreters. In this case I think these apps are genuine collateral damage, though I honestly doubt Apple would attempt to enforce the clause against them. In fact, using an interpretted language for game logic is already technically in violation of section 3.3.2 in the current agreement, though many developers may not realize it because under the original agreement it was okay, and the change that made it verboten was very subtle (changing an "and" to an "or"). I am actually not sure exactly when that changed, and only noticed it myself while I was researching this blog post.

    Why doesn't Apple like 3rd party runtime environments?

    People have speculated about why Apple doesn't like these 3rd party runtimes. The general conclusion is that Apple craves control over the user experience. While they do want control over the user experience, that is generally not a reason to object to 3rd party tools. After all, the majority of developers using these tools are using them to write games, many of which present their own user experience written completely in OpenGL even when using Apple's tools.

    What Apple does care about is their ability to control their own development cycles. iPhoneOS runs on extremely tight schedules, with a very high degree of secrecy, and at a pace completely controlled by Apple. I know it is popular to claim that maintaining binary compatibility is easy, that is the argument du jour made by people claiming Apple should just support developers using private APIs. Well, they are just wrong. Ask anyone who has been involved with a couple of releases of Mac OS or Windows about the amount of effort involved in keeping old apps working, especially those using private APIs. There is a reason why the majority of current and former framework engineers who comment on the issue come out really strongly against any use of private APIs. To really delve into what it takes would be an entire blog post.

    So, if you will indulge my claim that backwards compatibility is hard (even absent the private API issue) it is pretty easy to see why supporting other runtimes is ceding a lot of control to a 3rd party. Imagine if 10% of the apps on iPhone came from Flash. If that was the case, then ensuring Flash didn’t break release to release would be a big deal, much bigger than any other compatibility issues. Since Apple doesn’t have access to Flash CS5’s runtime library code or compiler frontend, they might be put in a position where they would need to coordinate with Adobe to resolve those issues. Shipping a new release where Apple breaks any specific application, even a top seller, is not an issue if the release is compelling, most apps work, and Apple has the option of working with the vendor to help them fix their app. Shipping a release where they break a large percentage of apps is not generally an option. Letting any of these secondary runtimes develop a significant base of applications in the store risks putting Apple in a position where the company that controls that runtime can cause delays in Apple’s release schedule, or worse, demand specific engineering decisions from Apple, under the threat of withholding the information necessary to keep their runtime working.

    This isn’t some perceived risk, I can think of incidents where Apple reverted OS changes, dumped new APIs, or was forced to committing massive engineering resources to something it did not want to do because a Must Not Break™ app vendor told them to. Apple does not want to give anyone that sort of influence over them. So ultimately, preventing Flash on the platform is about control, but is not control over the user experience of the Flash applications, or even the languages used. It is about the runtimes they bring on to the system, and Apple's control over future releases of iPhone OS.

    So who is to blame?

    It is easy to blame all this on Apple, and you will find no end of blogs screaming about their monopolistic power-hungry tendencies. I certainly agree that Apple should probably be more open, and that they are the party with the power to resolve this. If people want to complain about that, you will not hear me defending Apple. The developers using Flash, Unity3D, and MonoTouch have my sympathy, and I understand their anger with Apple. The Adobe evangelists writing screeds get none though.

    The reason is that I think Adobe holds much more of the blame. Adobe is a large company with a significant, and complicated, relationship with Apple. They have frequent high level contacts and meetings. Adobe has known for quite some time about Apple's desire not to have Flash on the iPhone. There is no doubt in my mind that if they asked Apple to bless this they were rebuffed, and if they didn't ask the only reason they didn't was because they knew Apple would say no. In either event, they announced the product to their customers and sold them on an idea they were not in a position to deliver, hoping Apple would be unwilling to piss off developers by not fulfilling Adobe's promises. They tried to force Apple's hand by putting Apple in a position where in order stop the Flash they would have to do it publicly in front of Adobe's users. That was a bad call on Adobe's part.

    Personally, in this whole thing the most distasteful part is that Adobe used its userbase and their livelihood as a bargaining chip. These kinds of high stakes negotiations have happened in the past many times. They are much more common than people think, and until the last few years Apple was more likely to be on the weaker side of the negotiation. The story of MacBasic is a classic example, but I can think of other (not publicly disclosed) incidents involving Adobe and Macromedia (which was acquired by Adobe, and is where the Flash team comes from) applying extreme pressure to Apple. This is the only case where I feel an active user community was publicly jerked around like this in order for one side to try to gain leverage over the other. That is saying a lot, because I am not pleased with Apple's actions either, but Adobe put Apple in a position where either Adobe got its way or Apple screwed developers.

    What Adobe can do

    If Adobe actually wants to persuade Apple to support Flash on iPhone (either as a plugin or compiled to native apps), I know how they can do it. They can get an awesome, high performance, Flash environment working on Android, and get a bunch of great Flash apps running on Android phones. As much as Apple wants to control iPhone, I am willing to bet they want to beat Android more. Currently Adobe is asking Apple to put Adobe in a position where they wield influence over Apple, in exchange for the promise of apps in the future, apps that Apple thinks will be low quality. That is a bad deal. On the other hand, if Adobe proved the apps were high quality by deploying them on competitor's platform, and was offering a library of existing high quality apps that neutralized another competitor's advantage, then there is enough value that Apple probably could be influenced.

    I hear that Flash Player 10.1 is the real deal, and it is going to work fairly well on the HTC EVO 4G. This is an oppurtunity window that is quickly closing. If Adobe had delivered a decent solution two years ago it would have carried a lot more weight, but at this point Apple has managed to cultivate its own 3rd party apps, and convince a lot of major sites to support html5. Every day Adobe does not have a widely deployed mobile Flash, is a day they are not having Flash based mobile apps developed, and is a day the odds of mobile Flash being successful goes down a little bit.

    If Android was making significant gains against Apple, and all of its best apps were Flash based, then Adobe could offer Apple access to all of Android's best apps, which would give them a lot of power. The fact is that there have yet to be any widely deployed Android phones that support Flash. That's right, Adobe has been making the case for Flash on iPhone for 3 years, but still hasn't deployed a non-lite version of Flash on any phones, even when Apple is not obstructing them.

    What I want from Apple

    I am comfortable with what Apple has done with Flash, it doesn't change my view on the platform. It sucks for some developers, but there are not a large number of deployed apps out there. If I were Apple, at this point I would not want to allow Adobe’s tools explicitly because of how they have acted. If this is the kind of crap they try to pull when they don't have influence over Apple through being a major toolchain vendor, imagine the kind of crap they could pull if a substantial portion of the apps on the store were dependent on them. Note that this has nothing to do with the performance or features of the apps themselves.

    I would like Apple to find a way to work with the existing vendors who have (for the most part) been good citizens, and find some way to let them continue. As I said above, I suspect Apple doesn't like their runtimes on the iPhone, but there is still some value in those platforms and I would like Apple to find some way to support them. I think Apple can probably achieve the control it wants over the runtime, and allow for more language flexibility than current license allows.

    Apple should also find some way to loosen the license to officially allow games to use included interpreters for their internal logic. I don't know how to do that without opening up loopholes, but that is what lawyers are for. If they don't do that then effectively they are just using their discretion on a case by case basis, which is completely legitimate, but causes significant uncertainty for developers. Ideally Apple should have some provisions for adjunct or secondary runtimes that let developers use internal scripting. Failing that, Apple should include some language interpreters on the system that games can use for their app logic. While not as flexible as letting games include their own interpreters, if Apple exposed JavascriptCore outside of UIWebView, and included a Lua interpreter in the base system it would solve this as practical a issue for many games.

    Oh, and while I am at it, I want them to do a rapid development tool aimed at light apps. Having a rapid development tool that could be used by non-programmers would probably quench some of the desire for Flash, which is largely driven by the ability of designers to actually create functional apps without significant programming resources. While we are at it, it should run right on the iPad. In other words, I want "HyperCard Touch." And a pony.

    References (6)

    References allow you to track sources for this article, as well as articles that were written in response to this article.
    • Response
      Response: Apple's wager
      The changes to section 3.3.1 of Apple's iPhone SDK license agreement have been extensively covered
    • Response
      Response: ssypmhoq
      ssypmhoq
    • Response
      Response: wfslqvqu
      wfslqvqu
    • Response
      Response: erofpicp
      erofpicp
    • Response
      Response: bcvdwjjl
      bcvdwjjl
    • Response
      Response: aaicfair
      aaicfair

    Reader Comments (122)

    It might be against 3.3.2, but 3.3.1 doesn't affect using Lua in games for internal game logic. I quote "and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs". What Apple doesn't want is for you to write an application in Lua, that goes through a middle process so that it calls Cocoa Touch APIs directly. Using Lua as the glue between pieces of code in the game wouldn't directly call their APIs so it would pass 3.3.1.

    April 12, 2010 | Unregistered CommenterCharles

    In the Unity Forums a spread sheet of Lua/Unity3D games was started. http://bit.ly/d4oJzK

    Good read , thanks :-)

    April 12, 2010 | Unregistered CommenterNicolas Goles

    A list of accepted tools would suffice. Fairly good read otherwise

    April 12, 2010 | Unregistered CommenterWayne

    @Charles:

    I agree that is a perfectly reasonable interpretation of that sentence. The problem is the sentence before that (also part of 3.3.1): "Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine." If you want to argue that the script code bundled with the engine is not part of an application then it might not be an issue with 3.3.1. I am not a lawyer, but I would not be comfortable making that claim.

    @Nicolas:

    Thanks for the link, I will definitely be checking that out over the next few days.

    April 12, 2010 | Registered CommenterLouis Gerbarg

    I'm a former Apple engineer. I've been a full-time iPhone developer for the past two years, but after the developments of this past week, specifically sections 3.3.1 and 3.3.9, I'm really thinking I don't want to work on software for Apple any more. And after reading your post I'm certain I don't want any thing to do with Apple any more. Apple is an untrustworthy business partner. Posts like this make a case that this is all "just business", but if it's just business why does Apple act so dishonorably? Why let Adobe develop their Flash compiler for six months then make it illegal 2 days before it's released? How is that business-like? Why screw companies like Corona? Mono? Appcellerator? Unity? Flurry? MediaLets? Even if you've been a good little developer and not strayed from the One True Path you're next.

    April 12, 2010 | Unregistered CommenterRelwal

    I'm a Flash platform developer and I agree with you entirely. I really think Adobe have missed the boat. They should have put all their time and effort into working with the W3C to integrate the Flash platform and maybe developed tools to compile from Flash to HTML5 and WebGL. They'd have been all over the iPhone and would have snuggled up to Steve Jobs quite nicely by now. Also, what you've said about the Android phones is correct also, I bought a HTC Hero on the promise that I'd be able to develop some Flash apps for it ... that promise was made over a year ago and they're never going to fulfill it. Everyone seems to be talking about the developers being kicked in the teeth ... sod the developers! What does the user want?

    April 12, 2010 | Unregistered CommenterLee Probert

    Gimme a break. The way *Adobe* have acted? Are you serious? You honestly cannot see the "screw you' message Apple is sending to its developers? It's worrying that you seem to be defending their actions - you call it 'business', I call it greed with utter disregard for anyone who stands in the way. I'm convinced that this will eventually back-fire on Apple big time. Of course in the minds of some, Apple clearly can do no wrong, and I'm sure if they hiked App Store fees to a 90% cut for themselves we'd still see some proponents rush to Apple's defence. There's always iAds to make a quick buck, right?

    In the meantime I will not be investing another cent into the iPhone platform, and rethink any other Apple purchase twice over. They've overstepped the line big time.

    April 12, 2010 | Unregistered CommenterStefan Richter

    Monotouch generally maps a new SDK within 1-2 days of its release - and are done during the betas. Every part of Monotouch is a 1-1 mapping of UIKit, you can only do custom UIs the same way you would in objective-C, via Cocoa.

    The announcement was made 3 days before Adobe planned to launch CS5 - of course this is a deliberate middle finger to Adobe and in the most humiliating way possible. I'm hoping Apple doesn't care about the other frameworks in future app store reviews and turn a blind eye.

    April 12, 2010 | Unregistered CommenterChris

    I second your wish for "HyperCard Touch" - you can keep the pony.

    April 12, 2010 | Unregistered Commentervmarks

    Why are the developers not saying that they want to control THEIR own development cycles? To be in control of their own destiny?

    Instead of worrying about themselves they're making excuses on Apples behalf, as though it wouldn't matter if they died as long as Apple shines on.

    Apple may pull the plug on you at any time. Have you prepared for that?
    This is not about Flash or Adobe's business. This is about your business.

    Thinking in cross-platform terms is a way to protect oneself from the maniac,
    even if the only profitable target platform was the iPlatform at the moment.

    April 12, 2010 | Unregistered CommenterFed up

    This isn’t some perceived risk, I can think of incidents where Apple reverted OS changes, dumped new APIs, or was forced to committing massive engineering resources to something it did not want to do because a Must Not Break™ app vendor told them to. Apple does not want to give anyone that sort of influence over them.

    That sentence is missing the last two words: "ever again".

    Apple has been there - they don't want to go back.

    April 12, 2010 | Unregistered CommenterMarshall

    Very interesting read, and a perspective I haven't heard before. Thanks very much for writing this.

    April 12, 2010 | Unregistered CommenterGrover

    Flash runs so well on osx, I can't wait to have that shit running on my phone.

    April 12, 2010 | Unregistered Commenterdurp

    As seen on a mailing list:
    ---
    That article makes a basic mistake on the grounds of backwards compatibility.

    Apple needs to ensure backwards compatibility for all the software on the AppStore, or risk having applications stop working. This needs to be done regardless of the languages and tools used to develop the software.

    In particular, if you use a third party library, let us say "CuteJsonParser" and you break the OS compatibility, every application using CuteJsonParser (and probably more) would be broken.

    If they were to break compatibility due to a major cause (let us say, "security hole" for the sake of the argument) it would be easier to get large swats of applications fixed by having developers recompile their code once with an updated tool, than having thousands of developers all audit their code. This is a classic one-to-many is better than a many-to-many setups.

    April 12, 2010 | Unregistered Commenterxyz

    This change is purely to stop Flash and the other app builder apps are collateral damage. I dont buy the argument that Apple are doing this to protect thier framework and platform. MonoTocuh for example doesnt use any API's not included in the documented SDK and is slave to whatever Apple put in the iPhone SDK going forward. Nothing MonoTouch does is going to put the Apple platform at risk. I can see an argument for not wanting another framework (.NET for example) to become the defacto standard, but that is a pointless fight. If Objective-C and Xcode has advantages over MonoDevelop and MonoTouch, who would use the latter? Brute forcing people to use a particular environment is the road to hell. It drives devs away and ultimatly weakens your entire framework. If this runs its natural course the App store and iPhone/iPad platform will ultimately die. It might seem that way now but its inevitable if the logic of these clauses stands.

    April 12, 2010 | Unregistered Commenterjga

    The real reason for the clause is very simple:

    AppStore market share in 2009 is 99.4% of the market:

    http://arstechnica.com/apple/news/2010/01/apple-responsible-for-994-of-mobile-app-sales-in-2009.ars

    Market revenues for mobile operators:

    http://www.ismashphone.com/2009/08/a-visualized-look-at-the-estimated-revenues-of-the-top-cell-phone-manufacturers.html

    There has been a litany of excuses from nerds on this subject ("Objective-C is beautiful", "If you cant write in Objective-C you are an idiot", "nothing beats strcmp to compare two blocks of strings, learn it or leave").

    The reality is that there is a crass business reason for this: anything that would allow developers to target other mobile platforms is a risk. Flash would make it easy for developers to write once and deploy anywhere.

    Using Objective-C means that you will be stuck in Apple-land until you decide that you are wiling to rewrite your code, line-by-line in Java for Android, in C# for Windows7 and in C++ for Symbian/Blackberry.

    This is not a programming issue, this is a clause to prevent 2 BILLION DOLLARS FROM GOING AWAY.

    It is crass, but it is the reality.

    Follow the money, like they say.

    April 12, 2010 | Unregistered Commenterxyz

    @Relwal. I think you missed the author's point. Adobe developed the CS5 iPhone packager either 1) after asking and Apple said no, or 2) without asking because they knew Apple would say no.

    Like the author says, Adobe was the one playing dirty here by forcing Apple into a position where it needed to tick off a bunch of people or let Adobe get its way. It's basically blackmail on Adobe's part.

    When you think about how long it took Adobe just to develop a Cocoa version of the Creative Suite, why should Apple trust them to keep the iPhone packager up-to-date?

    April 12, 2010 | Unregistered CommenterAaron

    Writing a program for the app store is little more than entering into a business relationship with Apple. Would you willingly decide to enter a partnership with a 10-year old petulant child, that demands the rules change whenever they're not winning?

    How can one plan ahead knowing that Apple is ready to change all the rules at the drop of a hat?

    And from a technical standpoint: clearly the really great developers at Apple must have disappeared-- as a developer myself, I frequently use _whichever_ tool is best for the job. If that happens to be interpreters, so be it. Language choices decreed from on high have always come from Dilbert PHBs that don't understand a single thing about programming.

    April 12, 2010 | Unregistered Commentergrisha

    "Since Apple doesn’t have access to Flash CS5’s runtime library code or compiler frontend, they might be put in a position where they would need to coordinate with Adobe to resolve those issues. "

    as long as Adobe only used public APIs why would a new OS break Adobe's cross compiler?

    April 12, 2010 | Unregistered Commenterphil swenson

    but, but, wait, my 4 years old nokia phone can play flash game and play mp3, at same time.
    from end user point of view, Apple just want to making more money by force use pay what is free.

    PS: flash running very slow on OSX, slower than intel Atom. I have to test my app on windowes to be sure the speed is OK.

    April 12, 2010 | Unregistered Commentermaddog007

    Great read.

    I hated the CS5 to iPhone feature as it would've destroyed the App Store. The low barrier-to-entry means a flood of low grade apps that people wouldn't want to pay for and likely to bring the average app price all the way down to $0. The App Store would be have gone the way of Youtube Comments.

    Reading this post has given me a new, well-rounded perspective on the issue.

    April 12, 2010 | Unregistered Commentervjk2005

    Flash and "developer" do not belong in the same sentence. Flash is bloated, unreliable, proprietary garbage on any platform and Adobe knows it. So boo hoo for them. I'm amused by all the whiners saying they won't write for the iPhone anymore. Nobody cares, it will not affect Apple at all, and learn a real language crybabies. Go write for the former Windows Mobile clone, now iPhone clone Android where they still can't manage to install and run more than 512MB of apps. Where the app store is garbage. Where every single touchscreen so far sucks and the rest of the hardware is not much better. Hey maybe you can write for blackberry or WinMo 7 when and if it ever comes out. All this means for users is better apps on the iPhone/iPad.

    Louis' post is the most amusing. Nobody cares if you are a "former Apple engineer" although we now know why its former. So newsflash...Apple is not obligated to tell anyone what they should or should not develop for the iPhone. It's their platform and the users. The users come out ahead in this squabble and there are plenty of talented committed developers to make up for every one of you whiners.

    The only people pissed off about this are companies like Adobe and the Flash "developers". Nobody else cares.

    April 12, 2010 | Unregistered CommenterDarwin

    Why are the developers not saying that they want to control THEIR own development cycles? To be in control of their own destiny?

    Because then, to actually put their money where their mouth is, they’d have to make their own phones too.

    April 12, 2010 | Unregistered CommenterPaul D. Waite

    Thinking in cross-platform terms is a way to protect oneself from the maniac, even if the only profitable target platform was the iPlatform at the moment.

    And nothing stops developers from doing that even with the new agreement. Write the core of your app in C/C++ then wrap that with ObjC and Cocoa touch, if you do it properly, you have well structured code that can migrate to multiple platforms and doesn't lock you into a particular environment like Flash.

    Sounds to me like what you really want is to develop for a different platform and have the app available for sale on Apple's platform, because well, let's be honest, there are other app stores, but only Apple has built a market for mobile apps.

    April 12, 2010 | Unregistered Commenterhuxley

    Excellent post and explanation.

    iPhone's market share is also part of the issue too. Apple is able to use the platform as a hammer against Adobe and Flash.

    Part of the reason you didn't mention is that Apple wants developers to learn the iPhone SDK and make it their platform of choice. You might know several programming platforms, but you usually have a "favorite", and Apple wants iPhone to be that favorite.

    A lot of people are claiming they're going to stop developing for the iPhone, but I take that as seriously as a 7 year old threatening to hold his breath until he gets ice cream for supper. You think Android development is any better? You have four active OS revisions you have to program against right now, and a dozen separate hardware platforms you have to test against. And, it's going to get messier. Verizon is planning to prevent people from going to the Android store and force users to go to VCast. You want your Android App in front of users? You're going to have to go through Verizon for permission.

    WebOS is dead. It was a nice platform and people tell me more open than Android. Meebo and Bada have even smaller communities. The only real competitor is Windows 7 Mobile, but there aren't any Windows 7Mobile phones. Besides that, Microsoft is wholesale coping entire chapters out of Apple's playbook. It won't be any more open than iPhone.

    If I was a Flash developer hoping to get into the mobile marketplace, I'd be pissed at Apple. I would cuss and scream. And, then I would swallow my pride, download the iPhone SDK and spend the next two week in seclusion learning it because if I want to make money, that's where the money is.

    Maybe Android development will get its act together. Maybe Windows 7 Mobile will open up a bit more and become a serious competitor against the iPhone. And, when that happens, Apple will change its mind. Until then, Apple will simply use its position to the best of its advantage.

    As you pointed out, Adobe could have had a working version of Flash 10.1 out on Android a year ago, but didn't. It could have come up with a Flash 10.1 for RIM but didn't. And, despite what Adobe says, it still doesn't have a Flash 10.1 out. In fact, the only mobile device that runs Flash 10.1 is the JooJoo pad, and it does such a rotten job (poor frame rates and drained battery life) that I almost think that the JooJoo pad was an evil plot by Apple to "prove" that Flash is bad.

    April 12, 2010 | Unregistered CommenterDavid W
    Comments for this entry have been disabled. Additional comments may not be added to this entry at this time.