You may try as well using App-Bound Domains to have Service Workers available for your specific domain.

Storing cookies also might depend on which configuration do you use and what type of cookie do you save(session or persistent). Please share all the code specially where you create WKWebView and which exact cookie object do you set?

Usually in such cases you want to add tokens as a cookie attached to request, in that case you need to save that cookie to WKWebView first and then load page. At this point question is what your server expects? In which way that token must be passed? p.s. Those delegate methods that you mentioned are designed to be invoked only for main resources like HTML pages and iframes so they are useless for sub-requests interception.

Hi! Service Workers are not available for WKWebView, except if your app has web browser entitlement. You may try to use regular Workers instead and store data in IndexedDB, LocalStorage or Cookies. Read here about Service Workers in WKWebView: https://forums.developer.apple.com/forums/thread/722160

No, it is not possible to run Chrome or Chromium headless on iOS, because there are no real browser on iOS except Safari, rest of the "browsers" are using WKWebView to render HTML content. We might help you to solve your problem in another way if you give us a bit more context: why do want to run Puppeteer inside WebView?

As far as I know there are no way to enable Service Worker inside WKWebView unless you enable Web Browser entitlement for your application, at least this is the situation at current moment. See here for more details about Web Browser entitlement: https://developer.apple.com/documentation/xcode/preparing-your-app-to-be-the-default-browser-or-email-client

Hello, "webViewWebContentProcessDidTerminate:" call is not always related to memory usage and I'd first try to detect more or less reliable steps to reproduce the issue and then implement "- (void)_webView:(WKWebView *)webView webContentProcessDidTerminateWithReason:(int)reason" instead of "webViewWebContentProcessDidTerminate:". This is a private method and you shoundn't be using it in release apps since it wasn't designed for any WKWebView app. It is documented in WebKit's Github repo, look for WKNavigationDelegatePrivate.h file. The reason why you may want to use is that it specifies reason of the WebKit termination, and once you confirm that this is memory crash, you will have zero in reason variable, then you should proceed with attempts to reduce memory usage, but if it is just regular crash, reason will be 3, then you need to find WebKit's crash log, and from that point continue your investigation, depending on call stack.

Per my understanding, this is not possible or at least shouldn't be possible because it would violate Apple's user privacy since you as a developer would know that certain application is installed on the device. Think about it in such a way: if Google is not doing it in their applications to detect whether Chrome is set as default browser why would I do that? You may look into Firefox for iOS source code for more details if you need to display any message to user asking him/her to set your browser as default to get some inspiration but I am pretty sure that they and other browser-implementing guys haven't found any meaningful answer to your question. FireFox iOS sources: https://github.com/mozilla-mobile/firefox-ios Chromium sources: https://chromium.googlesource.com/chromium/src.git/+/master/ios/

Hi @tininhaasa Have you tried to connect Safari debugger to your application and see whether there are some issues with JavaScript?

@huangzhikai, What do you mean by "third-party browsers"? I have tried on the most popular "third-party browsers" for iOS: Chrome for iOS and Firefox for iOS. The result is the same as in our browser: they are not displayed in the Desktop Safari Developer menu. Looks like something missing either in WebKit or in iOS browsers code. p.s. This time I tested on iOS 16.0 developer beta 3(20A5312g) with both Desktop Safari 15.5 (17613.2.7.1.8) and Desktop Safari Technology Preview Release 148 (Safari 16.0, WebKit 17614.1.17.1)

WKURLSchemeHandler is not designed to handle "http" and "https" schemes and you are doing this at your own risk. WebKit's documentation clearly says that all the methods of WebKit have to be called from main thread, that is not a case for you, as I see from screenshot. Always call WebKit functions and methods from your app’s main thread or main dispatch queue. Moving dealloc call to main thread may resolve your issue.