What to Expect When You’re Expecting a Hybrid App




It seems like everyone has an opinion about hybrid apps, positive or negative.

What is a hybrid app?

Back in 2007, the first iPhone came out, and anyone who wanted to make an app wrote it using Objective-C with Apple’s tools. Then Android came out in 2008 and app developers started thinking, “Wow. Making a version of my app for Web, iOS, and Android is a real pain and costs a lot of money.”

Various groups had the same idea: what if we could just run the web version of our application as a mobile app on both iOS and Android?

On paper, this sounds great because it allows a single codebase to be maintained while still addressing all three target markets.

Seeing the theoretical benefits, many companies jumped on the bandwagon and released hybrid apps into production. Discovering the various cons of hybrid apps the hard way (by trying to support one in production) caused a backlash, which fuels the negative sentiment you often hear today.

Common Complaints About Hybrid Apps

  • Hybrid apps are slower than native apps
  • Hybrid apps have a significantly worse user experience, in terms of supporting smooth animations, gestures, etc.
  • Sharing the codebase of your web app sounds good in theory but is very difficult to actually accomplish because both platforms have specific needs
  • Sharing code between iOS and Android mostly works but still has a variety of quirks you have to handle on a per-platform basis

So should you just never build a hybrid app?

That list of cons looks scary. Does this mean you should just never build a hybrid app?

The true (but not very satisfying) answer is: it depends.

Some of the negativity is outdated

Two main categories of advancements have happened in recent years that make hybrid apps more viable:

  • Both iOS and Android devices are much better at running Javascript, HTML, and CSS quickly. For example, there are plenty of tricks you can now use that cause CSS animations to use near-native levels of performance simply because phone browsers are better than they used to be.
  • There’s a middle ground of transpiled hybrid apps now. “Transpiling” means to take code in one language and switch it over to a similar language (in other words, instead of compiling it to bytecode or assembly, you transpile it from one high-level language to another). In layman’s terms, this means you can still write your app using web technologies but it becomes pseudo-native iOS and Android code. Various frameworks do this to varying degrees – the most well known is React Native.

What capabilities does your app need?

If you need fancy animations, smooth infinite scrolling, complex graphical elements (e.g. games), etc., then you probably need a native app because the limited performance of hybrid apps just aren’t going to cut it.

On the other hand, if your app is mostly static content, a hybrid app may be workable. For example, Amazon’s app is mostly hybrid (with some native elements). It doesn’t have to do anything fancy but show images and copy, and power a relatively simple ecommerce platform, which makes it a great candidate for hybrid development.

What are people going to benchmark your app against?

A user’s opinion of the UX of an app comes almost entirely from comparison. If your app is Instagram for Something Else™, then all of your users are going to expect it to behave as fast as Instagram. If it doesn’t they’ll say, “it’s slow and clunky”.

You might also need to think about the stage your app is in. If you’re launching it as a prototype to validate your idea, you can get some leeway from your users if it’s a little slower.

What’s your budget?

It’s pretty much guaranteed that a native app will offer a better user experience, so if you have the budget for it and can see the ROI, you should almost always go that route. Most large apps that you use regularly are native for this reason – the Amazon app being the one notable exception.

What platforms do you have to support?

If you need to support web, iOS, and Android, then there’s more of a case for a hybrid app since you can share some amount of code between all three. On the other hand, if you can support only iOS (or iOS and Android, but not web), then the cost savings of the hybrid app approach lessen.


Hybrid apps aren’t always the best way to go but they can be a viable strategy to save budget and time. It’s important to understand what to expect when you’re expecting a hybrid app versus a native app, weighing the advantages and disadvantages. Ultimately, whether you choose to go hybrid or native, the most important thing is to build an app that serves its users and accomplishes your product business goals, whatever they might be.

Author: Allan, Co-Founder & CTO

Devetry partners with clients to identify critical needs and build custom software. Understanding client needs comes first. Choosing the right technology comes second. Learn more.