It's fun to look back in time. This blog post from 2007 reminds us of the messy state of the web back then, and points out how the Flash runtime seemed like the best answer to writing Rich Internet Apps (RIAs).
Flash is great
Macromedia/Adobe delivered on a compelling vision, with a fast runtime and some incredible, rich features. They essentially solved the world's video interoperability problems (remember Quicktime, Real and Windows Media Player wars). They could even play video on machines with no hardware video acceleration (which was most computers until recently). They followed Apple's lead and supported the H.264 video standard (what some reporters like to now call HTML5 video) rather then proprietary formats (e.g. VC-1 from Microsoft).
Apple loosened restrictions slightly with this morning's announcement, but they didn't go far enough.
We are continually trying to make the App Store even better. We have listened to our developers and taken much of their feedback to heart. Based on their input, today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 to relax some restrictions we put in place earlier this year.
In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.
In addition, for the first time we are publishing the App Store Review Guidelines to help developers understand how we review submitted apps. We hope it will make us more transparent and help our developers create even more successful apps for the App Store.
What this means is you can now author apps in whatever developer tools you want. Section 3.3.2 had said that no interpreted code may be downloaded or used in an app except for code run by an Apple-documented software program. Sounds like you will now also be able to run interpreted code in your application. Sounds also like not only can Adobe's Flash Authoring tool be used to produce apps, but that your app can include a Flash runtime and can interpret and execute code in your SWF.
It will be interesting to see to what extent runtimes such as Flash will be allowed on iOS. Will Flash Professional continue to recompile code into native language, will they now produce an app that bundles the Flash runtime into each individual app, or will there somehow be a mechanism by which a shared Flash runtime can be used on the iOS? I imagine that Apple's restrictions still don't permit the later option.
This is a good move for developers but it falls short of allowing larger companies reign to innovate on top of the iOS platform. You will not, for example, be allowed to have an app that downloads an eBook that contains scripted, interactive content. See my previous post iPad an impediment to document innovation to understand what some of these issues are.
Of course the repercusions of this announcement extend beyond Flash. I hope it also means that we'll be able to run MacRuby on iOS sometime in the next few months :-). Publishing the App Store review guidelines is big news as well. You actually have a chance now of knowing before you start writing your app whether it will be rejected. For instance, I am working on an app that contains ads, and I won't use iAds. Apple now states that "apps that are designed predominantly for the display of ads will be rejected", which means I should be okay.
- Removed restrictions on running interpreted code in your app
- Did not remove restrictions on interpreted code within document formats
- App Store guidelines are now published
If you want to pass parameters down to your application through the badge installer launch parameters:
Make sure you set allowBrowserInvocation to true in your application descriptor file (appname-app.xml). Doh!
Encode your launch arguments. A lot of characters are not permited.
It's hard to believe Adobe can keep squeezing more goodness out of such a mature product. Favorite features in previous Illustrator releases were trace, art boards (I love art boards), smart guides and save for web and devices. This release they've improved art boards, overhauled arrowheads, and added various stroke features.
Steve Jobs posted on Apple's web site today an unprecedented diatribe on Adobe's Flash technology. I know a lot of folks like to revel in Flash bashing, and worship the flip flops Steve walks in, but it is way over the top when you are in a strong market position and yet feel the need to rip into another company and denigrate their technology. This is particularly true when the remarks are mostly wrong and easily refuted. What this is really is politics: one party labeling and name calling to make the other party look bad and deflect attention.
Jan Ozer in this article compares H.264 video playback performance of Flash and HTML5 across Windows/Mac, Chrome/Safari/Firefox and Flash 10.0/10.1.
Overall, it’s inaccurate to conclude that Flash is inherently inefficient. Rather, Flash is efficient on platforms where it can access hardware acceleration and less efficient where it can’t.
Adobe has responded to the CPU Performance gripes and Steve Jobs finger pointing and done a lot to improve performance in Flash Player 10.1.
With Flash Player 10.1, Flash has the opportunity for a true leap in video playback performance on all platforms that enable hardware acceleration.
But Apple does not expose the necessary hooks to do hardware accelerated video playback on Macs.
I don’t follow the politics of the situation, but after noting significant playback efficiencies in Flash Player 10.1 on the Mac, respected technologist and AnandTech founder Anand Lai Shimpi commented with actual GPU-accelerated H.264 decoding I’m guessing those CPU utilization numbers could drop to a remotely reasonable value. But it’s up to Apple to expose the appropriate hooks to allow Adobe to (eventually) enable that functionality.” So it looks like the ball is in Apple’s court.
Adobe just released this sneek peak of Adobe Flash CS5. Two nice improvements are:
- The ability to save projects as uncompressed xml-based text and asset files
- Tight code authoring integration with Flash Builder 4
A seemingly minor enhancement is that the native .fla project file is now zip and xml based. What is more interesting and progressive is that you can also save the project as an uncompressed project folder where all the assets are laid out in your file system.
The layout within the project folder looks like this:
The two major advantages here are version control and the ability to directly manipulate the contained files with other tools. Versioning text files, as compared with binary files, means that you can diff versions and your source control system can take advantage of diffs between versions to reduce storage requirements. This is particularly relevant when you use git for source control because git keeps a complete copy of the repository on your local system.
A second major improvement in Adobe Flash CS5 is for ActionScript 3.0 developers (ActionScript 2.0 and FlashLite developers are left out here). Flash CS4’s AS3 development environment was rather unsatisfactory. Rather then try to improve this, Adobe has gone the direction of Eclipse. Flash CS5 now includes tight integration with Flash Builder 4, a rich Eclipse-based code development IDE.