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

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

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

Web applications

Hybrid apps

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.

Native

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.

Conclusion

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.