aka: Adobe AIR 2.7 VS Titanium Appcelerator
Recently there’s been a lot of discussion in the mobile development world about Code once-Run anywhere tools like Adobe AIR or Titanium Appcelerator. At customedialabs we’re very interested in mobile app development so we didn’t think twice about putting those tools to the test, to evaluate if we could use them for future projects.
To understand the value of these tools, let me briefly describe the two options for someone who needs to develop an App for more than one platform (e.g. both iOSes and Androids).
1. Use the native development platforms supported by the device vendor.
Pros: You can use all the available device features to the full extent, and get the best possible performance.
Cons: You have to develop in Java for Androids, Objective C for iOSes, Silverlight for Windows Phones and so on. If we consider the different APIs, different hardware capabilities or different screen resolutions in all supported devices that need to be taken into account, we are facing a very challenging task.
2. Develop the application using HTML5/CSS3 and deploy it on the device’s mobile browser as a web app. PhoneGap is a platform that is becoming popular and is mainly using this approach.
Pros: This approach achieves a single codebase since the majority of smartphones support HTML5, although every platform has its own quirks.
Cons: The application runs on the browser’s sandbox, which makes it impossible to access some of the device’s built-in features like accelerometers/cameras etc.
What Titanium and Adobe AIR are trying to achieve is abstracting all the parametrization necessary for every targeted device, and presenting the user with a single IDE that can produce native applications that have consistent look and functionality on all platforms.
Let’s take a closer look at each one of them:
Titanium Appcelerator
Titanium Studio uses a Javascript API that gets translated to its native compiled equivalent when deployed as an application. It currently supports iOS, Android and Blackberry platforms; the last is in the beta testing phase. With Titanium, developers get native performance, access to all the device’s capabilities (those that are supported by the API) and a single JS codebase to maintain. How good can that be?
However there are some serious drawbacks that need to be considered.
- You are depending on their API use cases. If you would like to implement something that is not covered in the existing API, you are out of luck. Your best bet will be to implement it as a native module (Java for Androids, Obj-C for iOSes and so on) and embed it on the Titanium platform, however this beats the purpose of having Titanium in the first place.
- Titanium organizes the code in one JS-file-per-View which is not suitable for implementing large projects, or MVC methodologies.
- Debugging takes forever! I know this depends on Android’s SDK toolchain but spending 3-4 mins every time we want to debug the app on the simulator was the biggest turn-off for us.
- The implementation is not consistent on iOS and Android platforms. You’ll often find yourself wondering why your app looks good on an iPhone but breaks on a Nexus, often struggling with incomplete documentation or unanswered blog posts.
- Titanium applications have been reportedly accepted on both Apple store and Android Market.
- There is no UI Designer tool, so you end up measuring pixels to design your UI in code. Combine that with the fact that launching the Android simulator to actually experience your UI can take long time, and you have a very frustrating experience.
Our opinion after briefly testing Appcelerator, is that it currently offers very fast as well as trouble-free deployment for simple applications only. If you would like to implement a functionality that’s not common or covered on Titanium’s sample code, you are better off trying some of the other alternatives mentioned here.
Adobe AIR 2.7
When Adobe released their latest AIR SDK, with the ability to package AS3/Flex applications for iOSes and Androids, we were very excited to try it out. Adobe’s solution allows developers to use their existing Flash/AS3/Flex skills to create mobile applications. For iOS, the final app actually contains the AIR runtime as well as the actual app, so expect to see a 4 MB app for the simplest AS implementation, and a 7 MB app for a bare-bones Flex application. This isn’t the case for Androids, since the AIR runtime is available from download from Android Market and is required in order for your application to run. This means that the size of the actual application will be very small, but your users will need to download and install a 17MB AIR installer.
Let’s take a closer look at some of our observations:
- The development experience feels more comfortable than the one of Titanium. Stable IDE, faster debugging and well documented API.
- Android and iOS implementations are consistent in look and functionality.
- AIR allows you to access hardware features like camera, microphone etc on both platforms, using the same API.
- The AIR runtime actually poses a lot of overhead on the device. Expect acceptable performance on normal UI components like scrolling lists, but if you want to try more fancy stuff like Augmented Reality, you can forget it. Out of curiosity we tried a very simple Augmented Reality application with FLARToolkit and no 3D engine running, and got a whopping 1 frame/sec, but we ‘ll get back to this on a next post.
- Packaging a Flex application for iOSes can take forever, expect anything between 5-30 mins, but you don’t have to go through it unless your app is ready for deployment, since all debugging can be done using Desktop simulators that launch very fast.
Overall our experience with AIR 2.7 was pleasant although we did have some stability issues trying to iOS-package some fancy Flex components like graph charts. The performance for common form and UI components is decent and more importantly Flash Builder 4.5, which was our AIR IDE of choice for this test, is actually the first platform that allows iOS app development on Windows Operating Systems, without using virtual machines or other trickery. (Let us know in the comments if that’s not the case!)
Conclusion
Although Write once-Deploy anywhere seems to be the Holy Grail for mobile app developers, we sure ain’t there yet, but we’re getting close.
In the end, it all boils down to the actual project requirements. If you need performance, you can forget about everything and go Native. If a plain UI application is what you’re after, it seems the latest AIR SDK can be of help. If the Titanium API can cover your requirements, and you’re willing to sacrifice extending it in any way, then Appcelerator sure is the fastest way there.
What is your preferred strategy regarding multi-platform mobile Apps? Let us know in the comments.
COMMENTS