My team delivers both native and non-native applications - generally the answer to this question is dictated by three separate considerations 1) what are the core pieces of functionality required for the user? 2) what are the resource realities you are facing (i.e. budget and timeline)? and 3) what is your access to recruiting native mobile developers.

You are correct that the first and most important impact a non-native application has is on user experience. pagination, the swiping feature and all of that other rich mobile UX cannot be replicated on a non-native system. UX driven mobile applications are by nature of their layout more inclined to be better supported on a native platform.

The second point you bring up is the consideration of utilizing native device functionality (Bluetooth, Camera/Library, Contacts, GPS etc) - as of right now there are ways to integrate with several of the native hardware features in an non-native environment, however their actual working integration can be a little jerky and in most cases does not fully replicate the actual phone functionality you would get in a standard native mobile app.

Importantly there is another consideration to make for dictating the native vs non-native app decision: that is the need for any level of offline functionality of caching. Being a browser-driven experience, a user not having wifi access or reliable cell network connectivity makes accessing your application either time consuming due to delay on loading content, or impossible if truly offline. So caching content and offline access a lot of times become a major factor as to whether non-native is even possible for an application.

One other bonus point to consider: analytics - going native gives you a fairly usable and ready-made dashboard for base-level analytics on your app (just log into your developer account and start consuming download and utilization data) - your options for non-native analytics are more limited, at least for what you got out of the box (usually Google Analytics is the best bet there.)

Overall there is a fairly quick checklist of items you can walk through and get a quick indication to what extent (or not) non-native is a solution or option. My general preference is to lean towards native (look at Facebook and LinkedIn as good case studies - both launched non-native first and quickly realized they had to go native to be relevant and get the MAU they wanted); but i would do a quick analysis and put some thought behind detailing scope/options from there.

Happy to carve out time for a call and walk through details of your functional requirements and see if/how native or non-native solutions would be the best path forward. Just request a call time and we can touch base from there!