Sincerely this last crusade against flash is just annoying me ( the same way the first svg crusade against flash ). In my humble opinion I think that next year HTML5 will be already an old technology and everyone will forget this war.
then replace the BUILD_DATE const with the current date and the BUILD_NUMBER with an incremental build number. After being executed the first time, ant will also create a new file in your directory called “build.number” with the latest build number int.
My approach wasn’t too sophisticated: basically, as long as I didn’t have so much time to spend on writing a full binary converter, I was parsing the SWF and then generating static Objective-C/C++ (well mostly C++ and I’ve used Objective-C as glue where strictly required) code that then was Philadelphia Business Plan Writers compiled by Xcode to a working iPhone application.
Generated applications are really big in size, mostly because there is a lot of glue code generated and because you need to replicate the FPL API in C++ to be able to easilly convert the SWF into an iPhone app;
ActionScript is a dynamic language, and this dynamicity must be taken into account when generating binary code (or source code in my situation). Even if using LLVM probably helped with this, you will always need to generate additional dynamic checks that slow down a lot the execution;
The FPL doesn’t support (yet) threading API, nor the AIR version does. So, if they want to preserve the portability of a flash game so it can be run with AIR or on the iPhone without any change, they are limiting the developers on building just quite simple games;
The same can be said for all the other native APIs. AIR for instance has multitouch API, which are however at a lower level then the ones provided by the iPhone;
The other big issue is rendering performance. When I was working on my project, I’ve tried many different approaches to figure out which one was the best to render decent vector graphics with a good framerate on the iPhone. Core Graphics is not an option, as long as it is as slow as hell. Using OpenGL to render the graphics increases a lot the performances, but adds a few limits to the rendering quality. The best approach I found was to mix caching and OpenGL rendering together, but that was not working fine with rapidly changing graphics. But I must say I didn’t have the same knowledge as the FPL developers on this topic and I didn’t have months to work on that too …
iPhone developers must take special care for memory and resource management; probably having a huge bootstrapping code and transition structures won’t help.
Having the FPL on the iPhone will still limit us, but it will open up a brighter future for AS developers who want to release apps that runs on the iPhone too (Did you ever heard about compile once, run everywhere?).
Most of the Flash Player 10 and AIR 2.0 APIs will be available, so for instance: pixel Bender filters and also dynamically loading SWFs that contain ActionScript (but the Actionscript will be ignored since there’s no flash VM in the iphone).