Recently I had a great chat at a WWDC WebKit lab about app-bound domains and our special use case. I have an app where the user enters the domain/URL to a server the app should connect to. The server could be a dedicated backend server installed at the customers site. The employees of the customer download the app from the App Store and enter the URL given to them by their administrators. The app now connects only to this particular server. I now want to use app-bound domains for this use case, too. Right now I can set up to 10 app-bound at build time. This does not help for my kind of app because the domains need to be set at runtime and some apps, like enterprise apps with on-premise servers, might not know them at this point. What if WebKit would offer an API (possibly with a system prompt, setting etc.) to set an app-bound domain as soon the app gets the domain it needs to connect to by the user? Having this one domain the app connects to exclusively as an app-bound domain would offer benefits, like no ITP issues, security measures etc. I really like the idea of a "trusted domain" which get's more freedom for WKWebView apps and offers privacy and security for users. The app should only connect to the domain given by the user. Apps that are not web browser but use WKWebView to display content from local web files (Cordova, Capacitor etc.) have many stumbling blocks because of weird CORS and ITP behaviors right now. For these apps slightly less strict CORS restrictions with custom schemes could possibly help many developers, too. I would love to talk more about this and discuss ideas to make lives easier for developers using WebKit in apps like this.
Thanks for filing, Niklas! Cc’ing a couple of coworkers.
Kate and Brent, Niklas and I chatted about this during this year’s labs and I think the idea of being able to set one app-bound domain dynamically is interesting. It would allow apps to be tied to an install-time/first launch user choice service without busting out of the intended behavior of app-bound domains. There might be technical hurdles for such a write-once feature but still. I envision the state to be cleared on app uninstall as an escape hatch for a device you want to reassign to a different service.
Interesting use case! As long as we limit it to be set on first launch and not be dynamic after that, I think this is feasible.
Thank you for your comments. Having some option for dynamic app bound domains would be great. This dynamic (first launch) domain should be added be added to the fixed lists of domains right? I am thinking about Cordova, Capacitor apps than use WKURLSchemeHandler to run their local page on a custom scheme like app://myapp and connect to one external server like https://mybackend.com. This would be typical use case for "hybrid apps". If the dynamic domain gets set on first launch by the application, I think there are two things to consider for the use case in my mind. 1 .We have an enterprise app where users add the URL for their companies system during the initial setup. Setting the app-bound domain should be available via an API the app calls after the user has entered their setup information. 2. Most users will forever use this one server. Some users like developers, administrators etc. may need to reconfigure their app to use a different server like a testing instance of the backend. There should be a way to reset the dynamic app-bound domain like a system setting, prompt etc. Otherwise this would require such users to reinstall the app. I hope this brings a perspective for uses cases of this feature.
(In reply to Niklas Merz from comment #4) > Thank you for your comments. Having some option for dynamic app bound > domains would be great. > > This dynamic (first launch) domain should be added be added to the fixed > lists of domains right? I am thinking about Cordova, Capacitor apps than use > WKURLSchemeHandler to run their local page on a custom scheme like > app://myapp and connect to one external server like https://mybackend.com. > This would be typical use case for "hybrid apps". > You may already be aware, but note that custom schemes can be added to the Info.plist as well so that all local page loads for that scheme will be app-bound. > > If the dynamic domain gets set on first launch by the application, I think > there are two things to consider for the use case in my mind. > > 1 .We have an enterprise app where users add the URL for their companies > system during the initial setup. Setting the app-bound domain should be > available via an API the app calls after the user has entered their setup > information. > > 2. Most users will forever use this one server. Some users like developers, > administrators etc. may need to reconfigure their app to use a different > server like a testing instance of the backend. There should be a way to > reset the dynamic app-bound domain like a system setting, prompt etc. > Otherwise this would require such users to reinstall the app. > > I hope this brings a perspective for uses cases of this feature. Thank you for taking the time to specify additional details, this gives helpful insight into the needs of your app and others like it. We will keep all of this in mind as it seems to align with intended behavior of app bound domains.
<rdar://problem/79813565>
We also described & discussed this issues in the W3C WebView community group here: https://webview-cg.github.io/usage-and-challenges/#the-origin-in-a-webview-for-locally-hosted-content