1. Even Android 4+ devices that support Chrome sold in major carrier stores still have Android browser as the default (which means that most users will use it)
2. Even in Android 4.2 WebView is based on default browser, meaning that any hybrid Android app does not have WebSockets built in.
This is the main reason why WebSockets are not ready for production.
Haven't used SignalR but we've tried Socket.IO and SockJS for that, and have found SockJS to be absolutely awesome in production.
We're running an in-browser vt100 terminal, Tornado with a SockJS plugin on the backend, round-tripping every keystroke and output from the processes on the server and when SockJS uses WebSockets we get near-ssh responsiveness -- you can run vim just fine. Things are less good but still definitely usable (at least on the command line, vim can be a little frustrating) when it fails over to other protocols.
No serious issues -- Socket.IO was really good. But SockJS was noticeably faster, and we saw fewer cases where things arrived out-of-order -- blog post here: http://blog.pythonanywhere.com/27/
Also, IIRC the code we had to write to handle reconnects on patchy connections with SocketIO was pretty gruesome. The problem was that if the connection dropped, it would fail down from WebSockets through various polling systems (which is correct behaviour) but would then stop at the last failover option and never recover, even when the connection came back up. We poked around in the code trying to work out how to change this, but found it too confusing. SockJS didn't have this problem, and we also found the code a bit easier to read, at least from a fairly shallow overview.
This is the main reason why WebSockets are not ready for production.