Hybrid vs Mobile Web vs Native Applications: an Insider’s Look

Hybrid vs Mobile Web vs Native Applications: an Insider's Look

About two years ago I wanted to buy a microphone. As usual before the purchase I read a couple of reviews of the most popular models, figured out defining characteristics and visited website of the store, where I had decided to buy the device. I’ve chosen model M1 (the model’s name was changed in order to avoid being accused of advertising and product-placement). This model was available in two configurations: traditional option and a more expensive one with the USB-connection. Except for that, those two models were no different. Ok, let’s grab some money and go to the store. Both models were on display at the shop. So I managed to find a consultant and asked her to show me the microphone I had liked. “Would you consider buying this model?” she asked, pointing at that more expensive option with the USB. “Is it better in any way? I mean, as far as the sound quality goes?” After pondering about it, she replied: “Yes, definetely!”. My advice: don’t trust the sellers!

But who can we trust? If you want to purchase something, you’ll definitely have to deal with the sellers, who, unfortunately, aren’t experts in the field. In my opinion, there is only one way to solve this problem - to take the matter into your own hands and try to understand the subject, at least superficially, or to ask for a professional opinion. That’s exactly what I’m offering to do. The question we’ll try to answer is the following “Which applications - native or hybrid - are better for the mobile platforms?”

Hybrid vs Mobile Web vs Native

In order to start the research, let’s use a sure, well-tried way of googling the problem. Google will offer you dozens of articles painted with the same brush. All kinds of bloggers, programmers, managers, boosters, their mothers, managers’ grandmas and other people, who are “experts” in this area will try to tell you in an individual, interesting and funny way the following things:
  1. There are pure web apps that look almost like natives, for example, app.ft.com. They should be differentiated from the hybrid ones.

  2. Pure web applications do not work without connection.

  3. An interesting observation - it is easier to find the content of pure web apps. One will just have to type the necessary request into the search system and, if Google loves you, the user will see your site on the first page of search results.

  4. Another fascinating observation - hybrid and native applications must correspond to certain rules in order to be published in AppStore or GooglePlay. On the other hand, you can easily create a comfy app-site with gruesome content and eye-offending design and nobody will say a word.

  5. Creating hybrid applications demands less working hours than writing native ones, because the written code is usable for all of the platforms.

  6. Fewer developers are needed. Let’s just find a couple of solid guys, who know HTML and JavaScript, they’ll do everything. Otherwise you’d have to find Java, C#, C++, Objective-C developers and, what’s more, to pay all of them.

  7. Hybrid applications are cheaper to support, because, again, there is one code for all the platforms. Just change it in one place and you’re done.
  8. Native apps work much faster than web apps or hybrids.

  9. Native applications can work with every component of the device, whereas web and hybrid ones have limited access. For example, the ability of native apps to use cameras is something that is taken for granted. But you’d have to be really creative to make a hybrid one to take pictures with it.

  10. If we develop native applications, we’ll get a genuine UI for each platform. Hybrid and web applications can’t give you that.

Let’s tear the masks off

Seems like now we can tell the difference between hybrid and native applications, and it’s time to finish the article and go write some code. But no! As you remember, we can’t trust the sellers, and people, who’d listed all those points are sellers in one way or another. So, let’s do some more digging.

Web applications

The idea of a site that looks like an app is interesting. This approach has both some cons and definite pros. But there is one big question: “Why?” Picture yourself as a user who’s brain is not loaded with knowledge about IT. You open a site and…” OMG!” An app has opened. “What the hell is going on? This must be some virus stuff! But wait, why is the address bar of the browser visible? Is it some sort of website? Or an application? Hmm, it’s not in the list of installed apps. It works really slow. I think, I’ll rather use some regular app, not this non-identifiable something.”So, what’s the point of this mimicking? Why would you confuse the user? Because someone could truthfully believe, that it’s an app and expect it to behave correspondingly. To explain, I’d like to give an example: let’s take a rock, paint it as a football and then ask a football player with a broken leg, who had a pleasure of using it, for some feedback about our unique design solution.

Hybrid apps

