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.
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.
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.
A: There are two big reasons:
- Business requirements
There 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 access
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.
Tools for cross-platform mobile development
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 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.
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 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.
Native tools for cross-platform development
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.
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!