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.
Posted by Walter. Thanks for reading...