Mobile Apps: Native, Hybrid, and WebViews

Pure Native

Back in the days when feature phones ruled, there were no real native apps. Instead, we always had to use a J2ME (Java 2 Platform, Micro Edition) abstraction layer, which let most devices run a common, albeit limited set of functionality. The real benefit of smartphones isn’t their big touchscreen, but the ability to run apps that really take advantage of the speed, security, and all the features of each specific phone or tablet.

Developers code native apps in software-programming languages such as C and Java, as opposed to the markup and scripting of the Web—that is, HTML, CSS, and JavaScript.

Note—In case you don’t already know—despite the similarity of their names—Java and JavaScript have absolutely nothing to do with each other.

Code

The biggest downside of building native apps is the type of coding necessary. Your developers have to know how to work in the appropriate language. This means you may need totally different developers from those working on Web apps, desktop apps, or other mobile platforms. You’ll need at least one Android and one iOS developer to build apps for modern smartphones.

Some assume the cost will be higher because of a lack of code reuse, but that is not always true. The software and database design and the APIs (Application Programming Interfaces) for retrieving or storing any remote data are entirely reusable.

Formatting

Well-written native code always runs fastest for on-screen interactions or processing data that is stored locally. It also offers the best security by far of all technology options. In fact, I know people who consider native the only security and won’t even think about building hybrid or Web apps that have serious security needs.

At the presentation layer, native is native—providing the benefit of making your app act like the rest of the user experiences on a phone or tablet. But the OS makers change things all the time. On Android, individual phone manufacturers have their own variations. The easiest way by far to ensure your app looks and acts consistently with other apps is following good code practices, in native code.

Native also supports users best. Individuals can set their type size or enable accessibility features, and well-written native code respects these settings.

However, there are limits to what the OS offers. If you want to create a UI widget or layout that the OS does not strictly support, you’re looking at writing a lot of code to make that happen. Sometimes, pretty simple stuff is almost impossible to do. A classic case is the difficulty of displaying properly formatted bulleted lists in iOS native code. It is barely possible in Swift—and only with a lot of code—but is still almost impossible in C#.

Data

Native apps are not Web sites, and this can sometimes show through. If your existing site uses a Web service that serves up information with HTML tags, your native app won’t know what those tags are. Either your users will see these unformatted codes, you’ll have to take the time to remove them, or you’ll switch to sending XML.

Generally, apps take either of two approaches to getting data. The good way is to have an API—with as many endpoints as necessary—communicating with a remote server that your organization runs. For example, an API lets you get app updates, load or background-sync data to provide customers with what they need, or get analytics and crash reports.

The bad way is to store data locally and perform an update every time it changes. This approach is all too common because it emerges naturally from the whole concept of “we’re building an app” and the resulting assumption that there is no need for technology such as servers, APIs, or anything else that people perceive as relating to the Web.

Apps aren’t magic. They need lots of support to work well.

All Web, Hybrid Apps

The theoretical solution to a lot of the problems that are characteristic of native apps is a hybrid Web app—meaning a write-once solution of some sort that runs in the native browser, within a native wrapper that provides access to native platform features. Some or all of the code is in some commonly interpretable language such as HTML.

In fact, for the rest of this discussion, assume that I mean HTML, CSS, and other Web-friendly technologies rather than strictly hybrid. This also means a complete solution, in which everything the user sees is from Web code.

Hybrid is not at all new. To bring you back to the old J2ME days again, I designed a lot of hybrid apps back then and was a big fan of this approach. It was efficient, solutions for individual phones had no uniqueness, and we could use the same code as for a Web site or Web service.

Code

Today, hybrid also means a turnkey solution. You buy a tool such as Xamarin or PhoneGap, then just get right to work. The great dream of this approach is that it requires no new headcount and no notable effort. You can use normal Web developers with no extra training, push a button, and get an app. Ideally. But, in the real world, there are a number of issues.

You cannot use many phone features. Local storage is limited to the local Web server that loads your content, and it is sometimes hard to use a remote Web server. Camera or location access may be limited, difficult, or impossible. Bluetooth access, especially to the level necessary to connect to or configure IoT hardware is impossible—at least, without native code, at which point you are back to hiring native-app developers again.

