/dev/why!?!

If your biggest complaint is that Flash created iPhone apps use more battery power, it seems Adobe has done a great job.

Good to see an honest critique that doesn't turn into a 'Flash sucks!' rant. Of course all non-Flash devs hate flash because it's 'ruined the web' etc, but the fact is Flash has become so popular for a reason. It allows devs to create media-rich widgets + sites in a fraction of the time to do the same with some other tech.

Also, note that Adobe are also putting a lot of time into making the Flash player less resource hungry and more mobile friendly for the next version.

Having been a Flash developer for 10 years I'm pretty excited about this technology. My only hope is that, in time, Adobe will improve their branch of the ARM backend to bring apps closer to being first class iPhone citizens. As you say, there's no need for them to be using private APIs or bundling app assets in the binary. Here's hoping this is just a first step in the right direction.

Having said that, I suspect this technology will ultimately serve to attract Flash developers to the iPhone who, finding the limits of what is possible with the Adobe toolchain, will turn to Cocoa and Objective C.

Felix,

"It allows devs to create media-rich widgets + sites in a fraction of the time to do the same with some other tech."

But at a couple of serious costs: accessibility, usability, search engine crawlability (I know that's not a word, but you get what I mean).

Watching video in Flash on a Mac is a terribly painful experience compared to simply watching video.

Flash sites are typically inaccessible to the blind (98% of them are) and their content is not crawleable by Google et al.

Nowadays, an awful lot can be done with JavaScript, CSS3 and HTML5, rendering a lot of things Flash is used for obsolete. Similarly, most every Flash ad out there is just plain awful. In fact, short of Apple's Flash ads, I can't remember ever NOT having disliked a Flash ad. Is that a good thing? I doubt it.

Just as there are reasons Flash is popular, there are reasons plugins like FlashBlock and ClickToFlash are popular.

I have no personal reason to be against Flash apps on the iPhone via this system (or rather, workaround) that Adobe came up with, but I'll be thoroughly surprised and impressed if I ever come across an iPhone app I like that's made in Flash.

Great writeup--thanks for the objective information.

I'm a long time Flash developer who's been focusing on iPhone development using XCode/ObjC this year, and while I share many of the same concerns that you have about the way the .app is packaged and various linking issues, I want to point out that the apps currently on the App Store are using software rendering rather than hardware accelerated graphics.

The day it was announced at Max, I did much the same thing and pulled apart some of the App Store sample apps and tweeted concerns (http://twitter.com/#search?q=ianchia) to which one of the Adobe mobile engineers and one of those sample app developers replied to.

Greg made a video (http://www.youtube.com/watch?v=FtoY_LAbmq4) showing an app demoed at the Max booth that's not yet on the App Store using HW acceleration, and the performance is much superior. I've known Greg a long time and trust him. Seeing that video, I'd say doing an UI like Weightbot or any app using a framework like Cocos2D would be much easier in CS5 compared to XCode.

That said, all your technical concerns (aside from performance/battery life) is very valid and I'm skeptical/hopeful. It's early days yet. Hopefully we'll all be impressed with Flash CS5 beta comes out that they've sorted out the memory management/embedding assets and linking issues. I don't think performance and battery life will be an issue at all (well, no more than the difference between a poorly made ObjC app versus a poorly made AS3 app ...)

"Also, note that Adobe are also putting a lot of time into making the Flash player less resource hungry and more mobile friendly for the next version."

I've been hearing that the "next" version of Flash is going to contain massive performance improvements for several years now. I'm pretty sure 8.0 was billed as a major performance improvement, and am positive 9.0 and 10.0 were.

In the end, though, I sit here on a box with literally ten times the processing power I had a few years ago and watch a single Flash video player peg two Core2Duo CPUs just trying to put pixels on the screen.

I'll believe it when I see it. Adobe's Flash devs have been absolutely unable to get reasonable performance on any hardware/os combo besides Intel/Windows.

There was a lot less video back then, and it was smaller. Performance improvements have been very impressive in 8 and 9. Any resource cap that's lifted is promptly filled by developers.

I don't follow your logic about embedding resources in the binary being bad. It's actually quite efficient since the resource data is already mapped into the address space without having to open and close files or copy into the heap. I don't know of any "caching or prefetch logic the OS has for specific data types (like images)" -- higher level calls to load images from files will basically open the file, read the image data into the heap, and decompress it. Mapping the image data out of the app binary saves the first two steps.

Classic Mac OS apps used to do this (remember the resource fork?) and I believe Windows apps are packaged this way too. There's nothing wrong with it.

Felix: Yes, my biggest complaint is they are slow and use battery, but that is a pretty big issue for me, I want my phone's battery to last through the day.

hyperphonic: Hopefully your right about the HW compositing. I will note that most of the time Cocoa Touch apps get HW rendering unless they explicitly do something that breaks it.

snej: They are literally intermingling their resource data in the TEXT section, not as data in separate section the linker can do something intelligent with. This isn't at all like the resource manager, which had a clear delineation of what each resource was. Also on PPC Apple explicitly moved app TEXT out of the resource fork into the data fork explicitly to prevent this sort of fragmentation when they moved to page demand loaded binaries.

Think about it this way. With UIImage imageNamed: the system mmaps a file when it pulls it in and munmaps it when it is done, there is no remenants of the compressed version. With what Adobe is doing the only way the compressed version leaves ram is through VM pressure.

I actually have done some deeper research and looks like that those apps are already HW accelerated. What the compiled (Ahead Of Time....) Flash app does is to render each and every sprite/shape of Flash content to a texture, the texture is then stamped on a quad using OpenGLES and finally reach the screen. Only the final compositing is handled in hardware, but the bottleneck is the software renderer that creates those textures.

The main problems of current Flash-To-iPhone approach are the following (IMHO):

1) All the Flash Apps will be OpenGLES based, this doesn't play well with UIKit stuff and so you are stuck at just making games (and simple ones too)

2) Beside the OpenGLES problem, Flash IDE provide no access to UIKit, that means you will be constantly busy trying to replicate/emulate in Flash the UI experience that CocoaTouch developers can deliver by just drag and dropping components in Interface Builder. And UIKit is all hardware assisted by default.

3) The bottleneck of performance is not the hardware renderer (not used except for compositing), but rather the continuous transfer of soft-rendered textures to the OpenGLES side, a new texture is needed to be soft-rendered by Flash then transferred every time the shape/sprite in question is transformed (scaled, rotated etc). Textures transfer speed issues is independent from the language you use and this is not going to change unless the hardware itself changes. In fact every CocoaTouch-ObjC developer knows this very well and load textures at beginning of program or during level changes (for games), you just don’t pump textures to OpenGLES during runtime

