Thanks for sharing!

With a team of 2 x UX, 1 x Design, and ~10 Engineers I was able to create a Web App that used WebRTC in Production in ~<6 months. On devices that we knew where WebRTC was flakey, we directed the user to download a native app (Electron, iOS, Android). This native app rendered the same Web GUI however did not use clientside WebRTC. We rendered the web view on a transparent ChromeView or WKWebView and used WebRTC natively. This allowed us to have a common GUI, UX, and use WebRTC where it was stable.

Slowly over time and with usage metrics we were able to slowly add basic WebRTC functionality to Safari based experiences once we strengthened the code and made experiences more deterministic. This was primarily only around camera access vs P2P video chats.

getUserMedia does not work in WKWebView-based browsers:

https://bugs.webkit.org/show_bug.cgi?id=208667

getUserMedia working in Standalone mode:

https://bugs.webkit.org/show_bug.cgi?id=185448#c6

getUserMedia working in SFSafariViewController:

https://bugs.webkit.org/show_bug.cgi?id=183201

Sometimes it isn’t about size. There are some use cases that work better in a web experience than in an app. Especially for one-time and infrequent users. For them. the hassles of installing an app might mean losing them altogether.

If you are not a big company you usually go with the web app version so that you can avoid having to develop & support two different mobile ecosystems (Android & iOS). Therefore I can understand why some clients might be put off by that initially.

Nathan, I am more of an Android person, so don’t have Apple devices at easy reach. Haven’t tried iOS 14 or heard feedback about it yet.