Going Native on your Apps?
A recent Time article: The Mobile Web: Dead or On Hiatus? sparked a discussion with one of our clients regarding native app vs. HTML5 web app strategy. In a nutshell, native apps are built and optimized to run on specific devices, using specific programming languages. For instance, Objective-C for iOS, Java for Android and .NET for Windows devices. While web apps are built and optimized to run in web browsers, using HTML5, CSS and JavaScript. With the boom of mobile app stores and mobile use in general, many are jumping on the app publishing bandwagon. Tools like PhoneGap and Sencha Touch make it almost too easy to take existing web content and create native apps for almost any of the major mobile platforms. The problem is that simply wrapping a web site into the form of a native mobile app really doesn’t provide much added value to end-users. It could even add a lot of extra maintenance and support issues on the content producer / developer end. So what to do?
The article’s author sees “a world where both native apps and web apps will coexist. Developers leading this charge will be the ones who are making native apps and HTML5 web apps at the same time during the software development process.” The statement is straightforward enough, but what’s not so straightforward is how you accomplish this type of parallel development effectively. For native app development, should you target iOS first? iOS and Android? What about Windows Phone 7/8? You might even have a need to support Blackberry, WebOS, Symbian or even Bada. Luckily, you have the option of using something like PhoneGap to consolidate the various development environments into one, leveraging a common HTML5, Javascript and CSS architecture for all your native app outputs.
Aside from platform, the next thing you have to consider regardless of whether your app will be native or web based is the display. Will you limit the app for display on smaller smartphone screens, take advantage of the larger screens on tablets, or cover both by incorporating Responsive Web Design so that your content flows fluidly to fit any display? There’s a lot to consider. But let’s circle back to the original question of native or web app.
Consider content-based sites like: Huffington Post, CNN, Bloomberg, NBC, etc., you’ll find that their web apps (sites) compared to their native app offerings are distinctly different in form even though they draw from a similar content source. For instance, CNN’s app extends from the core stories on their web site into native app-land by adding special features like “My CNN”, their location based news filter, and “iReport” which allows app users to be ad-hoc CNN reporters, sending in their own audio and video news reports.
Their native app really goes above and beyond what’s available on the web site and provides a different experience for mobile users. In contrast, Huffington Post simply repurposes content readily available on their web site into their native app. The only difference is the user experience since the presentation of the content is optimized for touch interfaces. Beyond that, there’s nothing more on their app that a user couldn’t already get from the web site. Some people prefer reading their news on the go while others opt for the desktop experience. So they simply provide an option for a desktop or mobile experience of their content.
There’s also the question of whether future software will be “installed or accessed”. As a content publisher, do you want users to be required to download and install a native app before they can start accessing your content or should they simply be able to access that content more immediately through their mobile web browsers? It all depends on what experience you want to provide to your end-users. It also depends on what resources you have available. If your budget allows for it, and you have a development team that can seamlessly manage the app development process in both native and web forms, the decision is much easier.
But if you have to choose one or the other, keep the following in mind. Web apps that are built well, using standards-based programming and responsive design techniques, can give you the most bang for your buck, allowing wide audience reach while keeping development and maintenance costs more reasonable. Web app development is also closer to the promise of CODE (Create Once Distribute Everywhere), a great philosophy, although the “everywhere” part is difficult to truly achieve. We’re on the never-ending quest to reach that holy grail at Battle — the old but still existing challenge of cross-browser compatibility and the new challenge of device platform compatibility keep our developers on their toes.
On the other hand, a native app becomes a better choice when your needs require providing something beyond the normal web experience. Does your app need to implement features involving location (GPS), camera capture, or other device-specific hardware? Is your app designed to be used on the go or when no Internet connection is available? In these situations, a native app becomes the best option.
There is a convergence happening that’s beginning to blur the lines a bit between the two. But the reality is that the choice between building a web app vs. a native app will probably remain. Web apps will never be as powerful and full featured as native apps. Native apps will never be as close to ubiquity as web apps. So coexistence is unavoidable.
The point of all this then, is that you have to think about what you are trying to accomplish with your app in order to know how to best deliver it. It still boils down to the basics of creating the best user experience possible with either approach. If you have the option of choosing both, then definitely, more power to you.
