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 built the application using Appcelerator’s Titanium SDK and wanted to share our experiences with you and some thoughts to consider when determining whether to pursue a cross-platform development framework.
A Brief Introduction to Titanium
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.
The decision to develop using a cross-platform framework is not a light one. In fact, it should be 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. 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 several cross-platform frameworks out there, each with their own specialty: RhoMobile, Titanium, PhoneGap, Corona, etc. We ultimately proceeded 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 with no need to search their website for an answer.
Titanium “translates” the code you write to the SDK designed for that device. This provides for a 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 whereas 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 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, 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. These toolkits can limit your flexibility as the platforms evolve.
The Exit Strategy
The short of it is, by using a cross-platform toolkit to develop your mobile application, you’re strategically positioning your app for success across multiple platforms, or strategically shooting yourself in the foot. As you may look at implementing a cross-platform framework for your mobile app, we’d love to join you during the strategy process and help determine how to best use a cross-platform framework. We’d also love to hear how you’ve successfully implemented a cross-platform framework in your app or what headaches you’ve experienced because of going the cross-platform route. Has this cross-platform approach helped you from a strategic standpoint? Has it freed you, or put you in a framework you are trying to escape from?
Latest posts by Daniel Pfeiffer (see all)
- A More Mobile-Friendly Captivate HTML Template - October 21, 2013
- 3 Tools To Help You Optimize Your PhoneGap App’s Performance - October 15, 2013
- Tin Can iOS Library Compatible With Version 1.0 - May 2, 2013