Experience Matters: Flash, iPhone, and Beyond

Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0

flashipadA lot of speculationopinionpassion and even war mongering surrounds Flash’s conspicuous absence from the Apple iPhone, iPod Touch, and now the iPad. So much in fact that Adobe’s CTO felt compelled to defend Flash and discredit HTML5 video warning that “users and content creators would be thrown back to the dark ages of video on the Web with incompatibility issues.”

Once Upon a Time

Sitting on the sidelines, I can’t help but think back to my time on Flash. Before the iPhone arrived (a.k.a. the pre-smartphone era), several of us here at Ansca worked on mobile Flash. We worked on devices with as little as a megabyte or two of RAM, with computing power comparable to one of the original Power Macs, and with so little space for binaries that every kilobyte counted. By the time I left, we had achieved breakthroughs in rendering and VM performance that no one at Adobe thought possible on such an old code base and on such underpowered devices.

Fast forward to today. The iPhone is more powerful in every conceivable way, yet Flash apps produced for the iPhone run slowly, eat up RAM, and have gigantic footprints (by mobile standards).

So what gives? Shouldn’t Adobe be able to get its act together? Are they lazy? Are they stooping to new lows? Are they irrelevant?

Picture 5The Untold Story of Flash and the iPhone

The real story is that Adobe’s sole purpose is the Flash-enabled web which is a euphemism for the Flash Platform (with a capital ‘P’). That is why Flash is the way it is today, for by definition, a platform must be one size fits all. It has to be the same across all devices. In the end, this makes Adobe’s job that much harder and also puts its goals at odds with Apple’s.

What makes this story so dramatic is that Apple actually wanted Flash at one point — yes, you read that right, Apple wanted Flash on the iPhone. At least initially, they bought into Adobe’s vision of a Flash-enabled mobile web. Of course, that all seems stranger than fiction now, but remember the world when SJ first demonstrated the iPhone at MacWorld, months before the first iPhone shipped and long before the advent of the App Store. At that time, Apple was promoting the iPhone as a desktop-class web browser in the palm of your hands, which inexorably meant supporting Flash content.

And Apple was going to some lengths to make it happen, though as is typical with Apple, all of this was being done quietly. A friend from Apple and several of his colleagues had actually come to Adobe asking for help to get Flash working on the iPhone. Apple even tried multiple times to recruit me to join them and jump start the port — once when the iPhone was still a secret and again days after it was unveiled. (In hindsight, turning them down was one of the most prescient decisions I’ve ever made).

By the time the original iPhone finally shipped, Apple had clearly changed their mind. They removed all use of Flash from their web site so that iPhone users could view it, announced the iPhone SDK and the iTunes App Store, and never looked back.

Great Expectations

So instead of asking “Why isn’t Flash on the iPhone?” I prefer to ask “Why the change of heart?”

The answer is simple: experience matters.

When I worked at Apple, everything was about the end user experience. More than a quarter century after the original Mac came out, SJ’s famous mantra about making it “insanely great” still rings true.

I think that Apple came to the same conclusion I’ve come to — namely that Flash has its strengths, but not when it comes to creating insanely great mobile experiences. It was designed for a different era, one dominated by desktop computers and laptops, not one dominated by new interaction models and devices with limited resources.

Originally, everyone including Apple thought that the web browser experience was essential to differentiating the iPhone from WAP-based browsers on other smartphones. Remember all their commercials touting the Internet in your pocket? If their goal was to promote desktop web browsing experience on the iPhone, then naturally Flash-enabled browsing had to be part of that experience. Today, the world is very different. Flash is still not on the iPhone, nor does it seem like it will be anytime soon.

Ultimately, Apple had a change of heart not just about Flash but about web technologies in general. It used to be that Apple’s standard party line was to recommend using HTML and JavaScript to create iPhone “apps”. In hindsight, we all know this was too limiting, but Apple had the foresight to recognize that it would just be too difficult to create visually rich, engaging, and interactive experiences without a different approach.

So in the end, Apple decided that native apps were the only way to deliver the best possible mobile experience. Hence, they developed the iPhone SDK and enabled software engineers to create great user experiences on the iPhone.