There are performance issues. The app always takes longer to load, runs slower, and does not work as well or at all in the background. These are the issues that caused a major problem for Facebook a few years back, causing a bit of a backlash against hybrid for a while.

Untappd, an app for logging and rating beers, ran right into this issue when they encountered horrible performance with the first test versions of their app. They improved performance to near-native levels by finding out what parts of their code were slowing down rendering. In some cases, they had to change the design, but much of the solution was just changing how they coded the app. Which, of course, is no longer what many people would call pure HTML. Developers also have to spend time learning how to use the platform properly.

Security is so fraught with issues that most security experts won’t even consider working on hybrid apps. Security models are Web based, so often require session timeouts, which are unexpected for apps. In fact, that are so unexpected that users may even think an app is broken or is being attacked. This approach also has direct technical impacts on security that are beyond the scope of this article. But, as an example, several platforms I have worked on offer two key options for secure sessions:

1. Send the whole authentication string with each HTTP request—with very high overhead, of course.
2. Send all data through plaintext.

Formatting

Whatever does get coded, you aren’t ever going to get an app out the other side. Oh, sure, what your users download seems at first to be an app, but it’s really just a custom Web browser. When users open it, they’ll always get a splash screen, then see something purporting to be an app, but which often has the user interface and behavior of a Web site.

While it’s possible to code a Web app to look pretty much any way you want, making it look different for every mobile platform is hard. Mobile phones have unique interfaces. Thousands of them. Every version of every phone from every maker has at least slight differences. Plus, there are huge differences between iOS and Android. If you write a hybrid mobile app that looks like a native iPhone app, it just looks wrong on Android.

One good thing is that you can often use native controls. If you do a good job with form creation—setting proper inputs for dates, phone numbers, and so on—users get the native input methods, which help a whole lot. But other native features are very difficult to achieve. Fake-native dialogs are just the worst. The best way out of this is to go fully custom, avoiding things like dialogs or menu drawers that may reveal how non-native the app is.

If you don’t fully customize your app or go with the enterprise solution of no app-style customization at all, your users will notice and think the app is broken—even if it is, in and of itself, pretty and has good performance and functionality. Users’ expectations matter, and creating Web sites in app wrappers is sufficiently confusing that I routinely see one-star ratings for them on app stores and the apps often get pulled because of complaints.

Data

Some people refer to HTML5 apps when they mean hybrid. This is wrong, but for most cases, it illuminates the expectation that you’ll use the same presentation layer, software, APIs, and data seamlessly for both interfaces. And it’s true. Full win here.

Except where that’s a terrible thing. For the most part, turnkey hybrid tools are a lot like responsive Web sites. They use exactly the same data, giant tables, huge photos, and long titles on the mobile side—meaning users cannot read or use these items. Or users never get around to reading them because a page that is optimized for high-speed, low-latency connections takes two minutes to load on the 3G mobile networks that still dominate much of the world.

You can avoid these issues. It is possible to use responsive images, responsive content, or adaptive techniques. However, this additional mitigation takes time and money, and most adaptive methods rely on server-based tools that you cannot install locally on the phone. But most of all, this is not just turning your Web site into an app, but requires a lot more planning, work, and perhaps resources such as new developers that you were trying to avoid by choosing hybrid.

All in all, from many projects, I have found that hybrid development takes anywhere from 75–150% of the time and cost of simply building similar or even identical apps entirely native. Don’t fool yourself and make bad estimates of time, cost, and results when planning to use any method like this.

Web Components: Using WebViews

Hybrid is really a concept, not just the use of a store-bought tool. So the choice is not just all-native or all-hybrid, but a mix. How much of your app should be on the Web? It’s not a choice between none and all. It turns out that it may be convenient for some of your app to be on the Web.

All the smartphone operating systems support the use of WebViews in apps. WebViews are exactly what they sound like—a small view to a piece of Web content. A WebView can be a tiny part of the app screen, as shown in Figure 1, a whole page, or anything in between.

You can also use WebViews for full-screen previews of Web content, without going out to the browser. Often, this approach results from the weird belief that you can hold users hostage to your app experience if you just lock them in. We don’t intend that in this case, but are instead referring to WebViews that are seamless and integral to the application.

Code

No tricks are necessary here. Normal HTML runs fine and, because it’s usually a small portion of a page, it’s easy to avoid weird issues and performance problems. If you have a larger piece of content or some additional formatting, look at what might cause issues—as the Untappd team discovered—and try to clean them up.

