A little over a week ago Apple released a new draft of their iPhone developer program license which contained the following clause:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Essentially, this has the effect of restricting applications built with a number of technologies, including Unity, Titanium, MonoTouch, and Flash CS5. While it appears that Apple may selectively enforce the terms, it is our belief that Apple will enforce those terms as they apply to content created with Flash CS5. Developers should be prepared for Apple to remove existing content and applications (100+ on the store today) created with Flash CS5 from the iTunes store.

We will still be shipping the ability to target the iPhone and iPad in Flash CS5. However, we are not currently planning any additional investments in that feature.

To be clear, during the entire development cycle of Flash CS5, the feature complied with Apple’s licensing terms. However, as developers for the iPhone have learned, if you want to develop for the iPhone you have to be prepared for Apple to reject or restrict your development at anytime, and for seemingly any reason. In just the past week Apple also changed its licensing terms to essentially prohibit ad networks other than its own on the iPhone, and it came to light that Apple had rejected an application from a Pulitzer Prize winning cartoonist on editorial grounds (which Apple later said was a “mistake”).

The primary goal of Flash has always been to enable cross browser, platform and device development. The cool web game that you build can easily be targeted and deployed to multiple platforms and devices. However, this is the exact opposite of what Apple wants. They want to tie developers down to their platform, and restrict their options to make it difficult for developers to target other platforms. There is plenty of commentary online about this, so I won’t belabor the point, but I have included some links below that cover it more depth:

• Apple Wants to Own You
• Apple Locks iPhone Developers in Its Walled Garden

So, was all of the work on the iPhone packager a waste of time and resources? No, I don’t believe so. We proved that:

1. There is no technical reason that Flash can’t run on the iPhone
2. Developers can create well performing and compelling content for the device with Flash

However, more importantly, the teams implemented features (such as hardware acceleration and Ahead of Time compilation) that we will now be able to leverage for other devices and platforms. We have gained knowledge and experience that are being directly applied to Flash Player 10.1 and Adobe AIR 2.0 for other mobile operating systems.

Fortunately, the iPhone isn’t the only game in town. Android based phones have been doing well behind the success of the Motorola Droid and Nexus One, and there are a number of Android based tablets slated to be released this year. We are working closely with Google to bring both Flash Player 10.1 and Adobe AIR 2.0 to these devices, and thus far, the results have been very promising.

Because this is Flash, it is rather trivial to port games created with Flash that target the iPhone to target other operating systems, such as Android. At FlashCamp San Francisco on Friday night, David Wadhwani (GM and VP of the Flash Platform) showed off a number of games running on Android that had been created with Flash, many of which had already been deployed as iPhone games. My personal favorites were Chroma Circuit and GridShock created by Josh Tynjala of Bowler Hat Games. Both games were originally developed as browser based games and were then updated to target the iPhone (Chroma Circuit was featured on the iTunes app store). Josh recently updated and optimized them to target Flash Player on Android, and the results have been impressive. There have already been a couple of developers who have moved their Flash based content from the iPhone to Flash on Android (couple of examples below) and I expect that this is a trend we will be seeing more and more of.

Here are some links to developers who originally targeted the iPhone with their Flash content and are now deploying to Android:

• Adobe AIR for Android: Chroma Circuit and Qrossfire Videos
• Jobe Makar : Flash is Speedy on Android
• Jobe Makar’s Fruit Smash Organic (Video)
• Alan Queen’s Star Map Game (Video)

Both Flash Player 10.1 and Adobe AIR 2.0 for Android are in pre-release testing. If you are interested in being notified when we expand the testing, you can sign up at:

• Flash Player 10.1 for Android Beta
• Adobe AIR 2.0 for Android Beta

Personally, I am going to shift all of my mobile focus from iPhone to Android based devices (I am particularly interested in the Android based tablets coming out this year) and not focus on the iPhone stuff as much anymore. This includes both Flash based, and Objective-C based iPhone development. While I actually enjoy working in Objective-C, I don’t have any current plans to update and / or maintain my existing native iPhone applications (including the AS3 Reference Guide, and Timetrocity). As I wrote previously, I think that the closed system that Apple is trying to create is bad for the industry, developers and ultimately consumers, and that is not something that I want to actively promote. Don’t worry though, I definitely plan to get both Pew Pew and Bacon Unicorn Adventure running on Android and am planning on open sourcing both.

We are at the beginning of a significant change in the industry, and I believe that ultimately open platforms will win out over the type of closed, locked down platform that Apple is trying to create. I am excited about Flash Player 10.1 and Adobe AIR 2.0 and all of the opportunities that they will make available to Flash developers across multiple platforms (desktop, Android, Palm, Windows Phone 7, RIM, etc…).

NOTE : Please keep comments constructive and on topic. Off topic comments will be moderated / deleted. (And yes, commenting that “Flash SUXXORS!” or calling me a “wanker” are considered off topic).

