No matter how you measure it, mobile computing is growing astronomically. Daily usage, smartphone penetration, cellular subscriptions, search traffic, ad impressions, app sales: everything is up. It seems inevitable that mobile devices will overtake traditional desktop and laptop computers as our primary computing platform, perhaps in the relatively near future.
This massive growth presents software developers with amazing opportunities, but also significant challenges. The explosion of mobile platforms and devices has created an unprecedented level of fragmentation, and it's going to get worse before it gets better. Development, testing and distribution of an app for multiple platform/device combinations can be prohibitively expensive.
In this article, I'm going to share my process for determining the best development approach for an app and discuss some of the more popular tools that have emerged to address the fragmentation problem.
Spoiler alert: I'm not going to crown a winner at the end. The correct approach for your project will depend on your development resources, business model, target market and a half dozen other factors. My goal here is to provide information that will help you make an informed decision. For the sake of discussion, I'm going to assume that you are interested in developing apps for iOS, Android, and at least one more platform (eg Window Phone 7, BlackBerry, mobile web, etc...).
Web vs native
Web vs Native is a hot button topic, so please hear me out before branding me a heretic.
I believe that if you can build your app as a web app, then you probably should. Conversely, if you can't, you shouldn't. In most cases, you'll end up somewhere in the middle with a mix of web assets (eg HTML, CSS, JavaScript, images, audio, video, etc) and native code. Determining the right balance for a given project depends on the specific requirements involved. I'll walk you through the process I use to help make this determination: it might not be a perfect fit for your organisation, but it should at least get you started. Please feel free to customise as needed.
All of the development project work we get at Mobiquity comes from enterprise clients. Large companies, by definition, have to reach enormous groups of people with their products and services, so we never have the luxury of ruling out large chunks of the market based on their choice of mobile platform. In other words, every project is a cross-platform project.
When evaluating a new enterprise-class mobile project, I start with web as my default approach, and then ask three questions in an attempt to rule it out.
- Does this app need access to device hardware that the mobile web browser can't access?For example, a barcode reader app needs access to the camera, and therefore can't run in a browser. Ditto for an app that needs to record audio, run in the background, receive push notifications, etc. When an app does need a feature that isn't available to a web app running in a mobile browser, I try to determine what percentage of the app is based on this feature. In other words, is the camera feature the basis of the whole app, or is it just a nice to have?
- Who is the audience for this app?There is a big difference between distributing an app to the general public vs your employees or affiliates. If the app is going out to the general public, the only really viable distribution options are the app store specific to the platform, or as a web app. If the app is internal for employees only, the options are ad hoc, third-party app stores (eg Apperian), sideloading or as a web app.
- How memory intensive will the app be?Things like extensive animation with layers and opacity, very large data sets, file encryption or decryption, and complex map-based interactions can all contribute to a clunky user experience in a mobile web browser.
With the answers to these three questions, I can make a pretty strong determination between web or native. For example, if I'm given a request to design a B2E app that allows employees to manage their personal profile and benefits information and doesn't need to use any of advanced hardware features on the device, a web app is the obvious choice. If on the other hand, I'm asked to build an immersive mapping application with augmented reality layers that requires access to the gyroscope and will be sold to the general public, a native app is the obvious choice.
In cases where I determine that native is the appropriate path, I have a second series of questions I ask to decide if the app should be pure native or a native web hybrid.
Splitting the difference: native vs hybrid
These days, it's quite common for a native app to contain at least one or more WebViews. Normally, a WebView is used inside of an app to display HTML without having to bounce the user out to the web browser on the phone. Examples of mobile apps that use WebViews are the official Twitter and Facebook apps, the native App Store and iTunes apps on iPhone, the Bank of America mobile app, and hundreds (thousands?) of others.
A hybrid app takes the WebView from a supporting role and moves it centre stage. The native code portion of the app essentially becomes a dumb wrapper for the guts of the app, which are built with HTML, CSS, and JavaScript. Static file assets are bundled in the executable, and network data and dynamic assets are retrieved using standard Ajax calls.
Technically, hybrid apps are native but they are built so differently from typical native apps that it makes sense to draw a distinction between the two approaches. This often raises a couple questions:
Q: If I'm going to build a native app anyway, why would I use HTML in a WebView instead of the standard approach (ie using the native framework)?
A: The main reason to use a hybrid app is that it addresses the fragmentation problem. Remember, we're talking about building cross-platform apps. Since the WebView components of all the major smartphone vendors have more in common than not, you can build an app with HTML and have it run on lots of different devices. If you use the native framework, you're going to have to rebuild the app from scratch for each platform.
Q: If I'm going to build my app with HTML, CSS, and JavaScript, why wouldn't I just ignore the app stores and host it on my web server?
A: There are two big reasons:
- Business requirementsThere are lots of business cases that might require you to distribute your app through a platform app store. For example, you might want to charge for downloads. Or you might know that your target audience will only discover your app in the app store. Or, maybe you're building the app for a client who demands app store distribution.
- Hardware accessEven though hybrid apps are primarily made up of HTML, CSS, and JavaScript, they are technically native apps and are installed on the device. Installed apps are not restricted the way that web apps running in a mobile browser are. Therefore, hybrid apps can access the advanced hardware features of the device using JavaScript. For example, JavaScript code running in a hybrid app can control the camera on a device. This same JavaScript code would fail if the web app was running in a browser.
I'm pretty confident that most people who travel through this decision tree will end up picking a hybrid approach. In those cases, you'll need to pick from a wide range of tools available for building mobile apps using web technology. Following is a list of popular options broken into categories. I'll briefly summarise each and offer some insight about when I would consider using one over the other.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
Tools for cross-platform mobile development
The following group of products are JavaScript libraries that take some of the pain out of tough or tedious JavaScript coding tasks when building mobile web apps or hybrid HTML/native apps.
jQuery
jQuery is a hugely popular (and deservedly so, IMHO) JavaScript library that presents a unified API for common JavaScript web dev tasks like DOM traversal and manipulation, Ajax, and event binding. It uses a selector syntax based directly on CSS, so web designers typically find it very easy to start using jQuery.
jQuery is rigorously tested across all A, B, and C grade browsers (desktop and mobile), has a vibrant developer community and excellent docs, and is completely free open source software. The only potential downside of using jQuery for mobile development is that it's significantly bigger than it needs to be because it contains a fair amount of code targeted at fixing weaker desktop browser.
If I'm working on a website that is designed to be viewed in a desktop browser, you can be sure I'll include jQuery, even if that means potentially sending jQuery over the wire to mobile browsers. There's just too much value in the xplat testing that the jQuery team does to rule out the library based on a largish file size. That said, if I'm working on a site or app that won't be available to desktop browsers, I don't use jQuery.
Zepto
Zepto is meant to be a lightweight drop in replacement for jQuery specifically for mobile devices. Because Zepto makes no claims of support for older desktop browsers (think IE6) it can do pretty much everything you'd want to do with jQuery, but with a much smaller footprint. If you're familiar with jQuery and are working on a site or app that’s only going to be available on mobile devices, you should take a look at Zepto.
XUI
XUI is a very lightweight JavaScript library built specifically for mobile browsers. The emphasis is on simplifying just the most commonly used programming operations using the least amount of code possible. In other words, it's just the basics. The syntax is simple but it is different than jQuery so it can take a little getting used to.
Lawnchair
Lawnchair is a very lightweight JavaScript library that abstracts client side persistent "NoSQL style" data storage. It uses the adaptor pattern and supports multiple fallback approaches. The syntax is straightforward and simple queries are supported. When I want to add client-side persistence in a mobile app, perhaps for performance reasons or to support offline features in a mobile web app or site, I'll reach for Lawnchair.
Miscellaneous
New mobile JavaScript frameworks are cropping up constantly. Honourable mentions in this category include now.js, backbone.js, and underscore.js. For a constantly updates listing of JavaScript tools that are useful in mobile development, check in regularly with microjs.com ("Fantastic Micro-Frameworks and Micro-Libraries for Fun and Profit!").
JavaScript UI frameworks for mobile
jQuery Mobile
jQuery Mobile is like jQuery UI for mobile. It's a widget library that converts semantic markup into a familiar, finger friendly format. It's built on top of jQuery and as such has best-in-class support across A, B, and C grade mobile browsers. It's a fairly young but very ambitious project that aims to create the best possible mobile web experience on the largest number of browser. That being the case, the total file size is a bit on the large size but it's a great choice if you're creating a mobile version of a public website.
jQTouch
jQTouch is very similar to jQuery Mobile in that it's a widget library that converts semantic markup into a mobile-friendly format. The difference between jQTouch and jQuery Mobile is that jQTouch is specifically targeted at class A WebKit browsers on small screen devices. This means that jQTouch can use WebKit specific features to deliver a higher level of polish with a less code than jQuery Mobile. So I tend to use jQTouch when I know my users are going to have a WebKit mobile browser. Furthermore, Zepto support is supposedly coming soon, which means that jQuery will become optional. This will significantly lower the overall file size and runtime processing overhead.
Sencha Touch
Sencha Touch is a full featured widget library based on the Ext JS JavaScript library. Like jQTouch, Sencha Touch specifically targets class A WebKit browsers, but apps built with Sencha Touch can automagically reconfigure themselves to take advantage of the larger real estate of a tablet device. Also unlike jQTouch, Sensa Touch is not markup-based. Rather, developers write JavaScript code in a client-side MVC style. This is extremely powerful, but comes with a fairly steep learning curve, and it's a pretty hefty download. Sencha Touch is a good fit for medium-to-complex web apps that will be deployed to smartphone and tablet devices running WebKit browsers.
SproutCore
SproutCore is an open source JavaScript framework that was originally created to help web developers create advanced web applications for desktop browsers. In fact, it was so powerful and polished that Apple used SproutCore to build the original version of MobileMe. Because of its desktop browser origins, I've always found SproutCore to be too large to be practical for mobile development. That said, I know that their team is doing a lot of work in this area and I'm sure they've made progress since I last played with it.
Native tools for cross-platform development
PhoneGap
PhoneGap is a cross-platform mobile development solution that allows you to write a mobile app with standard HTML, CSS, and JavaScript and then wrap it in a native app shell. Currently 10 mobile platforms are supported. If you need to access any network resources, you'd retrieve them as you normally would in any modern web app (ie Ajax). Furthermore, PhoneGap exposes a bridge that allows your JavaScript code to access native device features that would normally be off limits to a mobile browser (eg camera, contacts, speakers, mic, etc...).
PhoneGap is not a widget library, it doesn't compile your HTML down to native code, and it doesn't submit your apps for you. Because your app is executing JavaScript at runtime, it can be hard to achieve as polished an interface as can be done with compiled code. I use PhoneGap for all my hybrid app projects. See above for more on how I determine whether or not hybrid is a good approach for a given project.
Titanium Mobile
Titanium Mobile is a cross-platform mobile development framework that enables you to write JavaScript which is then compiled down to native code for the iOS and Android platforms. Titanium is marketed to web developers and is often compared to PhoneGap although the two are actually quite different. With Titanium, you write your apps against the Titanium framework, as opposed to writing standard JavaScript that would run in a browser. From a syntax standpoint, writing a Titanium Mobile app looks a lot like writing a Sencha Touch app – ie it will immediately look familiar to advanced JavaScript developers but newer devs might experience a bit of a learning curve. If you only want to create native apps for iOS and Android, you might want to take a look at Titanium Mobile: it's a great way to avoid learning Objective-C and the Android SDK.
Corona
Corona is a proprietary SDK that uses the Lua programming language to deliver visually rich native application experiences on iOS and Android. It has full-featured physics and tweening libraries, as well as powerful rendering engine that takes full advantage of the GPU. These features make it perfect for immersive game development, but Corona is also useful for traditional mobile app development. I haven’t done any game development, so I haven't used Corona on a client project but I expect that to change soon. If you have to create an immersive pure native experience on iOS and Android, I'd recommend taking a look at Corona.
Mobile Enterprise Application Platforms (MEAPs)
A MEAP is a soup-to-nuts platform that can be used to manage the entire lifecycle of a mobile application across multiple platforms with a single backend. It's outside the scope of this article to get into a detailed comparison of MEAPs. I've only included them because RhoMobile is sometimes considered a competitor to PhoneGap, when in reality they are not the same thing at all.
Conclusion
I don't see "pure web app" and "pure native app" as an either/or proposition, but rather as opposite ends of a spectrum. The question isn't as much about which approach you're going to use for your app as it is about how much of your app will be made of HTML, CSS, and JavaScript.
Your goal should be to use as much HTML as you can without negatively impacting the user experience because the more HTML you use, the less you have to worry about fragmentation. And the less you have to worry about fragmentation, the more awesome stuff you can build. The world could use some more awesome stuff, so get out there and start building!
