We have several prototypes for apps currently in development using both Adobe AIR and other technologies such as PhoneGap/JQuery Mobile. Our current release is the Ransom Letters Word Game for both Android and iOS. This was built in Flash Builder using Adobe AIR 2.5, but we updated it to Adobe AIR 2.7 when that became available.
Adobe AIR has proven to be a great and fairly quick way to build mobile apps, but with it being our first app there were a lot of hurdles to jump through. From the process of registering as a developer to building apps for so many different screen sizes and orientations, there are a lot of things to learn.
Things that we have learned
This is a big part of the process if you are planning on selling the apps for Android and for iOS. The process of registering as a developer is quite simple, you just go to the respective OS sites and follow the registration process. There are costs associated with becoming both an Android developer and an iOS developer but they are reasonable.
It is not until you decide that you would like to sell an app that the process becomes more cumbersome. For Android, you have to fill out a couple of forms and verify a bank account for Google to make the deposits. For iOS, there are several forms that you are required to fill out and one that you need to mail in, this process takes much longer than Android so make sure you start the process well in advance of your planned app launch date.
2) Building the app
Flash Builder 4.5 has made it quite easy to start development of the app, and the AIR SDK has all the operating system ties that you will need to build a highly functioning app. The biggest pitfall that we experienced with using AIR is that it requires AIR for Android to be installed, and therefore v2.2 of the Android operating system.
While the runtime speeds are increasing, we have noticed that they are not up to par with native apps (yet). Until Adobe AIR 2.7 the iOS performance was quite poor, but 2.7 brought some much needed enhancements that made everything much more manageable.
3) Screen Orientations
When Ransom Letters was first launched, we were forcing it into portrait mode and ignoring all screen orientation changes, because it was just easier that way. We eventually changed that and built it so that you could switch between portrait and landscape as you pleased.. this proved to be a big challenge.
The challenge was positioning of elements, whenever the screen rotates everything needs to be repositioned. We ended up building a manager for handling some of the orientation positioning, but there is still a lot of manual positioning updates that we had to perform throughout the code. This challenge was made even harder when we took into account all the different possible screen sizes that the app was going to be available on (including tablets).
One other part of this that should be noted is the trouble in getting the initial orientation of the screen. This worked fine in iOS but Android didn’t seem to report the dimensions properly. There is also a slight delay at the initialization of the app where you can’t get the size of the stage. What ended up working best for us was to NOT try to get the initial size of the stage to figure out the orientation, instead we force the app to portrait mode on startup (done in the application XML) and then detect changes from there.
4) Publishing Apps for testing
Testing on devices was a breeze with Android, we were able to publish straight to the device from Flash Builder. It proved to be a much more time consuming challenge for iOS. With iOS, you need to go into the iOS development site and create a certificate as well as a development provisioning file that need to be used when publishing for testing on an iOS device. This takes some time, but it is completely worth it to test your app on the iOS devices. Also, make sure to follow all the processes on the iOS development site to make your device a ‘development device’.
5) Publishing Apps for marketplaces
Just as testing was simple and efficient on Android, so is publishing. You need to go to their only tool and create the app, enter all the information and upload the app using their web interface. When that is complete, the app available in the marketplace.
Publishing for iOS takes a little more time. You need to go through and create the appropriate provisioning file using the same tool you used to create the testing profile. You need to go into iTunes connect and create the app in the management system, entering all relevant data. And finally you need to have access to the Application Loader program (comes with XCode, mac only) in order to upload your app for review. If you have done everything right, you will be able to upload your application and it should be reviewed and approved within a week or two.
6) Updates take time
Just a little FYI, in iTunes connect if you would like to change any meta information about your application it has to be associated with an update. These updates are subject to the same review processes as the app was when creating it initially.
plan everything out before starting
register early and make sure all forms are filled out and approved
take screen sizes and orientation into account when designing and developing
keep an eye out for the latest Adobe AIR SDK’s