Should I develop hybrid mobile apps? Nope (at least not yet)

Hybrid apps are a very controversial subject when it comes to mobile app development trends. This topic has been receiving a lot of attention in the past couple of years, but even so the technology has never been massively adopted by the market. This post will explain why we still don’t recommend them (in 90% of the cases).

What they’re selling

The idea looks pretty good, at least on paper. The company can use their web developers and other more accessible assets instead of platform specialists. The development is faster and the web technology allows the application to be ported into various operating systems in no time.

Despite that beautiful concept, the real thing goes differently: in the past few years, some big companies, like Facebook and LinkedIn, dropped their hybrid versions because of critical tech issues.

LinkedIn, for instance, had memory problems on Android and iOS. Both their web engines use a lot of memory, much more than native code does. One WebView can easily consume more than 50 MB —  and it’s common to see 100 MB+ usage — for a trivial UX implementation.

Even though the memory capacity is increasing on mobile devices, the apps’ complexity is also growing, and mobile JavaScript performance still decreases exponentially when dealing with hardcore UI tasks — and that’s only one of the obstacles to take into account.

“Well, at least you don’t need to spend your time with Objective-C and Java, right?”

Not really.

All the top mobile applications, nowadays, wouldn’t be able to follow the latest trends without the help of third-party open-source libraries (especially the ones hosted on GitHub). And those are mostly developed in native languages.

Although the hybrid platforms support plugins to interface with native code, it’s essential to customize those libraries — and even contribute to improve their source code — for your specific needs. And to do that, you’ve got to understand how they work – guess what? – in native code.

Bottomline is: if you want to develop a hybrid world-class app that follows up with the newest trends, you’ll also need to know how to code natively. Wanted to get rid of one or two languages? Now you got to work with five, at least!

What you could be missing

Here are some examples of libraries that use native languages to implement trendy looks:

https://github.com/ra1028/PathDynamicModal

A modal view using UIDynamicAnimator, like the Path for iOS.

*    *    *

    

    

https://github.com/lexrus/LTMorphingLabel

A morphing UILabel subclass written in Swift.

*   *   *

https://github.com/andreamazz/GearRefreshControl

A custom animation for the UIRefreshControl.

*   *   *

 

https://github.com/chroman/CRMotionView

A custom photo viewer that implements device motion scrolling.

*   *   *

      

https://github.com/premnirmal/Magnet

A library that makes it very simple to create a window icon, similar to Facebooks chat icon.

*   *   *

Hybrids help the developer, not the user

In this report, only 23% of the developers answered that they used CPT (cross-platform tools) and 26% of those made an app for only one platform. It’s clear that these guys are most likely using the CPT to avoid learning the native platform rather than for building great applications with cost efficiency. It’s for their own comfort, not the user’s.

Our last words are…

At Cheesecake, we don’t want to rule hybrid applications out of our toolbox. It’s just not the silver bullet, ready to replace native experience as some people are trying to sell it.

Hybrid apps will only succeed once (and if) the open-source community embraces them. Facebook is already leading a path towards this direction with the creation of React-Native, but, for now, you shouldn’t put all your chips on non-natives.