Native, Web, or hybrid: How to choose your mobile development path

With new tools and frameworks and the right development kit, you can make sure your mobile apps reach multiple platforms.

Make no mistake: The enterprise is getting serious about developing and delivering mobile business apps. But whether the goal is to spread news, sell products, collaborate with business partners, or push mobile apps as products in themselves, the constant emergence and evolution of mobile platforms have many IT organizations wondering how best to execute the vision -- and what tools and methodologies they should implement to deliver their apps to the right audience at the right time, regardless of device.

Some of these emerging business apps have short lifetimes by design, such as event guidebooks, while others will persist for years. Some, like augmented reality viewers, need constant real-time information and access to low-level handset capabilities such as geolocation, camera, and motion sensors. Others require little more than a mobile screen and the user's finger. But there is one commonality: Every business wants IT to develop apps as quickly and cheaply as possible, and many want the apps IT creates to run on multiple device types -- Android, iOS, and Windows at least.

[ Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]

Not surprisingly, such diverse requirements have spawned a huge array of development tools. Navigating the sea of options can be tricky, as no one tool offers the trifecta of fast, cheap, feature-rich app delivery. If your organization isn't careful, you could find yourself boxed in to a development choice that doesn't grow with user needs, as Facebook discovered when it realized HTML5 wasn't the best approach for its iOS app.

Carefully assessing your prospective app's current and future requirements is key, as is balancing those requirements with the time it takes to get your app to market. Don't feel you have to choose a single platform for every app. It's reasonable to employ multiple development platforms to meet a variety of delivery requirements. The following is a primer on how to make the right choices for your mobile development needs.

Mobile app development's three golden paths

Mobile app development approaches have stratified into three variations: native, Web, and hybrid. Understanding the pros and cons of each approach is the first step in choosing a platform wisely. You're then ready to decide how complex to make your app and choose a set of target devices. If you want users to start touching your app sooner rather than later, you may have to trim back features and exploit application frameworks that simplify the delivery of features you need.

A cross-platform app doesn't have to involve tripling your project cost, but if you don't need that capability, you can save time and money by limiting your development to a single mobile OS. If you decide to target multiple device types, carefully weigh the costs, in development labor and delivery speed, of supporting more than one mobile OS.

Pure native apps deliver the best device fidelity and user experience, but require significant time and skill to produce. Pure Web apps -- including those using WebKit shells to masquerade as native apps -- are quick to deploy but have significant limitations. The latest approach, hybrid app development, combines prebuilt native containers with on-the-fly Web coding to try to achieve the best of both worlds. But this path requires you to buy into one vendor's vision of the app creation process.

Once you've chosen a development path, you're ready to go shopping for a mobile development kit. If you're new to mobile app development, expect to test-drive a number of products before committing time and treasure to one. Your first app must make a good impression, but it also needs to be delivered on time; it's a good idea to scale back expectations to make sure you don't inadvertently end up with mobile vaporware.

Mobile app-dev golden path No. 1: Native app development

Native app development for a single mobile OS is the traditional approach, but it's also the most time-consuming. Each mobile platform vendor offers completely different programming environments, and each has a unique UI style. Apple's Xcode IDE employs the proprietary Objective-C language for iOS devices, while Google's Android coders generally use the open source Eclipse IDE combined with Android's native Android Development Tools (ADT) Java programming plug-in. Microsoft offers Visual Studio Express for Windows Mobile and its Windows Phone SDK, aimed at WP7 devices, in which programmers code in the also-proprietary C#/.Net idiom.

The vendor-tool native approach guarantees access to every nook and cranny of a device, but it also requires computer-science-grade software engineers. In addition to being the most time-consuming, it is the most expensive methodology. Although device vendor tools are available free of charge (vendors having a vested interest in evangelizing their mobile OSes), building one requires real programming skills. Coding difficulty ramps up rapidly as app complexity increases. An experienced C programmer can build a simple app in mere hours, but more complex apps easily rack up hundreds of developer hours -- and tens of thousands of dollars in labor costs.

But for apps that will have a long lifetime or require best-of-breed performance, native development is the way to go. If your app needs to get online quickly, though, you may not be able to achieve a delivery deadline without hiring pricey consultants or investing in expensive in-depth staff training, such as that offered by Big Nerd Ranch.

Mobile app-dev golden path No. 2: Web-based development

The second, and quite popular, path is Web-based development. The app isn't really an app at all, but a customized website tailored to have the look and feel of an app. This is by far the simplest approach, and the app logic can readily tailor itself on the fly to different OS platforms. In iOS devices, you can even create an app icon using the Add to Home Screen feature in Safari, giving users more of the illusion of a native app.

Web-based apps rely on JavaScript for client-side programmability. JavaScript has full-fledged procedural and object-oriented language features; unlike client-side Java Applets, it's supported by virtually all mobile browsers. You can greatly simplify mobile Web app coding by employing an open source JavaScript framework, most of which provide precoded user interface elements and an MVC application model. Examples of open JavaScript frameworks include Ext JS, (now Sencha) JQuery Mobile, and The-M-Project. Using a JavaScript framework is as simple as including the framework's .js file in your JavaScript application and referencing framework functions in your own JavaScript code. Because of this, there is no need to change your IDE, and the learning curve is minimal.

Web-based apps can look and feel very close to native apps, if you discount performance. But because users access the app through their onboard Web browser, a network connection is required for most functions, and users will feel network delays. HTML5 includes the ability to access local storage, but the memory capacity on most mobile devices is usually a few hundred megabytes, which limits what you can do in a Web app sans Internet.

