Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Implement App-Bound Domains to enable Service Workers in WKWebView on iOS14+ #4122

Closed
jgoux opened this issue Jan 27, 2021 · 8 comments

Comments

@jgoux
Copy link

jgoux commented Jan 27, 2021

Feature Request

Description

Since iOS14, it's possible to make service workers works in WKWebView by providing a list of trusted domains (up to 10).
These domains then gain support for service workers, which is invaluable for us as we plan to use server.url in production to distribute our PWA on iOS.

Here are links describing the possibilities and features :

Platform(s)

  • iOS

Preferred Solution

I think being able to pass the domain list with capacitor's config file would be enough. Then capacitor could patch the Info.plist file with the domains, and build the WKWebView using the snippet provided in the first post I shared above :

let configuration = WKWebViewConfiguration()
configuration.limitsNavigationsToAppBoundDomains = true
// Create a WebView with this configuration

Alternatives

As of today I don't think there is any alternative to support service workers in WKWebView

Additional Context

@ikeith
Copy link
Contributor

ikeith commented Jan 29, 2021

Patching the Info.plist file to keep it in sync with the capacitor config goes against the spirit of capacitor, which tries to leave the native projects alone after creation so that you are free to modify it as you see fit.

But, enabling app bound domains is totally possible in Capacitor 3.0. If you add the domains to the Info.plist and subclass CAPBridgeViewController, you can then override webViewConfiguration(for:) to modify the configuration before the web view gets created.

It should be noted, however, that shipping a server.url configuration to the App Store is not advised.

@jgoux
Copy link
Author

jgoux commented Feb 1, 2021

Thanks for the info @ikeith !

If I want to subclass CAPBridgeViewController, where do the subclass file would live? Does it have to be part of a Plugin?

Also for the server.url, we know that's not advised but we'll take the risk as it's the easiest path in our case. If we fail the App Store validation then we'll reconsider.

@ikeith
Copy link
Contributor

ikeith commented Feb 3, 2021

@jgoux The subclass would not be part of a plugin but belong to the containing native app. So it would live alongside AppDelegate, Info.plist, etc.

@ikeith ikeith closed this as completed Feb 6, 2021
@jcesarmobile
Copy link
Member

we are adding limitsNavigationsToAppBoundDomains configuration option from the capacitor configuration file, see #4789

@webuniverseio
Copy link

webuniverseio commented Nov 24, 2021

@ikeith you mentioned that server.url in production is not advised, why is that? With live webview & service workers you're solving multiple problems - you get proper https:// protocol which avoids problems with recaptcha and google analytics which don't work out of the box with non standard protocols. You avoid issues with any 3rd party services which use //domain.com/path urls. Various 3rd party url parsers don't break or act weird. You get cookie support which may be an impossible issue to solve for 3rd party. After first load app can work offline due to Service Workers support.

Edit: This is where it was introduced I asked for clarification 7861b80#r756466909

@webuniverseio
Copy link

@jgoux would it be possible for you to share your experience with live server.url and AppStore release? I definitely know of some apps which have live webviews and are successful at it

@thomasvidas
Copy link
Contributor

FYI, Ian no longer works at Ionic so he probably won't answer 😄. To answer your question, here's why we do not advise using a live server.url:

  • Capacitor apps lose the secure context for several web apis. In the config docs we list a few if you scroll down to the server.url option.
  • Apple has rejected apps that point to a live URL. Apple's (and Google's) app review process is pretty opaque so it's hard to know exactly why they may reject one app that does this and approve another app. But in general, Apple is pretty clear that if your application is just an existing version of a website bundled in an app, they may reject it.
  • It is bad UX to point to an external server since if a user does not have internet access there is no functionality. By pointing to a localhost, the files are on the device. Meaning that even if your user has no internet access, the app is still functional.

@ionitron-bot
Copy link

ionitron-bot bot commented Nov 10, 2022

Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Capacitor, please create a new issue and ensure the template is fully filled out.

@ionitron-bot ionitron-bot bot locked and limited conversation to collaborators Nov 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants