Native vs Hybrid
Mobile Apps Native Apps Hybrid Apps Progressive Web Apps
Aug 28th, 2020 - Brian Tresedder

Native vs. Hybrid: 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: HTML websites, packaged as apps.
  • Hybrid: HTML websites with elements native to the mobile platform they run on.
  • Native: Apps coded in the language specific to the operating systems they’re made for.

Progressive web apps 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 to the farther corners of the internet.

Hybrid apps stake out the middle ground, combining native and web elements. You can call it the best of both worlds, or slapping lipstick on a pig. 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.

The Question

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 cede quality and performance to save in other areas.

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.

But for all the upside, 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.


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.


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.


may also like
May 22nd, 2020 - Brian T.

Building iOS Apps with SwiftUI

app store icon
Sept 20, 2019 - By Brian T.

Common Reasons for App Store Rejection

Contact Us

Have questions? Reach out. We're happy to chat about who we are, what we do, and how we can partner with your organization to better utilize custom software in achieving your business goals. Drop us a line and let's chat.