In contrast to native development's need for big-brained programmers, the only skill required for Web apps are those of the average Web developer: HTML5, CSS, and JavaScript, and possibly a server-side language such as Java, PHP, or Ruby. Because the entire app lives on the Web, you can update it at will without having to redistribute the app itself.

Xpous' $9.99 iGenApps offers a code-free approach to building Web apps for both Android and iOS. Aimed at small businesses with simpler app complexity requirements and a limited budget, iGenApps enables businesses to construct Web-based apps right on a mobile device. The app, hosted on Xpous' servers, is distributed via an HTML link in email. Recipients simply click to add the link as a home page icon.

The most powerful refinement to Web app development uses a WebKit browser shell that displays the app's user interface full screen with no navigation or status bars. The WebKit shell is, in fact, a native application, so it typically has access to low-level device features, such as geolocation. Even a minimal WebKit shell, when combined with a Web programming language such as PHP or Ruby on the server side, and HTML5, CSS, and JavaScript on the client, can deliver an impressive simulation of a springy native app with all the usual knobs and dials. But this is just a simulation, which works for basic apps but not those requiring complex graphics or processor-intensive computation.

Adobe's free PhoneGap exemplifies the WebKit strategy, letting you code your app once on the server side, then deliver to multiple mobile OS targets quickly and easily. PhoneGap augments the basic shell with plug-ins that emulate various native interface widgets, giving users even more of a native user experience.

Mobile app-dev golden path No. 3: Hybrid app development

WebKit paved the way for the third approach to mobile apps: hybrid development. The hybrid model replaces the simple WebKit shell with a more sophisticated, natively coded container, which runs as a native app unique to each target OS. The container vendor maintains the container code, thus incurring the high costs of native code development. That cost, however, is spread among the many customers of a particular hybrid platform, who implement their apps as JavaScript code that is either bundled with the container at installation time or can be downloaded later.

Rather than delivering an identical Web-ish interface on all device types, as pure Web apps do, hybrid apps can provide a different user experience for each mobile OS: Android idioms on a Kindle Fire, iOS behavior on an iPad, Metro accoutrements for a Windows phone.

Appcelerator's Titanium is one of the earliest, and still popular, platforms of the third kind. The latest product kit includes a cross-platform SDK with thousands of device-specific APIs, the Eclipse-based Titanium Studio IDE with built-in device simulators, and the option to host apps on Appcelerator's cloud servers. The SDK and IDE are free, while hosting and various levels of support are fee-based services.

Taking hybrid development even further is Sencha's Complete Team array of mobile development tools, which includes the Sencha Touch 2 JavaScript framework and Sencha Architect, a drag-and-drop GUI builder. Sencha.io is a beta edition of cloud-based data, messaging, and deployment services that let a business deploy an app without any of its own public-facing infrastructure.

For cloud-based mobile app development with no coding required, you might consider MobileFrame, which provides pre-built app templates you customize via a Web-based GUI designer, then deploy as either native or hybrid apps. Intended for enterprise-class app deployment, MobileFrame includes version and source control, database connectors, and an integrated test environment with device simulators. The platform features built-in MDM (mobile device management) capabilities, making it an attractive adjunct to BYOD.

Purpose-specific platforms

In addition to vendor-provided native IDEs and cross-platform hybrid toolkits, a number of mobile development products target specific environments, such as a specific mobile OS or server-side hosting environment.

A good example is Google's J2ObjC Java-to-Objective C translator, which aims to let server-side Java developers move their non-UI code to Objective C that executes natively on an Apple device. Native Java is still prohibited by Apple in iOS, creating a significant barrier to Java-skilled app coders. Although Java developers must still learn Objective C for iOS graphical app components, legacy Java business logic can be preserved, saving the time and expense of maintaining two code trees.

CodeName One is a similar tool, but rather than translating Java to Objective C, it lets developers code almost entirely in Java, including UI code. The product's "lightweight architecture" provides seamless UI development across multiple platforms. Developers have the option to replace Java-coded widgets with native Objective C "heavyweight" versions when necessary for performance or to access low-level device features. And a GUI builder gives developers a full-featured drag-and-drop UI canvas.

Salesforce Touch is a mobile development platform that provides enterprise developers the same app engine Salesforce uses for its own enterprise mobile apps. Touch can generate native Objective C or Java, pure Web, and containerized hybrid apps. The platform interfaces with Force.com, which delivers network services via REST APIs to access Salesforce-resident business data, provide social networking, and implement geolocation functions such as real-time maps. Touch's Identity feature provides a single sign-on service to authenticate mobile devices to enterprise servers.

CoralTree Systems' Renaissance is an example of a development platform aimed at a specific enterprise IT environment, the IBM i. An open source product, Renaissance provides specific hooks for IBM security APIs and the RPG programming language. Server-specific mobile platforms such as Renaissance let enterprises add mobile support to legacy applications, saving the cost of re-creating complex business logic in a more modern language such as PHP or Ruby.

Choose wisely

The selection of mobile development tools has never been richer, or more affordable, than today. You can go native but pay big bucks for a slick app that eventually ships, or use a streamlined Web- or hybrid-development approach. Take the time to enumerate your application requirements and match them to an appropriate toolkit. You don't want to end up like Facebook, changing horses midstream.

This story, "Native, Web, or hybrid: How to choose your mobile development path" was originally published by InfoWorld.

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies