We are currently implementing the payment flow, and for handling payment details — including card entry and validation — we are utilizing a WKWebView. The webview securely loads the payment provider’s page, ensuring sensitive information such as card numbers are entered and validated directly within the web context. I’d like to clarify that this change has not yet been released to Production. As part of a feature enhancement to our existing payment flow, we are transitioning to a new payment vendor, SnapPay. While trying to load the SnapPay URL embedded within an iFrame in our iOS app, I observed the following error in the Xcode console. While this error may be generic, I wanted to highlight it: 825a18 - [pageProxyID=7, webPageID=8, PID=67346] WebPageProxy::didFailLoadForFrame: frameID=24, isMainFrame=0, domain=NSURLErrorDomain, code=-999 Upon investigating, we compared the headers from our existing payment URL and SnapPay's URL, and found that SnapPay includes the following Content-Security-Policy (CSP) header: Content-Security-Policy: frame-ancestors ... "Content-Security-Policy" value="default-src 'self'; script-src 'self' https://hcaptcha.com https://.hcaptcha.com https://code.jquery.com https://www.gstatic.com https://code.jquery.com/jquery-3.3.1.min.js https://test.lightbox.cardx.com/v1/lightbox.min.js https://www.ssa.gov/accessibility/andi/ https://c.evidon.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' https://hcaptcha.com https://.hcaptcha.com https://fonts.googleapis.com/css https://stage.snappayglobal.com/Resource/ https://www.ssa.gov/accessibility/andi/andi.css 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' *.googleapis.com *.gstatic.com ; connect-src 'self' https://demo1.cditechnology.com https:; form-action https://hcaptcha.com https: 'self' *.ipg-online.com secure.bluepay.com https://test.api.lightbox.cardx.com https://3ds-acs.test.modirum.com/ https://demo1.cditechnology.com/; frame-ancestors https://snappaydirect-perf.fiserv.com 'self' file: https: http; frame-src .snappayglobal.com 'self' https://hcaptcha.com https://.hcaptcha.com https: https://www.google.com .ipg-online.com secure.bluepay.com https://.cardconnect.com https://test.api.lightbox.cardx.com/ https://test.lightbox.cardx.com https://paywithcardx.com/payment/auth.cgi securepayments.cardpointe.com *.cardpointe.com https://3ds-acs.test.modirum.com/ https://www.yokohamatire.com http://uat1-txt.ad.portal.texas.gov https://uat1-txt.ad.portal.texas.gov " After multiple working sessions with the SnapPay team, we were able to confirm that when they disable CSP or remove the frame-ancestors directive, the iFrame loads successfully within our app. However, SnapPay cannot change on their CSP. To enable the iFrame to load in the iOS app, we added the following line of code: webView.configuration.preferences.setValue(true, forKey: "allowFileAccessFromFileURLs"). This resolved the issue with loading the iFrame. Note: the file being loaded is a local .html file,. Before submitting this update to the App Store, I’d like to confirm whether this usage of allowFileAccessFromFileURLs is acceptable for App Store review. I wanted to confirm that with this change is there a security concern for WKWebview?

"We have a multi-tenant EdTech platform serving over 1500 clients, each with a unique domain (e.g., client1.eduapp.com). We use WKWebView in a native shell. Due to WKAppBoundDomains restriction, we can't dynamically list all domains. How can we support dynamic tenants while maintaining cookie persistence" "Can Apple suggest a best practice or alternative approach for apps using WebView/PWA shell architecture across multiple client domains?" Problem: We cannot predefine all 1500 domains in WKAppBoundDomains due to limitations. As a result: Service workers fail to register, breaking PWA functionality Ex: Offline.

with iOs26 it works so so great, that every time i look something up ChatGPT is the first thing to Seach the web for everything about it then, i can read it an it gives a link for me to go to if i wont to further look inti it ,this on I Phone SE 3 Generation ,it has better Siiri to better on the I Phone SE 3rd Generation.

Hi all, I need to detect if my web application (pure HTML / Javascript) is opened from: Safari from a Mac Safari from an iPad but by asking for the desktop version I tried to check for many properties (including the navigator.useragent) but no difference were visible. Anyone could help me? Thank you