What’s interesting is how critical the iPhone SDK is to the entire App Store ecosystem. Apple shrewdly realized that by making the iPhone frameworks similar to Cocoa, the framework for developing desktop Mac apps, they could tap their own existing developers. It was a perfect fit for all those engineers who were already fluent in Objective-C and already knew their way around all those Mac programming idioms. And if engineers new to the platform wanted to take a peek, so much the better.

But what if you aren’t a professional software engineer? What if you’re just a web developer who understands Javascript but not C? What if you’re a Flash designer who has design chops and ActionScript chops? What if you’re a UI designer who resorts to flipping through photos on the iPhone to demonstrate your ideas? What if you’re a non-Mac software engineer who simply doesn’t have the time to climb the Objective-C mountain?

And then there’s the issue of time and money. What if you need to put together an app quickly? What if you simply can’t afford to hire a real iPhone programmer in addition to the designer? Wouldn’t it be nice if you didn’t have to make sacrifices in your app at the expense of your users or customers?

banner-customer-apps-medA Fresh Approach

That’s where the Corona SDK comes in. Written from the ground up for mobile devices, Corona makes it incredibly easy for anyone to create graphically-rich native iPhone apps. All you need to get started are some basic scripting skills. You’ll instantly have access to our high performance graphics and animation engine that makes it effortless to deliver a native iPhone experience. In addition, you get OpenGL-ES hardware-based graphics acceleration for free; we’ve done all the hard work so you can focus on creating great mobile experiences.

If you’re a web developer or a Flash designer, you’ll feel right at home in our environment. That’s because in Corona, you code in a language called Lua which has a well-deserved reputation for simplicity and speed. More importantly, the syntax is very similar to JavaScript or ActionScript 2. You can create objects and add properties to them as you please. Some of our developers have even ported Flash games and told us they spent more time improving the images and sounds than they did porting the code!

Lua also comes with a bunch of useful libraries for dealing with the basics like strings, arrays, and files. On top of that, we’ve added our own set of libraries that let you access native features of the device like accelerometer, touch, GPS, camera, and much more. And we designed it so that you can accomplish an incredible amount of things with one line of code, like drawing an image on the screen, playing a sound, or sliding an object across the screen just to name a few.

One of the biggest advantages of using Corona is that it accomplishes so much in so little space. Why is this important? Nearly all apps are downloaded directly to the phone over the airwaves, so if your app is too large, you’ll likely lose customers because they’ll have to go the extra step of using their computer’s faster internet pipe. That’s why we count every byte in our framework. In fact, it’s so small that you could store multiple copies of it on an old floppy disk. That gives you plenty of room to add stunning graphics and sound to your app to create the greatest possible experience without sacrificing distribution potential.

With our recent release of 1.1, we’ve added a ton of features like the ability to internationalize your app, overlay web pages over animated backgrounds, and access all native fonts on the iPhone. We’ve also added professionally-designed sample code to show you the kinds of visually-rich user experiences that are possible in Corona: the Compass sample is a beautiful and simple app that demonstrates integration with the magnetometer hardware in the iPhone 3Gs; the Twitter sample shows you how to combine native textfields to login your account and then use the Twitter web api to send a tweet; and the GPS sample connects location updates with the ability to open up a Google map of your current location.

When we started Corona, we code named the project after the Pixar movie Ratatouille. Like the food critic who was transported to the joys of his childhood after eating Remy’s ratatouille, this was a chance for us to go back to our roots: the joys of computer graphics, creative authoring tools, and mobile runtimes. The movie’s thematic message — anyone can cook — also resonated with us in the context of iPhone apps: anyone can create an iPhone app. So for us, the Corona SDK is just the beginning of our vision. Soon, the mobile app party won’t just be for those who code. It’ll be for everyone. Stay tuned.

Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0

