Calendar

July 2016
Mo Tu We Th Fr Sa Su
<< >>
123
45678910
11121314151617
18192021222324
25262728293031

Langs

CS5 iPhone Support

Posted on Oct 10 2009

As announced at Adobe MAX conference, Flash CS5 will have the ability to output iPhone binaries directly (read FlashMagazine Article about it).

I don't have much details on how it's done, but here's my guess based on what I've been reading : Adobe have built a SWF Bytecode-to-C converter (maybe using LLVM which was already used for Alchemy), then are using a cross compiler such as a modified version of GCC in order to link together this C code and a static library containing the Flash Player for iPhone.

This way there is no runtime interpretation of the SWF Bytecode, everything is "native".

Haxe already has a Haxe/C++ target which enable in particular to target the iPhone, so what are the differences between the two methods ?

First, I'm pretty sure that you will be able to use SWC in iPhone projects in CS5 (or else that would be a too much crippled feature). And since Haxe allow you to output reusable SWC, it means that you will be able to use Haxe together with this CS5 feature.

However, in that case (or if you are using AS3) you are still targeting the Flash Player. You will have additional API to handle touch screen, but you will mainly be limited by what the Flash Player gives you. In particular, that mean that you will not be able to access OpenGL ES API, etc.

This is the main difference with Haxe/C++ way of doing things.

Haxe/C++ allow you to natively target the iPhone (and all other devices that can be programmed with C++ BTW). And in order to ease the from-Flash transition, some API of the Flash Player have been ported to C++ in order to reproduce their behavior.

But with Haxe/C++ you are no longer limited by the Flash Player : you can directly access to all the API provided by the iPhone, and in terms of graphics capabilities you don't have to go through the Flash Player API, which is good when you want to abstract things, but bad if you want to get best performances or innovative visual effects.

So in the end it's nice to have the choice : either use CS5 feature to be able to directly run your unmodified apps on the iPhone, or if you really want to be able to "hack" the iPhone and use its native capabilities, use Haxe/C++ for that.

