As developers ourselves, we have been debating about this for … as long as the term, “Hybrid Mobile Development”, first appeared. “Framework”, in general, is a term of getting things up and running less painful, a bit faster, and easier to maintain; also, it provides powerful tools for devs to utilize. However, it’s a bit misleading in this context though. Why? Because the underneath technology powered the frameworks are different (web framework vs mobile framework).
Hybrid Mobile Framework
First, we want to be clear that we are not going too deep onto the framework itself but rather provide a general idea of what that is and how that works.
How Does Hybrid Mobile Framework Work?
As we just mentioned in the previous paragraph, “Hybrid approach” eliminated the step which is learning another platform specific language to create apps. For instance, traditionally if you want to make an iOS app, you need to learn Swift programming language (previously Objective-C language). The same applies to android apps that if you want to make any android apps, you will need to stuff yourself into the Java programming language world. But because of the Hybrid mobile frameworks such as PhoneGap, ionic, and React Native (this one is sort of in between though), companies are able to further utilize their in-house web developers’ skill sets to get their mobile apps up and running fast and cost effectively.
One of the Major Differences (our opinion) Between Hybrid and Native approach
It’s the UI (User Interface) design. We brought up the cross-platform design feature but we did not stress that enough. Let’s talk about it here. If you choose to use native to create apps, chances are you will spend a big (we mean … BIG) chunk of time on designing and creating your mobile apps UI components. It is critical for any mobile apps to succeed in the mobile world. UI draws a line between (hopefully potential) success and a certain death of your app. Take Apple’s marketing slogan that “There is an app for that”. The mobile app war is much fierce than anyone can imagine. It’s not solely because of the threshold of getting into it but also because the freedom to update apps and put apps in front of target audiences. If you think web apps battlefield is bloody, you shouldn’t even think of getting into mobile battleground.
Basically, if you have more than 3 months to 6 months (full time) to develop, test, and push your app to the market, native approach might be into the consideration. Why? Put android devices aside, you need to make your UI works on, at least, 8 different screen sizes of iPhones and iPads. Each single UI component is critical to the success of your mobile strategy. Buttons fit on iPhone 8 might not fit on iPhone X or iPad mini or 12.9″ iPad Pro. Even if they fit, the margins among those buttons might seem weird and totally spoil the entire user experience. And if you include all the android devices, good luck on that if you think you have time to go native on your own. The rule of thumb here is that native mobile development is a no-brainer for corporations having resources and labors to take. However, if you are a one man team (still a team in a way) but you still want to do so, you should have a laser focus. Meaning that you should not spread yourself too thin on making and maintaining multiple apps on different mobile platforms. One app and one platform at a time. If you want to expand to another platform, you should hire another dev for that (or partner up with another dev who is an expert on your targeted platform).
if you include all the android devices, good luck on that if you think you have time to go native on your own
If you do NOT have the privilege to wait for 3 to 6 months, you should SERIOUSLY consider taking the hybrid mobile dev approach (why only considering? because there are apps which should go native only such as gaming apps or heaving rendering applications). Those leading hybrid mobile frameworks provide basic (great) UI components and, most importantly, you really rarely need to deal with the UI layout of your apps on different sized devices. Furthermore, the debugging level can be instantaneous if you don’t use device level hardware feature such as camera, gps, …etc.
Of course, there are some drawbacks; otherwise, everyone would have already gone hybrid. We are going to just point a few of them out here and list some major disadvantages on the next section.
Using hybrid can shorten dev cycle and reduce dev cost drastically but also you will face some major performance issue if your app uses lots of heavy graphic renderings. Another weakness is that you won’t have the total control of the UI or the whole application’s detailed behaviors in general since a hybrid mobile app is NOT a really device level mobile app. What hybrid framework does is that it wraps your app within a webview which is a browser view. Therefore, users aren’t really interacting with mobile device components. Users are actually interacting with web components wrapped in a browser view acting like a mobile app (view). Some limitations here which is that the keyboard function (interaction) won’t be able to be changed compared with if you develop your app via native approach. Also, the view detailed interactions to the minute level such as a view within another view (image) then creating some animations to make UI experience even better. All of those attention to details stuff won’t be able to be easily done if you choose hybrid. Another major issue is that whenever iOS or Android releases next version OS, there are higher chances that your apps will break and you can do NOTHING about that since it’s on the framework level you will need to wait until your chosen framework update its core codes and then you can update your apps accordingly.
What hybrid framework does is that it wraps your app within a webview which is a browser view.
Sometimes some unseen and unusual bugs occur after the OS upgrades (e.g., Safari fails to decode Base64 images using iOS 11 when the iOS 11 first released) and either you or your chosen framework can fix. At that point, you really are a sitting duck to your clients (they will be coming after you. They don’t care how you make your apps and which level bugs are produced. They only know that you are the one who made it work or not).
The Pros & Cons Compared with Native Approach
We are going to just scratch the surface of this since most of our audiences aren’t in dev so there is really no reason to go deeper.
* Fast dev cycle & Quick to the market * Low cost * Low entry point - threshold usually isn't that high (react native is a bit different though) * Cross-Platform
* Performance * Hardware control * Device level component control * Freedom on the design (UI components) * New features are slow to the market (since you don't code natively, you need to rely on your framework or 3rd party plugins to bring new features to you)
* Performance (since it's directly interact with all the hardware components, the performance just cannot be compared with) * Freedom of design (complete device integration) * Better user experience * New features to the market * Support from platform directly * Better coding environment (e.g., XCode)
* Longer dev cycle * Higher cost * Platform dependent * Dealing with all different sizes devices
We were thinking of writing another section for “should you go hybrid?” However, we decided to get that included into the summary since that’s the usual place readers generally look for answers. Hence, we are going to tell you that you should go hybrid if you are “blank (explaining below)”. And you should pick native if you are “blank (explaining below)”.
You should go hybrid on mobile dev if your app aren’t having too much device level hardware interactions.
You should go hybrid on mobile dev if your app aren’t having too much device level hardware interactions. Also, if your apps are the general business apps such as corporation website access that sort of stuff, you really should use hybrid to get your mobile apps up and running. We talked about the performance issue with hybrid mobile apps above. But the truth is that the technology advanced too fast that the hardware restrains are almost being reduced to a minimum human noticeable level that if you use the modern smartphones (which most of us do), you really can’t tell the difference between hybrid and native. Or, we should say that, you won’t care that much since a 0.01 second delay really won’t bother you.
You should pick native approach if you care about UI design (also user experience), you want to have the tightest device integration on the UI level, or you are into gaming app dev.
You should pick native approach if you care about UI design (also user experience), you want to have the tightest device integration on the UI level, or you are into gaming app dev. All of such really cannot be solved simply by putting more hours on hybrid end of the spectrum. You can only go native to get those jobs done and, trust us, it will be well worth it since you won’t need to wait for 3rd parties to make new features which just being releases by iOS or Android available for you. Also, you can make almost any modifications you want on the UI components… meaning that you can certainly apply your creativity to make a beautiful mobile app if you know how to.