Optimizing Your Flash Content for iPhone

Mobile Development Comments (6)

One of the most highly anticipated features in Flash CS5 is the iPhone application packager. This will allow Flash Designers and Developers to create new applications for iPhones, iPod Touches and iPads. One of the greatest things about this in my opinion is the opportunity to port over existing content and applications to the devices. If you have a stack of RIAs, eLearning modules, or other Flash content that you think would be appropriate for a mobile device like the iPhone, it’s a great opportunity to give that content some new life and reach a whole new audience. If you have considered entering the world of iPhone development beforehand but were held back by the toolkit (Xcode being Mac only), or the language (Objective C is certainly a bit more high level than ActionScript), this is also a great chance to target a very popular family of devices.

The possibilities for eLearning/mLearning developers on this platform are virtually limitless. With institutions like Abeline Christian University requiring iPhone/iPod touches for all students, and the recent uptake by a number of large corporations, it doesn’t seem that the rate of application development and deployment (billions and billions of apps downloaded) is slowing down anytime soon. It seems that the market is there, and as of yet, there is not a corresponding huge development crowd in the eLearning world that is comfortable with the advanced toolkits required to create the content for the iPhone. It’s only a natural fit then, to think that eLearning professionals have interest in this new avenue. Porting eLearning content to a mobile device friendly format is a burgeoning field. This is obviously commonly known as mLearning. Barring some basic misconceptions that simply making your eLearning content work on a handheld is the perfect way to go (answer – it’s probably not), this article examines some of the technical considerations you need to recognize in this transition.

For Flash platform content creators there are a number of things that you must consider in making the transition to the handheld world. For those of you familiar with targeting other mobile devices using Flash Lite, much of this will be familiar. For designers that have only delivered to the desktop or laptop there are some big changes in front of you.

The Flash community is rapidly testing this new opportunity out and documenting these differences. Mike Chambers has a great presentation on basic performance optimization tips that is well worth the download and a must read for any nascent iPhone Flash developers. Christian Cantrell has a great article at the Adobe developer center on the new input modes that are available on the devices. Some other content from Max of last year is still very much applicable, though some minor changes have occurred that put a little of the content out of sync with some other sources floating around out there. There are even some links offering tips for the, as of yet unreleased, iPad. At Float we have performed some extensive testing on Flash performance from a mobile perspective and have some tips that you may not have heard about yet. We’d like to share some of these initial findings with you to help you in determining how to best adapt your content for the mighty mobile: the iPhone.


As mentioned before, reading the slides from Mike Chambers and the other articles is required. Beyond that, a few other things have sprung to the forefront in our tests. We have used the Hires Stats package from Mr. Doob for determining the results of these tests. These tests are not

  • Framerate doesn’t seem to have a direct affect on the overall memory usage, and the old trick of incrementing your framerate by one over the lowest ten (31 vs 30) doesn’t seem to offer any noticeable benefits.
  • Even a very simple application is going to have an application size of at least 3.5MB (this is evidenced by various Flash package ipa files available on the iTunes store). Not a big deal, but something to consider if you are planning on deploying this application in locations where EDGE may be the only cellular data network available.
  • No real noticeable performance issues arise from orientation switches or choosing to create a full screen app or one that displays the devices title bar. That said, orientation changes do seem to produce a little hiccup in the app’s display animation when the screen is rotating. We’ve downloaded every iPhone application on the iTunes store that we know to have been produced using Flash to assess this.


Very quickly, when graduating from creating a simple Flash animation to something that requires screen transitions or state changes, people start to use programmatic tweens to move DisplayObjects around (movieclips, sprites, bitmaps, etc.) We have performed some tests on this, using several of the most popular Tweening engines out there to find out which one should offer the best speed and quality on the lower processor speed of the iPhone. We used the built in Tween class Flash provides, the Tweener engine from Zeh Fernando (we love you Zeh – Tween still rocks), and TweenLite from Greensock. In most operations, Tweenlite outperformed the other engines noticeably. It’s safe to say, that if you’re porting content over from a desktop Flash deliverable, we would consider switching over the animations from the original method you used to the TweenLite package. Of course, the TweenLite package does have a few minor limitations (no built in Color tweening, for example), so be mindful of that.


