We are developing a mobile-first, browser-only web application that requires users to upload 20–200 images stored inside a single folder (for example, a merchant product directory). On iOS Safari: window.showDirectoryPicker() is not supported. is not supported. File System Access API is not available. Users must manually multi-select images from the Photos picker. This creates significant friction for bulk upload workflows. We are NOT requesting unrestricted file system access. We are asking whether a privacy-preserving, user-granted folder-scoped permission model is being considered for web applications. For example: User explicitly selects a folder. The web app receives scoped access only to that selected folder. Access is session-bound and revocable. No background or global storage access is required. Questions: Is folder-level access for web apps being considered for iOS Safari? Does installing a PWA provide any enhanced file access capability? Are there recommended best practices for handling bulk image uploads in browser-only iOS applications? Is there any roadmap alignment with the File System Access API standard? Our goal is to remain browser-only and maintain strict user privacy while improving usability for high-volume image workflows. Any clarification on intended platform direction would be appreciated.

In my chat web app I have button to upload images. On iOS in Safari I can see action sheet with "Media library", "Caption image or video", "Open files". Can I prevent opening this action sheet and directly open media library using HTML or JavaScript?

I created a form field using: On Safari and Chrome desktop, it behaves as expected. Safari shows the current date in grey by default, and Chrome displays a format hint like dd.mm.yyyy, which is perfectly fine. On iOS, however, the field appears completely blank. I understand that the placeholder attribute is not part of the iOS date input behavior, which is technically fine. Still, it would be helpful if developers had the option to define a default display value. In the past, browsers prefilled date inputs, but many developers objected because they needed the field to be empty by default. I have searched extensively and tried several AI tools, and everywhere it says that this cannot be changed. Am I missing something, or is there any way to display a placeholder, the current date, or some kind of visual hint in iOS Safari? Right now, the empty field creates poor UX because users may overlook it. Since the field is required, this can easily lead to validation errors and additional friction. As a workaround, I used a CSS hack with input[type="date"]::before and a content attribute. I also added JavaScript to toggle a pseudo-placeholder value specifically for iOS. Is there a cleaner solution that avoids this workaround? Thanks in advance for your guidance.

Hello there, Credit card autofill works in Safari when accessing the checkout on my website, but does NOT work when the same page is loaded in a WKWebView within the my iOS mobile app. is there any way I can make it work?

We are using WKWebView to load content from a local server. On specific iPhones running the latest iOS, the web view gets stuck on the loading state. We confirmed this is a system-wide networking issue because the same URL also fails to load in mobile Safari. Workaround: The only way to restore connectivity to the local host is to reboot the iPhone. this happens on last iOs releases on some iPhones with ios 26.2 and 26.3

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 }