This is one of the most controversial topic in the mobile App world: hybrid (non-native) or native?
Who we are
At Lunabee Studio, we are publishers of our own Apps since 2010 (oneSafe being our flagship), and an “App Studio” for our customers. Our customers are 40% startups, 40% large corporations, and medium-sized enterprises represent the last 20%.
We create premium (native) Apps from the ground up. Premium apps, what does it mean? To us, the user experience is key, and it’s a blend of these characteristics: simple, focus, efficient and natural.
And with these characteristics in mind, the technology you choose to develop your Apps must be super efficient and scalable i.e. allows you having a clean architecture, great performance (no flickering, lags), debugging tools, simple maintenance, easy upgrades to new version of iOS/Android etc.
Ok now that the scene is set, let’s talk about hybrid vs. native. This is THE question we have to tackle with every single prospect.
By “hybrid”, I mean all non-native technologies (e.g. Xamarin, React Native, Cordova, Ionic…).
Killing two birds with one stone. Really?
Most of the time, the hybrid folks are obsessed by killing two (or more) birds with one stone. Usually, the hybrid fans come either:
- from the technical side (CTO) wanting to optimize code (and cost), trying to have 1 source code to rule them all (Android, iOS, Web, and why not Windows).
- or from agencies not having iOS/Android resources (they’re hard to find!). Hybrid is a way to recycle their developers (having Web/C# skills for instance). Web agencies are a good example too: they have Web developers, and their customers need mobile Apps ; they naturally feel hybrid is the way to go.
A great User Experience is costly
First of all, there is no hybrid Apps in the top 100 on Stores, simply because the user experience is bad for two main reasons:
- Performance: Animations in hybrid apps are not fluid, and even scrolling with a lot of items lags from a graphical standpoint (even with React Native — tested by the DroidCon guys in a very visual way in Nov 2015, and read this article on Medium).
- Design guidelines: Hybrid apps are most of the time not properly following interface/design guidelines set by Apple and Google, so users don’t feel “at home”!
Then you can try to fix these issues by trying to optimize performances, and also to adapt your hybrid App to fit with the design guidelines of each platform.
But bad news, it’s costly to do that, and more costly than creating native Apps right from the beginning (with the right tools — see below).
And even after such an investment, it will be even more frustrating when you will finally admit that you can’t reach the same level of smoothness in scrolling and animations, available out-of-the-box natively. And the day design guidelines evolve (e.g. with next versions of iOS or Android), you will have to reinvest again to adapt your interfaces while it will be almost free with native Apps.
Still some doubts? Mark Zuckerberg @ Disrupt SF 2012:
I think the biggest mistake that we made as a company is betting too much on HTML5 as opposed to native. (…) We just never were able to get the quality we wanted [from the HTML5 apps we were building]… We burned two years. That’s really painful.
We’ve read people explaining that it was not due to hybrid, but to Facebook bad execution, and the poor “tools” available to develop hybrid Apps. It’s right too:
Tools & development environment
If you have seasoned iOS and Android resources in your company, they will be extremely swift to create Apps with these tools and development environments. And many frameworks / technologies will come almost “for free”, including OS updates with minimal effort to upgrade from one version to the next.
I had an interesting discussion on Cordova/Xamarin at the Apple WWDC 2016 with a Director of iOS developers in a well-known consulting company. He had to work on these technologies for some customers, and here is his feedback:
By experience, Cordova is super painful for what concerns the maintenance.
And Xamarin increases the complexity of the configuration and the maintenance of the Apps, which is rarely compensated by the code factorization.
This is the hidden part of the iceberg: maintenance is a nightmare!
— François G. @ Apple WWDC 2016
Latest technologies… 6 months old?
OK, now you want to have your App leveraging all Android and iOS innovations and cool features?
With native development and tools, you can implement new features instantly, with no workarounds (e.g. Touch/Face ID, 3D Touch, Siri, iMessage Apps, or ARKit more recently).
Why? simply because Apple/Google will do everything possible to have their developers implementing these innovations very quickly (simplifying it to the maximum) increasing de facto the value of their respective ecosystems.
Featuring on the Stores: bye bye
Last but not least. If you develop an App, I’m pretty sure you want to have plenty of users on your App, right?
One of the best ways to dramatically increase the downloads of your App is to have Apple/Google featuring your App, in the top banner of the Stores (you know, the “App of the Week” banner, in the Featured tab of the App Store), or in the “Best new Apps” section.
Apple/Google will never feature your App if it’s not native.
Why? Back to all the previous points I mentioned.
Note: if you tell me there are exceptions to this rule, fair enough. These exceptions are well-known companies with huge success — only question to ask yourself: is it your case? Will Apple/Google help you pushing your app and service despite the fact you don’t play the(ir) game?
What happens in real-life: Airbnb, Dropbox, Udacity…
Some companies have tried to move to hybrid technologies, in particular to React Native. From 2018, companies like Airbnb and Udacity are moving back to native technologies. Here are two articles you can read to have more details on their stories:
- Airbnb: https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c
- Udacity: https://engineering.udacity.com/react-native-a-retrospective-from-the-mobile-engineering-team-at-udacity-89975d6a8102
And more recently, Dropbox after having shared code in C++:
We have now completely backed off from this strategy in favor of using each platforms’ native languages (primarily Swift and Kotlin, which didn’t exist when we started out). This decision was due to the (not so) hidden cost associated with code sharing.
A challenge for you
Each time I try to convince someone about developing native Apps, my last question is always the same: show me a kick-ass hybrid App (I mean a 100% hybrid app), so that I can finally change my mind.
Do you have one in mind?
If you liked this article, thanks for clicking the ❤️, and feel free to comment 💬