November 2014
Volume 29 Number 11
Modern Apps : Mobile Web Sites vs. Native Apps vs. Hybrid Apps
Rachel Appel | November 2014
.jpg)
One question routinely surfaces in today’s modern development landscape—whether to build a mobile Web site versus a native app versus a hybrid app. As a developer, you need to take the time to think through a few considerations before running off to develop software. One such consideration is determining your target audience. To a large degree, this will determine your target platforms.
Your users will use many different devices to access your software. Some will access apps through a corporate network only, while other apps are consumer-focused. Once you’ve determined the audience and platforms, you must figure out what kind of software will serve the needs of those audiences, potentially with platform-specific features.
There are three main types of modern apps: mobile Web apps, native apps and hybrid apps. I’ll review each type, their pros and cons, and how to get started developing them. For the purposes of this article, I’m not considering traditional desktop (native) apps created with Windows Forms or Windows Presentation Foundation (WPF). They’re not considered modern, as they only run on large desktop screens and not across a multitude of devices.
Mobile Web Sites
Mobile Web sites have the broadest audience of the three primary types of applications. Any smartphone can at least display content and let the user interact with a mobile page, although some do so better than others. Along with reach, another benefit is easy deployment. Just update in one location and all users automatically have access to the latest version of the site.
If you already have a Web site and want a companion app or want to expand into the app market, you can start by making your Web site mobile-friendly. This means making a few modifications, but there’s a big payoff for a small effort, especially when compared to building a complete native set of apps. Web sites that target desktop or large monitors are hard to use on small devices. Modifying them so they’re easy to use on mobile devices will directly affect customer satisfaction.
Making mobility a first-class feature in your site also increases reach. It’s easier to use mobile Web sites. There are fewer pop-ups and distractions. Also, mobile design generally leans toward large square or rectangle buttons that are easy to tap.
You can use all your current Web development skills to build a mobilized version of your Web site. That means using HTML, JavaScript, CSS and perhaps a few of your favorite frameworks. The knowledge required to mobilize apps isn’t limited to a certain platform or vendor.
Two big things to note about going mobile are integrating a responsive design and restructuring the content so it works on small hardware. CSS media queries cover the responsive design. Media queries are a way to code CSS to define style rules that target specific device form factors. For example, your site should have media queries for several device form factors, including phones, tablets, phablets, laptops and large screens.
Fortunately, you can build media queries that work for several devices within a category. Restructuring the content entails changing the layout to something a tiny screen can display that’s easy for users to view. This changes the data volume, as well. There are default media queries that come with Twitter Bootstrap, a popular library that contains responsively designed CSS and styles to get you started.
For example, Figure 1 contains CSS that works on a large swath of devices. The code in Figure 1 doesn’t cover every scenario, but it covers most of them. You might have some modifications to make to the code to fit with your needs.
Figure 1 CSS Media Queries for Popular Form Factors
Smartphones
Portrait and Landscape
@media only screen and (min-device-width : 320px) and
(max-device-width : 480px) { ... }
Landscape
@media only screen and (min-width : 321px) { ... }
Portrait
@media only screen and (max-width : 320px) { ... }
Tablets, Surfaces, iPads
Portrait and landscape
@media only screen and (min-device-width : 768px) and
(max-device-width : 1024px) { ... }
Landscape
@media only screen and (min-device-width : 768px) and
(max-device-width : 1024px) and (orientation : landscape) { ... }
Portrait
@media only screen and (min-device-width : 768px) and
(max-device-width : 1024px) and (orientation : portrait) { ... }}
Desktops, laptops, larger screens
@media only screen and (min-width : 1224px) { ... }
Large screen
@media only screen and (min-width : 1824px) { ... }
Smartphones
@media only screen and (min-device-width : 320px) and (max-device-width : 480px) and (orientation : landscape) and (-webkit-min-device-pixel-ratio : 2) { ... }
Portrait
@media only screen and (min-device-width : 320px) and (max-device-width : 480px) and (orientation : portrait) and (-webkit-min-device-pixel-ratio : 2) { ... }
The CSS in Figure 1 not only works in mobile Web apps, but native apps, as well. That means it applies to all three types of apps covered in this article. On the Windows platform, you can use it in Windows Library for JavaScript (WinJS) projects and hybrid apps in C#. For a more in-depth look at responsive app design, see my October 2013 column, “Build a Responsive and Modern UI with CSS for WinJS Apps” (msdn.microsoft.com/magazine/dn451447).
Mobile site UIs and UXes likely won’t match that of the host OS, as the Web and native platforms tend to surface certain design patterns and techniques. Many folks try to cram a Web site that targets desktop monitors into the tiny screens of the smartphone or phablet. This rarely works well. Be sure to consider how users consume information on small devices.
One downside to mobile Web sites is that many features available to native apps simply aren’t available to mobile Web sites. Even some of the native features hybrids enjoy are out of reach for mobile Web sites. This is primarily for security reasons.
Access to the file system and local resources isn’t available in Web sites, whether or not they’re mobile. This will change when browsers widely adopt the File API. For now, Mobile IE, Opera Mini and some iOS Safari versions don’t support it. Code can’t call on the webcam, sensors or other hardware components. At some point, browsers will expose more of the hardware features, but for now it’s mostly off-limits.
To enable offline capabilities, mobile Web sites have to use Web technologies such as Web Storage, IndexedDb and AppCache. Mobile sites can’t take advantage of file system resources, but their sandbox model still allows for some client-based storage. Many existing Web sites don’t support offline capabilities, rendering them useless when they’re disconnected.
Native Apps
For most platforms you’re targeting, you should be able to retain your skills. If you’re developing on Windows, you can power your app with C#, Visual Basic, or C++, alongside XAML for the UI. You could also write in JavaScript, alongside HTML, CSS and WinJS for the UI. On Android, you can write in Java and Objective-C for the iOS.
When going the native route, you can leverage the marketing power of the app store. It doesn’t really matter which store. The fact is, they all try to help market your app with free exposure or promos you wouldn’t get otherwise. Of course, the downside of an app store is a potential user has to find and install your app. Even with the boost in marketing the store gives you, there will be users who won’t find your app.
Something that often blocks you from targeting multiple platforms is the need to recreate at least part of the UI for each targeted platform. That means you’ll need a UI for Windows Store and Windows Phone, iOS and Android. It can be quite a challenge to build a flexible UI that works well on dozens of slightly different screens. However, the result is users get that rich, native experience they expect from quality apps. In the end, the ratings in the app store reflect apps that provide an excellent UX.
When going native, you’ll have to map out a cross-platform strategy. Consider which of the platforms you’ll target and the order in which you’ll publish them. From the perspective of the mobile Web versus native versus hybrid apps question, the smoothest path is mobile Web to hybrid to native.
Even though you might publish native apps, you’ll want to keep the mobile Web site well maintained, as mobile accounts for moat traffic. Then choose a platform, perhaps one that meets your developer background, and start developing. For more guidance on the various considerations when creating cross-platform apps, see my May 2014 column, “Design a Cross-Platform Modern App Architecture” (msdn.microsoft.com/magazine/dn683800).
Visual Studio contains many project templates for creating native apps for the Windows platform. Under C#, Visual Basic and C++, you’ll find Windows Store and Windows Phone apps. Visual Studio also contains templates for JavaScript apps. You must first determine the language you’ll use, as there are many considerations here, including whether the app will be cross-platform. My September 2013 column, “Understanding Your Language Choices for Developing Modern Apps” (msdn.microsoft.com/magazine/dn385713), can help you decide which language to use. As you might expect, there’s a rich ecosystem of tools around native apps including APIs and controls targeting each platform of interest.
Most native apps within a particular platform have a similar navigation paradigm. For example, the Windows Store platform employs app bars and a strategically placed back button. Taking advantage of built-in navigation schemes lets your app give users a familiar feel and no learning curve. This results in better ratings and more downloads. My April 2014 column, “Navigation Essentials in Windows Store Apps” (msdn.microsoft.com/magazine/dn342878), contains all the facts about Windows Store app navigation.
Hybrid Apps
In that place between mobile Web sites and native apps lie the hybrid apps. Hybrid apps are a way to expose content from existing Web sites in app format. They’re a great way to take your Web content and package it up for publishing in an app store. You can publish hybrid apps in any of the major app stores: Microsoft Windows Store, Google Play, Apple App Store, Amazon Appstore and even BlackBerry World.
The great thing about a hybrid app is it can be a published app or a stopgap measure to fill the store while you’re working on creating a set of native apps. It gives you great headway into the market to publish something and get the marketing process started while you work on completing a native app set, if that’s your goal. If not, a hybrid app can serve as a way to have something formally listed in the app stores for the exposure.
Hybrid apps may enjoy a few more privileges with local resources than mobile Web sites, depending on the host OS rules. That means things such as webcam use or certain sensors might not work everywhere.
The good news if you’re considering hybrid apps is you get to use familiar Web development skills. Hybrids are essentially Web site wrappers. Their foundation is the same old HTML, JavaScript and CSS you already know.
There’s an entire third-party ecosystem around building hybrid apps for the various app stores. As you might expect, there are templates for creating hybrid apps in Visual Studio. Popular vendors such as Xamarin, Telerik, DevExpress and Infragistics all have tools and controls that speed up the hybrid app development process.
Using an iFrame in Visual Studio JavaScript apps, you can create a hybrid app completely from Web languages. You can also build a Hybrid app using the Windows Phone HTML5 project template with C# or Visual Basic .NET. Finally, take any XAML-based app and add a WebView control for the same effect. The WebView control behaves as if it were a browser. This means you control it by calling methods like Navigate, Refresh or Stop, often mapping to an equivalent user-driven action. Here’s a sample of the WebView control and some basic code that navigates to a start page for the app:
In MainPage.Xaml
<WebView x:Name="webView"/>
In MainPage.Xaml.Cs
public MainPage()
{
this.InitializeComponent();
Uri targetUri = new Uri("https://rachelappel.com");
webView.Navigate(targetUri);
}
You can tap into WebView events to perform navigation, page load or other tasks. For example, you can tap into navigation to log the popular links, as in this example:
private void webView_NavigationCompleted(Windows.UI.Xaml.Controls.WebView sender,
WebViewNavigationCompletedEventArgs args)
{
logNavigation(args.Uri.ToString());
}
This is exactly the kind of event you’d expect when controlling a Web browser. The WebView makes it much easier to combine existing content on the Web with native app capabilities.
Wrapping Up
Each way of designing and building apps comes with its own set of benefits and drawbacks. The app store concept, for example, is both a pro and a con. The upside is targeted visibility. The downside is you have to develop multiple UIs, although back-end services code is often sharable.
Regardless of whether you’re going to build a native or hybrid app, you should have a mobile version of your Web site. Mobile Web sites offer the largest immediate and instant reach of all the types of apps. You don’t get to leverage the store’s marketing efforts, which can boost sales. Hybrid apps help you enter a marketplace earlier while developing native apps. This is a great way to collect download and usage data, to determine if that’s a viable market. Finally, responsive design and responsive CSS add richness to any of the apps discussed here that support Web technologies.
Rachel Appel is a consultant, author, mentor and former Microsoft employee with more than 20 years of experience in the IT industry. She speaks at top industry conferences such as Visual Studio Live!, DevConnections, MIX and more. Her expertise lies within developing solutions that align business and technology focusing on the Microsoft dev stack and open Web. For more about Appel, visit her Web site at rachelappel.com.
Thanks to the following Microsoft technical expert for reviewing this article: Frank La Vigne