When the smartclip became the component, something wonderful happened. What was rigid and had limited utility, became powerful and highly useful. The V3 Actionscript Components dramatically improved on this once again, adding configurability and easier skinning. One thing they also added was heft. Download speed, memory usage and CPU requirements were definitely increased. On a desktop, not that big of a deal. On a handheld, it is a big deal indeed. An application with a kitchen sink of components: Buttons, Slider, ComboBox, Text Field, Text Area, Radio Buttons, Checkboxes, etc. uses over 6MB of ram and is pretty sluggish in our tests. So what are you to do if you have a piece you want to publish to iPhone that requires these form elements we all depend on to add functionality to our Flash? Here are a couple options…

  • Strongly reconsider if you actually need that components featureset before using them. Realistically, the Button, Slider and Text Components offer very little in terms of advantages that make them viable for use on mobile platforms. Perhaps you could code something up quickly that uses just simple Sprites or MovieClips and write your own listeners, etc to handle the input and interaction.
  • Use a smaller component set like Keith Peters’ MinimalComps. A little over two years ago Bit-101, as Keith is known to the Flash community,  released a suite of simple components with a nice minimal look and feel. They also have a substantially smaller footprint than the included Flash components. They would probably require some tweaking visually to work well on the iPhone, but after those adjustments, they use nearly 33% less memory and are definitely more responsive than the defaults. Keith continues to enhance and improve the components, adding new UI elements often. Take a look at the screenshots following.

    Basic Flash Components - 6.3MB

    Bit-101's Minimal Components - 4.4MB

  • Wait for a component framework like Slider to come out. When will this be? According to sources in Adobe, “Sometime in mid to late 2010”. *Eugh*.

Display Objects

Obviously stacking tons and tons of items on top of each is something that is CPU intensive. The aforementioned presentations warn us of the CPU implications of said stacking. Place items carefully. Examine why you need that item there. Do you really require that many sprites or movieclips? Could you composite them together to make one or two items out of the 6-8 of them? In addition to display object depth, we have found that on a sprite by sprite basis, bitmaps require less memory and CPU to render a comparably designed visual element. Surely, you can cache items as bitmaps or use the BitmapMatrix to convert on the fly, but why not prepare your assets the right way the first time?

Fonts and Type

Fonts have always been somewhat expensive in Flash. Back in the days of spotty broadband, they took precious kilobytes. Then, CPU. Now with mobile users, it’s really a combination of the two. Honestly, if you can get away with using a device font, do it. If not, consider how you are using the type. Could it be better served as a bitmap sprite? It’s strange but true, this could be possible. Take a look at the memory and quality in these two images and then compare. Choose wisely when embedding fonts. Certainly branding standards are important, but so is application performance.

Device Fonts

Fonts Embedded

In closing…

So, the already released info from Adobe and the evangelist team is great. Very helpful and really really sharp as usual. Only dabbling in these tools can provide you with more insight. We hope that you have found these initial musings useful. What other sorts of optimization tips are you coming across in porting Flash content to mobile devices? Adobe AIR for mobile, Flash Player 10.1 mobile are all just around the corner. Are you getting your content ready for the eventuality of publishing to the small screen? We’re definitely listening. Leave a comment below and let us know.

Follow Float
The following two tabs change content below.
Chad Udell is the Managing Partner, strategy and new product development, at Float. There he leads his design and development teams to successful outcomes and award-winning work via a strong background in both disciplines and a singular focus on quality. He has worked with industry-leading Fortune 500 companies and government agencies to design and develop experiences for 20 years. Chad is recognized as an expert in mobile design and development, and he speaks regularly at national and international events and conferences on related topics. Chad is author of Learning Everywhere: How Mobile Content Strategies Are Transforming Training and co-editor and chapter author, with Gary Woodill, of Mastering Mobile Learning: Tips and Techniques for Success. His newest book, Shock of the New, co-authored with Gary Woodill was released in April of 2019.

» Mobile Development » Optimizing Your Flash Content for...
On March 9, 2010
, ,

6 Responses to Optimizing Your Flash Content for iPhone

  1. Jake Burkart says:

    Did you guys do any testing with embedded video? I’m still having issues getting smooth playback even on a 2MB file with the iPad!

  2. chadu says:

    Jake, no not as of right yet. Are you embedding the video in the main app file or linking out to a h.264 file? What is the files resolution and datarate?

    Thanks for visiting. I look forward to hearing more on this line of testing.

  3. Great post … i have a question … How Fonts are handled in the iphone?. I am in the middle of a iphone development with Air .. my fonts look weird or low resolution. I have read this post and i can’t see the idea clear … how to achieve a normal resolution ?? … must rendered as bitmap ? .. or i have to embed a font ??? …

  4. gavin power says:

    This post is almost a year old but I still found it useful. Thank you. To get any type of decent performance from iOS with the packager, you need to focus on rendering. The simpler, the better.

  5. […] Optimizing Your Flash Content for iPhone […]

Leave a Reply

Your email address will not be published. Required fields are marked *

« »