This has been a continuous source of conflict and division within mobile apps developers, almost surpassing the eternal nuclear war of tabs vs. space (hey, that can be a great subject for the next article!). But first of all, let’s have a look at what are native and hybrid mobile apps.
What are the differences between native and hybrid mobile apps?
The main difference between native and hybrid apps is the technology used to build them. Native apps are developed using the native SDK (Software Development Kit) of the platform, which developers can use in Java for Android or Objective-C for iOS. Hybrid apps, on the other hand, are developed using web technologies (HTML, CSS, JavaScript) and then, either transpiled to native code or wrapped into a native web view.
Most of the other differences are a consequence of that technological divergence. Hybrid apps mostly encourage code reuse between platforms by adding a level of abstraction over the SDKs. Therefore, you can code an app once and have it work on Android, iOS, Windows Phone, FirefoxOS, etc… On the other hand, if you want to build native apps, you will need to build a completely different app for each platform. Native apps are therefore more expensive to build and to maintain than hybrid apps. But on the bright side, native apps possess intrinsically higher performance than hybrid apps and they enjoy an effortless native UI.
Facebook and LinkedIn, from hybrid to native
Going native or hybrid has always been a fairly hard choice. Is the cost of a native app worth it? Are hybrid apps that bad in performance? To answer those questions we can look at Facebook and LinkedIn, both of which started publishing hybrid apps before switching to native apps.
Facebook CEO Mark Zuckerberg famously declared that betting too much on HTML5 was Facebook’s “biggest mistake”, and the numbers prove it. Facebook had a hard time providing a good mobile experience for its users with an hybrid app, and after switching to native apps on both iOS and Android, user satisfaction skyrocketed! LinkedIn’s story is slightly different and focuses more on the lack of development tools available at the time for hybrid apps, but they probably benefited from a better performing app overall as well.
Indeed, several studies have shown how much users actually care about app performance. 56% of users have experienced performance issues on mobile apps, and while 79% may give it another try, more than 33% will eventually head to a competitor. Further more, 84% of users think that performance is somewhat or very important in mobile apps.
Are those apps hybrid? (and do you actually care?)
So, users do care about performance, and hybrid apps are known to lag behind native apps on that. But does that mean that users care about using native or hybrid apps?
Here is a little game for you: find the hybrid apps!
Answer: all of them are!
Let’s sign a ceasefire and get things done!
According to Garner, more than 50% of mobile apps deployed by 2016 will be hybrid. Developers also tend to bend towards hybrid apps, with 33% preferring to build them compared to 29% for native.
Besides, new tools such as React Native (built by … Facebook!) are bridging the gap between native and hybrid, allowing developers to build near-native apps performance-wise using web technologies. It is easy to build a poor performance app using hybrid technology, but it is also possible to build great apps using those same technologies.
At the end of the day, users don’t care that much about how an app was developed, but they do care about what the app actually does and how responsive it is, so let’s just sign a ceasefire and get things done!
Top comments (7)
Most people talk about PhoneGap/Cordova when they talk about hybrid, but NativeScript and React-Native are also partially based on Web technologies (CSS/JS) and aren't 100% native.
I also read that NS & RN get better performance (60fps yaddayadda) than PG/C, so if you don't persist on using HTML as render target, the difference between "real" native and "hybrid" native isn't that big anymore.
That's very true. And this is a big problem with technology which evolves quickly but we can't (and probably shouldn't) rename each different iteration. So hybrid means something totally different in different times and places.
The Facebook story is from, like, 2010 and newer approaches to both the native-interacting/compiling and the Cordova approaches have evolved a lot.
Yes.
At the moment I make react-native apps for a living and clients still only know about "hybrid" (PhoneGap) and "native"(Objective-C/Java).
Then I tell them about the "app spectrum" and they're mind blown, haha.
Then there's the situation where you were able to convince the clients that hybrid isn't what they think it is but now they think nothing will ever go wrong and if something does go wrong or is non-performant, there's the "If only we'd gone full native" cloud hanging over your head. Either way, the client will have a hard time envisioning all the problems that were avoided by making the choice that was made.
That's just a mini-rant about clients. :P
I agree fully. Users don't really care but they do care about responsiveness. Using HTML will in almost all cases generate delays in responsiveness, but can be executed so well you hardly notice it.
Being a hybrid app developer myself (Appcelerator Titanium) I tend to notice those things, yet I didn't notice the app "Untapped" actually is a cordova app! So it can be done!
Still wouldn't want to build an HTML app though, I'll stick with Titanium for now.
Yeah, I think anecdotes like Facebook failing with early HTML5 approach and similar tales like Twitter leaving Rails muddy the waters for shops that really don't have the same concerns as Facebook or Twitter. There is so much at play, and so many things change along the way. Clearly Facebook still believes in hybrid or they wouldn't have developed React Native.
There's another case that's going to be ubiquitous. If you take Twitter, specifically Twitter Lite, that's just a web application. It looks like a native app, it feels like a native apps, but it's the web. Solely the web. And it can work offline, it can have a local cache and storage, and all the stuff.
It's the magic of Progressive Web Applications.
Now supported in Chrome, Firefox, Samsung Internet, UC Browser and even in development in Edge. Only Safari is missing, but as soon as it will support Service Workers things may change drastically for many, many apps.
Because what users do care about is not having to install another specific app to use your services.