We currently are using private web security certificates for our URLs. Our users download, install, and enable a Root Certificate on their devices to reach our website (trusted). The web security certificates have expirations that are less than 13 months from expiration. Since the deployment of iOS 18, our users are now getting a "This Connection is not Private" warning in the web browser on both Mac and iOS devices. What change was implemented in iOS 18 that is causing this issue? Other than changing our web security certificates to Public ones, what solutions should be implemented to prevent this from occurring?

Hi, We developed a web app based on the iPhone Safari browser, and we would like to ask if it's possible to use JavaScript to prevent the iPhone's screenshot function from capturing screenshots of the web page?

Hi, we developed a web app based on the iPhone Safari browser and would like to apply to see if it is possible to use JavaScript capabilities to prevent the iPhone system from taking screenshots of web pages.

Hello everyone, in my website I need to give users the ability to choose a color via input type=“color”. I don't understand why it works fine on desktop (even on Safari for Mac) but doesn't open the color picker on iPhone. How can I solve this? Thank you, Andrea

So I know I can request for an email in the paymentRequest requiredShippingContactFields and could also access minimal information with onshippingcontactselected, but how can I actually get the full shippingContact AFTER a transaction. The documentation doesn't say what API call this is returned with or anything, so please help! Relevant doc: https://developer.apple.com/documentation/apple_pay_on_the_web/applepaypayment/1916097-shippingcontact

I'm trying to use the simulator from Xcode to emulate an iPhone. I have created a sandbox account and logged in but pressing the Apple Pay button doesn't do anything. I have also tried the demo website for Apple Pay and that doesn't work either. Does the simulator work at all for Apple Pay on the Web?

In Safari Web Extensions on iOS 18, declarativeNetRequest Rulesets and Dynamic Rules take over twice as long to apply -- which causes rulesets to often fail to apply before sites load. In a boilerplate Xcode project you can note the time difference toggling the OISD (https://oisd.nl) ruleset on iOS 17 and iOS 18 simulators. Additionally, if you force quit Safari and reopen to a site with ads blocked by OISD list (e.g. espn.com) the content will be blocked in that initial state on iOS 17, but not in iOS 18 due to the latency. Based on the boilerplate extension, this bug is impacting all Mobile Safari Extensions using declarativeNetRequest Rulesets and Dynamic Rules. We know several other extension developers dealing with this issue. Our team wrote detailed reproduction steps in our Feedback Assistant ticket: https://feedbackassistant.apple.com/feedback/15196130 but have received no responses. I would attach a screen recording here but it won't allow me.

I've observed a discrepancy in cookie consent options between iOS 18.0 and 18.1 on some websites, such as www2.hm.com. On iOS 18.0, I see "Accept All Cookies" and "Only Required Cookies" options, whereas on iOS 18.1, the options change to "Accept All Cookies" and "Cookie Settings." I would like to understand if this behavior is related to differences in how websites detect the operating system version (iOS 18.0 vs. 18.1) or browser changes within the iOS update. Has anyone else experienced similar variations in cookie consent banners, and could this be tied to differences in the user agent or website A/B testing for different OS versions? Any insights or technical clarifications would be appreciated!

Hello everyone, I am currently facing an issue with a Cordova-based app using WKWebView. In our app, we handle page navigation within the WebView. We’ve implemented a back button at the top of the page, which successfully triggers history.goBack() when clicked. However, we also want to support the native left edge pan gesture (swipe back) to trigger history.back(). The issue is that, while the swipe back gesture works most of the time, there are cases where instead of navigating to the immediate previous page, it behaves as if it’s going back to the first page (or initial page). This only occurs on iOS versions 17.5.1 and above. I’ve already set allowsBackForwardNavigationGestures to true, and the back button itself works perfectly. Has anyone experienced a similar issue, where the swipe back gesture sometimes skips pages and seems to return to the first page on iOS 17.5.1 or later? Any suggestions on how to fix or troubleshoot this would be greatly appreciated. Thank you!

I am working Web to App flow for my product. Tolink to my app from web service, I define uri scheme from app and use it from my web site. But, when I try to use this scheme from mobile safari web, It sometimes failed with message that uri is invalid. That is weird It failed SOMETIMES not always Even I tried with same url. In my device, there is current version app. Why this happen? How can I resolve this issue?

I'm building a share extension for my app when I noticed something weird. When I open a mobile URL (URLs with "m." like m.randomsite.org) on iOS using a browser (I'm using Safari & Chrome) and then try to share it, what will be share is the URL without the "m." (i.e. randomsite.org) This messes up with my app since I'm not getting the real URL that I'm viewing using the browser. I don't think it has something to do with my app since even selecting "Copy" when sharing will result in the altered URL too. So far this is happening on both iOS 17 and 18. Does someone know whether this is a bug from iOS or not? I don't think this is a Safari bug since I noticed the same thing on Chrome as well