13 comments
  • Tek
    Oct 10, 2009 at 11:21

    Hi Nicolas, as you explain I've seen a diagram somewhere on the Internet explaining that the compilation will use a SWF bytecode as source. But I can't find this diagram anymore. I even don't remember if it was during video or a blog post. It was during the MAX online, there was to much news at the same time. Could you please give us a link if you have one?

    I talk about that on Twitter and the only diagram I found was this one http://twitpic.com/kgo9c

  • Oct 10, 2009 at 11:58

    Hi Nicolas,

    AFAIK they build an LLVM frontend that is used to compile AS into LLVM IR, then the IR2ARM backend is used to generate the binary code. The approach is pretty interesting because they should be able to achieve decent performances as long as converting portions of AS code into structures suitable for static analisys should permit a lot of additional optimizations.

  • Oct 10, 2009 at 14:58

    Thanks to both for the additional informations ;) I was actually thinking that it was an LLVM frontend since I knew that LLVM had at least a C output. If there's an ARM backend then there is no need for an additional cross compiler, LLVM will replace it.

  • Oct 11, 2009 at 06:02

    I was in the private Flash on iPhone beta (I wrote a little about it at http://coderhump.com/archives/517), and the same day I got the beta bits from Adobe, I also downloaded Haxe and tried out the C++ path on my iPhone.

    It was cool but I would have had to learn a new language and forever live in a different world from all other Flash developers. If I want to target the advanced features of the iPhone or desktop, I can just use C/C++.

    If Haxe could take AS3 and compile it to C++ I'd probably be using it right now to port my projects to the iPhone, and people wouldn't be making a big deal out of Adobe's official support. If it could compile AS3 to SWF, I would use it for all my release builds so that I could get better performance.

    Nicolas, the compiler tech you have is great and I want to use it, but requiring people to use Haxe as the language means it will forever stay in a niche role. It's a nice language but it's not enough better that people will give up the mainstream for it.

  • Oct 11, 2009 at 11:23

    @Ben : AS3 has not been designed to run on several platforms. There are several language features that are impossible to implement on another platform without modifying the semantics, but in that case that's another language.

    Haxe has been carefully designed so each of its language feature can be easily adapted to all present (and future) supported platforms.

    Your argument is a chicken-and-egg problem : because Haxe is not mainstream, you don't want to use it. Some people don't care about it and are already using it. In the end, the more people will use it the more it will become mainstream.

    But it's up to you to make your own choice.

  • Oct 11, 2009 at 21:07

    My point is that if there was a good way to get Haxe's foot in the door, it would be a lot easier to experiment with using it, and as a result, the user base would increase. So it would be a tactic to get around the chicken and egg cycle.

    BTW, which language features are problematic? (I ask out of curiosity, not to be a jerk; obviously with enough effort they can all be supported, but some are a lot harder than others. We are working with Turing machines after all.)

  • Oct 12, 2009 at 09:07

    @Ben

    Moving form AS3 to Haxe is extremely easy (as long as they both share the same programming paradigm and they have a really similar syntax) so I can't understand why you see that as a problem limiting you in trying out Haxe C++.
    Usually when you have to learn a new language, the biggest issues you may face are related to platform specific API, specific frameworks or maybe a different programming paradigm.
    Give Haxe a try: you'll find yourself productive in less time than you have thought; then you can decide to move back to AS3 or implement an iPhone app in C++, but for sure it won't be because of the language itself.

  • Oct 12, 2009 at 17:00

    I think the reason Ben wants Haxe to use AS3 is so that he doesn't have to have two code bases, not necessarily because learning another language is problematic (Ben has learned many languages and Haxe is still a curly-brace derivative).

    To put it another way: Nicholas has put an incredible amount of effort into an optimizing SWF compiler (much like Joa Ebert has with his work) that's very underexploited by the community at large because it requires a different toolset (largely because it requires a different language).

    Clearly, Nicholas' goals are more about aiding multiplatform/multilanguage environments, not about improving the Flash Player platform specifically. No problem with that, but he (or the Haxe community) shouldn't be surprised when the Flash community doesn't embrace Haxe's advantages.

  • Oct 13, 2009 at 22:19

    This post is about the differences and choice, not a moan about the how Haxe has been embraced.

    Thanks for the clarification Nicolas

  • Oct 23, 2009 at 17:54

    Linux lead the way, Microsoft and OS follow....
    Now Haxe lead the way and Macromedia follow...
    Long life to Haxe.

    Keep it real Nicolas.

  • Nov 23, 2009 at 03:54

    I feel like most of the actionscript developers have Stockholm Syndrome or something.

    Look, the mxmlc compiler is lousy. It's one of the poorest pieces of software that Adobe produces, next to the Flash IDE.

    Flex developers can use the hacked eclipse version, which might have slightly more features, but at the expense of being even less responsive and bloated.

    The actionscript community is great. Full of creative and bright people. Lucky Adobe. Flash needed people like that to find creative loopholes around incredibly poor language design choices like untyped Arrays, etc.

    HaXe offers you a way out of that mess. You can still retain your "adobe" community status because you're still developing for a SWF target. Most (if not all) of the API specific discussion, documentation, and tools will work out of the box (or with very minor modifications usually provided by Haxe community members).

    You get very real performance benefits.
    You get very real type checking and reliability benefits.
    You get very real cross-platform target opportunities.

    You don't owe Adobe anything, they're holding you back.

  • Steve
    Dec 06, 2009 at 19:17

    Could the Haxe/C++ API be expanded to encompass other mobiles? I understand Nokia and Samsung are the worlds two biggest handset manufacturers, Nokia already have C++ compilers for Symbian and Maemo and Samsung are going to release one for their new OS (Bada) later this month.

    Wouldn't it be exciting to be able to target all of these with Haxe/C++?

  • Frank
    Mar 05, 2010 at 06:19

    Would it be possible to target winmob 6.5 and lower? That seems to be left behind and cut from adobes master plan. Whatever that is at this point. Would it be possible to even include .net api and get a packager going that took a swf and made it .cab or .exe?

    Old thread I know, just had to ask, Haxe looks very tempting and am sick and tired of adobes whims so to speak. Don't want ot bash it too hard but this last couple quarters been just moronic.

Name : Email : Website : Message :