4) Only possible gain of speed comes from the content being static, at this point using the flag cacheAsSurface (similar to cacheAsBitmap but iPhone specific), Flash runtime (because there is till a runtime...) knows that a specific texture belonging to a certain sprite/shape doesn't need to be refreshed when it is being transformed, the second you perform a transformation on a non-cached object, the associated texture would have to be regenerated (look at the difference in speed at the examples “Circles” and “CircleGLES” at http://onflash.org/ted/2009/10/source-to-4-flash-iphone-apps.php#comments )

5) The soft texture baking and transfer process is very energy consuming, that’s you see games that only uses very tiny sprites with zero animation effects

That said, I believe there is still room for improvement, as I don’t expect CS5 to be on the market before at least another year. I don’t agree with the sort of crusades against people that believe they can use Flash to do iPhone applications, but certainly I would encourage them to get out of the box. Let’s also not forget that Flash developers who can understand programming in general had little trouble in exploiting their experience in CocoaTouch-ObjC; the ones still waiting for this “miracle” to happen are the same who complain about the difficulties of learning ActionScript3 (which you need to use to target iPhone).

It is critical to understand that by going with this tool there is a high level of unpredictability of the final result without considering that you are totally in the hands of Adobe to add any kind of support with new features that the iPhone platform may have in the future as your apps are delivered as closed compiled binary so it is simply not possible to add any kind of extension on your own.

Thanks for the detailed information.

What I still don't understand is why CS5 is making private calls. It makes no sense since the OpenGL ES API has everything they need.

Did you find out which library/functions are they calling with dlopen ? Perhaps it's legacy code and they are not using those functions.