I’ve been working on a personal iOS project for fun — essentially a YouTube music player, learning how background media playback works in native iOS apps. After seeing that Musi (a famous music streaming app) can play YouTube audio in the background with the screen off — I got really curious. I’ve been trying to replicate that basic background audio functionality for YouTube embeds using WKWebView. I've spent a crazy amount of time (probably 20 hours) trying to figure this out but have achieved no success. Here’s what I’ve tried so far: -Embedding a YouTube video in a WKWebView -Activating AVAudioSession with .playback and setting .setActive(true) -Adding the UIBackgroundModes key with audio in Info.plist -Adding the NSAppTransportSecurity key to allow arbitrary loads --Testing on a real device (iPhone 14, iOS 18.1 target)-- What happens: Audio plays fine in the foreground. If I exit the app and go to the lock screen quickly enough (less than 3 seconds) after pressing play, I can resume playback briefly from the lock screen — but it doesn’t automatically continue like in Musi and other apps like it. Most of the time, the audio stops when the app is backgrounded. I get this error consistently in the logs: Error acquiring assertion: <Error Domain=RBSServiceErrorDomain Code=1 "(originator doesn't have entitlement com.apple.runningboard.assertions.webkit AND originator doesn't have entitlement com.apple.multitasking.systemappassertions)" It seems like the app lacks some specific entitlements related to WebKit media playback. I don’t have AppDelegate/SceneDelegate (using SwiftUI), but can add if needed. I’m super curious how music streaming apps using youtube as a source get around this — are they doing something different under the hood? A custom player? A SafariViewController trick? Is there a specific way to configure WKWebView to keep playing in the background, or is this a known limitation? Would really appreciate any insight from folks who’ve explored this before or know how apps like Musi pulled it off. Thanks in advance!

input type="file"でアップロードした画像データからGPS情報が除去されます。 こちらはiPadOS16.5.1で発生しておりました。 iPadOS17.4.1、iPadOS18.3では正常にGPS情報が保持されます。 iOS、iPadOSのアップデートでGPS情報を保持するよう修正されたと見受けられますが、リリースノートを参照しても上記修正についての記事を見つけられませんでした。 お手数ですが、上記修正に該当する記事をご教示頂けませんでしょうか。 どうぞよろしくお願い致します。

Howdy, WKWebView feature request: allow Fullscreen API without User Gestures similar to ElectronJS' userGesture: true flag that allows devs to bypass user gesture restriction for Fullscreen API and similar executeJavaScript(code[, userGesture]) https://www.electronjs.org/docs/latest/api/web-contents#contentsexecutejavascriptcode-usergesture afaik this is allowed because of a fairly recent update to Chromium that also allows users to give Fullscreen API permissions per domain https://chromeos.dev/en/posts/using-the-fullscreen-api-without-gestures Would be greatly useful for a use case in my cross-platform app, so I can avoid rewriting all platforms to use Chromium Thanks

Hello, I followed the instructions to set up a custom logo for our domain name Allogarage.fr, both for the brand and the domain. Everything appears to be correctly configured in Apple Business backend for several weeks now, but the logo still doesn’t show up in Mail. Is the branded email feature available in France? Are there any additional steps required?

I want use the Safari Extension to decorate the window.fetch function, But No matter how I try, I can't get the fetch function to execute correctly. I was going through the documentation: https://developer.apple.com/documentation/safariservices/using-injected-style-sheets-and-scripts and found this sentence: "Injected scripts have an implied namespace — you don’t have to worry about your variable or function names conflicting with those of the website author, nor can a website author call functions in your extension. In other words, injected scripts and scripts that you include in the webpage run in isolated worlds, with no access to each other’s functions or data." Does this mean I can't modify the window object in the content script just like a Chrome extension does with the webpage? BTW, In chrome I use chrome.scripting.executeScript API, and in plasmo I just use world: "MAIN" content script's config to achieved this feature.

