Blurring the Lines Between Native, Hybrid, & Web Apps

By: Brian Fegan

It’s fair to say we’re living in the age of mobile apps. According to the results of a September 2015 study, mobile web & apps now account for 62% of all internet traffic, and 87% of that usage is from mobile apps.

It’s been over seven years since the App Store and Android Market (now Google Play) debuted, and there’s never been more options to create an app. A developer can write an app in Objective-C, Java, C#, JavaScript, Swift, ActionScript, and more. The lines between native, hybrid, and web apps have never been more blurred, and they’ll continue to get blurrier.


The Success of Native Apps

The success of native apps can be attributed to features that mobile web sites didn’t offer when native apps were first introduced; i.e. hardware access, offline storage, push notifications, and full screen display.

However, while a native app will offer the smoothest UI with the highest frame rates on each platform, for many businesses, it’s not possible or necessary to produce multiple versions of an app for multiple platforms. Cost, the need to get something in market quickly, and resource availability are just a few factors that affect choosing to build for one platform, or instead, to produce a hybrid app.


The Rise of Hybrid Apps


According to an industry survey of 10,000+ app developers, 42% said they use HTML5 (including CSS and JavaScript) to produce apps, making it the most widely used technology among survey respondents. In addition, JavaScript is the most popular language in GitHub, with 45% more repositories than the language in 2nd place (Java).

The popularity of web technologies has been the driving force in the creation and usage of what are known as app wrappers such as PhoneGap/Cordova,, Sencha, etc. These wrappers allow developers to produce a web app which can be embedded inside of a native app, while utilizing almost all of the same features that traditional native apps do. In fact, there’s even UI frameworks such as Ionic and Chocolate Chip UI that allow a developer to make their hybrid app look just like native platform UIs.

So why isn’t every app a hybrid?

The argument those in the native camp come back to time and again is poor UI smoothness; HTML DOM (Document Object Model) operations are slow, and will always be slower than the frame rates achieved by native applications.


Focus on Solutions, Not Problems

The thing is, whether the DOM is too slow or not, more and more app developers feel comfortable writing JavaScript than any other language. If history teaches us anything, it’s that platforms and frameworks flourish when they cater to what the public wants, often before they know they want it.

When a framework allows developers to create sites and apps quickly, while leveraging their existing skills, mass adoption quickly follows. We’ve seen similar mass adoptions with jQuery, with Angular, and we’re likely about to see it with React Native.


React Native uses React’s abstraction of views from the DOM and applies it to a native mobile context. As Facebook’s Tom Occhino says, “The only difference in the mobile environment is that instead of running React in the browser and rendering to divs and spans, we run it in an embedded instance of JavaScriptCore inside our apps and render to higher-level platform-specific components.”

While this framework was just announced in March at Facebook’s F8 conference, the reaction to its release has made waves across the industry. With it, the biggest obstacle that prevented many developers from building smooth native apps has been removed, as you can now use JavaScript to write them. Further, while the original release targeted iOS devices, Facebook recently announced support for Android devices as well.

It seems we’re witnessing an evolution in what a “hybrid app” is, as developers can use JavaScript to produce apps without needing the embedded web view.

What About Web Apps?

While React Native provides a glimpse into the future of app development, web sites aren’t going away anytime soon. Even if mobile web accounts for only 12% of total mobile internet traffic, Google’s mobile path to purchase report finds nearly 80% of mobile research starts with search engines and branded websites.

If a brand can provide the experience and features a user needs on their site, there’s no need for that brand to offer an app. I’d argue customer conversion rates would trend higher as that user doesn’t have to then go download a separate app as well.

There are evolving web standards for almost every “native” feature so they can be utilized in traditional web sites and apps. The Geolocation API, Device Orientation API, Fullscreen API, and Application Cache already offer features on par with native apps. With the Service Workers API, the W3C continues to work on standards for features that originally seemed unlikely to make their way into web sites.

As for the slow DOM, there are two ways to look at that issue. First, browsers are ever increasing in their ability to parse and render data quickly. Eventually, it’s likely speed won’t be a concern when interacting with the DOM. However, waiting for “eventually” isn’t much of an option.

On the other hand, there are those who feel the web can’t evolve to its full interactive glory with HTML, a markup language originally intended for nothing more than displaying text, and the DOM as its base. And they may be right.

Recently, makers of the Flipboard app developed an innovative solution that leverages the HTML <canvas> tag to accomplish app-like UI performance on the web. With the creation of their React Canvas library, in conjunction with Facebook’s JavaScript implementation of CSS, they were able to create a web app with performance approximating a native app.

Innovative thinking like that is what pushes the web forward, and influences web standards bodies to focus on ways these ideas can become part of a browser implementation (i.e. document.querySelectorAll).

With conventions like web components, we’ll likely see that there isn’t a one-site-fits-all solution either. Sites and apps will be broken down into components that talk to each other through standardized APIs, knowing nothing about each other’s technology stack. As a result, developers can produce new functionality using emerging technologies, without needing to update older pieces of an application.

Give the People What They Want

As I mentioned earlier, platforms flourish when they cater to what the public wants. As a development community, we fought hard in the early 00s against proprietary browser features in the battle for an open web. While we’ve had to adapt to a fragmented platform landscape, we’ve learned our lessons from the browser wars.

In the same way the popularity of JavaScript has affected its adoption as a viable server-side language, native apps will soon follow the same fate. Along the way, it’ll be difficult to determine where web/hybrid starts and native ends. And while those lines will blur more and more, in the end, it doesn’t really matter so long as users can’t tell the difference.


Brian Fegan is an Interactive Architect in Isobar’s Denver office. With more than 15 years of experience in interactive development, he is adept at leveraging existing and emerging technologies to create engaging user experiences.