Presenting information is fairly easy, but linking to other pages can be odd. Plan that out early on. You might find it easier simply not to have the WebView content link at all, but be static content. However, if there are links, you need to make sure users stay in the app.

Custom URIs (Uniform Resource Identifiers) should solve your issues with linking, but if you aren’t expecting this issue and do not set up the app manifest to support all the relevant domain names, people will be clicking around your app and suddenly pop out to a browser. That will confuse and anger users.

Similarly, think about how you are going to use phone features or data. Sharing or other intents have to launch properly. Many times, I have clicked a location link and had a Web version of Google Maps load instead of the app on my phone. As I suddenly found out, the app had a WebView with poor intent coding.

Consuming data can be even harder, really exposing the Web nature of your app. Say you want to embed a map in a WebView. It won’t work right unless you also use the native part of the application to retrieve the location and pass a request to the Web server to send that data over properly and seamlessly to the user.

Formatting

Yes, all the issues of formatting that can make the Web tragic on hybrid are also risks in WebViews. The way around this is to use only content that looks the same regardless of the platform on which you present it, including lists of content, search results, tables of information, Help documents, and images. Of course, it’s sometimes easier to format that sort of information properly with HTML anyway.

Avoid input boxes, complex controls, and functions that try to interact directly with the phone features. Make those native instead. Use the content that works best on each platform.

Data

A very good use of WebViews is for displaying data that is already formatted in HTML and would be needlessly tedious to reformat in native code. Doing this well is one way to avoid a lot of work reconfiguring or runtime-parsing your existing information.

One key thing you should consider now is whether a Web site is local or remote. Hybrid apps use Web technology, but locally, with everything stored on the phone. In contrast, WebViews that are embedded in a normal app can be local or remote. So you can retrieve data just as you would for a Web site—with all the typical disadvantages of needing an Internet connection, slower speeds, and latency. However, this approach also offers the advantages of live information, updating your data without an app update or customized sync, storing data in the background, and remote processing—such as the use of artificial intelligence—without writing APIs and parsing data.

I can’t tell you how many times I have had to help push an app update where all that had changed was the new terms and conditions that the corporate legal team required. Syncing data is cool, but for low-use, probably connected users or conditions such as authentication, you can probably just load data from a Web server and save a lot of hassle. A lot of hassle. Web servers are easy to create and WebViews are easy to integrate—a lot easier than building a database, an API, and having a native app consume an XML stream. If you can get away with using remote data instead of embedding and syncing data, that can help you launch and iterate faster and cheaper.

Web-Driven WebView Apps

What if you decide that almost all of your data is live, so the entire app—or at least most of it—should be a WebView? Does that mean going back to hybrid? No. What you can build is what we’ll call a WebView app. While there’s no one agreed-upon term, it’s a concept that some big, successful organizations have used.

The general idea is create a wrapper—the visual and technical container for the app—that is native, and fill all the content areas with WebViews. A lot of important digital products that are well known as app platforms are actually WebView apps. While most companies don’t share their technology, we know that Facebook, Evernote, Instagram, LinkedIn, Uber, Slack, Twitter, Gmail, the Amazon Appstore, and many others are or have been WebView apps.

Quora is a WebView app of some sort, with a few clearly native components along the edges. As you can see in Figure 2, there’s a lot of Web-formatted content in the middle of the viewport, but things such as the tab-bar overflow and search input take advantage of native features.

Code

At first blush, it seems like WebView methods could be quite inefficient because you need more types of developers, including native developers for each platform to build the wrapper and set up the flow from page to page, as well as Web developers for the content.

However, your app doesn’t exist in a vacuum. Concerns about cost, time, and quality apply to the entire application-development lifecycle. You should take into account, not just immediate costs, but also the following:

• ease of updates—Much app functionality is remote, so you can change most of the app and fix most bugs as you would for a Web site, without scheduling app releases.
• marketing value—While this approach offers the ease of building a Web site, you can confidently tell everyone that it’s an app because it acts like a native app, delivering much of the performance and capabilities everyone expects of an app.
• complete control—You are not limited to particular platform choices, so can react more quickly to changes or problems. You can even shift platforms when issues arise. If you’re having a problem with a piece of native code, you might be able to address it temporarily by switching to a WebView.
• efficiency—Your Web developers probably won’t need to work only on the app and can do most of their work for all platforms. Some of the promise of hybrid apps still exists if you plan well.