So, the Interwebs is all a buzz again around the latest article that “proves” that Flash will not be useful on mobile devices (much less the iPad). From the article:

Current Flash sites could never be made work well on any touchscreen device, and this cannot be solved by Apple, Adobe, or magical new hardware.

That’s not because of slow mobile performance, battery drain or crashes. It’s because of the hover or mouseover problem.

Basically, the writer is arguing that because some Flash content uses Mouse over / hover events (MouseEvent.MOUSE_OVER), and because there is no such event as a hover on a touch devices, then apparently, most Flash content just flat out wont work on touch devices.

I wanted to make a quick post that corrects some of the false assumptions and conclusions presented in the article, which include:

1. Hover events do not work in Flash content on devices with touch screens. That is false, they do work.
2. Any issue with hover or any other mouse events on a touch screen device, are specific to Flash. They are not. They affect HTML and any other web content as much as Flash.
3. Most Flash content relies on hover events. Wrong. I dont have a scientific breakdown on how much Flash content RELIES on hover events, but at least in my experience with the Nexus one, almost all content I have come across has worked well with touch screen input, including those that use hover events.

First, lets look at all of the Mouse events that Flash developers normally have access to.

• MouseEvent.CLICK
• MouseEvent.DOUBLE_CLICK
• MouseEvent.MIDDLE_CLICK
• MouseEvent.MIDDLE_MOUSE_DOWN
• MouseEvent.MIDDLE_MOUSE_UP
• MouseEvent.MOUSE_DOWN
• MouseEvent.MOUSE_MOVE
• MouseEvent.MOUSE_OUT
• MouseEvent.MOUSE_OVER
• MouseEvent.MOUSE_UP
• MouseEvent.MOUSE_WHEEL
• MouseEvent.RIGHT_CLICK
• MouseEvent.RIGHT_CLICK_DOWN
• MouseEvent.RIGHT_MOUSE_UP
• MouseEvent.ROLL_OUT
• MouseEvent.ROLL_OVER

Now, lets look at a list of events that will not work on a device whose primary input is a touch screen:

• MouseEvent.MIDDLE_CLICK
• MouseEvent.MIDDLE_MOUSE_DOWN
• MouseEvent.MIDDLE_MOUSE_UP
• MouseEvent.MOUSE_WHEEL
• MouseEvent.RIGHT_CLICK
• MouseEvent.RIGHT_CLICK_DOWN
• MouseEvent.RIGHT_MOUSE_UP

As you can see that list doesn’t include the MOUSE_OVER and ROLL_OVER events. It only includes middle and right mouse button events, as well as mouse wheel events, which in general, are used as a secondary means of user input / interaction.

Basically, hover events do work in Flash content on touch screen devices. The main difference is that on a touch device, you will get also get a MouseEvent.MOUSE_DOWN event prior to the MouseEvent.MOUSE_OVER event, where as on a desktop machine, you MAY only get the MouseEvent.MOUSE_OVER event.

I put together a very simple Flash example for the iphone, that shows all of the MouseEvents being generated. You can view the video here:

View Video on YouTube

Here is a list of the events which were generated in the video:

• doubleClick
• mouseUp
• mouseDown
• click
• mouseUp
• mouseOver
• rollOver
• mouseDown
• rollOut
• mouseOver
• rollOver
• rollOut
• mouseOut
• click
• mouseUp
• mouseOver
• rollOver

So, to summarize:

1. Hover events do work in Flash content on touch devices.
2. Any issues with mouse input on a touch device are not specific to Flash, but affect all content, including HTML based content.
3. If your content RELIES on MIDDLE, RIGHT and / or SCROLL_WHEEL mouse events, then you will need to update your content IF you want users on touch devices to be able to use it. This applies just as much to HTML content as it does to Flash content.

Now, this doesn’t mean that all Flash content designed and developed for mouse input on a desktop computer will run well on a mobile device with touch input. Indeed, some content will not run well due to differences in input (such as keyboard input), user interface, or performance. However, again, those are all issues that affect HTML content as much as they affect Flash content.

Again, any potential input issues apply as much to HTML as they do to Flash, and as browsing the web on the iPhone has demonstrated, these have not been a major barrier to consuming content on a touch device.

As a content creator, you should focus on creating content that provides a good user experience across all platforms that you are targeting. However, even though most Flash content on the web today is not designed with mobile viewing and touch input in mind, my experience has been that existing content works surprisingly well when viewed on a mobile device with touch input.

Here are some links to videos of existing Flash content running on mobile devices. A lot of this content is content never designed to be run on a device with touch input.

• Demos of Flash Player 10.1 on various mobile devices (iPhone, Palm Pre, Nexus One, Droid, and more…)
• Flash Player content on Nexus One
• Unofficial Nexus One Flash Demos

Please keep comments constructive and on topic. Off topic comments will be moderated.