Its all about the framework…
Monday, April 12, 2010 at 1:05AM 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.
Reader Comments (122)
For the "devs" that leave, go make something great elsewhere. Good luck. Remember, there is always someone willing to fill the gap you leave. The iPad is not cheap, nor are the people who own them - 3.5 million apps downloaded in five days.
All Apple have to do is license tools officially. Therefore they can tell the tool developers or game engine developers what is required. They would then have a direct line of communication with the tool makers.
The private API's argument doesn't fly with me because we all create our own libraries and mini engines. This is purely over cross platform apps, funny that Apple didn't mind Adobe Air creating apps for their platform.
I've lived with Adobe products on the Mac platform for the last ten years.
I've loved my un-jailbroken iPhones since I got one the first day that the first one was available.
I love my new iPad.
I'm ordering a new MacBook Pro as soon as they drop (maybe Tuesday????)
<shrug>
This post was very insightful, but I think it is still a bit too sympathetic to Apple's position.
If Apple makes a big change to their API that would actually break apps based on Adobe's platform, it could just as easily break individual developers' apps. This in fact is one reason I use Unity: if Apple changes something, the Unity guys are going to catch and fix it much faster than I would alone.
If Adobe is too sluggish to keep up with Apple's changes then developers will abandon that platform or their apps will get poorly rated. Either way, the market does the heavy lifting.
Trying to enforce section 3.3.1 rule as currently written puts the burden of enforcement on Apple's already-stressed app approval process, and hamstrings developers. I honestly think Apple has no idea how many of today's apps would technically be in violation of 3.3.1.
There is another angle to this, which is that with this rule Apple makes it more difficult for a company like Google or Adobe to substitute their own ad/social network, even making Apple's inaccessible to developers. That's a whole other topic, but again, I think there are better ways for Apple to tackle the problem.
Apple will always shaft the geek for the consumer. They want to be able to dictate that the iPhone never crashes and there is never a BSOD. They want iPads and iPhones and iPad Touches to be like your toaster. It only breaks when your drop it.
Unfortunately for them, in technology, like in Love and Marriage, you can't have one without the other.
This comment assumes that (a) Apple knew when Flash CS5 was to be released, and (b) that Apple had any power to stop Adobe from pursuing what amounted to a big game of chicken. Neither is a foregone assumption.
Look, Adobe knew that Apple doesn't want Flash on the iPhone. It's hardly been a secret, I think, and certainly it's not been a secret to the folks who have wagered so much of their company's revenue on the adoption of Flash. (Apple's also not the only organization that's hostile to Flash, but that's another discussion). Adobe was hoping that, by pressing forward with their development initiatives despite the fact that they knew Apple was opposed to Flash on the iPhone platform, they could force Apple to blink. They were hoping to use market power and momentum to force Apple to accept a solution that Apple didn't want to accept.
They played a game of chicken, big corporation against big corporation, and they lost this round. Them's the breaks sometimes.
Fundamentally, this is really a simple problem. Apple's the one selling the iPhone platform, and they have every right to decide under what terms those sales are made. If not having Flash on your iPhone is a deal-breaker for you, don't buy an iPhone. But Adobe has no right to force Apple to support Flash, any more than Microsoft could force Apple to support .NET on the iPhone. Apple built the platform, Apple created an opportunity for iPhone developers to make money, and Apple has the right to set the rules of the game in their marketplace. Don't like it? Buy an Android phone, or a Windows 7 phone, or whatever. (Is anyone bagging on Microsoft because you can't develop apps for it with Xcode?)
Or are the pro-Flash people really saying that Apple doesn't have the right to control its OWN platform? That any company with enough market muscle should be able to force a competitor to support their platform? Are you really arguing that a competitor should be able to force Apple to take an action which Apple views as contrary to its interests, simply because that competitor has some muscle in the marketplace?
Get real.
As I said above, Adobe played a game of chicken with Apple. Adobe bet a lot of money on their ability to strong-arm Apple into supporting Flash by presenting Flash on the iPhone as a fait accompli. Adobe lost. Sorry, but that's the way the cookie crumbles. Do you honestly think Adobe wouldn't do the same thing to their competitors, if they thought they could get away with it? Do you honestly think they haven't?
Great article but I think your missing a key change about the rule. Interpreters were already against the rules, technically, because of 3.3.2. I think the major problem is that now apple is also banning source to source compilers. Also, I doubt that an interpreters which only uses public APIs will be much more likely to break with a new OS then a regular application.
Ironically someone is attempting a 'hypercard touch' for the iPhone (http://www.runrev.com). I guess this sinks them too.
I don't see the license wording as banning Lua. Look at it carefully: "Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited."
It looks to me that Apple is okay with interpreters as long as those interpreters aren't being used to talk directly to the operating system (such as iPhone Wax). A scripting language that interfaces with your own C code should be fine. There are a few hazy areas, such as loading files directly from Lua (which I double Apple cares about).
Has anyone here actually tried the Flash based apps already available in the App Store? They suck. And the reviews are horrible.
Don't feel bad for Adobe. Apple didn't screw them in the 11th hour. They were fully aware that Apple did not support their intention to provide an iPhone Flash compiler in CS5, yet they kept going anyway.
Apple has defined a set of tools for developers to use to develop iPhone OS apps, and some rules for how those tools should be used. If someone wants to visit my house for a party, I can give them directions to get there, and maybe tell them what to bring. I may set the tone by saying that it's a dinner party with friends and family, and that implies a certain set of rules to be followed. If one of the invitees starts telling other guests that they're going to bring their drums and really "rock the house", I may have to explicitly state that it's not that kind of party and, if that person still wants to attend, they'll have to leave the drums at home. They can show up with the drums anyway if they choose to do so, but I'm not going to let them in just because they decided that it would be OK for them not to follow the rules.
Regarding the "HyperCard Touch" rapid development tool aimed at light apps - don't they have that already - in the form of web apps?
This is an attack by Apple on the toolchain.
Your arguments about the "runtime problem" are hollow, because these runtimes (and programs generated from environments other than Objective C) have to play by the same rules as "originally written" code. They can't call private APIs.
Any problems with "backwards compatibility" encountered by another runtime or intermediate library could be encountered by any pure Objective C program invoking the same APIs.
Apple's gateway IS the public API. This is a very reasonable and supportable thing for them to do. It's also reasonable for them to prohibit creating a runtime that allows downloading and execution of external, arbitrary code from the net.
It's not reasonable for them to prohibit INTERNAL code execution (like scripts in an application that are embedded in the app). It's not reasonable for them to impose a particular development methodology and authoring set on developers.
To paraphrase, "Any reasonable complex program contains a buggy informal LISP interpreter". The same principals apply here.
@jga
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?
Lazy developers, that negate everything new or that they don't know!
coherent post thax
Facts:
- If your iPhone app adheres to Apple's guidelines, nothing changes
- If your iPhone app doesn't use private APIs, nothing changes
- If your iPhone app was developed using CocoaTouch, nothing changes
- Adding the iPhoneOS 4 features to an app that abide by the former three bullets is a breeze and will get it approved without a hassle
- If you try to walk on or step across the boundaries Apple has clearly stated in the past, you should and are probably well aware that your success may be hanging on a tight rope
- Apple wants their platform to be the best out there. Since apps are a major part of that, it's quite normal Apple wants to keep it that way by making sure performance and memory usage on a "limited" mobile device are top-notch. Part of that QA is done when you submit your app for approval. Third-party frameworks could lead to apps not being approved and we all know how much of a fuss non-approved apps have caused in the past. Imagine the uproar if ALL these apps would be disapproved because of the framework and you have a "developer" on the other end who doesn't know what an intermediary framework actually is.
- Apple's development tools are quite easy to learn as a developer, the learning curve isn't that steep as some claim it to be. Of course, if you're a WYSIWYG developer and your code writing knowledge is trivial, everything's too hard.
- If you don't have the knowledge inhouse or you don't want to invest in it, either outsource it or find another way to make money than through the app store.
I'm quite sure there are some smart companies out there, like Unity3D and MonoTouch, who will find a way to put their code into XCode so you can compile a native and compliant application. Adobe must have been very aware of what they were doing and how much of a buzz the new section paragraph would generate on the web.
Apple has the right to keep their platform as closed as they want to and frankly, I believe we all like the iPhone just because Apple kept so much control over it. Have you used an Android-based cellphone? It's a horrible experience imo. But hey, you can brag about being able to run lots of apps simultaneously for the little time your cell has battery life. And none of them feel the same, but that's not surprising on a platform where even the OS doesn't have any consistency in it.
I am still amazed that everyone is so P.O.'d about this closed system where apps have to be verified by the vendor, built using tools approved by the vendor and only run on a single platform.
This closed system is called the XBox.
Or the Playstation.
Or the DS.
Really people, video game platforms have had the exact same set-up as the iPhone for years and nobody boohoo'd about it. Now that it's apple, suddenly is wrong for THEM to do it, but fine for MS, Sony and Nintendo to HAVE DONE IT FOR 20 Years.
*shakes head in amazement* really....just.....wow....
Making JSCore available or a sanctioned Lua lib would be a great move by apple and is needed.
My concern is what impact this new section has on Python and other scripting languages. Flash can go hang for all I care.
Another possible casualty: the nascent Qt for iPhone project.
@Relwal:
As I said in the post, I think it is very unlikely that Adobe was surprised about Apple's objections. Having said that, every platform has its tradeoffs, and if the way Apple manage's iPhone is not something you feel allows you to work on the platform then it is probably best to find a different platform where you find the various tradeoffs acceptable.
@Stefan:
From my perspective Adobe promised their developers something they were not in a position to deliver, then threw their developers in the middle of a game of chicken with Apple. Yeah, that is pretty bad in my book. I say this as someone who has had my share app submission issues with Apple. None of the platforms is a panacea, they are all trade offs, iPhone is no exception. Apple did something that, rightfully, pissed a bunch of people off. But they did it because Adobe kept pushing them. They are both to some extend responsible for the current situation, in my mind Adobe much more so, though everyone needs to weigh the facts they have available to them and make their on call on that.
@xyz:
It is a lot more complex than that. Just to give you an example: On one OS release we were doing we found there was a latent bug in a 3rd party sound library that was used by a number of popular games. The bug was a memory smasher that hadn't been an issue previously because of the exact pattern of accesses, but we were changing the allocator to make substantial improvements, which changed the pattern and exposed the bug. We couldn't even find a work around for the bug (short of reverting all the memory allocator changes) because 90% of the games code was written in a proprietary scripting language we did not have debug tools for which meant that trapping it in GDB we just watched their main interpreter loop. In that case the vendor was actually unable to help us for reasons I can't get into, but for the same reasons they were pretty sure they couldn't roll a patch to game either.
Thats one game, but it is a real story. Now replace "3rd party sound library" with "Flash runtime." Obviously every library has this issue, but the more apps using the library, the more likely that Apple will need to find an OS level workaround to keep it working, the larger the library the more chance of a bug, and when the library uses its own language/compiler there is a greater chance Apple cannot track down the issue on its own, and becomes dependent on a 3rd party.
@Chris:
I assert that it is not the mapping of the APIs that is the issue, it is the substantial amount of additional runtime machinery that these environments include. I have not looked in depth at MonoTouch, but I know that it includes a substantial runtime that they see as a competitive advantage, as you can see in their recent blog post. Having said that, I think that there has to be some accommodation for these sorts of things in the long run.
@grisha:
I am going to assume you have never done any development for other closed platforms. Despite the sort of app store issues that people (including myself) have seen, it is light years ahead of any previous mobile devices or video game platforms in terms of certification. The kind of stuff that Apple does is nothing compared to what the cellular carriers used to do, or what the the game console companies still do.
Obviously, in comparison to open platforms (where a lot of the current iPhone developers come from) the approval process is very frustrating, but plenty of people have made plenty of money working with companies that had much more restrictive rules that were subject to change on a whim.
Again, it is about what tradeoffs each individual developer is willing to make.
@phil:
I assume you are talking about Flash Lite, which is a subset of Flash. It is a substantially different thing, and I think there are close to 200 million installed devices. Having said that, it is not "Flash" in sense that most people thing of it.
@Darwin:
I think you confused Relwal's post with mine. That is my fault, the seperate line in my comments was not intuitively placed. I have moved it to make it clearer (though it is a bit uglier now). Having said that, I am also a former Apple engineer ;-)
@Matt:
I try to be objective, but ultimately this blog is going to tend to lean in Apple's favor because I am with the issues of shipping an OS and dealing with issues from that side of things.
@James:
If I need to squint and look at the license to read it the way I want I get nervous, even if I only need to do that because it is ambiguous. Ultimately it is Apple who gets to set the intent of the license, since they can change it at any time.
Having said that, you might be right, that might be what the intend. I hope so, and if I was developing a game I might just assume that. But if I was going to be trying to develop some middleware product I certainly would be hesitant to wager a lot on that without clarifications from Apple.
@Jimmi:
That may provide a runtime environment, but there is no hypercard like development environment that builds html5 apps.
Completly agrée with this read.
I'm a developer too and I confirm that background compatibility is a HUGE issue in software and more particularly in OSes/SDKs.
MacOS used to suffer from this. Just look at the reason why Snow Leopard is here.
On the other way Adobe used only a 'offensive' strategy. Why didn't they try to implement smarter Flash light using JavaScript/HTML 5 features ?
Why didn't they try using smarter app builder using tighter OS integration in templated Xcode projects ?
In all scenario the reply is the same : Adobe doesn't want Flash to become an Open format (Open source).
It's a war between two companies that want to keep 100% of control over their tools.
The only difference is that Apple isn't claiming their case to be opened.
Has anyone considered that Apple may have authorized it and then changed its mind?
It has happened before with 64bit Carbon
Adobe missed the boat. And they treated the Mac as a second class customer for nearly 15 years. Karma is a bitch. Apple went thru the down cycle of being dependent on almost absolutely every other tech company they ever dealt with. Now they are in a position to throw their weight around and they have every right to. And spare me the monopoly talk or "Apple is a big bully" garbage.It's their phone, it's their platform. When the iPhone is the only phone you can buy, come back and see me. Apple is under absolutely no obligation to assist Adobe in making money, ot to allow Adobe even a modicum of control over Apple's mobile platform Like I and many other people have already said, they already know where that leads.
Blah blah. Can we have Python then?
Maybe someone can help me out here, but when has there EVER been a useful Flash application? Do we really want the entire Newgrounds Flash database ported to the iPhone, especially when now there's the option of making people pay for those games? It would be ridiculous for Apple to allow such a gaping loophole to exist.
Will be interesting to see what apple is doing cause apple has shown Tap Tap Revenge 3 on stage which is clearly violating their own new ruling so they shot their own legs.
Its clear that if apple is going to enforce this, they will have their army of lawyers permanentely seated at court cause every single app that is allowed to go to the store will form a new base to go legally against apple for unfair treatment
I doubt that apple will be that stupid cause otherwise they will lose much much more money with the app store than they ever feared they could and it would not the least bit help their already existing problems with the FTC etc
Apple should have done finally what they should have done since day 1:
1. Quality and performance guidelines for all "immersive type apps" (non UIKit driven) that would have killed 99% of all flash apps too
2. Finally add an approval fee of $100 per app to ensure that people stop sending in trash just to have enough cross referencing. if you lose $70 with a send in by your expectations its clear that you will stop sending it in.