5 reasons NOT to build a hybrid mobile app

So, you finally have that million dollar mobile app idea. Something amazing that has never been seen before. You have it all clear in your head, down to the smallest detail and you’re ready to start building it. And then you get to THE question:

Should I build a native or a hybrid mobile app?

Aaah, the old native vs hybrid war… Let’s begin.

What are native apps?

Native apps are smartphone (or tablet) apps developed precisely for a mobile operating system. They are built using the development tools and programming language that the respective OS supports (for example XCode with Objective-C or Swift, for iOS; or Android Studio with Java, for Android). For simplicity’s sake, I will only be referring to iOS and Android when I talk about “native platforms” in this article as they are the biggest players in the market.

What are hybrid apps?

Hybrid apps, also called cross-platform apps, are really only websites packaged into a native wrapper. Basically, a hybrid app is a web app built with HTML, CSS and Javascript, wrapped with a native container and it usually loads most of the information on demand requiring an internet connection (native apps download the content when the user installs it on the smartphone).

Ok, now that we’ve got the definitions out of the way, let’s move on to the reasons why you should NEVER choose to build a hybrid app.

1. There’s a hidden cost to hybrid apps

“What do you mean? I heard that hybrid mobile apps are a lot cheaper than native apps since you only build them once and they run everywhere?”

Yes, it’s true that the hybrid approach looks great in theory and even starts great. Many companies work with HTML, CSS, Javascript. They start building an app that will “just work” on both Android and iOS devices, you see rapid progress, investors are happy and you’re thinking you’ll be done building the app in no time.

So what’s the problem? Finishing it. Usually, in software development the last 10% of the project requires 90% of the work. It’s really easy to build something functional compared to building something polished, bug free that can compete in the marketplace. The crucial features are developed in the last 10%. This is where hybrid falls behind. Allow me to explain.

With hybrid apps, native features can be used only by using plugins written by other developers. Sometimes the plugin that you’re looking for doesn’t exist. Sometimes it hasn’t been maintained and doesn’t work for the current operating systems. And sometimes it’s full of bugs and unusable. Developing such a plugin from scratch or even fixing it outweighs even the cost to add said feature in the app.

Another thing to consider is that native platforms have differences, big and small, between them. The code for a hybrid app must account for these differences. Usually, developers must choose between dropping down to a common solution that applies to both platforms or writing code to support BOTH platforms. This defeats the whole purpose of cross-platform and it’s also much much MUCH more difficult to maintain two different applications in the same codebase.

2. You can’t stay ahead of the curve

What I mean by this is, by choosing to build a hybrid app, you will most likely not have access to the latest introduced features of the operating system (OS). Why? Because of those native plugins that I’ve talked about earlier.

When new versions of iOS and Android are released, native developers are given early access to the software development kits (SDKs) to start testing newly added feature and integrate them into their apps. This way, native app owners can have an update for their app the day their users update to the new OS version.

Hybrid app developers need to wait until a third-party developer implements a plugin to bridge the new operating system features. This gives native app developers a three to four months head start with the new features. That’s the best case, by the way. Worst case is that hybrid apps may never support them altogether.

The hybrid approach tricks owners and investors into a false sense of progress until it’s too late to switch to native and they must ship the inferior product.

3. Time to market vs doing it right

Usually, when building an app, you’re either playing catch up with competitors or have identified an untapped opportunity. Whatever the case, you will want the app built ASAP. But ASAP doesn’t have to mean that compromises need to be made and that bad decisions need to be taken. Both native and hybrid approaches can get the job done, but you need to be aware of some things first.

First, if you can wait a few months before the app is launched, go with native. Native apps have the best performance, best feel, best user experience, highest security and run smooth and fast.

If you can’t wait those few months and need it done even faster, a hybrid approach could be a faster way to build it, but be warned: Your users will expect a great experience. They don’t care about which development route you took, what made you do it and how much you’ve invested in the app. They EXPECT the app to have a great user experience, be intuitive and be fast.

Getting to the market fast may win you the battle, but not the war. Acquiring users before your competitors is important, but even more important is the retention of those users. Nobody has time for bad user experiences. Here’s a stat to blow your mind:

While 79 percent of consumers would retry a mobile app only once or twice if it failed to work the first time, only 16 percent would give it more than two attempts. Poor mobile app experience is likely to discourage users from using an app again. Source

You have one chance to get it right. You won’t get the second.

4. Performance

How important is performance for your app? Very important, I hope.

Even the most avid hybrid app evangelists can’t deny that native apps win the performance race by a landslide. A native app is faster and more reliable by nature. It has all the structure, content and visual elements ready to be displayed at any time instantly, providing a seamless experience.

Hybrid apps, on the other hand, has to download the website’s content into the user’s phone first.

Experts agree that hybrid apps take a hit in the performance war:
“There’s no indication the DOM [document object model, the API used to pass information before the mobile interface and the server] will ever be fast enough, and if it does happen it’s light years away on mobile. I’ve seen no technical description of a truly plausible way to make it significantly faster.” – John Long, developer at Mozilla (Source)

Along with experts, the users also agree with this, 84% of them considering performance to be an important or very important factor. Source

5. Security

Last but certainly not least, let’s talk about security. It’s important to understand the security risks behind a hybrid app. Every layer in an application introduces a new opportunity for an attack.

As explained earlier, hybrid apps add new layers to bridge the non-native code to the native features. These layers are owned by third-parties and most of the time you can’t inspect the code behind them.

Even if the hybrid platforms would be 100% safe, the community driven plugins are a big security concern. Because for every native feature available in the app, a plugin must exist.

In conclusion, is there no actual reason to build a hybrid app?

Well, most of the time no. 99.9% of the time, you’re better off building a native app instead.

However, a hybrid app solution could work effectively if it wouldn’t need to take advantage of native features, it wouldn’t need to compete in the marketplace and have the best performance or the highest security. For example, a company might build a hybrid app as an in-house tool for their staff. In this case, a first-class user experience is not really needed, since the purpose of the app is just to solve an internal need. Another example would be if you’re building a game. Then you can use something like Unity, which is what we used for Watercolors.

Need an app built and are still not sold on the benefits of native apps? Let’s talk more. Feel free to reach out to me at ancu@adonissoft.com.