The eternal question, what or when is better? Native Mobile ? Hybrid Mobile ?
Go on (these are my personal vision not sure to be "universal arguments"):
Language
Native Mobile: built using "serious langs" like Swift (iOS) or Java (Android). Serious means: statically typed, good OOP and speed.
Hybrid Mobile: based on the horrible JavaScript (weak types, bad OOP, not so quick than native langs), unfortunately if your application UI is sophisticated you must be ready to tons of clumsy JS. In pure Web you have GWT, Dart... to generate JS, in mobile web is a lot of harder to avoid JS.
UI Fidelity to Platform
Native Mobile: ready in your hands. Just using the default native components you get a perfect native UI look and feel.
Hybrid Mobile: you must use a mobile toolkit simulating native UIs and make two visual versions (iOS/Android) of parts of your app.
Access to the Native API
Native Mobile: direct and unlimited access (only security restrictions of the app are applied).
Hybrid Mobile: you must use a mobile toolkit because native access from JavaScript is not unlimited, for instance in Android the native (Java) methods to be called by JS code must be defined in a interface, this is the job of the mobile toolkit API. If you need a stronger integration be ready to program in native Java. In fact the term "hybrid" is used because many hybrid applications are really hybrid native-web, that is, some architectural elements are native (menues etc) and other parts web rendered. Some things are very annoying like the necessary asynchronous calling between JS and native code (for instance, in Android the JS code is executed in an exclusive thread different to the main thread).
Development Performance
Maybe this is the most opinionated item of this analysis.
In my opinion native development is by far more productive than hybrid thanks to the language, the tools, the natural native integration... Yes, you must make two (iOS/Android) apps, usually two teams. The performance of both teams surpasses in quality and development performance to the "one hybrid team". Some things can be reused like data management using a Java-Objective C generation tool like Google does. I recognize that if you need to support Windows Mobile the advantage is not so great.
Debugging/Testing
Native Mobile: native tools are fine enough.
Hybrid Mobile: debugging tools have been improved but not in the same level than native.
Version Management
In this subject we must differentiate between two types of hybrid applications:
Behavior/UI (HTML/JS) is mainly local. In essence the hybrid app is self-contained and is not different to a native app.
Behavior/UI is mainly remotely delivered. In essence the hybrid app is like a mobile web site packaged into a native app.
If your application is type 2 you are lucky, version management is by far easier than a native app, in a native app minor UI changes and behavior requires a new release and you must keep back compatibility with old versions because upgrading is a task of the end user. This is where hybrid development can shine.
I suspect Amazon Shop apps are of this type 2:
http://www.theserverside.com/news/2240174316/How-Amazon-discovered-hybrid-HTML5-Java-Android-app-development
"the most compelling reason to incorporate HTML5 into your mobile applications is to get the ability to update the app without requiring an upgrade on the device user's side. This capability makes it both easier and safer to manage apps -- permitting developers to roll out or draw back updates as needed. In the brave new world of continuous deployment and live testing, that's a huge advantage"
And by the way, this type 2 is the reason of ItsNat Droid development.
ItsNat Droid: native UI (and optionally behavior) delivered remotely.
Enjoy!
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}