DZone
Mobile Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Mobile Zone > Native Mobile vs. Hybrid Mobile: The Eternal Question

Native Mobile vs. Hybrid Mobile: The Eternal Question

The debate over native mobile and hybrid rages on. Learn about the pros and cons of both native apps and hybrid apps in the world of mobile tech.

Jose Maria Arranz user avatar by
Jose Maria Arranz
·
Jul. 15, 15 · Mobile Zone · Opinion
Like (1)
Save
Tweet
3.86K Views

Join the DZone community and get the full member experience.

Join For Free

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:

  1. Behavior/UI (HTML/JS) is mainly local. In essence the hybrid app is self-contained and is not different to a native app.

  2. 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!

mobile app

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Automatically Creating Microservices Architecture Diagrams
  • Selenium vs Cypress: Does Cypress Replace Selenium?
  • The Differences You Should Know About Java and Python
  • Trending Programming Language to Learn

Comments

Mobile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo