Hello Apple Developer Community, I currently have a Safari Web Extension on iOS that blocks certain URLs for users. I would like to provide the same functionality for Chrome on iOS. I understand that Chrome on iOS uses WebKit under the hood, and Safari Web Extensions can run in Safari, but I am unsure whether there is any way to implement URL blocking in Chrome for iOS—either via an extension, API, or other supported mechanism. Specifically, I’m looking for guidance on: Whether any browser extension (Safari, Chrome, or otherwise) can intercept or block web requests in Chrome on iOS. If not, what Apple-supported alternatives exist for implementing URL-blocking functionality for users of Chrome on iOS. Any best practices for maintaining a cross-browser URL-blocking solution for iOS users. I want to make sure my approach is aligned with Apple’s policies and platform capabilities. Any guidance or official references would be greatly appreciated. Thank you!

Summary: We are facing a serious issue on iPhone where multiple passkey authentication problems occur when accessing passkey-enabled login pages via shortcuts placed on the iPhone Home Screen. These issues may also occur when opening the same pages directly in a standard browser window. However, launching the login pages from a Home Screen shortcut appears to increase the likelihood of encountering these issues. Affected Services (examples, not exhaustive): Amazon GitHub Adobe Observed Issues: Issue 1: A passkey authentication dialog/popup shows two times without any user operation: What happens due to this issue: Login does not complete after the first passkey authentication. A second passkey authentication UI automatically appears. Completing or canceling the second authentication allows the login to proceed. Issue 2: Login remains stuck until the user manually invokes passkey again What happens due to this issue: The login page does not advance after the first authentication. The user must tap the ID/username field again to manually trigger the passkey UI. Completing the second authentication enables login. Issue 3: Automatic second authentication occurs, but login still fails What happens due to this issue: A second automatic authentication UI appears. Login still does not complete. Tapping the ID field no longer opens the passkey UI; instead, the password auto-fill panel appears. Passkey login becomes impossible. Observed reproduction steps (not guaranteed but most consistently observed): On iPhone, navigate to a passkey-enabled login page (e.g., Amazon, GitHub, Adobe) using a browser. Create a shortcut from the browser's share menu and place it on the Home Screen. Launch the login page from the Home Screen shortcut. Tap the ID/username field to invoke the passkey prompt. Complete passkey authentication. → One of the issues described above occurs. Environment: Device: iPhone SE OS: iOS 18.6.2

aID is an ID service for 150+ newspaper sites in Norway. Since the middle of January the average login time with passkeys on our site https://www.aid.no/ has increased for Safari users, the number of logins using passkey in Safari has decreased dramatically. Previously Safari was the browser that provided the best user experience during login, since it triggered fingerprint reader straight away, but this behavior has vanished. Has something changed that we should be aware of, and is there something we can do to make conditional get great again? Without mediation conditional, the passkeys work as expected. In Chrome and Firefox, we get passkey suggestions in the username field, in Safari it's only password suggestions. To make things even stranger, the same code works as it used to in our test environment. It triggers a small popup by the username field and activates the fingerprint reader. If I cancel this, I can click on the Passwords icon and get passkey suggestion there.

Hello, After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project). Observed behavior On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return. This happens not only for: evaluateJavaScript("navigator.userAgent") but also for simple or even empty scripts, for example: evaluateJavaScript("") On previous macOS versions, the same calls typically returned in ~200 ms. Additional testing I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls. In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2. Question Is this a known issue or regression related to: iOS Apps on Mac, Swift + WKWebView, or behavioral changes in evaluateJavaScript on macOS 26.2? Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated. Thank you. Test Code Swift class ViewController: UIViewController { private var tmpWebView: WKWebView? override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. setupUserAgent() } func setupUserAgent() { let t1 = CACurrentMediaTime() tmpWebView = WKWebView(frame: .zero) tmpWebView?.isInspectable = true tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in let t2 = CACurrentMediaTime() print("[getUserAgent] \(t2 - t1)s") self?.tmpWebView = nil } } } Test Code Objective-C - (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions { NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970]; WKWebView *webView = [[WKWebView alloc] init]; dispatch_async(dispatch_get_main_queue(), ^{ [webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) { NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970]; NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime)); }]; }); }

Hi, after upgrading MacOS (MB Air M1 Version 26.2 (25C56)) & Safari (Version 26.2 (21623.1.14.11.9)) to latest versions, we are experiencing a new bug occurring with our web extension (Click & Read) on local storage writing and getting this error : Invalid call to browser.storage.local.set(). Disk I/O error. This doesn't happen on other browsers (chromium, Firefox). export const setLocalStorage = async (value: object) => { try { await browser.storage.local.set(value); } catch (error) { console.error("[Click & Read] Error setting local storage", error); } };