This entry has 25 replies

  1. mtz says:

    Flash is a scriptable runtime environment that can also stream audio and video. Apple being apple wants a final say on what code ran on its devices and what code doesnt and they couldnt allow flash to work and maintain this control and that is why flash is out.

    If flash was allowed, people would write flash based application and bypass the appstore and apple would loose their 30% cut

    As a linux user, i know how terrible flash is but i think the main reason why apple doesnt like it its ability to run code apple cant control

  2. Tony P says:

    Oh please. Defend it all you want. It’s my god damned iPod Touch, if I want Flash on it I should be able to install it.

  3. lkl says:

    Isn’t Lua a JITed language? I thought App Store forbids anything that isn’t compiled ahead of time.

  4. I’m sorry, I really do NOT believe it’s a performance issue but one of politics. I think even if Adobe got Flash to run in 5K of memory Apple would not let it on the iPhone. I think part of it is Steve Jobs ego, and much of it Apple having a bone to pick with Adobe for Flash displacing QuickTime as the default video format on the web.

  5. John Doe says:

    nice PR, but I’d prefer to play flash based scrabble for free instead of going to the appstore. That and Jobs’ presentation where he went to news sites using the iPad and the Flash pages didn’t work was sad.

  6. Apple doesn’t want Flash because they have to pay for it. They don’t want to enrich Adobe.

  7. ObamaPacman says:

    It’s always been a performance issue. Flash content drives up CPU usage on Macs, so it’ll be a problem for a mobile device.

  8. I agree with VideographyLab, the use of Flash (whilst IMHO being a true coup for the user) the incremental revenue generation for Adobe would be unthinkable for Mr Jobs and crewe.

  9. steve says:

    Well, this article is absolutely OK with not condoning Flash on the Apple Mobile OS because it is pimping it’s own product. We now see that there are tablet devices about the same size as the iPad and they run Flash Player 10.1 amazingly well.

    Clearly, this is really about Apple wanting monetize the App Store for as long as it can. Once all of the other devices (hand held or tablet) prove they can run Flash, then everyone (including me, I have an iPhone) will make the switch away from an inferior device.

    Two corrections:

    VideographyLab and Franke Sinks UK happen to be wrong. Adobe no longer charges vendors to sell their devices with Flash Player included. They did. They haven’t for a while now.

    ObamaPacman makes a good point but who is to blame. I own mac computers too, and I can remember when people would talk about their Windows computers and brag about how well they would run before people put software on them. Then people would complain about bloat-ware, blah blah blah. In the case of OSX you are looking at a different beast than the mobile Mac OS. For example, ever since Flash went Intel and the systems began running with NVIDIA cards it became a lot more simple to boost the visual performance of apps via hardware acceleration. In the iPhone they limit access to certain APIs that would specifically benefit the Flash Player. Adobe has recently gotten very vocal about the fact that Apple is making choices that hold back any alternative development effort. So, yes, maybe their are performance issues. But maybe it isn’t enough to keep Flash off the device and maybe Apple is playing a roll in creating the performance issue.

    It is like entering the automobile industry late (which Adobe has… Flash has been mobile for longer than Apple has cared about the iPhone or the failed Newton device) and then creating uniquely goofy cars than run sideways on unique roads and then acting like it is everyone else’s fault that the other cars can run on those roads with those goofy cars. It is their prerogative to make that decisions (new cars and new roads) but in the end, it will be seen as amazingly proprietary and limiting, not inevitably innovative. In the end Apple created a very specific road and you have to build cars like them, screw the rest of the web. That isn’t very forward thinking. Apple is the bottleneck (reminder… I own an iPhone and Mac computers, so this isn’t an anti-Mac flamewar comment. I have been building the web for 10 years.)

  10. steve says:

    Some examples of Flash 10.1 running just fine and snappy on mobile devices:

    Tablet example:

    Mobile Example:

    Flash in a Mobile Browser:

    Mind you these are early examples. As the Flash Player 10.1 and Flash CS5 leave beta I am certain we will see more and more examples of the Flash Platform running great in mobile devices.

    I think the question will be, once Flash clearly proves that it can run well in the mobile platform, will the Apple devices let go of their monatization deathgrip? Worthy of note: When Flash proves to work on those devices, Adobe won’t be forcing people to use their technology to create apps (the way Apple does now) so suddenly we will all be looking at Apple and say, “hey, what gives?” as we watch Steve Jobs running away with pockets full of his 30% cut!

    Another prediction: PCs often cost a lot less than say the macbook pro and iMac I own. The cost has been prohibitive enough to keep the PC a huge leader over the mac forever. If the iPhone proves to be inferior (meaning other mobile devices, tablets or phones, can run more plugins and run them fine) will people feel the same way about the Apple mobile devices? Will apple’s only defense be “Well, maintaining control means ensuring a wonderful experience,” even though they are ignoring and neglecting the “wonderful experience” people are having on other mobile devices that are less restrictive?

  11. Evan says:

    Hi, Steve. We’re all pretty familiar with Flash (and I do read theflashblog.com) — you realize that this company was founded by ex-Adobe engineers from the mobile Flash and Flex teams, right? 🙂


    I look forward to installing Flash player on my Droid whenever I finally can, but I’ve already been working with mobile Flash since the days of Flash 5 on PocketPC. Here are my personal predictions, not based on any inside information:

    * What we currently call the “Flash platform” is actually a bundle of unrelated use cases that evolved to solve problems on the desktop, and my guess is that mobile will peel those cases apart again. For example, H.264 decoding is now standard phone hardware, so a good way to handle smartphone video is the way that iPhone and Android currently handle YouTube: show the embedded thumbnail, then launch the fullscreen native player. A Flash player doesn’t really add anything here.

    * Rich ad banners and navigation have been another important use of Flash on the desktop, but I think Flash 10 on mobile is overkill for the simple task of animating a banner or a navbar — and mobile WebKit already supports keyframe-based animation in CSS with tweens, easing, and 3D transforms. I definitely wouldn’t write a game in CSS, but it should be good enough for advertising. (Of course, someone still needs to write a good animation tool for CSS; we’ll see whether Adobe or Apple gets to it first!)

    * That leaves games and apps, for which I think Adobe is doing the right thing on iPhone and Android: get the player out of the way and write a cross-compiler for Flash source code. Why would you want to run something in a browser plugin, when you could run it as an application instead? But getting this to work well is a difficult engineering problem, and we won’t know how it performs in real life until they release CS5 to the public.

    * Also, speaking as a longtime mobile Flash developer, the App Store is a MUCH better way of making money than any previous indie opportunity on mobile. Apple’s 30% cut is an amazingly good deal: the mobile carriers used to take 50% off the top, and then you’d split the rest with a publisher, since carriers would never deal directly with indie developers. And then you had to negotiate separate deals with one carrier at a time, while Apple wraps the entire world into one interface AND takes care of all the local tax issues. Carriers used to make you pay really high testing fees (on Verizon, this was around $10,000 per Flash Lite game to get BREW certification), while Apple does testing for free. Carriers would take months to pay royalties, Apple takes 45 days. Carriers accepted a handful of titles per month and had a terrible store interface that their customers hated, Apple accepts tens of thousands of titles per month and their store has actual screenshots and reviews. Etc, etc. I understand people’s complaints about Apple, but honestly, you have no idea what it was like in the old days before iPhone!

    * In short, the web plugin seems like the least interesting use of Flash on mobile, and apps are where the real action is. But in either case, the idea of using Flash authoring to deploy the “same content” on desktop and mobile has never made a lot of sense — this isn’t related to Flash, it’s just not a good design idea. So ultimately, I view the phrase “Flash platform” as marketing-speak for “using mostly similar Flash authoring skills and shared assets to deploy some of the same content in different applications”. But it sounds a lot less snappy when you put it that way 🙂

  12. Andre Hinds says:

    All the petty politics aside, I’m glad to see a company that is building on the strengths of the iPhone/iPod Touch/iPad platform to give “the rest of us” to ability to code for this important and lucrative platform.

  13. Agreed @Andre Hinds

    “glad to see a company that is building on the strengths of the iPhone/iPod Touch/iPad platform to give “the rest of us” to ability to code for this important and lucrative platform.”

    Moreover It will more help full for us in future

  14. Frank says:

    Hmmm… Now hello world app costs 8.7meg, this article suggest they keep the binaries small.. are they for real?


  15. Walter says:

    @Frank, here’s my response to a similar question on stackoverflow (http://stackoverflow.com/questions/6517653/corona-sdk-produced-iphone-app-size):

    If you are a Corona (Indie or Pro) subscriber, then you will get an optimized binary. I just did a test on build 484 (the latest public release as of today) and HelloWorld is only 2.2 MB on iOS.

    The exe is actually an universal binary, meaning it targets armv6 and arm7 (run lipo to see) instruction sets. If we only supported one instruction set, Hello World would be only 1.1 MB, still less than a 5.25″ floppy disk!

    If you are a trial user, then you will get an unoptimized/trial binary that is 8.7 MB. The reason is b/c for trial users, we do not optimize the binary code size based on libraries that you “require” in Lua code.

    For trial users, the OpenFeint library gets included in the unoptimized/trial version whether or not it actually gets used. And believe it or not, OpenFeint is responsible for nearly quadrupling the code size of Corona!