Software development has gone mobile. We see a large audience using smartphones and tablets, and as developers/marketers/entrepreneurs we want in. When planning such a project there are myriad decisions.
CHOOSE – THE PLATFORM
The choice of target platform (e.g. iOS) and target device (e.g. iPad2) is a primary consideration. Apple’s iOS hits the majority of the market but with time others will mature and may offer more competition. Moreover to hit your market you may be best served to offer your software to more than one platform and more than one device-per-platform. Quite quickly a rather conservative project can target 5-10 unique pieces of hand-held hardware.
CHOOSE – THE DEVICE
Each device offers unique features. The market-penetration, platform, processor-speed, input-capabilities, screen-size, and other factors are all important. Two major form-factor camps are ‘phone’ size and ‘tablet’ size. There is some overlap between these categories such as the Samsung Galaxy 1000.
CHOOSE – THE MONETIZATON
There are many monetization schemes possible. Here are a few of the popular ones;
- Free – To gain experience and reputation.
- Freemium – Offer a free version and market within the experience for a pay-version with more features.
- Ads – Integrate video ads, animated ads, or still ads into the experience.
- Micro-transactions – Offer bite-sized purchase opportunities which enhance the experience.
CHOOSE – THE DEVELOPMENT PATH
When the platform(s) and device(s) have been chosen, the path to develop must be chosen. In general there are two strategies
a) Native App Development – This means you use the 1st-party language (and tools) offered by the platform creators. This means using XCode tool with Cocoa framework coded with the Objective-C language when developing for iOS. Native development generally offers the very best potential performance (i.e. for high-end gaming) and tightest integration to the devices (e.g. detect battery level, etc…) and OS/marketplaces (e.g. iOS in-app-purchase).
b) Non-Native App Development – Many 3rd parties offer code libraries and tools to ‘speed up development’. Some of these are in the native language and some are not. Some of these non-native solutions offer the ability to ‘code once (so to speak) and deploy to multiple platforms’.
c) Mobile Web Development – Instead of a standalone application, an experience can be made available via web-browser and development to fit the size of the target (mobile) device(s). With HTML5 much is possible, but in general this is used for less-expressive less-device-specific experiences. It can also be a very inexpensive way to ‘break into mobile’, as you can use assets/code from your existing website..
While the ability to develop one project for multiple platforms offers many advantages in saved development time and ease in maintenance, it also offers many challenges. Designing a compelling application that takes advantage of the unique features of each device and looks polished on the dizzying array of screen sizes out there can be daunting. For Flash-To-Mobile there are many resources on Adobe’s Mobile Devnet to help you learn the basics.
It is possible for an application to be self contained, including all data/assets with the original install. This is common for games. However many projects require internet connectivity. The data/assets loaded can reside on existing servers outside of your control, or can reside on your own servers. Custom backend solutions using typical backend languages (c++, Java, PHP, Python, etc…) may also be required. All of this depends on your particular project. In general any of the development-paths can contact any of these backend solutions, but some may connect more easily than others.
Let’s assume you have a great new game and want to capture a ‘big audience’ with ‘modest investment’. If the application does not require deep-device-integration a recommended choice is to target both iOS (iPad1/iPad2, iPhone3G/iTouch3G, iPhone4G/iTouch4G) and Android (various devices). If your team has Flash expertise the Flash-To-Mobile publish path may be ideal.
With Flash CS6 and more-so Flash Builder 4.6, Flash/Flex developers can publish ONE codebase to MULTIPLE platforms. Using Adobe’s AIR 2.7 (latest public release) you can develop many platforms & Devices.
Compatible Target Platform/Devices: Web-Browser (Mac+Windows+Linux+Non-iOS Mobile Browsers), Desktop (Mac+Windows+Linux), iOS (Ipad1+Ipad2, iPhone+iTouch 3rd Generation, iPhone+iTouch 4rd Generation-Retina), Android (Myriad Devices), Blackberry Tablet OS (Blackberry Tablet).
Supported Flash-To-Mobile Device-Specific Features: Flash-To-Mobile does offer view-persistance, data-persistance, video playback, still-camera capture, still-camera-roll save/load, internet access, in-app web-browsing, accelerometer/gyroscope, Microphone, Geolocation, Multitouch, File-system access. Not all devices offer the same features. In the future ‘Native Extensions’ (see below) offer a solution.
Project Setup: A recommended options is one bulky Flex Library with (most) all code and assets, and then one Flex Project *PER PLATFORM*. You add/edit to the library and publish each of the projects as needed. You can test with an mobile-emulator (fastest) window that appears on your computer, or on the device via USB (best to test hardware features like accelerometer. The ‘flash’ code is converted to ‘native code’ (so to speak) before deployment.
Deployment: Upon completion the platform-specific file is uploaded to the platform-specific marketplace (e.g. iTunes’ App Store for iOS). A Flash-to-Mobile project sits along-side native applications. Ostensibly users have no idea the application was developed with non-native tools. The marketplaces do not delineate this or otherwise make that info available in any way to users. The end-user experience can be indistinguishable from a native app (project type and project polish depending).
In light of the ‘Device-Specific’ features listed above, Flash-to-mobile currently leaves us without everything we may want to do (e.g. iOS in-app-purchase). The yet unreleased (release date is ‘early October 2011′) Adobe AIR 3.0 will include ‘Native Extensions’. In short, this allows for *ANY* Flash-to-mobile project to access *ANY* feature on *ANY* supported device (Android / iOS / Blackberry Tablet). Developer will require knowledge of both AS3 (flash) as well as the Native language(s) on the target device(s) to add new features. Or your team can find free and premium extensions which the community could share. This is not just for mobile, this technology will also allow AIR on desktop computers and AIR on TV’s to integrate with those devices too.
Native Mobile Development
Non-Native Mobile Development – Flash-To-Mobile
- Flash-To-Mobile (Using Flash and/or Flex) for iOS/Android/Blackberry Tablet OS… also Desktop/TV/Browser
- Success Bringing Flash Games to iOS
- AIR 2.6 (Available in Full Release) – Commonly in use today.
- AIR 3.0 (Available in Public Beta Now) – Offering Native Extensions and more.
- Example of Best-Seller Flash-To-Mobile Game for iOS
- Example of Best-Seller Flash-To-Mobile App for iOS
- Flash-To-Mobile for iOS – Using SWC files to build large Flash and AIR projects with multiple SWF files
Non-Native Mobile Development – Others
- Corona for iOS/Android
- Corona vs Adobe AIR (Great Article)
- RhoMobile for iOS/Android
- Appcelerator for iOS/Android
- Mosync for iOS/Android
- Phonegap for HTML5 Mobile-Browsers
Some of what is coming in the future is listed below.. This may or may not all be included in the very-next tools. Recently Adobe has announced What’s new in Flex 4.6 SDK and Flash Builder 4.6.
I. The Second Coming (Halleluiah) – Flash-To-Mobile Native Extensions
This future feature will ostensibly allow Flash-To-Mobile projects to access *ANY* feature on *ANY* targeted device (e.g. in-app-purchase on iOS).
- Adobe AIR 3.0 Native Extension – Explained!
- Adobe AIR 3.0 Native Extension – Demo Mapview on iOS
- Adobe AIR 3.0 Native Extension – Tutorial 1
- Adobe AIR 3.0 Native Extension – Tutorial 2
II. The Second Coming (Halleluiah) – Stage3D
Stage3D (Formerly codenamed ‘Molehill’) is a set of API’s available in the future that will ostensibly allow Flash Browser projects (using Flash Player 11) and Flash-To-Mobile projects (using Adobe AIR 3.0) to show high-grade hardware rendered 3D. Finally, the Flash Platform can truly compete as a 3D gaming engine. The same API (despite the name) can also be used for radically improved 2D gaming performance too.
NOTE: These API’s are low-level and challenging to understand. We expect 3rd parties will wrap this functionality with easy-to-use API’s for free/premium use.
- Stage3D – Explained!
- Stage3D – Demo!
- Stage3D – How-To! (For 3D Gaming)
- Stage3D – How-To! (For 2D Gaming)
- Unreal Releases ‘Citadel’ – The first interactive demo of UNREAL engine running in Flash Player.
- BlackSun Game for Stage3D
III. The Second Coming (Halleluiah) – Air 3.2 = Stage3D for Mobile + Many Stage3D Frameworks
So with AIR 3.2 (See Adobe Press Release) we can use Stage3D for mobile. This means GPU-Accelerated graphics on iOS/Android. I think there is a marketable benefit on getting the Flash Player to compete against other 3D gaming solutions (such as Unity3D) and perhaps compete less with emerging 2D gaming solutions (such as HTML5 gaming) so I can sympathize with Adobe’s (better late than never) focus on 3D for Flash. This article “Why Starling (or any other 2D framework on top of Stage3D)?” explains some really good reasoning.
An unknown HTTP error occurred. Please examine shortstop's debug output for further details
Mind-blowing Demo’s of AIR 3.2 on mobile
- Five AIR 3.2 Stage3D Mobile Demos That Will Knock Your Socks Off
- Spaced Away is the first game in the iOS app store to feature Stage3D by developers Falanxia.
Regardless of why, Stage3D is here, and Starling’s power lies in how it uses the Stage3D – first available in Flash 11 and AIR 3.0. Stage3D is designed for GPU accelerated 3D. While its possible to use the Stage3D API’s directly, it is very difficult. There are 3D frameworks for AS3 , but for many game developers we can exploit its power for 2D gaming. That’s why Starling focuses purely on 2D. So an API like Starling helps developers make great content – quickly.
AS3 frameworks use Stage3D for 3D gaming;
AS3 frameworks use Stage3D for 2D gaming;
Key Articles I’ve written on the subject