The wrapper is simply all the code that wraps around the content on a page. There’s generally a distinction in the form of the code as well, with the wrapper in native code and the page’s content mostly using Web technology. But it’s not just the presentation layer. The native app handles things such as interacting with the phone to accept and send data, read settings, cache and store data, and use sensors. You can add anything to this wrapper, including all the custom code you need to create IoT controls, machine-vision cameras, or whatever your app needs to do.

Formatting

While WebViews in apps are more capable than the custom browsers in hybrid apps, the same performance issues can arise. As usual, careful design can mitigate these problems, so carefully research and test what will and won’t work well. Design for mobile, understanding that latency is more important than speed and using as few data calls as possible.

Another nice thing is that the wrapper code can intercept any number of functions, so you can display popups from the Web by asking the native code to generate them. With a lot more care, you can use native interfaces and intents.

Adaptive technology works fine once you have servers to host it, allowing you to send different versions or styles of the content to each platform if necessary. One way to really take advantage of this capability is for major platform changes. Tablets, for example, can get different views or content that takes advantage of their larger viewports. For example, newspapers often write different headlines for each platform, so they’ll fit better and be more readable on each screen size.

The native wrapper means you don’t need actual device-detection systems, because the app knows what platform it is on and passes that information with requests to format the WebView code appropriately.

The easiest approach is usually just to make careful choices about what is native and what is Web. The wrapper provides menus, can display dialogs, opens intents, and grabs data such as location, so acts more like an app than a Web site. Uber made their map and other functions Uber-like, with the wrapper acting native enough so the whole experience feels familiar to every user. Quora uses modal pages for items that might otherwise have been dialogs. Since these have a lot of content, this is just a good design choice that benefits the overall experience.

And don’t forget that you don’t have to commit to using Web content everywhere. As I mentioned for smaller WebViews, if something would be terrible as a Web interface, just build that page partially or entirely as a native screen.

Data

Understanding the value of data flow is key to deciding whether a native app, WebViews, or a full WebView app is the way to go. If yours is largely or entirely a live-data product, there’s not much value in native caching—it might even confuse your users. If you cannot think of a good reason to build an app at all, a WebView app is likely the best choice.

Do take advantage of the wrapper to make the app act like an app. Make sure the user signs on just once, not for every session. Cache whatever data you can to make the app appear to behave more intelligently and respond more quickly.

Your App Is Never Done

Once you choose one of these types of apps, your choice is not final. Your app may grow and change over time, so the conditions that caused you to make your original choice might also change. Getting bogged down by a decision that you made on day one of your project is the very definition of technical debt. Many apps that used to be hybrid or WebView apps have become more native over time. Make an explicit plan up front to re-evaluate your technology choices periodically or transition from one method to another.

Yelp uses WebViews to quickly launch products and more rapidly iterate features across all of their platforms. Once they’ve found a successful combination and locked a feature down, another team slowly and carefully turns most features into native code, platform by platform. Since the app has already launched, there’s no pressure from anyone to get features out faster, and they can focus on quality.

The choice you make very much depends on the nature your project, what your goals are, and what your users’ expectations are. There is no single answer for every project, at every phase in the evolution of an app. 

Resources

Avola, Greg. “Native or Hybrid: The Path of Least Resistance.” Telerik Developer Network, April 6, 2016. Retrieved July 19, 2018.

Blomo, Jim. “Whoa! That Embedded WebView Looks Hot in Your iOS App!” Yelp Engineering Blog, November 7, 2013. Retrieved July 19, 2018.

Kim, Dan. “Myth Debunking: WebViews Suck, Everything Should Be Native.” Signal v. Noise, June 11, 2016. Retrieved July 19, 2018.

Martin, Jonathan. “The Tip of the Iceberg: Your Mobile App Is Really a Web App.” Big Nerd Ranch, February 14, 2017. Retrieved July 19, 2018.

Waugh, Zach. “Basecamp 3 for iOS: Hybrid Architecture.” Signal v. Noise, September 8, 2017. Retrieved July 19, 2018.