Mobile Application Development– Apple Moves the App Goalposts
The recent change to Apple’s iOS Developer Agreement, the change that now permits iOS applications from third party development tools, is big news for Flash developers wanting to get in on iPhone/iPad development. More than 6.5 billion downloads have been made from the Apple App Store since mid-2008, so an enormous market may have just opened up for Flash developers.
We’ve always been able to pursue mobile application development for the iPhone and iPad but with this latest change we may be able to offer our clients a broader digital deployment range from one AS3 codebase, which translates to an increased value proposition.
With these changes, we may be able to build an application in Flash, then publish it for the web, publish it as a stand alone application (AIR) and also publish it as a iPhone application for download from iTunes. Each of these deployment endpoints has unique constraints and hardware considerations but the fundamental logic is retained. Moreover, by not having to employ Objective-C (the native coding language for Apple applications), we can build solutions from existing Flash codebase, 3rd party libraries and years of Flash development experience.
We’ve run a couple of quick tests with the iPhone packager as it stands as a way of further developing our in-house knowledge around how all of this might work.
A note on our apps: they were created solely to run some quick discovery tests and are in no way comprehensive or optimised for the device. Furthermore, both of these apps were based on publicly available AS3 packages and not custom built, so we’re not in a position to comment on how optimised the code’s logic may be.
The first application we devised was to see how the device performed as an increasing number of sprites are added to the stage. We’ve used gSkinner’s fantastic Wander Motion Class, which again wasn’t specifically intended or optimised for device deployment. The only change we made to the script was to cache each flying object as a bitmap and control the number being added to the stage. The application was published to iPhone using CPU Rendering (GPU was very slow, and it seems the Auto option is yet to be implemented).
By tapping the screen we could add 5 more flying objects to the stage (Or “dudes” as Grant puts it in his code comments) while monitoring the frame rate and the total count.
You’ll notice in our video demonstration that the device held up pretty well to around 80 objects, after which the motion became fairly clunky as the frame rate dropped. It didn’t plummet, but dropped steadily with each extra tap of the screen.
Our second test video was a response to Jesse Freeman’s brilliant Bitmap Scroller Class, and thanks to Jesse for making this available, complete with test, on Android. I should also mention, that the original use for the Bitmap Scroller Class was The Johnny Cash Project, which is also worth a look.
Another quick disclaimer: the images are actually embedded in the Flash library, which is different to Jesse’s execution, in which they are loaded externally from a folder inside the AIR package.
You can see on the video the first pass of loading the library assets into memory is a bit chunky, but from then on it runs at lightning fast speeds. Imagine what the performance would be like for an application running with an image of this size on the stage?
In summary, it’s still very early days, however Flash Developers should be feeling excited. We certainly are after these couple of simple tests and what it means we may be able to offer clients in the near future.