Forgot your password?
typodupeerror
Iphone Apple

Apple Relaxes iOS Development Tool Restrictions 347

Posted by CmdrTaco
from the no-complaints-here dept.
An anonymous reader writes "Earlier this year Apple caused major upset among developers by updating the iPhone developer program license with clause 3.3.1. It basically stopped the use of cross-platform compilers, meaning Adobe Flash could not be used to develop an app for the App Store. The move also put into doubt which other development platforms could be used and generally caused a lot of confusion. Apple has just significantly relaxed that policy and allowed for the use of development tools, as long as 'the resulting apps do not download any code.'"
This discussion has been archived. No new comments can be posted.

Apple Relaxes iOS Development Tool Restrictions

Comments Filter:
  • Problem (Score:3, Insightful)

    by Anonymous Coward on Thursday September 09, 2010 @10:52AM (#33521836)

    There are still interesting problems in not allowing to download or update any code. With the rise of jailbreaking iPhones and them running unsigned and modified applications (cracked and/or otherwise), there is no way for an anticheat system to update itself. All anticheat systems like Valve's VAC, PunkBuster and Blizzard's Warden rely on downloading updated code from the internet.

    What this means for online iPhone games is that when someone releases a hack for the jailbroken iPhones, their users can completely ruin the games and legit players cannot do anything. And since Apple is a control freak, they check every update to your application slowly and ineffectely. All while the hacking is rampant and ruins everyones game.

    There certainly are need for updating code and Apple needs to remove that clause too. We don't want walled gardens controlled by mega corporations, we want systems we can use the way we want.

    • Re:Problem (Score:4, Insightful)

      by Kjella (173770) on Thursday September 09, 2010 @10:57AM (#33521970) Homepage

      And how is the situation you describe any different than every console? If you live in a signed sandbox, you live on the good graces of the signee. Doesn't seem like that's a dealbreaker to anyone.

      • Look at the differences between the Orange Box version of Team Fortress 2 and the PC version. Yeah, its a pretty big deal. Plus, Xbox live has a team to crack down on modded consoles that could have cheats.

        But yeah, its a pretty big deal not being able to have lots of content such as Team Fortress 2.
      • Re: (Score:3, Insightful)

        by Hatta (162192)

        Why do you assume that's not a deal breaker for anyone? Every console ever has been hacked, people wouldn't do that if they didn't object to being restricted.

    • On another note. Mozilla could release their Fenec browser. However, add-ons would have to be disabled as they download extra code.

      I only wish!

    • by SuperKendall (25149) on Thursday September 09, 2010 @11:25AM (#33522442)

      there is no way for an anticheat system to update itself.

      What's to prevent the game maker from simply issuing a software update, and having software issue challenges to each other related to versions before accepting games?

      Online cheating is not as great a problem as with the PC's or consoles.

      It only takes a few seconds to update a new version on the device.

      • Re: (Score:2, Informative)

        Not when each of those versions has to go through another round of approval.

        • Re: (Score:3, Informative)

          by BasilBrush (643681)

          These days it typically takes a couple of days for approval. Sometimes it can be as short as a few hours.

    • Most of the time these worries are about anti virus instead. There the updates also contain exe updates.

      But the same update mechanism used for an normal application can apply to a any application. Let it bet antivirus, anti-cheat or a simple game. If you want to update it you do it via a the app-store, and don't come up with a own update system. If that is not good enough, that should be updated, not implement it on yourself.

      The fact that windows does not have a central update system and every app has to d

    • by blueg3 (192743)

      The anti-cheat systems require updating code and not updating data that is used by code?

    • Re:Problem (Score:5, Interesting)

      by tlhIngan (30335) <<ten.frow> <ta> <todhsals>> on Thursday September 09, 2010 @11:55AM (#33522954)

      There are still interesting problems in not allowing to download or update any code. With the rise of jailbreaking iPhones and them running unsigned and modified applications (cracked and/or otherwise), there is no way for an anticheat system to update itself. All anticheat systems like Valve's VAC, PunkBuster and Blizzard's Warden rely on downloading updated code from the internet.

      What this means for online iPhone games is that when someone releases a hack for the jailbroken iPhones, their users can completely ruin the games and legit players cannot do anything. And since Apple is a control freak, they check every update to your application slowly and ineffectely. All while the hacking is rampant and ruins everyones game.

      There certainly are need for updating code and Apple needs to remove that clause too. We don't want walled gardens controlled by mega corporations, we want systems we can use the way we want.

      Jailbroken and/or pirated apps are easily detected. So easily detected, that Apple doesn't really bother, because apps can do it themselves.

      Firstly, an app downloaded from the App Store has DRM on it, which consists mostly of encrypted portions of the binary. That binary is then signed. On running the app, the kernel loads the app, validates the signature, then in-memory decrypts the binary, and finally runs it.

      A cracked app can't be re-encrypted for a specific device, so they're shipped decrypted. The kernel, however, cannot load unsigned binaries unless a special flag is set to indicate that it's a decrypted binary that's OK.

      An app just needs to check for that flag which exists in its info.plist file. It can do several checks - first, is info.plist in text format (it should be binary XML)? Second, do those keys exist in the file?

      The apps that do the obvious checks are quickly re-patched to disable those checks, but there's nothing to say that an app has to pop up an "I'm pirated!" notice - it can silently report its pirated status to the server, for example, but otherwise run normally. Most crackers don't check, and most pirates won't bother. Even the ones running Firewall IP (a really nice firewall alert). You need someone to actually go and sniff the WiFi transmissions to ensure it's sending the same data to the server. Use SSL and you're golden. (Sure the pirate could disable all network access, but then who cares about single-player cheating?).

      Also, assets are signed as well, so replacing all the textures with transparent ones also have the exact same issue - you have to go and decrypt the binary, make your mods and set the flag. There are also tests for jailbroken phones as well.

      Online multiplayer is not a huge thing on iPhones, iPads and iPod Touches - at least, the ones where you can't do server-side validation of inputs (which you should do anyways). Local multiplayer may be a bigger deal, but there are probably social pressures against that behavior as well.

    • What this means for online iPhone games is that when someone releases a hack for the jailbroken iPhones, their users can completely ruin the games and legit players cannot do anything.

      it also means that a developer can't "bait and switch" by getting an app approved and then adding code that allows the app to do things that would have prevented it from being approved in the first place. So there isn't a "Certainly a need" as the updates to code could go through the app updates system, and the developer can plug those holes in a normal update. Furthermore, the problem you are referring to should reasonably be secured at the server end, anyway, since, as you pointed out, the game can never

    • by takev (214836)
      I find anti-cheating software an unnecessary evil.

      It is very basic software engineering: "never trust input from a user". As the client software of game is in the hands of the user this extends to the client itself. In fact this also extends to the anti-cheating software itself.

      Like DRM, anti-cheating software is a mathematical impossibility.

      It is far easier to just design your game so that you do not trust the client code, run the simulation/game on the server and let the client be a dumb terminal. Dumb be
      • Re: (Score:3, Informative)

        by afabbro (33948)

        I find anti-cheating software an unnecessary evil. It is very basic software engineering: "never trust input from a user". As the client software of game is in the hands of the user this extends to the client itself. In fact this also extends to the anti-cheating software itself. Like DRM, anti-cheating software is a mathematical impossibility.

        Much as I hate to step on a good pompous rant, you're oversimplifying and missing quite a bit. For example, there's rendering information the server has to send the client. If the client is altered to make some of the rendering transparent, the ability to look through walls is gained, which is cheating. No "trusting user input" is needed here. It would not be practical to render on the server and send the frames to the client, yet the client needs info that the user can't necessarily see to render corre

  • This would have been the first app had it not been for the stupid restrictions.

  • Yea (Score:2, Interesting)

    by mrsteveman1 (1010381)

    It's refreshing to see Apple wrong so many times in a row. Watching them backpedal is amusing.

    • Re:Yea (Score:4, Insightful)

      by Tom (822) on Thursday September 09, 2010 @11:09AM (#33522194) Homepage Journal

      At least they are. We all know companies that'd rather die than admit they were wrong.

      • Re: (Score:3, Interesting)

        At least they are. We all know companies that'd rather die than admit they were wrong.

        Such as? I suspect that if you name a company or companies, people can point out similar things they backpedaled on.

      • Re:Yea (Score:5, Insightful)

        by 0xdeadbeef (28836) on Thursday September 09, 2010 @12:33PM (#33523588) Homepage Journal

        We all know companies that'd rather die than admit they were wrong.

        Yes, Apple. Does this sound like a mea culpa?

        The App Store is perhaps the most important milestone in the history of mobile software. Working together with our developers, we will continue to surprise and delight our users with innovative mobile apps.

        They didn't admit that their critics were right, the said that they "listened to their developers". As one of those developers, I assure you that what they really listened to was negative press and Android's rising numbers.

        • Re:Yea (Score:5, Insightful)

          by abhi_beckert (785219) on Thursday September 09, 2010 @02:53PM (#33525776)

          Get off your high horse.

          Just because Apple doesn't carry out the wishes of every individual developer doesn't mean they don't listen. The ENTIRE POINT of the app store is to allow developers to create and distribute great software.

          Do you seriously think apple doesn't give a shit about developers? If that was true, there would be no app store at all.

    • Re: (Score:2, Insightful)

      by Zelgadiss (213127)

      No significantly complex system comes out right the first time.
      Apple has a goal, I believe it's to give as much freedom to 3rd party developers without losing control of the platform.

      It's like how Blizzard balances WoW, they have "back-pedalled" countless times.

      • No significantly complex system comes out right the first time.
        Apple has a goal, I believe it's to give as much freedom to 3rd party developers without losing control of the platform.

        That's an interesting way of looking at it, considering that it runs completely counter to the iOS 4 guidelines which forbid applications written in any programming language other than Objective C, C, or C++.

        No, the truth is that Apple implicitly targeted Adobe's Flash Packager for iPhone (due out the week after the new iOS4 te

        • by Sancho (17056) *

          That's an interesting way of looking at it, considering that it runs completely counter to the iOS 4 guidelines which forbid applications written in any programming language other than Objective C, C, or C++.

          And this whole story is about them revoking that clause.

    • Re:Yea (Score:5, Funny)

      by Anonymous Coward on Thursday September 09, 2010 @11:15AM (#33522278)

      It's refreshing to see Apple wrong so many times in a row. Watching them backpedal is amusing.

      When was Apple wrong? Apple was never wrong. Apple knew this was right all along. There is no evidence of the old license. The old license never existed. It is dead now. Apple never endorsed it. It was a lie made by Apple's enemies to discredit Apple's name. Apple is good. Apple would never hurt you. Apple is your friend. Apple is magic. Apple has never backpedaled. Apple is at war with Google. Apple has never been at war with Microsoft. Why do you hate Apple? Apple only wants to help you. You are clearly disturbed. Apple wants to assure you this is not your fault. Please report to your nearest iThoughtCorrection facility. Apple is your friend. Trust in Apple. Apple is your friend.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        I read this over 15 times and I really felt a warm fuzzy feeling towards Apple.
        Someone should mod parent disturbing.

    • by Qwavel (733416)

      Apple rarely backpedals or admits they were wrong.

      I think the FTC is to thank for this one. They are being investigated for anti-competitive actions in relation to the app store. Their problem is that anti-competitive behavior has been one of the app store's most important function.

      For them, it is much better to backpedal on their own and hope to end the investigations rather then going through the humiliation that MS and Gates went through.

    • by mliu (85608) on Thursday September 09, 2010 @12:15PM (#33523292) Homepage

      I think this line from the guidelines is pretty funny:
      "If your app is rejected, we have a Review Board that you can appeal to. If you run to the press and trash us, it never helps."

      So basically, don't snitch.

      To the contrary, however, in the past, it seems like running to the press and trashing them can really help get your app approved.

      See, e.g. http://apple.slashdot.org/story/10/04/16/2327219/Bad-PR-Forces-Apple-To-Reconsider-Banning-Mark-Fiores-App [slashdot.org]

    • Re:Yea (Score:4, Insightful)

      by thetoadwarrior (1268702) on Thursday September 09, 2010 @02:11PM (#33525116) Homepage
      It must upset you that they were spot on about Flash.
  • Google Voice (Score:2, Insightful)

    by esocid (946821)
    So...when will they be approving Google Voice?
    • Google Voice is already an iOS web app. Remember, GV is not VOIP (and there are in fact plenty of VOIP apps for iOS).

      • by Bigjeff5 (1143585)

        Google wrote an iPhone app for it, and Apple approved, then rejected it.

        As you said, GV is not VOIP, so why the hell would Apple reject it?

  • by line-bundle (235965) on Thursday September 09, 2010 @10:56AM (#33521916) Homepage Journal

    Does that count as downloading?

    I am looking at this in the context of scriptability.

  • More importantly (Score:5, Informative)

    by BasilBrush (643681) on Thursday September 09, 2010 @10:56AM (#33521918)

    More importantly, developers will no longer have to second guess the reasons why apps may or may not be accepted. From the statement:

    "In addition, for the first time we are publishing the App Store Review Guidelines to help developers understand how we review submitted apps. We hope it will make us more transparent and help our developers create even more successful apps for the App Store."

    • by Pojut (1027544)

      I think this is the biggest news of all. Why they kept such things secret, I have no idea. There really was no good reason to not disclose these guidelines before.

      • Re:More importantly (Score:5, Interesting)

        by Sarten-X (1102295) on Thursday September 09, 2010 @11:22AM (#33522400) Homepage

        It's to prevent/reduce the lawyer-like arguments. The moment a set of guidelines becomes public, people start trying to find loopholes. Arguments about terminology, implementation, and technicalities ensue. Then the rules get updated to account for what's been argued already, which brings in a new set of loopholes. Soon, a whole new industry springs up around just knowing the rules, and the whole process grinds to an inefficient halt.

        It's much easier to keep guidelines internal, and only release very general suggestions.

        • Re: (Score:3, Insightful)

          However, simplicity/efficiency is often the enemy of fairness. It certainly was in this case.

          I mean, I can drastically simplify the American legal system if we toss the laws and move to a system of laws only I know. We'll get rid of all the lawyering and costly trials, and I'll just let the secret police know who they should quietly execute.

        • It's much easier to keep guidelines internal, and only release very general suggestions.

          Of course it's easier to do so, since less people have a say as to what the guidelines should be. However, it's not really possible to claim that it's a transparent process as a result. The lack of transparency makes people think that Apple has something to hide, especially when it has not really been clear to this point why some apps are being rejected. Allowing input from the community on what those guidelines should be would create a public image that peoples' opinions matter, and that Apple is not arbit

      • Re: (Score:3, Insightful)

        by Bigjeff5 (1143585)

        How can you change the guidelines to justify removing any app you want if everybody knows what the guidelines are?

        Duh.

        The only reason they are doing this now is because they've gotten too much pressure not too.

        Any reasonable company would have released them from the very beginning. Most companies tell you what their criteria are for rejection specifically so you can avoid and correct any potential issues.

        • Re: (Score:3, Interesting)

          by bill_mcgonigle (4333) *

          The only reason they are doing this now is because they've gotten too much pressure not too.

          Naw, the iPhone is, literally, the textbook example from The Innovator's Solution. [amazon.com]

          Apple's best profit maximization came from keeping everything proprietary for as long as they didn't have significant competition. That they're doing this is likely an indication of a sales slump vs. competition from Android. Now they'll begin the process of competing in a commoditized market.

  • browsers (Score:2, Insightful)

    by hey (83763)

    Browsers download and run code (javaScript).
    What about them?

    • Re:browsers (Score:4, Informative)

      by line-bundle (235965) on Thursday September 09, 2010 @10:59AM (#33522000) Homepage Journal

      webkit is exempt.

      Written like a true slashdotter who didn't read the article.

    • Re: (Score:2, Informative)

      The WebKit JavaScript implementation is essentially the one exception to the downloadable code rule. I imagine that you could still be rejected for implementing core functionality in downloadable JavaScript, as that would open up a potential security hole.
      • Re: (Score:3, Interesting)

        Makes me wonder... WebKit is embeddable in iOS apps, right? Is it possible to embed it in such a way that it is not visible - e.g. just hide it, or overlay it with something - and use it solely as a JS scripting engine?

  • Applause (Score:3, Interesting)

    by Superken7 (893292) on Thursday September 09, 2010 @11:01AM (#33522036) Journal

    Its good to see big companies backpedal and fix their mistakes, even more if the company is Apple/Ms/Google

    Don't get me wrong, I think it made sense for *them* to ban things like Adobe CS5, but I don't think it was good for everyone involved (especially users and developers), and its great to see them do that, for whatever reason it must be.

  • Clarification (Score:4, Informative)

    by mr100percent (57156) on Thursday September 09, 2010 @11:04AM (#33522106) Homepage Journal

    Let's clarify, since the description isn't that great. Apple will now allow Adobe's Flash to export in iPhone app format

    Also, Apple released their App Store Review Guidelines (PDF) [bit.ly]. Worth a read.

    • Re:Clarification (Score:4, Insightful)

      by BasilBrush (643681) on Thursday September 09, 2010 @11:21AM (#33522390)

      I suggest actual developers access that list on Apple's site. It'll change quite often.

  • Unity (Score:5, Insightful)

    by Xest (935314) on Thursday September 09, 2010 @11:05AM (#33522120)

    This was all about Unity, which basically does exactly what Adobe's Flash packaging tool did for the most part. The Unity game tools have been used to develop some fairly popular iPhone games, and Apple knew it couldn't continue to authorise Unity based apps whilst denying apps created with Adobe's tools without falling foul of competition laws. Similarly, by kicking Unity off too they'd be throwing away from of the iPhone's most popular games.

    So the question now is, does this mean if Adobe tries to release it's tools again that Apple is going to let it, or are they now going to try and find another excuse to deny Adobe access to the platform?

    Apple stood to lose far more if it continued to stand by this policy, and if it stood by the policy whilst letting some apps through it also stood to face the DoJ, so it had to decide one way or the other.

    • Re:Unity (Score:5, Insightful)

      by BasilBrush (643681) on Thursday September 09, 2010 @11:25AM (#33522450)

      So the question now is, does this mean if Adobe tries to release it's tools again that Apple is going to let it, or are they now going to try and find another excuse to deny Adobe access to the platform?

      That's probably the reason they've released App Review Guidelines at the same time. Apple can probably deny most Flash apps based on other rules that already exist. e.g.
      "Apps that rapidly drain the device's battery or generate excessive heat will be rejected." and
      "Apps must comply with all terms and conditions explained in the Apple iPhone Human Interface Guidelines and the Apple iPad Human Interface Guidelines"

    • This was all about Unity, which basically does exactly what Adobe's Flash packaging tool did for the most part.

      Actually I thought Unity was more intermediate, producing an XCode project you would compile - the flash tool produced a binary directly.

      Apple knew it couldn't continue to authorise Unity based apps whilst denying apps created with Adobe's tools without falling foul of competition laws

      Actually it could do that forever because there are no such laws. Anti-Trust doesn't enter into the picture in any

      • Re: (Score:3, Insightful)

        by delinear (991444)

        Whats really odd is that it took this long to come up with any kind of review policy document!

        Well I guess the reason for that is primarily twofold. Firstly, it benefit Apple to grow the App store massively in a short space of time - if they'd rejected all those fart apps and similar early on, there'd likely be nowhere near the 250,000+ apps there are in there now. Secondly, I guess there's also the question of what the guidelines actually are. As has been said elsewhere, they've probably been largely making these up as they went along. Oh sure they would have had some foundation stones to build on,

        • Re: (Score:3, Insightful)

          by SuperKendall (25149)

          Well I guess the reason for that is primarily twofold. Firstly, it benefit Apple to grow the App store massively in a short space of time - if they'd rejected all those fart apps and similar early on, there'd likely be nowhere near the 250,000+ apps there are in there now.

          Right, but that aspect did not have to be in an initial version of the document.

          Secondly, I guess there's also the question of what the guidelines actually are. As has been said elsewhere, they've probably been largely making these up as t

    • by samkass (174571)

      I'm also interested in what other languages this opens up. The new rules explicitly ALLOW interpreters as long as the interpreter and all interpreted code are included in the original app bundle.

      This could open the way for:
      * erlang : A few people have ported erlang to the iPhone before but since Apple disallowed interpreters no serious work was done on this front. I think this could change. Especially with the iPad becoming more of an enterprise system, I could imagine embedded erlang services being avai

    • by AC-x (735297)

      So the question now is, does this mean if Adobe tries to release it's tools again that Apple is going to let it

      Apple can't prevent Adobe releasing the tools, it can only prevent iPhone apps that were written in the tools from being approved (if they can fingerprint the apps well enough to tell)

  • Apple's Statement (Score:5, Interesting)

    by amolapacificapaloma (1000830) on Thursday September 09, 2010 @11:06AM (#33522136) Homepage

    This is the actual statement by Apple [apple.com].

    Also, I've read some rumors [gizmodo.com] about the next iLife '11 having a new program for creating iOS apps in a similar way to the Android's AppInventor [googlelabs.com]. This new statement seems a like a pointer in that direction, otherwise they would have a hard time arguing about antitrust issues on the App Store...

    • I doubt it. iLife is a consumer app bundle. The last thing Apple is going to do is encourage non-developers to create half-assed apps and submit them to the app store. They have more than enough real developers developing with Cocoa-Touch.

      • Re: (Score:3, Interesting)

        All this is highly speculative, but I'd expect it to be like Automator on OS X, and the "apps" not being submitted to the store, but used but executed inside an apple made app. Easy way for power users to scratch their own itches, and a nice mousehole in the walled garden... Pure speculation though.

  • I wonder if this means that I can develop using Eclipse CDT and an iPod Touch, rather than having to buy a Mac.
    • What in the article even remotely hinted at that?
      • erm.

          From the header.."..It basically stopped the use of cross-platform compilers..."

        Using eclipse on windows to code, with a cross compiler to convert the resultant Java to native Ipad code, would fall fowl of this. And now, apparently it wont.

         

  • Does this mean that I can use C# to generate a Silverlight app that will run on Windows, Windows Mobile, Linux, Android and iPhone?

    Can I write in Java an app that will run on every desktop and mobile?

    • Re: (Score:3, Insightful)

      by rjstanford (69735)

      Does this mean that I can use C# to generate a Silverlight app that will run on Windows, Windows Mobile, Linux, Android and iPhone?

      Can I write in Java an app that will run on every desktop and mobile?

      Well, considering that a good app experience on a desktop (with a mouse and keyboard) is by definition very different than a good app experience on a multi-touch device, probably not, no. You might be able to share some code internals, but you could do that anyway.

    • Can I write in Java an app that will run on every desktop and mobile?

      only if you distribute it with your own developer-locked-in version of java. (I have fond memories of java version 2.something.{our lead developer's name} for the software written for one version of solaris on specific hardware with specific os patches.)

  • Hopefully that means you can write apps in Qt and hopefully they will be cross-platform with Android so developers don't have an excuse to marginalize one platform.

  • by codepunk (167897) on Thursday September 09, 2010 @11:38AM (#33522660)

    What I would like to see apple do is to add performance to it's application review process. Say for instance you app does not boot to a stable runnable state in 10 seconds it gets disapproved. Same goes for memory usage and and processor load. That would solve the whole "user experience" goal that they claim to have. Of course it would keep most of the interpreted apps, flash, java etc off of the phone but I have no problem with that. On one hand I would like to have to option to use interpreted languages on the device on the other hand I know that for performance reasons it is not the way to go.

  • Meaningless (Score:3, Insightful)

    by Andy Smith (55346) on Thursday September 09, 2010 @11:44AM (#33522758) Homepage

    Apple seem terribly random and unpredictable. It would be senseless for any developer to begin work on a project that has become permitted by this clause, because tomorrow the terms could change again.

    I'm an Android developer, releasing my first game in the next 4-6 weeks. Then I need to consider whether or not to produce an iPhone version. The decision will only slightly be based on forecasted sales, market share of competing products, and demand for my product. For the most part I will need to decide if I can afford to invest the time developing for a platform that may, at any point, "ban" my product for some obscure reason. (For example, all of my graphics are produced in 3D Studio and rendered as 2D sprites. Suppose Apple takes a dislike to Autodesk...?)

    • Re:Meaningless (Score:5, Insightful)

      by BasilBrush (643681) on Thursday September 09, 2010 @01:28PM (#33524474)

      (For example, all of my graphics are produced in 3D Studio and rendered as 2D sprites. Suppose Apple takes a dislike to Autodesk...?)

      It's always wise to do a risk analysis before embarking on a new project. Don't forget to factor in the possibility that you'll spend so much time posting ridiculous scenarios to slashdot that you never get round to doing the work.

  • by grapeape (137008) <`moc.rr.ck' `ta' `7epopm'> on Thursday September 09, 2010 @12:23PM (#33523414) Homepage

    After the disaster that has been flash on Andoid so far, perhaps this is just Apples way of saying "see we told you". I expect a plethora of sub-par apps flooding the app store soon, in the end this will probably help HTML5's cause much more than Adobe.

Never say you know a man until you have divided an inheritance with him.

Working...