I switched to Android after 7 years of iOS

> The user experience is similar to webcam/microphone access

What happens behind the scenes is not. The microphone and webcam are far easier to secure because they just provide data streams if authorized and the web browser can provide a visual cue when it is in use. Some webcams even have a light to indicate when they are I use. Although that might not be perfect, it is far better than things like browser plugins.

Bluetooth is another story. With WebBluetooth, you are effectively providing access to an Advanced Persistent Threat attack vector. That takes things to a whole different level for black hats. If it is widely adopted, someone somewhere will find a way to target it as compromising the firmware of paired Bluetooth devices should be easier than typical escape from sandbox attacks. How long it takes for us to hear about it is another story.

> Access through web browsers could expose issues in the user's kernel bluetooth stack, but that risk exists with any binding. There should be time to explore this possibility while the feature is still behind a flag

Whether WebBluetooth can attack the Bluetooth stack directly is irrelevant. What matters is the embedded device's Bluetooth stack. Allowing a web site to dictate the contents of an otherwise legitimate communication with an embedded device's Bluetooth stack allows it to compromised with no compromise of the machine required.

Running exploits against the embedded device should just requires gaining control of a webserver hosting a site that the browser permits to use webbluetooth or injecting code through a XSS attack. If the embedded device allows firmware updates over bluetooth, getting malicious code onto it is easy. If not, the embedded code that communicates with a paired device should have been written under the assumption that the other end would not try anything malicious and consequently, it should have vulnerabilities.

Regardless of how a blackhat gets into a paired bluetooth device, once they are inside, they have code execution on the opposite side of the surface typically attacked on modern computers.

I have to say that I'm all for web apps and web based apps using things like Cordova or what not, but recently my company's app has been hitting some walls. There are a lot of great things those systems can do and they're great for starting out. However in the long run you might as well consider developing native or developing using something Xaramin (which will probably be even more free soon). Native development just provides a less kludgy of developing. My company will be making the switch soon in this light.

EDIT: I'd also like to say that the reason it's tough to develop for the web is languages like Javascript, sure it's getting better very slowly, but it also doesn't really allow for other languages to run in the browser and probably won't in the future. Sure you can compile, but why compile to JS and use a web view and work around conflicts while developing an app, when you can use a typed language and access APIs that work?

"This app provides the functionality I require" is a pretty meagre goal. The idea of native apps using a platform's native support is that users come into your app already knowing how to use most of it, having learned the platform conventions.

If every app is a cross-platform web app, what's the point in having more than one platform?

There aren't any programs that do the same thing without rooting. Android doesn't have any APIs that allow you to change the color temperature, so all of the non-root apps just add a transparent red overlay on top of the screen.

I know this area well since it's one thing I was really looking forward to when I got an Android phone and I was very disappointed.

TLDR: Chrome on Android supports Service Workers and WebRTC while Safari on iOS does not. This means Android these days is better suited for fully-fledged web applications that do not require a native app (or at least a native app wrapper).