Native vs. Hybrid Apps: The On-going Discussion

At Entrision, our app development team builds mobile applications with varying feature sets of all different sizes for all different industries. So our team here in Milwaukee is constantly exploring technical decisions when it comes to the best way to build those apps.

Broadly speaking, there are three ways to build mobile apps.

• Progressive Web
• Hybrid
• Native

Progressive web apps are HTML websites packaged as apps. They are very easy to build, and require relatively little effort, as they’re not much more than websites fit for mobile screens. For these reasons they generally perform poorly and are largely relegated. When building mobile applications, most developers weigh the options for either a hybrid or native app.

What are hybrid and native apps?

A hybrid app is an HTML website with elements native to the mobile platform they run on. Highly recognizable brands that run on hybrid apps are Uber, Evernote, and Instagram.

A native app is coded in the language specific to the operating system they’re made for. This means a brand will need to create two mobile applications if they would like to reach both the iOS and Android marketplace. Popular brands that use native apps include Spotify, Pokemon Go, and Waze.

What is the difference between hybrid and native apps?

Hybrid apps stake out the middle ground, combining web elements and elements native to the platform the app is running on. You can call it the best of both worlds, but we say: slapping lipstick on a pig. Typically, hybrid apps will be slower and more dependent on third-party platforms. Companies willing to concede on quality and performance often look to hybrid as a lower-cost option.

Native apps perform best because they’re made for the platforms they run on. Yes, they are more complex to build than a web or hybrid app, because it take a skilled developer to understand the nuances of a specific operating system. Native mobile applications run seamlessly for the user on their mobile device, because the developer has full access to the operating system’s feature set. Native apps are built specifically for the operating system the user is on, which creates a satisfying user experience.

Which is better: hybrid or native apps?

The fact is: native apps are superior to hybrid apps. It’s why almost all the apps on your phone will have been written with native code. Why bother writing this article, then? Because the debate isn’t about performance, it’s about priorities--whether you and your company are willing to trade quality and performance to save in other areas (usually budget).

Let’s say your company is developing an app. You want it to function optimally, but also reduce cost. Here’s the question you are asking yourself: Do the upfront savings of building a hybrid app outweigh the long-run costs and performance and quality benefits of building a native one?

Case Study: AirBnB

In 2016, AirBnB--the online marketplace for renting out rooms in homes--was growing fast. It was growing so fast, in fact, that entities within the U.S. government began to investigate whether intervention was necessary to sustain the hotel industry.

Leveraging this popularity, AirBnB sought to expand their app with new features, and an entirely new service called “Experiences.” And, in the spirit of Silicon Valley, they took a risk on a new technology that promised all of the benefits of native and hybrid apps, in one package.

They decided to use “React Native.”

As AirBnB began using React Native, the benefits became apparent. Despite being a hybrid paradigm, their React Native software was performing just as well as native software. The developers, for the most part, loved using it--60 percent described their experience with React Native as “amazing,” with only five percent characterizing their experience as strongly negative.

The real kicker was what they gained in efficiency. Most companies, remember, have to code entirely separate apps for iOS and Android. With React Native, only 0.2 percent of AirBnB’s code was specific to iOS or Android. That means just under 100 percent of their code really was written in Javascript, and really did work for both iOS and Android. In other words, React Native did exactly what it was supposed to.

If it seemed too good to be true, it was. There were plenty of technical problems to go around. Bizarre crashes were frequent. Initialization and rendering were slow. Refactoring was cumbersome and, in some cases, just broken. Upgrading to new versions of React Native itself was a nightmare. Especially when it came to implementing advanced and specific customizations, React Native just couldn’t do what Native can.

Outcome

After two years with it, AirBnB had a decision to make: would they stick with React Native for its developer efficiency and popularity, or ditch it for all its technical hiccups, disturbances, and outright failures?

Ultimately, they chose the latter.

When everything came together, which it did for many features, the iteration speed, quality, and developer experience matched or surpassed all of our goals and expectations. At times, it really felt like we were on the verge of changing the game for mobile development. Even though these experiences were highly encouraging, when we balanced the positives against the pain points plus the current needs and resources of our Engineering organization, we decided that it wasn’t right for us anymore.

It’s necessary to note that React Native is quite popular today, with plenty of companies using it including Skype, Tesla and, of course, Facebook. AirBnB’s experience didn’t demonstrate that React Native is inherently bad, or good--only that it’s situationally good, and bad under the wrong conditions.

Conclusion

For the right team, React Native can be a cost-effective solution for building a mobile app - especially for early iterations. Ultimately though, there’s no getting around the fact that native apps perform better--especially in the long run for enterprise-level applications.

For building MVPs, prototypes, proofs-of-concept, or generally simple applications, cross-platform is great - especially if you have an engineering staff full of web developers. For advanced products with extensive and highly customized features though, the cross-platform solution will eventually end up causing more trouble than it’s worth, which is why most of our apps at Entrision are still built natively.