Hello everyone, I am currently working on integrating a WebView into my macOS application, intended to allow users to browse tutorial webpages directly within the app. Although I’ve followed an example that appears syntactically correct, the WebView does not render any webpage content. Below is a code snippet for reference: import SwiftUI import WebKit struct HelpWebView: View { @State private var toggle = false @State private var page = WebPage() private var url: URL { toggle ? URL(string: "https://www.webkit.org")! : URL(string: "https://www.swift.org")! } var body: some View { WebView(page) .onAppear { page.load(URLRequest(url: url)) } .onChange(of: toggle) { page.load(URLRequest(url: url)) } .toolbar { Button("Reload", systemImage: "arrow.clockwise") { toggle.toggle() } } } } I would greatly appreciate any insights or suggestions on what might be causing this issue or how to resolve it. Thank you in advance for your help!

I have an iOS app that generates and renders a custom HTML document inside a UIWebView. After updating a device to iOS 26, the same HTML is rendered with noticeably smaller fonts compared to previous iOS versions. No code or HTML changes were made. Context HTML is generated dynamically and rendered in a UIWebView The HTML is embedded inside a custom XML wrapper The issue happens only on iOS 26 Earlier iOS versions render the font size correctly

Hello, why is Safari blocking my domains? https://fitgel.ru https://fittoma.ru https://ohota.pro There are no errors in them, other browsers respond normally.

Hello everyone, I am currently working on integrating a WebView into my macOS application, intended to allow users to browse tutorial webpages directly within the app. Although I’ve followed an example that appears syntactically correct, the WebView does not render any webpage content. Below is a code snippet for reference: import SwiftUI import WebKit struct HelpWebView: View { @State private var toggle = false @State private var page = WebPage() private var url: URL { toggle ? URL(string: "https://www.webkit.org")! : URL(string: "https://www.swift.org")! } var body: some View { WebView(page) .onAppear { page.load(URLRequest(url: url)) } .onChange(of: toggle) { page.load(URLRequest(url: url)) } .toolbar { Button("Reload", systemImage: "arrow.clockwise") { toggle.toggle() } } } } I would greatly appreciate any insights or suggestions on what might be causing this issue or how to resolve it. Thank you in advance for your help!

I am using the native SwiftUI WebView and WebPage APIs (iOS 26+) and would like to implement file download functionality using the native SwiftUI WebView. However, I have not been able to find any APIs equivalent to WKDownload. In WKWebView, the WKDownload API can be used to handle downloads. I am looking for a similar API or recommended approach in the native SwiftUI WebView that would allow downloading files. If anyone has guidance or suggestions on how to implement this, I would appreciate your help.

Expected Behavior: Display the digit “6”. Actual Behavior: The rendered character appears as a composite glyph—the left half resembles “9” and the right half resembles “6”, resulting in a malformed digit. other examples： Environment & Characteristics: Occurs intermittently on iPhone 15 Pro Max and iPhone 16 Pro Max. Reproducible within the Taobao App, specifically in WKWebView. Font Used: AlibabaSans102_v1_TaoBao-Bd.ttf

I’m currently developing an application using WKWebView. After updating to iOS 26.2 Developer Beta, the following Web API started returning false: isUserVerifyingPlatformAuthenticatorAvailable MDN: https://developer.mozilla.org/ja/docs/Web/API/PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable_static This issue did not occur on iOS 26.1 — it only happens on the beta version. Has anyone else encountered this problem or is aware of any related changes? OS: iOS 26.2 beta 3 (23C5044b)

I'm in the process of supporting Apple Pay through a 2nd payment gateway for some users, so I need to support two separate Apple Pay relationships. Both require their own apple-developer-merchantid-domain-association. I don't see how I can have both files for the one domain. Is this possible? Is there a workaround other than just replacing the old file with the new one and hoping that doesn't disrupt anything. That seems to be the approach taken by others (https://developer.apple.com/forums/thread/695538) but it is too high risk for me without any confirmation from Apple that this is ok. I'd also like to avoid having to setup a 2nd domain for these customers, since the current domain is already quite embedded in their operations.

We're trying to implement Cross-domain session check for SSO by making CORS request. is Intelligent Tracking Prevention blocks all cookies in CORS requests? I saw all cookies are blocked in CORS requests. We are not able to check the auth session in source domain. Are there anyway to bypass this without user interaction? benefitier.com -> source.com