Hi everyone, We work on a macOS plugin which then gets loaded into another application. I'm trying to load a webpage in that application through our plugin using a WKWebView & I set my class as the navigationDelegate for the same. I do not receive any callbacks for the WKNavigationDelegate methods. I have debugged & made sure that the navigationDelegate is actually set to my class. Here is a sample code of what I'm doing : [[NSApplication sharedApplication] runModalForWindow:self.mWindowController.window]; - (void)windowDidLoad { [super windowDidLoad]; [self.window makeKeyAndOrderFront:self]; [self.window orderFrontRegardless]; if (self.mLoadingView == nil) { self.mLoadingView = [[LoadingView alloc] initWithFrame:[[self.window contentView] frame]]; } [[self.window contentView] addSubview:self.mLoadingView]; [self.mLoadingView showLoadingView]; [self.window setLevel:NSMainMenuWindowLevel]; [self loadWebPage]; } -(void)loadWebPage { [self.mWKWebView setUIDelegate:self]; [self.mWKWebView setNavigationDelegate:self]; [self.mWKWebView stopLoading]; NSURL *lURL = [self samplePageURL]; WKNavigation *lNavigation = [self.mWKWebView loadRequest:[NSURLRequest requestWithURL:lURL]]; } - (void)webView:(WKWebView *)pWKWebView didFinishNavigation:(WKNavigation *)pNavigation { [self removeLoadingview]; [self.mWKWebView evaluateJavaScript:@"document.body.setAttribute('oncontextmenu', 'event.preventDefault();');" completionHandler:nil]; } I do not get any calls in the webView:didFinishNavigation: & I also tried other methods like webView:didStartProvisionalNavigation, webView:didFailProvisionalNavigation:withError: etc but did not receive any call in those either. Instead of runModalForWindow: if I use showWindow: on the mWindowController the webpage somehow loads but I still don't get any callbacks & so the loadingview subview is also present. The WKWebView is placed in a storyboard, and I have an IBOutlet connected to it in my class. Has anyone faced a similar issue or can point me to something I might be missing? All help is appreciated. Thanks in advance.

Anybody succeeded sending a Web Push Message using the new Declarative approach introduced with Safari Version 18.4 (20621.1.14.11.3)? I will help as well if someone can point me to a solution debugging the entire system using Xcode and Minibrowser? Currently I can't get the MiniBrowser connected to the WebPush Daemon.

Hi Apple Developer Community and Support, We are implementing Apple Pay on the Web and are encountering a persistent issue with merchant validation when the ApplePaySession is initiated from a JavaScript application running within a cross-origin iframe. Our Setup: Top-Level Domain: https://application.my.com/ (where the Apple Pay button is displayed, and the iframe is embedded) iFrame Content Origin: https://cashier.my.com/ (Our custom JavaScript application that handles the Apple Pay integration and directly calls our Payment Service Provider's (PSP) API for merchant validation). iFrame allow attribute: The iframe correctly includes allow="payment *". The Problem: When a user clicks the Apple Pay button, the ApplePaySession is successfully created and the Apple Pay sheet opens in Safari iOS. This suggests the browser recognizes the allow="payment *" attribute and allows the API calls. However, during the session.onvalidatemerchant callback, our JavaScript code makes a direct API call to our PSP (Nuvei)'s endpoint. This call consistently fails with an "Invalid domain name!" error, and the Apple Pay sheet then shows "Payment Not Completed." PSP's Diagnosis: Our PSP (Nuvei) has investigated and stated that for this specific endpoint (getAppleValidationApiFlow.do), "there is no explicit way to pass domain to the endpoint and domain for which session is issued is based on 'Referer' header." Our Question for Apple: Given that Safari 17+ now supports allow="payment" for cross-origin iframes to enable Apple Pay APIs, we have the following questions: What is Apple's official guidance or expectation regarding the Referer header for ApplePaySession.onvalidatemerchant calls when the ApplePaySession is instantiated from a cross-origin iframe? Is it expected that the Referer header for calls originating from the iFrame will always be the iFrame's origin? Does Apple's merchant validation process (when the PSP calls apple-pay-gateway.apple.com/paymentservices/startSession) itself rely on or interpret the Referer from the initial client-to-PSP call? Are there recommended best practices or standard approaches for PSP integrations in this cross-origin iFrame scenario to ensure the Referer validation (or equivalent domain validation) is correctly satisfied? We're trying to understand if our PSP's specific reliance on the Referer for this validation is a standard requirement implicitly set by Apple for this flow, or if there are other architectural approaches that should allow this scenario to work seamlessly. Thank you for any insights or guidance you can provide.

