As we near the completion of development on version 1.0 of one of our new apps, the Mobile Learning Primer, we wanted to share some of what we’ve been encountering. While planning for the app, we placed a high importance on the app being available on both iOS and Android from day one. Unfortunately, the timeline didn’t allow for development in both Objective-C and Java. We ultimately decided to build the application using Appcelerator’s Titanium SDK and wanted to share our experiences with you as well as some thoughts to consider when determining whether to pursue a cross-platform development framework. A Brief Introduction to Titanium Titanium features a JavaScript-based SDK that allows for the development of a native application on both iOS and Android devices (with BlackBerry coming soon?). Titanium has gained a lot of visibility lately with the success of 6Wunderkinder’s Wunderlist application. Wunderlist is a simple task list app that syncs with “the cloud” so your tasks are available wherever you are. They have desktop apps for both Mac and Windows, mobile apps for iOS and Android, and a web application. As far as I know, Wunderlist is the only app built using a cross-platform framework that has been featured in the Apple App store. It has proved that cross-platform done right is a very viable option. What 6Wunderkinder had originally planned as serving as a prototype, ended up becoming the backbone for their entire suite of applications. Going Cross-Platform The decision to develop using a cross-platform framework is not a light one. In fact, it should be absolutely central to the planning phase of the app. There are a lot of benefits to developing with a cross-platform framework. Even if you’re only targeting one platform, it’s often faster to develop using a framework. Moreover, when it comes to targeting multiple platforms, there is a high percentage of reusable code. But the convenience comes at a cost…and ironically, sometimes the cost is convenience (what happens when the framework you’re using doesn’t support feature X?). There are a number of cross-platform frameworks out there, each with their own specialty: RhoMobile, Titanium, PhoneGap, Corona, etc. We ultimately decided to proceed with Titanium because of it’s core support for a native experience while still maintaining a high percentage of reusable code. 6Wunderkinder estimated that between the different platforms they support, about 90% of the code has been reusable. In the Mobile Learning Primer, nearly 100% of the code has been reusable between iOS and Android. What We Love About Titanium Development progressed quickly. It took only a matter of hours to set up the basic infrastructure of the app. In about 100 lines of code, the five different tabs were set up with tableviews and ready for data. The Titanium API is well-documented and their KitchenSink example app is a fantastic way of answering the “How do I…?” question without needing to search their website for an answer. Furthermore, Titanium “translates” the code you write to the SDK designed for that device. This provides for a truly native experience on each platform. One of the most overlooked obstacles when developing for multiple platforms is the user interface. An Android device does not navigate or operate like an iOS device (and neither work like a BlackBerry device or a Windows 7 device). In iOS, you have the navigation bar with a back button where as Android devices have the hardware back button. A navigation bar on an Android device will not make sense to the average Android user. A “native” app should not just be one that uses the phone’s native language, but also one that achieves the same user experience. What We Don’t Like About Titanium Bugs. Bugs and inconsistencies tend to plague cross-platform frameworks like Titanium since it requires the framework to keep a consistent SDK that works with multiple SDKs that are evolving in different directions. But, for being a 1.6.1 release, the fact that documented features of their SDK don’t work consistently (or at all) is frustrating (looking at you, Ti.UI.Label.size.height). What’s more, we’re limited to what their framework supports. This is a problem when using any cross-platform toolkit. Instead of asking “How do I implement this feature?” you’re forced to ask “Can I implement this feature?” A subtle difference, yet by choosing to develop cross-platform, you’ll be forced to work within the bounds of the tool instead of the limits of the device. When Wunderlist was first released for iPhone in December 2010, it didn’t support the high resolution of the iPhone 4′s retina display even though the iPhone 4 had been out for months. It was not an oversight by the development team at 6Wunderkinder, but a limitation of Titanium at the time. Currently, Android 3.0 devices are also not dependably supportable using Titanium. This speaks to the argument Steve Jobs has given time and time again about using native code and SDKs vs. emulation and translation via cross-platform toolkits. Simply put, these toolkits can limit your flexibility as the platforms evolve. The Exit Strategy Here’s an important tip to developing with a cross-platform toolkit: leave yourself a way out. What happens when your app outgrows the cross-platform framework or the framework stops being developed? Will you be left with a pile of totally useless code? Sure the backbone of Titanium is JavaScript, but that code would be almost totally worthless without the Titanium SDK. The Mobile Learning Primer relies pretty heavily on SQLite and webviews (we made the assumption that HTML, CSS, and JavaScript weren’t going anywhere for a while). The benefit here is that while being fully compatible with Titanium’s framework, we also have the option of dropping the framework and transitioning towards a more native solution if we ever need to without worrying about starting from scratch. The short of it is, by using a cross-platform toolkit to develop your mobile application, you’re either strategically positioning your app for success across multiple platforms, or strategically shooting yourself in the foot. As you may [...]![]()