In WKWebView, there is the WKUIDelegate method: func webView(_ webView: WKWebView, createWebViewWith configuration: WKWebViewConfiguration, for navigationAction: WKNavigationAction, windowFeatures: WKWindowFeatures) -> WKWebView? {} This delegate method provides a callback when a new window (for example, target="_blank") is requested in the web view. However, in native SwiftUI (iOS 26), WebView / WebPage APIs do not provide an equivalent delegate method to handle new window requests. As a workaround, I am using the following method: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy {} In this method, when action.target == nil, I treat it as a new window request. My question: Is relying on action.target == nil in decidePolicy a reliable and future-safe way to detect new window requests in SwiftUI’s WebView, or is there a better or more recommended approach for handling target="_blank" / new window navigation in the SwiftUI WebView APIs? Code: public func decidePolicy(for action: WebPage.NavigationAction, preferences: inout WebPage.NavigationPreferences) async -> WKNavigationActionPolicy { guard let webPage = webPage else { return .cancel } // Handle case where target frame is nil (e.g., target="_blank" or window.open) // This indicates a new window request if action.target == nil { print("Target frame is nil - new window requested") // WORKAROUND: Until iOS 26 WebPage UI protocol is available, we handle new windows here // Try to create a new WebPage through UI plugins if handleCreateWebPage(for: webPage, navigationAction: action) != nil { // Note: The new WebPage has been created and published to the view return .allow } } return .allow }

When using iCloud Keychain passkeys with WebAuthn (mediation: "conditional") in non-Safari browsers (e.g. Chrome or WKWebView-based browsers), Face ID / Touch ID is requested twice during Passkey Autofill. This issue occurs only when the focused input field shows a numeric keypad–style keyboard, such as: Japanese Kana Chinese Zhuyin With a standard QWERTY keyboard, authentication completes with a single user verification. Notably: Safari completes authentication with one Face ID / Touch ID prompt even with numeric keypad keyboards. Other browsers require two prompts. The issue does not occur with other credential managers (Google Password Manager, 1Password), suggesting this is specific to iCloud Keychain. This issue has been confirmed on the following OS versions: iOS 17.6.1 iOS 18.7.2 iOS 26.2 iOS 26.3 beta Impact This behavior results in a confusing and unintuitive login experience for users relying on Passkey Autofill. Steps to Reproduce: Go to Settings → Keyboards → Keyboards, and set “Japanese – Kana” as the primary keyboard. Enable Face ID / Touch ID, and make sure “Use Face ID / Touch ID For” → “Password Autofill” is enabled. Open Chrome and navigate to https://webauthn.io. Enter a username and tap “Register” to create a passkey using iCloud Keychain. Tap the username field again so that the “Japanese – Kana” keyboard appears and the passkey suggestion created in step 4 is shown. Tap the passkey suggestion. Face ID / Touch ID is requested twice. === This issue has already been reported via Feedback Assistant as FB21726047. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.

The crash is specific to iOS 26.2 prior versions working fine. WKScriptMessageHandler delegate func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) Name attribute is accessible but WKScriptMessage body attribute causes crash The object seems to be not accessible(not in memory) self.webkit.configuration.userContentController.add(self, name: "sampleHandler") self.webkit.load(request) func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) { print(message.name) // works print(message.body) // crashes }

This demonstrates an issue with SwiftUI's WebView on iPadOS. To repro, testing on iPad Simulator OS 26.2, macOS 26.2, Xcode 26.2. Download and unzip this project: https://drive.google.com/file/d/1z3MobjDf_RvvOtriXtinXvrJ7rGHwZRs/view?usp=share_link Set up Signing and Run the swiftui-webview App target on simulator (I'm using iPad Pro 13-inch (M5 simulator) Tap/click the fullscreen [ ] button in the bottom left corner of the webpage. Tap/click the 'X' button in the top left, to exit fullscreen. Result: The WebView exits fullscreen, but there is no content loaded, just a white background. It's also now not possible to visit other URLs - the WebView appears to be unresponsive and not repaint. This does not appear to affect macOS 26.2, just iPadOS.

Our app uses ASWebAuthenticationSession for login. This launches an incognito (ephemeral) browser window of the system’s default browser with the authentication URL. Recently, on the latest macOS Tahoe, we observe that: The browser application is launched(we could see in the dock) But the authentication window with the URL does not appear No error is returned to the app (silent failure)

Issue: On Safari, two Smart App Banners appear for the same webpage when the iOS app is installed. Cause: • Banner 1: Native Apple Smart App Banner, automatically triggered by Safari via AASA / Universal Links. • Banner 2: Smart banner injected by a third-party SDK (Branch.io). • Both operate independently, resulting in duplicate banners. Finding: Safari’s native Smart App Banner behavior is system-controlled and cannot be disabled programmatically using web rules or JavaScript while Universal Links are enabled. Question: Is this behavior expected by design? Is there any Apple-supported way to suppress the native Smart App Banner when using a third-party banner, or is the recommended approach to rely on only one banner system?