When it comes to mobile, native vs hybrid vs web is among the most common debates. The trade offs are not very complicated.

Native means you have to re-implement similar features across at least 2 platforms but likely a couple more. It also tends to mean you have some sort of shared back-end anyway that doesn't have any user interface but still provides a bunch of common APIs to persist and share data across platforms. It often requires 2 or more teams to handle all the multiple specific platform changes and peculiarities but it often provides a more natural and better experience for the users.

Web only tends to the easiest and quickest to achieve. HTML, CSS and JS are now decently standardized enough that the many mobile browsers around can handle a good chunk of what you need to generate a page that looks very similar across platforms. Those also tend to include the backend and the sharing. One platform for all. Obviously the look and feel won't quite match the user's usual platform but, then again, they likely have noticed it's only a website anyway. You also get limited when it comes to device specific hardware (camera, gyroscope, 3D accelerators, etc) and certain types of notifications.

Hybrid promises to be the middle ground that settles it all. And honestly, in a world that has more and better wireless connection, we're getting there. The small thin native shells that provide you access to those native capabilities and integrations. There are two magic glues. The first one is the web view or equivalent that allows your html structure to be rendered by the default browser on your device. Along with the web view comes the ability to invoke JavaScript functions which is the second glue. Now your native code can (if properly designed) inform your web code of things that happened on the device. The other way around is a little harder (replace your html structure with native elements) but is getting there.

For the first one, the beauty of firing events is the big magic. Whatever happens in the device on native code can simply trigger an event in JavaScript. Whoever listens to that event gets the appropriate notification and execution and you can easily shoot that back to the server. For example:

The second option requires a bit more work and craft on the web site. Pieces of your html structure as well as JavaScript need to allow for the native experience to overwrite the default web-experience. The easiest solution is an iframe as it allows the web view to reject making the request and consider it should host that address natively. It does, however, limit how much that piece of the page can share with the outside area as well as what is shown and how.

For now, I would say, my default go-to option would be the hybrid option to hook native events with javascript triggers and, therefore, define the interface façade that I support. Adding new devices means, if they only exist native events already known, is merely the work to ensure the native shell triggers those events. Add new events is a matter of ensuring the Javascript interface is well defined and then implementing the calls on the shell. If the shell doesn’t know how to react to the event, nothing happens and all continues along just fine.