I'm running ClickToFlash on my Safari browser. Glad to get rid of those stupid Flash banners and such. All I know is that all the other smartphone companies are going to try to leverage the iPhone's lack of Flash handling to say their platforms are infinitely better even though most of the browsing on the internet by smartphones is done by iPhones.

I say if Apple doesn't think Flash is appropriate, then I believe they have a good reason to keep it off the iPhone. I don't believe the lack of Flash will cause iPhone sales to drop at all. Flash is a battery burner and a processing hog on Macs. Not sure who's fault it is: Adobe's or Apple's? I'm not a website developer, but as a user, I say get rid of Flash. Those animations are just a waste to me even if I use a desktop computer. Flash is one full web experience I don't need or want.

I like this type of website (though not the white text on black) since it loads very fast and doesn't make the processor go ballistic. I wish more websites were like this. Some of the sites I run into are just Flash crazy. So seemingly useless. I hope HTML5 takes the wind out of Adobe's sails.

There are many things where Flash is a lot more efficient than any other web langage, I'm talking about fonts, vector and animation or even video. The key is to code it right. Which is not the case of lots of flash files on the web, simply because lots of designers are using flash, and they are not conscious of optimization. Also, some of those files have been made years ago.

On top of that, Flash has gone a long way. If you have a closer look to actionscript from 1 to 3, you will see that it came from nothing to a something that's now really close to java.

Flash still make things possible where other langages can't. Casual games are still mostly made using Flash. And RIA's too. I'm not sure that the most complex apps done in Flash could be done in JS. And HTML5 is not going to change things when it's about to be that interactive.

I dont think that the fact that you can integrate a video in a page without Flash will make Flash less popular or widely used. At all. That's just the tiniest bit.

Hey Luis,

Great post. I wrote Trading Stuff and participated in the early beta - I made some comments in the second half of my post at http://coderhump.com/archives/517 . I'd be interested to hear what you think.

Ben Garney

riq: No idea why they are doing it, I have not done enough analysis of exactly what they are doing for me to feel comfortable speculating

Stephane: I am going to have to disagree with you. I think there are a lot of places where the potential overhead implied by Flash is not significant, and is outweighed by the benefits (particularly compatibility). All things being equal there is no way that flash can beat things like SMIL, SVG, and the video tag in terms of raw performance on a modern browsers. The reason is two fold:

1) Flash doesn't have as deep access to the hardware as most modern browsers. Look at something like Mobile Safari or what Google is going to do with ChromeOS. When they encounter the video tag they can hand off the content to the HW decoder. In general that is not exposed at a level that anyone but the OS vendor can utilize directly.

2) Everyone is moving to a model where they run plugins completely sandboxed because they can't validate their security. Chrome, Safari on Snow Leopard, even IE. When they encounter something that needs a plugin they launch the plugin a subordinate process, then uses IPC to move all the data back and forth. They are relatively efficient, but that is still not going to beat anything that can be handled directly in the browser engine without spawning another process and bouncing everything back and forth.

Mind you, I am not trying to get down on Flash here. There are some fairly good reasons to use it (and some downsides, which other people have mentioned). Absolute performance is not the most significant factor for a lot of projects, it is often eclipsed by things like the developer tools or browser compatibility. But lets be honest, there is an inherent overhead to using a plugin, and all things being equal it will be slower.

Ben: I am glad you like the post, and I am excited to see that you have a version using the HW rendering path, I look forward to trying it out. I also want to thank you for being a good sport, I just to dissect Trading Stuff because it is the kind of game I enjoy, and any criticisms I expressed were not about the game itself. It is exactly the kind of thing that excites me about Flash CS5, so I am hopeful everything works out well in the end. You definitely have done an impressive job so far. Honestly, for a first release I think Adobe did a pretty good job, if they waited until they had all the issues worked out they would never be able to ship it.

One point I wanted to make. The issue with mixing assets into the text is not that you might page, swapping is disabled on the phone. The issue is that it increases the working size of the application (the vnode_pager can effectively swap by throwing out pages since it knows the app binary on disk never changes, so it never pages stuff out, but it can be forced to throw things out then page them back in, even on the phone). It also may have negative performance implications because the TLB on the phone is quite small (I want to say 32 entries, but I would need to check that to be sure), so you have a higher chance of causing TLB thrashing. Then again, if you get decent frame rates who cares ;-)

I don't understand so much all the complaints people use (although you certainly show a balanced perspective). I am a 10+ years Flash developer and now am learning Obj-C and am also surprised about the Adobe announcement but, why is everybody complaining about Adobe and its Flash-to-iPhone initiative? What is the difference between using Flash to create your game and Torque, or Unity, or whatnot? Aren't those other engines/softwares serving a similar purpose (for a similar price). I would be worried for a flood of app submissions and Apple not being able to handle that, especially given their current track record on that regard. But that is another question.

I'm grateful for a balanced and highly technical point of view, when most reading I've done on the subject is boring anti-Flash rant.

To your commenters who just don't like Flash, you're missing the point. Accessibility, indexability, performance are not the only criteria when developing a website. Sometimes the client doesn't care one iota about blind people - because they're not the target audience. Major Hollywood studios spend billions on _visual_ effects that sight-impaired people can't experience, but the website promoting it needs to be blind-accessible?

Flash banners, meh. I don't like _any_ banners. Animated gifs are just as obtrusive to my browsing experience. I blame the advertising industry.

The thing with HTML 5 is that it's playing catch up. It only purports to do what can already be done, albeit in a standards compliant way. Yes once we can actually use it for development (read, maybe in 5 years time) we'll be able to embed video in pages without plugins. Like we've been able to with Flash for 5 years. That's if all the browser vendors settle on a codec which so far they've been unable to do.

There are plenty of examples of badly developed software. For every OS, for every browser, for every development platform, for every language. Don't blame the technology, blame the developer.

If there aren't any serious technical reasons why Flash for iphone is a bad idea then I'll give it a nudge. Though it sounds like there might be a few concerns, I'll wait until it's at least in beta to see whether Adobe are likely to address them.

If Apple wasn't such a tyrant, this wouldn't be a problem. But heck, my iPhone experiences sucks. I constantly have to reboot.

I used to have a nice little Free Memory tool in the iStat app. It let me free up memory, and greatly reduced the need to reboot. Apple removed it. Now I am plagued with crashes, freezes, and constantly have to reboot again.

***

"Watching video in Flash on a Mac is a terribly painful experience compared to simply watching video. "

People say this...but when I used a Mac I never really had a problem watching video. And it wasn't some super-mac, just an iMac.

"Flash sites are typically inaccessible to the blind (98% of them are) and their content is not crawleable by Google et al."

So is driving...what percentage of web users are blind. We cater to them, and I am all for improving accessibility. But have NEVER considered it a real justification of complaint.

Cars have been around for an order of magnitude longer than the internet and they are still not accessible to the blind.

"Nowadays, an awful lot can be done with JavaScript, CSS3 and HTML5, rendering a lot of things Flash is used for obsolete."

Sorry, I've found very few AJAX apps to perform as well as Flash apps. Furthermore, new browsers and browser updates can render AJAX apps unworkable.

***

Lastly, Apple's restrictive behaviours are what's to blame. Adobe's just working on a solution.

And remember...this is just a beta.

********

Let me lastly add, that the AJAX code being used on this blog is not rendering properly and results in me not being able to post easily. Just goes to show that AJAX as well as Flash can have poorly written apps. And I tend to experience a lot more AJAX ones personally.

mga: I agree, at a technical level there is not much of a technical difference between this and Unity. The issue that doing something like this is very tricky, and some of us doubt Adobe's follow through.

The Saj: The iPhone is Apple's playground, they get to make the rules, and anyone developing for it should make peace with that. That is another reason I would not use this tool, because I doubt Apple likes it, and they could choose to modify the SDK terms to disallow it. That isn't a technical issue, but it is a risk early adopters.

As for Flash on Mac, I am pretty sure Apple publicly stated that Safari crashes where the backtrace went through the Flash plugin were the single largest source of application crashes on Mac OS X by a pretty wide margin. I know that the difference when I run Safari in 32 bit mode (where flash runs in process) and 64 bit mode (where it runs out of process) is like night and day in terms of memory usage and stability.

