A lot of speculation, opinion, passion 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).
The 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.
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.
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.
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?
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.
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.