Back

Navigating Mobile Development Alternatives

Mar 05
Posted by Andy Wager in html5, mobile, strategy, #technology

Development and technology choices abound in the mobile space. Making the right decision requires tradeoffs and intimate knowledge of the alternatives, fit with strategy and experience.

In a previous post we talked a little about how mobile is increasingly changing business models, customer touch points and opening new doors to strategic opportunities. Mobile devices excel in portability and provide a much more connected and personalized experience to the user. Mobile applications can provide your users with instant access to information, or instant information sharing, anytime, from anywhere that they have a network signal.

One of the most significant challenges in executing mobile strategies is technology selection and development approach. Technical issues of device runtimes, operating system fragmentation, native apps vs. cross-compiled applications vs. HTML5 web applications, device capabilities and inconsistencies are just a few challenges.  Factor in user experience impacts from technology selection such as touch vs keypad entry, pixel vs point size and device screen resolutions and we're just scratching the surface of technology considerations.

The age-old idiom "There's more than one way to skin a cat" didn't have its origin in mobile development technology but it certainly fits.
The growth of mobile devices has also led to a tremendous growth in alternatives to development languages, compilers, and choices. Mobile applications can be written in one of several generalized manners with their own unique pros and cons. If not approached correctly, these alternatives can make mobile initiatives complicated and expensive.  Below are several alternatives to technology selection and development approaches. Keep in mind that technology choices should not be made in isolation and must support delivering on strategic objectives.

Native Applications: Applications written in the preferred language of the device and are compiled to native executables.
An example of this would be an iOS application written in Objective C or an Android application written in Java.

Devapproach_001

Cross-compiled applications:  These are applications that are written in a single language that are then compiled to a format that is executable on a device.  Runtimes of this nature include Adobe AIR, Appcelerator Titanium, Phone Gap, and Ansca Corona, among others. Some of these technologies compile to a format that runs inside of a virtual machine which runs on top of the native operating system. Others have an intermediary cross compilation step where the original language is used to generate operating system specific code, which then gets compiled into native executables.  

Devapproach_002

The Web and HTML5:   HTML and javascript are accessible to nearly every platform and maintain a certain level of ubiquity across platforms. If your application doesn't require operating system interaction and you need to target the widest audience possible, this could be a potential solution.

Devapproach_003

The pros and cons of each listed above are by no means exhaustive of items to weigh in determining technology selection but are presented to show that there is no perfect solution for all situations. As some of these technologies and methodologies mature, there may be cases when multiple technologies can creatively be utilized without reliance on a single approach. More and more we're finding new ways to make different technologies and approaches work together, improving efficiency and cost of delivering a mobile application. The space continues to evolve and experimentation and experience across all platforms is as important as ever in the mobile space.

Without a doubt, the complexities and permutations of options can become costly at a very rapid pace. If you don't have a clear strategy, attempting to streamline the approach or iterate to develop a quality solution with a lower cost point will be difficult. Its really not a great a answer to the question of which approach to use, but "it depends" is truly the case.  

Posted by:
Andy Trice, Principal Architect
Andy Wager, Director of Solution Strategy

 

2 Comments
  1. John Stapleton 03.23.11 at 9:30 PM

    Hi Andy,
    Great article so thank you. A few items might already need some updating.
    Seems Adobe Air 2.6 has iOS native speed and it will be launching quartely updates. Does that take away a few cons from the Cross-compiled applications pro/cons list?

  2. Andrew Trice 03.25.11 at 9:34 AM

    Hi John,  It’s too early to tell.  The current public build of the Flex SDK still doesn’t perform well on iOS devices, even using the AIR 2.6 runtime.  Although I’ve seen actionscript-only projects run very well on it.  Adobe is also starting to float videos showing Flex on iOS running very well (see here:http://coenraets.org/blog/2011/03/flex-on-the-ipad/ ).  However, that toolset must still be internal and not available to the general public.  Once this is publicly available and can be proven, then this list may need to be revised, however that would apply only for the Adobe toolsets, not for all cross-compilation or 3rd party tools.  Time will tell, and I would certainly be happy to see the Adobe tools become a more viable solution for iOS.  With that in mind, I also hope it follows the same SDK for iOS, Android, and BlackBerry so that we don’t end up having to maintain multiple source trees; otherwise, you still end up with maintenance headaches.

Add a comment