Also, I assume the issue you are referring to is that the bounds of the text in the comment window is wider than the bounds of the comment and can cause the text scroll back and forth as you are typing it? That isn't an AJAX issue, that is an iframe issue and can impact plain old HTML, JS, or Flash. It is an interaction between the template and the way blogspot handles its comments editor. Maybe I should look at fixing it, but I didn't write the template code, I used it because I like the visual design.

The point being, just because something isn't flash doesn't make it AJAX, and even if a site uses AJAX or Flash doesn't mean they are the cause of some particular problem. If you can trace a particular issue to the tech itself then it is worth looking at it, but blaming some technology for being proximity to an issue you have is how a lot of decent technologies get bad reputations.

@Louis

--
As for Flash on Mac, I am pretty sure Apple publicly stated that Safari crashes where the backtrace went through the Flash plugin were the single largest source of application crashes on Mac OS X by a pretty wide margin.
--

No, at this years WWDC Apple said "plugins" not "the Flash plugin" (although daringfireball reported it incorrectly).

Although, considering that Flash is the most widely distributed plugin, then you would assume it is the plugin that causes the most crashes.

mike chambers

mesh@adobe.com

mesh: Fair enough, I stand corrected on that point.

I'm going to have to jump on the flash bandwagon here...

I agree whole-heartedly with Barry Hannah when he says this: "The thing with HTML 5 is that it's playing catch up. It only purports to do what can already be done, albeit in a standards compliant way. Yes once we can actually use it for development (read, maybe in 5 years time) we'll be able to embed video in pages without plugins. Like we've been able to with Flash for 5 years. That's if all the browser vendors settle on a codec which so far they've been unable to do."

Flash is a very capable and ubiquitous platform for deploying all sorts of apps from the simple to the complex. But more important than the specific capabilities or technical strengths/weaknesses, IMHO, is the fact that flash is, in fact, a STANDARDIZED DEPLOYMENT PLATFORM, all by itself. To me, the single most convincing reason to use flash both now and into the future is because the flash player is standardized across all browsers and (theoretically) all platforms. As a developer, I can write the code once and it runs everywhere. I don't even need to know what the word "port" means (a nasty little 4-letter dev word if there ever was one).

Regardless of whether flash is a little bit faster or slower, the point is that it's supported everywhere (except iPhone so far). Without porting. And that's a beautiful thing.

Louis,

I can always appreciate it when a person like yourself shares an opinion that is not just based on superficial assumptions and baseless conclusions, but that you quite obviously put a good deal of time and effort into taking a look under the hood and truly seeing for yourself what's going on. I think you gave a fair, thorough, and highly competent analysis on this topic and I enjoyed reading it.

With that being said, I share a somewhat more optimistic perspective about this than you do, and I'll tell you why.

Firstly, all of the performance, security, and bad practice issues that you mentioned are valid, but considering that this is still in beta form, I won’t hold their feet to the fire just yet, so I'll go out on a limb and say that I'll wait and give Adobe the benefit of the doubt that they will tackle most, if not all, of these concerns.

But beyond these overcome-able issues, what's more important is that this opens the door to an even larger audience of developers for the iPhone. This is a good thing for Apple and the Apple community (well maybe not for their App approval team whom will become a lot more busy than they already are). Not only will this open the flood gates to more apps, but it's going to add a whole new breed of apps that have that "Flash" dimension to it. And quite frankly I think Objective C lovers are a little nervous. Flash programmers for the iPhone will be able to produce some extraordinary apps in a fraction of the time. I wouldn't be surprised one bit if you saw all the major iPhone app developers (like EA, Gameloft, etc) shifting their focus toward developing more of their apps in Flash. As an experienced developer in both technologies, I would prefer to create an iPhone app, hands down, in Flash than in Obj C unless there was a specific reason for me to do so otherwise, which would be less times than not. And I truly believe that most people who feel differently are those who don't have as much experience in Flash as they do in Obj C.

I tip my hat to Adobe for choosing to create this solution and I hope they deliver soundly on it. And I also hope that Apple recognizes the value of this and shows some due support for Flash apps.

Regarding dlopen(), dlclose() and dlsym(), those functions were indeed linked in by mistake, although never called. This will be fixed in our next private drop (and in the public drop later).