This is a huge change in stance for Apple and basically allows Adobe Flash based AIR apps to run on the device natively again. I think this is a very wise decision by Apple to let the market decide on what is a quality app while respecting Apple’s concerns about downloading and running code that might create security concerns (non compiled script outside the web sandbox).

Developers using Unity, MonoTouch, Adobe Flash AIR Packager, Lua scripters etc are now all safe as long as it is AOT compiled and scripts it uses are downloaded with the binary and not downloaded later (only content and data can be downloaded unless it is in an approved app update).

All your technologies are safe… for now.. dun dun dun…

However Apple also tightened quality control so they will be rejecting bad or duplicate apps, so at the same time this has made it harder to get apps approved if there is questionable quality or too many of one type of app. It is good on the surface but also I believe the store should be an open market where the best app wins, crap will naturally filter out. This is probably a stop-gap for all the apps that will be submitted with AIR or other less complex platforms because more novice users will be submitting them. So this is good for skilled developers on any platform making quality and original content. But it could cause some problems.

Engadget has some nice covereage if you dont’ have access to the iOS developer site:

Well good news for Flash developers, Flash CS5 will finally compile to native iPhone and Touch Applications. This is great news for many developers out there who have stuck with the Flash platform. I am sure there will still be limitations to what you can do with Flash on the iPhone and it will probably be mostly 2D games and apps but this is a great start to getting the Flash platform truly mobile and up to the rest of the industry.

Flash Professional CS5 will enable you to build applications for iPhone and iPod touch using ActionScript 3. These applications can be delivered to iPhone and iPod touch users through the Apple App Store.*

I have been questioning why they have not moved to this model beforewhen others are doing so such as haXe, Unity3D and MonoTouch. Getting Flash on the web browsers on a mobile is hard because Flash is pretty CPU intensive on embedded devices which is really where computers were in the late 90′s and close to 400-600 MHz processors. Today these machines wouldn’t be able to run Flash very well and that is the same effect you get on a mobile phone. But cross-compiling to native, similar to how Unity 3D does it or other solutions like MonoTouch and XNATouch, this is the best solution until mobile/embedded devices have 1GHz processors and more than 500MB of memory. Adobe is using LLVM, much like the Alchemy model, to achieve getting AS3 content onto an iPhone/Touch with AOT or Ahead of Time compilation rather than JIT compilation.

So how do you build an application for the iPhone? It’s simple, really. The forthcoming beta of Adobe Flash Professional CS5 incorporates the ability to create an iPhone application. You have access to nearly all the AIR 2.0 and Flash Player 10.1 APIs. For example, you can use APIs such as RTMP, Remote Shared Objects, and AMF as well as AIR APIs like SQLite and filesystem access. For more information see the developer FAQ on Adobe Labs.

I am glad to see Adobe finally moving on mobile platforms beyond Flashlite. Flashlite is a poor solution in most cases on embedded devices because they really need native apps to perform, again due to the hardware limitations and it is a whole new platform to learn. Adobe is doing the hard work to make it easy to get developers content on the new embedded devices that are storming the world such as the iPhone and Touch.

Exposed all 4 screen orientations as iPhoneSettings.screenOrientation. iPhoneSettings.verticalOrientation is now deprecated.

Added support for vibration (iPhoneUtils.Vibrate).

Exposed number of properties via Editor Player Settings UI (including bundle version and UI interface orientation).

Implemented support for up to 8 texture units in shaders for iPhone 3GS. Added iPhone 3GS emulation in the Editor.

Introduced automatic batching for small (less than 300 vertices) dynamic objects if they share same material. Reduces OpenGLES draw-call overhead.

Unity respects your XCode project now. It is not overwritten anymore by default. You can safely add new files, modify project itself or AppController.mm file, Unity will append its things as necessary. Note however that some folders like Libraries, Data, root project folder are always overwritten.

haXe is an interesting programming language that allows abstracting the source from platform target. It outputs for targets such as Actionscript and Javascript from haxe language source. But, haXe can also output to native code to run on Windows, Mac OSX, and Linux.

Well because of this it is possible to run haXe on the iPhone. The gamehaXe site has found a way to get haXe to compile to iPhone via hxcpp which creates a C++ output from haXe code very similar to Actionscript 3.

I am a bit late to the party but this is great news. It uses the NME library which will allows code to mostly be written to the Flash 9 API and create the C++ for XCode to compile and run on the iPhone and Touch. This creates a path to port Flash games to iPhone/Touch.

This project is one to watch and participate in. Native compilation to the iPhone from haXe is a more simplified code to write in while providing lower level performance which is needed on mobile devices, as processors, cache and ram are much lower than desktop and below what is capable of running the Flash AVM2 currently.

The hxcpp project is a newer output target along with a java one but this could be interesting if actionscript like code and many libraries like Physaxe or AS3 libraries could be ported to haXe to output to the iPhone.

I updated to iPhone SDK 3 beta 4 and iPhone OS 3 beta 4 and the latest Unity iPhone and things were much better in perception of speed at least in early testing. Not sure if it was more from one or the other but the games I am testing/building so far are quicker and the OS feels faster overall.

This build fixes many issues and makes some great optimizations for speed as listed here:

New Features and Improvements

Reduced memory footprint for uncompressed audio by 50%

“Memory usage for textures reduced by 50%. Texture memory is now freed once it has been submitted to OpenGLES on the device. The “Enable Get/SetPixels” flag in the Texture Import Settings lets you disable this feature on a per texture basis in order to access the texture data from a script using GetPixel etc.

A quick roadmap was posted by Unity3d.com blog on the immediate future of Unity iPhone. Currently I am developing two games for the iPhone OS 3.0 and these are welcome updates. We are really looking forward to items not in the hard version just yet but we are looking forward to terrain support and downloadable content support in iphone sdk 3.0.

Unity iPhone 1.0.2. Based on custom builds we’ve been sending to devs in need, this release will address engine memory leaks and fix other outstanding issues:

Physics and audio related memory leaks

Asset leaks while reloading scenes

.NET sockets and threads

Compressed audio related issues

Stripping away too much of GUI components

Occasional crashes in AOT compiler

Support for both portrait and landscape splash screens

Next will be Unity iPhone 1.1. Since the release of 1.0.1 we’ve been working on a number of performance and memory optimizations. Most of the work on 1.1 is finished already and we’re doing an internal bug fixing round before it goes to beta testers too. Along with optimizations this release will include number of important features such as:

Binding custom ObjectiveC/C++ functions to C#/Javascript

Native on-screen keyboard support and interoperability with Unity GUI

Movie playback support

Performance optimizations:

significant C#/Javascript performance improvements

general rendering loop optimizations resulting in less OpenGLES state changes and less CPU work per object

number of internal routines were rewritten using VFP coprocessor assembly

way much faster mesh skinning utilizing VFP

batching small objects, given that they share same material, into single draw call

*drawlogic is authored by Ryan Christensen of *drawlabs and *drawcode, both dedicated to taking ideas to ship doing entertainment focused web, mobile and desktop game and interactive development projects.