Why hybrid Apps are crap

Thomas Jaussoin
Lunabee Studio
Published in
7 min readFeb 12, 2016

This is one of the most controversial topic in the mobile App world: hybrid (non-native) or native?

👉 Updated in May 2024, with SwiftUI and Jetpack Compose + new article on performance by Theodo + Apple/Google ecosystems section

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, Flutter…).

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:

  1. 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).
  2. 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:

  1. Performance: Animations in hybrid apps are not fluid, and even scrolling with a lot of items lags from a graphical standpoint. This comparison done by Theodo between native/SwiftUI, Flutter and ReactNative is interesting “Comparing iOS rendering performance: SwiftUI vs. React Native vs. Flutterhttps://blog.theodo.com/2023/09/ios-rendering-performance/
  2. 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 (long long time ago, ok, but it illustrates perfectly what the consequences can be when you don’t use native technologies):

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

Xcode and Android Studio, in 2024, are awesome IDE (integrated development environment) with almost no equivalent in the software industry in terms of quality.

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.

Swift UI and Jetpack Compose ❤️

And now, you have Swift UI and Jetpack Compose that are a game-changer when you develop natively your user interfaces (and in 2024, it’s mature enough for production apps). With these frameworks, both Apple and Google tackled here the last complexity on UI coding…

Here is what Google says about Compose:

Using modern design practices, Jetpack libraries enable fewer crashes and memory leaks. Describe your UI, and Compose takes care of it. As app state changes, your UI updates.
https://developer.android.com/jetpack/compose

… and Apple about SwiftUI:

SwiftUI helps you build great-looking apps across all Apple platforms with the power of Swift — and surprisingly little code.
https://developer.apple.com/xcode/swiftui/

In 2024, we can now encourage you to use SwiftUI (iOS 15+ to get all its power, ideally 16+) and Compose in your apps. And this recommendation encompasses sophisticated apps in production.

What can happen with hybrid technologies

Anecdote on Cordova/Xamarin — 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

This is to illustrate — again — the possible consequences on selecting the wrong non-native technologies.

One other possibility is that hybrid technologies could be impacted by decisions/changes in terms of priorities from the main actors (like Flutter lately and Google’s layoff). This could affect the developer community on this technology, making it harder to hire people, and the libraries / dev resources that wouldn’t be updated as often.

Make the most of Apple/Google ecosystems

OK, now you want to have your App leveraging all Android and iOS innovations and cool features in their ecosystems?

With native development and tools, you can implement new features instantly, with no workarounds (e.g. Touch/Face ID, Siri, Dark mode/theme, extensions, universal search, widgets, ARKit or App Clips more recently and so on).

If you want to make the most of Apple/Google ecosystems (e.g. AR/XR headsets — hello Vision Pro — , Carplay/Android Auto, smart watches, etc.), native technologies will make it simple and smooth. This is what Google call Ambient Computing.

Why will it be simpler? simply because Apple/Google will do everything possible to trigger this virtuous circle, and therefore 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 Day” featuring, in the “Today” 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:

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.

https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android/amp/

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 💬

Lunabee Studio is a company creating premium mobile Apps in the Alps. We love mobile UX, iOS and Android. Follow us to keep up with our latest publications and news.

--

--