iOS 26 (from beta 1 to beta 2) We have a VPN app that installs a per-app VPN profile with SafariDomains to filter Safari network traffic. This setup works as expected on iOS versions lower than 26.0. See here more details on SafariDomains: https://aninterestingwebsite.com/business/documentation/Configuration-Profile-Reference.pdf On iOS 26, all SafariDomains configured to go through the per-app VPN result in the following error: "Safari can’t open the page. The error was: Unknown Error" Additional Details: Only SafariDomains encounter this error. Other managed apps traffic through the per-app VPN works correctly. Steps to Reproduce: Install the VPN app with a per-app VPN profile. Configure SafariDomains with any URL (e.g., example.com). Open Safari and navigate to the configured URL. Example Configuration: We tested with a simple example by adding only one URL to SafariDomains (example.com). Logs from the console were captured at the moment Safari opened and encountered the error. safari_google2.txt Has anyone else encountered this issue on iOS 26? Any insights or solutions would be greatly appreciated. Thank you!

Hello, When I view my website (lasaluade) on iphone or ipad the top of my page bodies are cut off (3-4 first lines). However, on PC, Mac or Android everything is OK (see screenshots). For the record, I built this site with Wordpress and Divi Builder, and I've the same result on Safari and Chrome. Not being a developer, I don't know where to look (I just think it's iOS-related). Have you already had this problem? Do you have any ideas? Thanks for your help!

Hello there, For a video like this <video src="blob:safari-web-extension://***" autoplay="" loop="" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; object-fit: cover; z-index: -1;"></video>, no matter if its local or remote, blob or mp4 files, is constantly being reloaded (refetched? revalidated?) if the loop tag is added. I can confirm there is actual constant traffic from the server based on my server logs. I am running iOS/macOS 26.

I recently noticed that putting the app on background for some time, then switching back to it again causes the WKWebView to reload the current page, same with just hitting f5 on it. How do we disable this behavior?

Issue Description I'm developing a hybrid iOS app and encountering WebView bridge communication issues after updating to Xcode 16 with iOS 18 SDK. App Architecture AViewController: Initial view controller displayed at app launch Handles WebView setup and web-to-native bridge communication Pushes BViewController when receiving "B" bridge message from web BViewController: View controller stacked on top of AViewController Managed by navigation controller AViewController's WebView continues bridge communication even when BViewController is active Problem Behavior Xcode 15 (iOS 18): WebView bridge communication in AViewController works normally while BViewController is active Xcode 16 (iOS 18 SDK): Server communication breaks or hangs without response while BViewController is active Communication resumes only after popping back to AViewController from BViewController Questions Is the current architecture (configuring WebView in AViewController and maintaining bridge communication through AViewController's WebView while BViewController is presented) not a recommended pattern? Is Xcode 16's iOS 18 SDK the cause of this issue? If so, could you help me understand which specific changes are affecting this behavior? This is urgent as we need to deploy soon. I would greatly appreciate a prompt response.

Dears, We are facing some issue in ios 18.4.1. Recently some of our end users who updated their ios devices to 18.4.1 have experienced random 403 errors in runtime. as per our analysis, We identified that these errors are associated with "CSRF token mismatch". After successful login, the user's CSRF token is causing issue and it was changed in runtime, this causes the cookie mismatch, and the users is getting 403 errors, and the user session is getting invalid suddenly. let me know if anyone facing the same issue in ios 18.4.1 and let me know Is there any workaround for this issue. Thanks.

Hello everyone, We've had our app rejected twice under Guideline 3.2.2 regarding charitable donations, and we're seeking clarification on the correct implementation. We've read the guidelines but want to confirm the technical approach with the community's experience. The Rejection Reason: Apple states: "We still noticed that your app includes the ability to collect charitable donations within the app..." They specify that since we are not an approved nonprofit, we must use one of the alternatives, primarily: "provide a link to your website that launches the default browser or SFSafariViewController for users to make a donation." Our Current (Rejected) Implementation: User taps a "Help" button in our native app. A native modal appears inside our app where the user enters their donation amount and email address for the receipt. The user clicks "Donate," which then opens an SFSafariViewController to our website's payment page (e.g., Stripe, PayPal). The amount and email are passed as URL parameters to pre-fill the form. Our Questions for the Community: Is the issue solely the fact that we have a native modal for data entry? We understand we cannot process the payment in-app, but we thought collecting the intent (amount, email) was acceptable before handing off to Safari. What is the definitive, compliant flow? Option A: Should the "Help" button do nothing more than open an SFSafariViewController to a generic donations landing page on our website (https://ourwebsite.com/donate), with no data pre-filled? The user must then navigate and enter all information on the website itself. Option C: The rejection also mentions SMS. Has anyone had success implementing a "Text-to-Donate" link instead of a web flow? Wording: The button in our app currently says "Donate". Should this be changed to a more passive call to action like "Visit Website to Donate" to make it absolutely clear the transaction is external? We want to ensure our next submission is successful. Any insight, especially from developers who have successfully navigated this exact rejection, would be immensely helpful. Thank you.

Hi everyone, I want users not to see the system context menu when long-pressing text on a page in Safari on iOS. I found on MDN that the CSS property -webkit-touch-callout: none; can achieve this. But in reality, it doesn't really work. MDN documents URL: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/-webkit-touch-callout Here’s a minimal example: function preventIOSSafariContextMenu() { if (document.getElementById(STYLE_ELEMENT_ID)) return; if (!IS_TOUCH_DEVICE) return; const style = document.createElement("style"); style.id = STYLE_ELEMENT_ID; style.textContent = ` html, body { -webkit-touch-callout: none !important; } `; (document.head || document.documentElement).appendChild(style); } The context menu persists. Has anyone else encountered this? Is this an intentional change in WebKit, or could it be a regression? If it’s intentional, is there a recommended alternative? Thanks in advance for any insights!

Hello, ive been dealing with this glitch all year that hasnt happened last year. When I watch a video on public safari and then it exit the video it immediately takes me to the private tab but when I go on the private tab to watch videos and exit out it takes me back to the website just like normal. Its a pretty annoying bug and I watch all my videos in the private tab because of it

We are experiencing a problem that seems to be caused by a specification changes for Safari. We would like to discuss how to solve this problem. Sample JavaScript: <html> <head> <script> function jumpPage(code) { document.main.code.value = code; win1=window.open("","win1","toolbar=no,resizable=yes,menubar=no,scrollbars=yes,status=yes,left=0,top=0"); win1.resizeTo(width=screen.availWidth,height=screen.availHeight); document.main.action="details"; document.main.target="win1"; document.main.submit(); } </script> </head> <body> <form name="main" method="post" action="" target=""> <a href="javascript:jumpPage('001')">details</a> <input type="hidden" name="code" value=""> </body> </html> This JavaScript performs the following actions when a link is clicked. Open a window using window.open in JavaScript Submit the above opened window by post method to the target in JavaScript. When this operation is performed, the process in (2) could submit to the target page with “POST” method before iOS18.1, but will transition to the page with“GET”method from iOS18.2 onward. All protocols are http. This problem does not occur if the URL is specified as an IP address, but it does occur if the host name is specified as. Please let me know how to use with“POST”method as in iOS 18.2 or earlier. Best regards,

I have a website that has been built in Wordpress and hosted on wordpress engine. In testing now and on the i phone with safari browser it keeps crashing after short time 2/3 minutes, content does not display properly pages go blank etc. Has anyone experienced this /have a solution? Thanks

Hello, I am developing a Mac application via Mac Catalyst and encountering an issue with WKWebView. Specifically, I'm loading a webpage (e.g., https://translate.google.com) in WKWebView, but when I press the copy button on the page, the content doesn't actually copy to the clipboard. I've attempted modifying the UserAgent without any success. Here is the relevant part of my code: override func viewDidLoad() { super.viewDidLoad() let config = WKWebViewConfiguration() config.preferences = WKPreferences() config.defaultWebpagePreferences.preferredContentMode = .desktop let webView = WKWebView(frame: .zero, configuration: config) webView.translatesAutoresizingMaskIntoConstraints = false view.addSubview(webView) webView.scrollView.showsVerticalScrollIndicator = false webView.backgroundColor = UIColor.white webView.scrollView.backgroundColor = UIColor.white webView.leadingAnchor.constraint(equalTo: view.leadingAnchor).isActive = true webView.topAnchor.constraint(equalTo: view.topAnchor).isActive = true webView.trailingAnchor.constraint(equalTo: view.trailingAnchor).isActive = true webView.bottomAnchor.constraint(equalTo: view.bottomAnchor).isActive = true if let url = URL(string: "https://translate.google.com") { let req = URLRequest(url: url) webView.load(req) } }

I have an app which has at least two extensions: A Content Blocker extension with a request handler that returns an appropriate NSExtensionItem as part of beginRequest. A different file URL is returned depending upon if the content blocking is on or off by a user setting A Safari Web Extension that includes a toolbar button and popover that enables users to enable or disable the ad blocking of the content blocker extension All three targets (App, Content Blocker appex and Web Extension appex) use an App Group default to read and set the on or off status of the content blocking. When the user changes the content blocking status, the app group default is updated and SFContentBlockerManager.reloadContentBlocker(...) is called. The Content Blocker extension reads the default and then returns the appropriate file URL. The issue is, I have noticed that whenever SFContentBlockerManager.reloadContentBlocker(...) is called from the app, Safari always applies the correct rules from the returned file URL. However sometimes when SFContentBlockerManager.reloadContentBlocker(...) is called from the Safari Web Extension using native messaging, Safari does NOT apply the correct rules from the returned file URL. Using logging I have confirmed that the Content Blocker extension always returns the appropriate file URL irrespective if called as a result of the app or the web extension. Despite this, Safari does not seem to always apply the returned file URL rules when it is called from the Safari Web Extension appex. In these cases, quitting Safari and relaunching it seems to make it apply the rules correctly (obviously this is applying it due to its launch state, not due to the Web extension appex asking it to do so at that point). All targets have access to the App Group location where the active content blocking file URL belongs and the inactive content blocking file URL is within the Safari content blocker target as a resource. I don't think this is a memory status issue as I cannot see the Content Blocker extension being killed when it returns complex rules --- the fact it always works when called via the app also seems to rule this possibility out. This brings up a number of questions: Is calling SFContentBlockerManager.reloadContentBlocker(...) from a different appex, of the same app target and app group supported? (it seems to work sometimes and did work in previous versions of the app). Is there an issue that the Content Blocker extension sometimes returns a file URL that perhaps the calling Web Extension appex may not have access to (even though Safari should via the Content Blocker extension)? Any other ideas of why this may not be working correctly? Has anyone else experienced this? It seems to happen on both iOS and macOS Safari using the same codebase.

As the title suggests, given today’s overpowered device performance, shouldn’t Safari and WKWebView allow repainting during window resizing? Currently, all WKWebView-based apps pause page rendering during resize. When a user double-clicks the drag region, the sequence goes: pause rendering → enlarge or shrink the window → leave a blank area → repaint the page. The whole process feels inelegant—especially on devices that support ProMotion.

After updating to iOS 18.4, our web application (with service workers) crashes on devices that accessed it prior to the update. This issue also affects hybrid mobile apps using the same web application; reinstalling the app resolves it by refetching and reinstalling service workers. Debugging is challenging because clearing the cache or reinstalling the app fixes the problem, and no useful error logs are available. Has anyone encountered similar crashes related to service workers after an iOS update and have any insights into the cause?

Hi. With update to 26.2 on my iPad the Favorites Bar has gone missing in Safari. "Show Favorites Bar" is selected in Apps -> Safari. I've emptied cache, deleted all history, etc in Safari. Restarted the iPad multiple times, but issues prersists. This issue is limited to my iPad. Favorites appear in both my iPhone and MacBook. Any ideas?

I have compiled some Java code to WebAssembly via TeaVM and wrapped it in a PWA. The resulting code runs nicely in Firefox and Chrome but throws an exception in Safari. CompileError: WebAssembly.Module doesn't parse at byte 1657: invalid extended GC op 24, in function at index 2251 Can anybody tell me what's wrong with that code? I mean it can't be so bad if Firefox and Chrome can parse and run it without problems. I am using the most recent versions of all browsers and the offending code can be found here: Run the demo via: https://mpmediasoft.de/demos/Emmentaler/Emmentaler-Demo-TeaVM-Wasm/index.html The offending wasm file is: https://mpmediasoft.de/demos/Emmentaler/Emmentaler-Demo-TeaVM-Wasm/tvw/ModelBridgeTeaVM.wasm With Safari the demo just shows some empty space instead of a complex polygon. You can see the error in the javascript console of Safari.

Hello, I have an authentication flow where my app communicates with a backend protected by F5 client certificate validation. The client certificate is distributed via MDM and is available in the device keychain, but not accessible directly from the app. When using ASWebAuthenticationSession (or SFSafariViewController) Safari can successfully pick up and present the certificate during authentication, so that part works fine. However, the backend’s authenticate endpoint only supports a POST request with an Authorization header, whereas ASWebAuthenticationSession only accepts a GET URL when starting the session. My questions are: How is this type of flow typically implemented in iOS? Should the backend provide a GET-based endpoint that redirects into the POST, or is there a recommended iOS pattern (e.g., an intermediate HTML page that does the POST after certificate validation)? Are there Apple guidelines on handling certificate-based auth with ASWebAuthenticationSession when the API requires POST, especially for In-House distributed apps? Any guidance or best practices would be very helpful.

I have a Safari extension that plays audio via the javascript AudioContext API. It was working fine under iOS 17 and is now broken under iOS 18. It does not play audio at all. I've tried in both the iOS 18 public beta and the iOS 18.1 developer beta. It is broken in both of them. I've also created Feedback item FB15170620 which has a url attached to a page I created which demonstrates the issue.

Hi there, I have a popular open source app called Foqos. What I'm finding in iOS 26 (might even effect older versions) is that when using the webcontent api within Managed settings as the following: store.webContent.blockedByFilter = .specific(domains) It doesn't work on Safari, but does work on third party applications like chrome, firefox, etc. But when using the all and exception enum like the following store.webContent.blockedByFilter = .all(except: domains) This does work on Safari This is pretty inconsistent behavior of the API and should be fixed to match the documentation. Documentation does not mention anything about Safari limitations Again source code is open: https://github.com/awaseem/foqos You can run the app yourself and find the same issues. Is anyone else experiencing this?