From a mail app or similar, when opening a webpage in Safari as an external browser, JavaScript on the webpage stops running if Safari goes into the background. Is there a way to prevent this from happening? Sample code for the counter: Behavior: Upon returning from the background, the counter continues for about 7-8 seconds but does not progress further. For example, if Safari is kept in the background for about 20 seconds and then brought back, the counter stops at around 7-8 seconds and only resumes counting after returning to the foreground. Expectation: The counter should continue running even if Safari goes into the background.

Hello, I’m working on a cross-origin WebAuthn implementation where a parent page embeds an iframe from a different origin to perform authentication. According to the WebAuthn Level 3 spec (Section 7.1.1), when crossOrigin is true, the clientDataJSON may include topOrigin—but Safari does not seem to populate this field. Observed Behavior: Chrome/Firefox: Include topOrigin in clientDataJSON when crossOrigin: true. Safari (macOS/iOS): Omits topOrigin even though crossOrigin is correctly set to true. Example clientDataJSON from Safari: { "type": "webauthn.get", "challenge": "...", "origin": "https://iframe-origin.example.com", "crossOrigin": true // Missing `topOrigin` (expected: parent origin) } Questions: Is this an intentional omission in Safari for privacy/security reasons? Are there specific requirements (e.g., HTTP headers, permissions policies) needed for Safari to expose topOrigin? Is there a known workaround to reliably obtain the top-level origin in cross-origin WebAuthn flows? System Info: Version 18.4 (20621.1.15.11.10) OS: Sequoia Version 18.4 (20621.1.15.11.10) Reproduction Steps: Parent page (https://parent.example.com) embeds an iframe (https://webauthn-rp.example.com). The iframe calls navigator.credentials.get() with a WebAuthn challenge. Safari returns clientDataJSON with crossOrigin: true but no topOrigin. Code Snippet (iframe): const credential = await navigator.credentials.get({ publicKey: { challenge: new Uint8Array(/* ... */), rpId: 'webauthn-rp.example.com', allowCredentials: [], hints: [], userVerification: "preferred", } }); console.log(JSON.parse(atob(credential.response.clientDataJSON))); Has anyone encountered this? Any insights would be greatly appreciated!

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.

We are encountering a download issue in Safari 18.2 on macOS Sequoia 15.2 where file downloads initiated by our AngularJS application (such as Excel exports) are silently blocked. There are no errors in the browser console, and the download does not occur. Interestingly, after testing on Safari 18.3 with Sequoia 15.3, the downloads worked as expected. However, the problem reappeared on Safari 18.4 with Sequoia 15.4. We suspect that recent changes in Safari’s security or download handling may be preventing downloads triggered via asynchronous JavaScript (e.g., AJAX calls) that are not initiated directly by user interaction. We would appreciate any insights, suggestions, or possible workarounds from the community. Looking forward to your guidance on this matter.

I am currently developing an app using WKWebView. In iOS 17, Apple introduced ProxyConfiguration, and I have two questions regarding its usage: Is there a way to use ProxyConfiguration to distinguish between HTTP and HTTPS traffic? I have reviewed the documentation but couldn’t find a clear method for this. As an alternative approach, I am attempting to determine the request scheme within WKWebView and switch proxyConfigurations just before loading the request. My current implementation sends requests to hoge_a by default and switches to hoge_b only for HTTP traffic. 　 if #available(iOS 17.0, *) { if URLString.contains("http:") { webView.configuration.websiteDataStore.proxyConfigurations = [hoge_b] } } webView.load(request) if #available(iOS 17.0, *) { if URLString.contains("http:") { webView.configuration.websiteDataStore.proxyConfigurations = [hoge_a] } } 　 2. Since I modify proxyConfigurations every time webView.load(request) is called, are there any potential issues or concerns with this approach? I would appreciate any insights you may have on either of these questions.

Dear Apple Developer Support Team, I am writing regarding critical issues we are facing with Safari web push notifications in our application iLiveMyLife.io, which is severely impacting our ability to maintain reliable communication with our users. Issue Description: We are experiencing persistent problems with Safari push notification tokens expiring or becoming invalid without any notification to our server. This creates several critical issues: Users stop receiving notifications without any indication of failure Our notification delivery system has no way to detect token expiration The expiration appears to happen frequently (seemingly almost daily in some cases) There is no reliable mechanism to re-establish push communication without users manually revisiting the app Technical Impact: Our messaging functionality becomes completely unreliable We must resort to email or SMS as fallback mechanisms, which is not feasible for a real-time communication platform This makes building any reliable messaging application on Safari practically impossible The Broader Context: What makes this situation particularly challenging is that all potential alternative browser APIs that could help address this issue appear to be deliberately disabled or restricted in Safari: Background Service Workers don't function in the background on iOS Safari Background Sync API is not supported WebSockets cannot operate when the app is closed There's no way to programmatically check the validity of push tokens The combination of these limitations creates a situation where developers have no viable technical path to build reliable notification systems for PWAs on Safari. This appears to be a systematic restriction rather than individual API limitations. Requested Information: Is there a recommended approach to detect Safari push token expiration? Are there alternative notification mechanisms for PWA applications on Safari that offer more reliability? Is there documentation on the lifecycle of Safari push tokens that could help us implement proper handling? Are there plans to improve the Web Push API implementation in Safari to address these reliability issues? Could you clarify if these limitations are intentional design decisions or technical constraints that might be addressed in future updates? Business Impact: This issue fundamentally undermines our platform's core functionality. For a collaborative tool, reliable notifications are essential - users cannot collaborate effectively if they miss updates because their push tokens silently expired. The current state creates confusion among our users, who don't understand why they suddenly stop receiving notifications. Any guidance or assistance you could provide would be greatly appreciated. We're committed to providing an excellent experience on Safari, but the current push notification limitations make this extremely challenging. Thank you for your time and consideration. Best regards, Ilya

I built a web application using the Apple Pay on the Web Interactive Demo with the Payment Request API, but encountered a few issues: The initiated web Apple Pay interface shows a spinning circle at the bottom and cannot proceed with payment（Bottom display:正在处理）. What could be causing this? How to set up sandbox testing for payments? How to asynchronously and synchronously retrieve payment results (backend code to fetch payment results)? The demo only shows frontend code using await response.complete("success"); for retrieving payment results my demo URL： https://shop.wowseer.com/rsolomakhin/pr/applepay/

This is a rare occurrence on our site, having only detected 4 instances of it over the past few weeks, where 10s of thousands of transactions have occurred successfully. We only call the following PaymentRequest API onClick from the <apple-pay-button>: async function startApplePay(merchantIdentifier, amount) { ... try { const request = new PaymentRequest([ applePayMethod ], paymentDetails); ... catch (e) { // cancel, just stay here if (e.name === "AbortError") { if (consoleLog) console.log("Payment canceled", e); logServer("INFO", "Payment canceled"); } else { handleError("Error caught: " + e.name + ", " + e.cause + ", " + e.message); } } Where the "handleError" else case is what gets triggered: Error caught: SecurityError, undefined, show() must be triggered by user activation. All 4 instances have been from iPads, but with that small of a sample size, we can't tell whether that's relevant or coincidence. Different iOS versions, but looks like same Safari version. Here are the 4 User Agents we've seen thus far: Mozilla/5.0 (iPad; CPU OS 18_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/352.0.715618234 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 17_6_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/352.0.715618234 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 18_3_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/133.0.6943.33 Mobile/15E148 Safari/604.1 Mozilla/5.0 (iPad; CPU OS 18_2_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/133.0.6943.33 Mobile/15E148 Safari/604.1