Since I don’t have a rich experience in working with PhoneGap or other similar frameworks, I’ve decided to discuss this matter with our JS/HTML developer, who had written programs using PhoneGap. Turns out, as of today the majority of described problems has been solved. On this page a dressed up Dark Master promises us fast and painless click reaction. There is plenty of different plugins, which allow to gain access to multiple systems of the targeted device. And if something is missing, you can write your own. And you’d think that there it is - an excellent solution for cross-platform mobile app development! So, let’s investigate further.What kind of magical pills are those plugins that solve all the problems? Is this some sort of magic? Unfortunately, magic doesn’t exist in our world. At least in IT. Plugins are JavaScript wrappers over native Android or iOS code. Basically, PhoneGap is GUI, which is actually a web application, opened by WebView. The logical part of a program, performed by the plugins, which actually work with the native code by means of JavaScript, interacts with the device. Now, that we are aware of the components of a PhoneGap app, we can think about how it is going to work.
  1. What do you even know about pain?WebView for Android (version 4.3 and earlier) will function dreadfully slow, if you attempt to view something a bit more complicated than a text. Version 4.4 of WebView uses Chromium engine, that might improve the situation. Mostly, for PhoneGappers and others like them, attempting to launch an app on Android only causes pain and suffering. For iOS the situation is easier, because Safari engine is working slightly better.

  2. - Excuse me, are you a woman? - I’ll be whoever you want, baby. Different styles can be used for application interface in different devices. Sure, that’s great, but it doesn’t change the logic of the design. If there is a ”Go Back” button in iOS, then there will be one in Android, even though nobody actually expects it to be there. Another example — Actionbar. In iOS it is traditi?nally on the bottom of the screen, in Android it’s on the top. In a PhoneGap application the placement of the Actiobar won’t be changed. Whatever your device is, it’ll just look differently. One more thing: every OS has its specifics, like animation. Look at iOS and Android. Animation of transition from one screen to another is different! Hybrid apps won’t be able to recreate those special features.

  3. All of the problems are really in our heads - another important aspect, that, for some reason, isn’t taken into consideration by anybody. PhoneGap developers are usually the front-end ones. They have no idea of how the interface for Android or iOS should look like, because they haven’t seen style-guides. They know nothing about the platform specifics, because they haven’t read the documentation. But they’re good at creating websites. So, as a result, you’ll get an application that looks like a site. Is that what you need? Are you sure? Look at this picture. Are you still insisting?


  4. What are those..? Helpful Elves? Let’s move on to the plugins. They’re just pieces of code that solve some tasks. You can also use them in a native application. The problem is that your app has to solve a bit different tasks, than the ones those pieces of code do. This means they’d have to be changed, but who’s going to do that? Your developer only knows JavaScript and HTML. Another subtlety is combining plugins from different developers. If plugins work in contiguous fields, they’ll be able to use the same components, which can lead to having quite interesting side effects. And to give plugins the last dig, I’d have to say, that a lot of them aren’t very popular - which means they barely have been tested. Be prepared to test them yourself.All in all, what am I trying to say? Cross-platformity, in this case, is illusional, and the apps are going to look weird. Hybrid applications should be perceived as prototypes, used for evaluation of customers’ reaction and receiving some feedback, I think. It’s better to use native apps for production version. Those discourses are proper for all of the hybrids that are based on combination of HTML/JS.


I’m not going to write a lot about the native ones, because it’s pretty clear. They work fast, look good, have broad customization possibilities. But with all those features comes a different price. Though the first three points are applicable unless you’ve hired a team of great professionals from New Delhi.

True cross-platformity

In my opinion, the only framework, that could really allow you to write a cross-platform application today is C++ Qt. This framework can generate native Android code using Android NDK, i. e. productivity, in theory, must be at the level of the code, written by a programmer with the help of Android SDK. As for the fragments with even higher calculations, NDK is used. Qt is a quality, well tested library, which means you won’t have to deal with any non-related bugs in the process. If problems appear, you can take a look at the Qt initials - that is a really useful feature for the developers, sometimes the only way to defeat the bug. In order to get a program for the required platform (Android or iOS), you’ll just have to recompile the initials. Though, as far as I’m concerned, sometimes you’d still have to write some native code for the platform, because not all of the facilities are available from the Qt library. I hope this will be corrected soon. There are also cons: you’ll have to buy a license, if you want to use Qt for the production version, which means spending money. For beginner developers it’s a real problem. As of today, Qt is a bit raw for mobile development. Let’s wait for the next releases.


At this moment there is no solution that we could fair and square call a true cross-platform environment for mobile app development. Maybe, in the future Qt will take this place, but currently it’s vacant. To test your idea by developing a prototype you totally can use JS/HTML frameworks, but I wouldn’t recommend them for development of complicated production apps. In this respect, native applications are second to none.

Kirill B.
November 27, 2017
Everything You Want to Know About Mobile App Development App Development Calculator Infographics: Magora development process Dictionary
News Technologies Design Business Development
Logo Magora LTD
Thank you very much.
Magora team

Grab your e-book: Development to attract more buyers

Logo Magora LTD
Get in touch
Do you agree to the personal data processing?

Logo Magora LTD
Thank you very much.

Your registration to the webinar on the 27th of September at 2 p.m. BST was successfuly completed.
We will send you a reminder on the day before the event.
Magora team
Registration for a webinar

"Let Smart Bots Speed up your Business"
Date: 27.09.2018 Time: 2 p.m. BST
Do you agree to the personal data processing?