Hi, I was implementing Apple pay button by checking active wallet and at least one cards active. I am using applePayCapabilities as per DOCS but i am still getting the same type of response with apple pay wallet enabled and without apple pay wallet enabled on different devices as Loading the Apple Pay SDK: script.src = "https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js"; script.crossOrigin = "anonymous"; document.head.appendChild(script); script.onload = function() { console.log("Apple Pay SDK loaded successfully"); // Initialize Apple Pay or perform actions that require the SDK here }; script.onerror = function() { console.error("Error loading Apple Pay SDK"); }; Calling applePayCapabilities method: window.ApplePaySession.applePayCapabilities("merchant.com.example").then(r => console.log(r)) Output: {paymentCredentialStatus: "paymentCredentialsAvailable"} Image attachments of applePayCapabilities: Devices Config Used:- Chip - Apple M3 Pro macOs - Sequoia 15.0.1 memory - 36 GB Safari Version - 18.0.1

I have a question. In the file located at /Library/Preferences/com.apple.networkd.plist, if the dict entry for enable_unified_http is set to true or if the value is missing, there is an issue where the video player does not run on MacOS Sequoia Safari 18.0. I found that setting it to false allows it to function properly. Could you explain what this setting does and whether it is possible to change this setting to false within the app?

Howdy! On Safari, when using the column-count CSS property to split text into multiple columns, I've noticed that when applying a text-shadow, there is an unexpected whitespace created above all subsequent columns. I've put together a codepen demonstrating the issue and its reproducibility on Safari (using latest as of this posting: Version 17.6 (19618.3.11.11.5)) Codepen: https://codepen.io/cubepresser/pen/ExqvzjL Expected behavior: Actual: I tested this on the latest versions of Chrome, Firefox and Edge. This bug does not occur. Expected behavior is that there should not be an extra line added to the beginning of the second column, third column, etc. Here's some code if that codepen link doesn't work: HTML: <p id="example">0000000000111111111122222222223333333333</p> CSS: #example { font-family: monospace; max-width: 20ch; column-count: 2; column-gap: 0; word-break: break-all; line-break: anywhere; text-shadow: 0 0 4px black; }

This is problematic when opening links to other websites that require separate authentication. A typical example would be a Gmail web app, and then trying to open a link to a GitHub PR. In the 18.0 release notes, this is mentioned as Added support for opening links directly in web apps on macOS. (113034778 It'd be great if this could be customizable so that one could choose the old behavior.

iOS WKWebview - When we run the WKWebview with loading the HTML file. Including JS method call and video looping it here in js file. Getting this method call webViewWebContentProcessDidTerminate(_ webView: WKWebView). Can anyone provide the solution? Thanks

We are developing an Add To Wallet flow on our website where we add the "Add To Wallet" button to a user portal for them to be able to add a loyalty card pass to their Apple Wallet. In other projects with Apple Pay, we can check whether or not the browser supports the JS library by checking if it exists on the global window property (if (window.ApplePaySession) { //do stuff } Is there an equivalent to determine if the user's device is capable of accepting a Wallet pass?

Since iPadOS 18.x WKWebView seems to have a bug within its Fullscreen API (which can be enabled via WKPreferences.isElementFullscreenEnabled). This bug has the effect that websites trying to make an element (for example a video player) fullscreen fail to do so. This does not always happen, most of the time the fullscreen mode does work fine, but sometimes (far too often to be ignored) it does not. If an instance of WKWebView shows this issue, it can not be "fixed" by reloading the page or loading other pages, this issue exists in this instance forever. My App is a web browser App so I can create and remove WKWebView instance easily (by opening or closing Tabs). And there are times where I never see this bug, and times where ever other tab shows this bug. It's totally unreliable. The App does not show any issues at all when running under iPadOS 17 or older. The issue is only present under iPadOS 18.x. After some testing I've found out that when the bug has affected an instance of WKWebView, the JavaScript call element.requestFullscreen() will work if the element is a video element, but does no longer work if it is another element (like a DIV). If an instance of WKWebView is not affected by this bug, element.requestFullscreen() will work for all HTML elements. Does anyone has experienced this bug as well? And maybe found a workaround? Or maybe found a pattern which helps to find out what exactly is triggering this bug?

Good day, I'm attempting to check whether Apple Pay is available using the ApplePay JS API. Prior to upgrading to Safari 18.0+, I was using window.ApplePaySession.canMakePayments to show/hide the Apple Pay option. I've noticed with the new Safari version, the preferred method of checking the availability of Apple Pay is by using the applePayCapabilities method. When logging and inspecting the window object in Safari 18.0.1, this method seems to be missing from the ApplePaySession object. Additionally, my conditional code which is dependent on applePayCapabilities does not execute: if (typeof window !== 'undefined' && window.ApplePaySession) { // Safari version 17 and lower if (window.ApplePaySession.canMakePayments) { // set Apple Pay available } /** * On Safari version 18 and higher, we must check whether a user has a card saved in their wallet. * If this is the case, Apple Pay must be presented as the primary payment method. In our case, * this means selecting Apple Pay as the default payment method. */ if (window.ApplePaySession.applePayCapabilities) { const merchantIdentifier = '***'; const promise = window.ApplePaySession.applePayCapabilities( merchantIdentifier ); promise.then(capabilities => { switch (capabilities.paymentCredentialStatus) { case ApplePayCapabilities.CREDENTIALS_AVAILABLE: // set Apple Pay as available and default break; case ApplePayCapabilities.UNSUPPORTED: // not available break; default: // set Apple Pay as available only } }); } } I feel I'm missing something very simple here, help would be greatly appreciated!

The behavior has changed when specifying an xlsx file in the src of iframe in my PWA app. On iPadOS 17.3：Content of xlsx file shown in iframe On iPadOS 17.5.1：A screen appears on top of the original screen to select an app to open the xlsx file. I would like to restore the original behavior, but how can I do that? In addition, if i open and operate the same URL as the one opened in the PWA app in Safari on iPadOS 17.5.1, "download test.xlsx dialog" is open and the dialog has view or download buttons. If the behavior has changed to same to safari on iPadOS17.5.1, it is good for me.