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'm trying to download mods for Stardew Valley, before the beta it worked but now it doesn't. Is there anyone who can help to fix this? Used Firefox and Safari as well as Safari on my ipad.

It seems that in iOS 18.5+ built with Xcode 16.4+, there has been a breaking change since 18.4 with 16.3 within WebKit and how the navigationAction.sourceFrame property is initialized when implementing the decidePolicy delegate method. The flow goes: Implement a WKNavigationActionDelegate with decidePolicy Call WKWebView.loadHTMLString("some-string", baseURL: nil) Upon loading the HTML content, read the value of navigationAction.sourceFrame within the decidePolicy method of the WKNavigationActionDelegate On iOS 18.4 (and below) with Xcode 16.3 (and below); navigationAction.sourceFrame is <uninitialized> On iOS 18.5+ with Xcode 16.4+: navigationAction.sourceFrame is already initialized and is equal to navigationAction.targetFrame It appears that this change was made between minor versions of Xcode and is unexpected behavior of a minor version. Not only was this not called out in the release notes for Xcode 16.4 and iOS 18.5, but it's technically also a breaking change to the WebKit API. Can we get insight on why this change was made and what Apple's policy is on breaking changes between minor versions of Xcode/iOS?

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

Hi, I am developing the Click & Read web add-on for Chromium, Firefox and Safari. We use xcrun safari-web-extension-converter tool to generate the Safari add-on, with up-to-date MacBook MacOS, Xcode et Safari : Sequoia 15.3.2, Safari Version 18.3.1 (20620.2.4.11.6), XCode Version 16.0 (16A242d). We have updated our addon to Manifest v3, having the Background script as Server Worker "background": { "service_worker": "background.js", "type": "module" } self.addEventListener("activate", (event) => { console.info("Service Worker activated", event); event.waitUntil( self.registration.pushManager .subscribe({ userVisibleOnly: true, applicationServerKey: urlBase64ToUint8Array( process.env.VAPID_PUBLIC_KEY ), }) .then(async (subscription) => { console.info("[Service Worker] Extension is subscribed to push"); const { subscription: savedSubscription } = await getLocalStorageKeyData("subscription"); if (savedSubscription) fetchApi({ url: `${API_SERVER_URL}/subscription/remove/${savedSubscription.keys.auth}`, }); // Remove previous subscription from server on addon activate currentBrowser.storage.local.set({ subscription: subscription.toJSON(), }); // Save subscription in local storage currentBrowser.runtime.setUninstallURL( `${API_SERVER_URL}/subscription/remove/${ subscription.toJSON().keys.auth }` ); // Set uninstall URL to remove notification subscription on addon uninstall fetchApi({ url: `${API_SERVER_URL}/subscription`, reqInit: { body: JSON.stringify(subscription.toJSON()), method: "POST", headers: { "Content-Type": "application/json", }, }, }); }) .catch((error) => { console.error("Push subscribe error: ", error); }) // Subscribe to push notifications ); }); When trying to subscribe the addon instance to our Push server, we get this error : Push subscribe error: NotAllowedError: User denied push permission Our NodeJS backend is using the web-push librabry : https://github.com/web-push-libs/web-push) to save subscriptions and make notifications push. By looking for same errors on forums, the best hint I found is that it could be related to the testing is done on localhost (addon is built from XCode onto Safari, and Push server is running on localhost). Thanks for your help !

Hi! I'm working on a web extension for Safari and I need to send messages from the containing application to JavaScript. For this I use the method class func dispatchMessage( withName messageName: String, toExtensionWithIdentifier identifier: String, userInfo: [String : Any]? = nil ) async throws of the SFSafariApplication class. If the site is opened in Safari in normal mode, everything works as expected. However, if the site is "docked", the messages are not transmitted to this "Web App". Is it possible to somehow link the container application to the docked website so that messages from the application are received by this "Web App"? That you.

I'm working on a Safari web extension that uses the nativeMessaging facility to communication with native code. When I want to notify the javascript extension from the embedding application, I use SFSafariApplication::dispatchMessage. As per the documentation, this call ... ensures that Safari is launched and that your extension is running before delivering the message. Everything works fine when the background script is running. However, after the background script gets unloaded at some point in time (non persistent background page, default behavior for a manifest V3 extension), the background script is not reloaded by the message from the native app (background script still appears unloaded in the developer menu of Safari, double-checked using a counter stored in browser.storage.local incremented on message reception). In this case, the completion handler of the application gets no error (error == nil) as if the message was correctly delivered. I was able to reproduce this behavior with the sample app delivered for WWDC20 (after upgrading the manifest from v2 to v3 to make it non-persistent). Is it supposed to work ? What I'm doing wrong ?

On iPhone 16 running iOS 18.0(Xcode 16.2), cookies configured with SameSite=None; Secure fail to apply correctly—iOS forcibly converts the attribute to SameSite=Lax. As a result, cross-site requests from H5 pages within our app cannot carry the required cookies, causing failures. Can anyone help me on this? Thanks in advance.

We are building a hybrid iOS app using Angular (web) rendered inside a WKWebView, hosted by a native Swift app. Communication between the Angular UI and native Swift code is done using WKScriptMessageHandler. The app mostly works without issues, but in rare edge cases, we’re seeing crashes on the main thread, and the crash is reported in Firebase Crashlytics. The root cause appears related to CFRelease and WKScriptMessageHandler. Here’s the relevant crash stack: Crashed: com.apple.main-thread 0 CoreFoundation 0xbfac CFRelease + 44 1 CoreFoundation 0xa734 __CFURLDeallocate + 128 2 CoreFoundation 0x730c _CFRelease + 292 3 libobjc.A.dylib 0x4e28 AutoreleasePoolPage::releaseUntil(objc_object**) + 204 4 libobjc.A.dylib 0x4cbc objc_autoreleasePoolPop + 260 5 WebKit 0x99f194 WebKit::WebUserContentControllerProxy::didPostMessage(WTF::ObjectIdentifierGeneric<WebKit::WebPageProxyIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, WebKit::FrameInfoData&&, WTF::ObjectIdentifierGeneric<WebKit::ScriptMessageHandlerIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>, std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::CompletionHandler<void (std::__1::span<unsigned char const, 18446744073709551615ul>, WTF::String const&)>&&) + 680 6 WebKit 0x1b358 WebKit::WebUserContentControllerProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 392 7 WebKit 0xe86b0 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 272 8 WebKit 0x23c0c WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 44 9 WebKit 0xe3f054 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 252 10 WebKit 0x332d4 IPC::Connection::dispatchIncomingMessages() + 744 11 JavaScriptCore 0x58a7c WTF::RunLoop::performWork() + 204 12 JavaScriptCore 0x599a4 WTF::RunLoop::performWork(void*) + 36 13 CoreFoundation 0x56328 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 14 CoreFoundation 0x562bc __CFRunLoopDoSource0 + 176 15 CoreFoundation 0x53dc0 __CFRunLoopDoSources0 + 244 16 CoreFoundation 0x52fbc __CFRunLoopRun + 840 17 CoreFoundation 0x52830 CFRunLoopRunSpecific + 588 18 GraphicsServices 0x11c4 GSEventRunModal + 164 19 UIKitCore 0x3d2eb0 -[UIApplication _run] + 816 20 UIKitCore 0x4815b4 UIApplicationMain + 340 21 APP1 0xa2f80 main + 21 (AppDelegate.swift:21) 22 ??? 0x1c234eec8 (シンボルが不足しています) Steps: WebView: WKWebView Message passing: WKScriptMessageHandler → passing data from Angular → Swift WKWebView is long-lived and reused Native is using WKUserContentController.add(_:name:) to register handlers Crashes are intermittent (hard to reproduce), but often follow: Screen sleep/wake Push notification open Angular calling native immediately after resume Questions: Has anyone seen this specific crash pattern involving CFRelease and WKScriptMessageHandler? Are there known WebKit or CoreFoundation bugs related to WKScriptMessageHandler and retained URLs or message content? Thank you for your help!

Hello i would like to report a bug on iOS 26 beta. The problem is on the epic games website you see when I hit sign in it is just blank but the epic games store is just fine i would like this to be fixed on iOS 26 beta 3 thank you.

Hi, I'm using a webview in Swift, where I load an html file locally. Basically I have an angular project built and loaded directly into my app bundle. The webview requires the use of the camera. I request permissions via and javascript, the pop-up appears, I accept the permissions and the app works correctly. Only that after a certain number of seconds, the permissions are requested again. It's as if the webview doesn't cache the accepted permissions. Is this normal behavior?

Crash Stack: thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x19ba3bb04) frame #0: 0x000000019ba3bb04 CoreFoundation`forwarding.cold.2 + 92 frame #1: 0x000000019b8ab718 CoreFoundation`forwarding + 1288 frame #2: 0x000000019b8ab150 CoreFoundation`_CF_forwarding_prep_0 + 96 frame #3: 0x000000019df230b0 CoreText`TCFRef<CTRun*>::Retain(void const*) + 40 frame #4: 0x000000019e052050 CoreText`CreateFontWithFontURL(__CFURL const*, __CFString const*, __CFString const*) + 476 frame #5: 0x000000019e052874 CoreText`TCGFontCache::CopyFont(__CFURL const*, __CFString const*, __CFString const*) + 144 frame #6: 0x000000019df27dcc CoreText`TBaseFont::CopyNativeFont() const + 232 frame #7: 0x000000019df8ee64 CoreText`TBaseFont::GetInitializedGraphicsFont() const + 152 frame #8: 0x000000019df26d70 CoreText`TBaseFont::CopyVariationAxes() const + 296 frame #9: 0x000000019df2d148 CoreText`TDescriptor::InitBaseFont(unsigned long, double) + 768 frame #10: 0x000000019df21358 CoreText`TDescriptor::CreateMatchingDescriptor(__CFSet const*, double, unsigned long) const + 604 frame #11: 0x000000019df251f8 CoreText`CTFontCreateWithFontDescriptor + 68 frame #12: 0x00000001bff8dfb8 WebCore`WebCore::createCTFont(__CFDictionary const*, float, unsigned int, __CFString const*, __CFString const*) + 124 frame #13: 0x00000001bff8e8bc WebCore`WebCore::FontPlatformData::fromIPCData(float, WebCore::FontOrientation&&, WebCore::FontWidthVariant&&, WebCore::TextRenderingMode&&, bool, bool, std::__1::variant<WebCore::FontPlatformSerializedData, WebCore::FontPlatformSerializedCreationData>&&) + 228 frame #14: 0x00000001c128eef4 WebKit`IPC::ArgumentCoder<WebCore::Font, void>::decode(IPC::Decoder&) + 1352 frame #15: 0x00000001c1333ca4 WebKit`std::__1::optional<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>> IPC::ArgumentCoder<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>, void>::decodeIPC::Decoder(IPC::Decoder&) + 480 frame #16: 0x00000001c1333a5c WebKit`std::__1::optional<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>> IPC::Decoder::decode<WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>() + 28 frame #17: 0x00000001c1333804 WebKit`std::__1::optional<std::__1::pair<WebCore::AttributedString::Range, WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>> IPC::Decoder::decode<std::__1::pair<WebCore::AttributedString::Range, WTF::HashMap<WTF::String, WebCore::AttributedString::AttributeValue, WTF::DefaultHashWTF::String, WTF::HashTraitsWTF::String, WTF::HashTraitsWebCore::AttributedString::AttributeValue, WTF::HashTableTraits>>>() + 156 frame #18: 0x00000001c121f368 WebKit`IPC::ArgumentCoder<WebCore::AttributedString, void>::decode(IPC::Decoder&) + 172 frame #19: 0x00000001c121f124 WebKit`std::__1::optionalWebCore::AttributedString IPC::Decoder::decodeWebCore::AttributedString() + 28 frame #20: 0x00000001c12594ec WebKit`IPC::ArgumentCoder<WebCore::DictionaryPopupInfo, void>::decode(IPC::Decoder&) + 76 frame #21: 0x00000001c12d0660 WebKit`std::__1::optionalWebCore::DictionaryPopupInfo IPC::Decoder::decodeWebCore::DictionaryPopupInfo() + 28 frame #22: 0x00000001c12ceef0 WebKit`IPC::ArgumentCoder<WebKit::WebHitTestResultData, void>::decode(IPC::Decoder&) + 1292 frame #23: 0x00000001c1338950 WebKit`std::__1::optionalWebKit::WebHitTestResultData IPC::Decoder::decodeWebKit::WebHitTestResultData() + 28 frame #24: 0x00000001c1ec7edc WebKit`WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 31392 frame #25: 0x00000001c1fb8f28 WebKit`IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 272 frame #26: 0x00000001c19ab2c0 WebKit`WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 44 frame #27: 0x00000001c1fb3254 WebKit`IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder) + 252 frame #28: 0x00000001c1fb3768 WebKit`IPC::Connection::dispatchIncomingMessages() + 576 frame #29: 0x00000001b9ab90c4 JavaScriptCore`WTF::RunLoop::performWork() + 204 frame #30: 0x00000001b9ab9fec JavaScriptCore`WTF::RunLoop::performWork(void*) + 36 frame #31: 0x000000019b8cc8a4 CoreFoundation`CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 frame #32: 0x000000019b8cc838 CoreFoundation`__CFRunLoopDoSource0 + 176 frame #33: 0x000000019b8cc59c CoreFoundation`__CFRunLoopDoSources0 + 244 frame #34: 0x000000019b8cb138 CoreFoundation`__CFRunLoopRun + 840 frame #35: 0x000000019b8ca734 CoreFoundation`CFRunLoopRunSpecific + 588 frame #36: 0x00000001a6e39530 HIToolbox`RunCurrentEventLoopInMode + 292 frame #37: 0x00000001a6e3f348 HIToolbox`ReceiveNextEventCommon + 676 frame #38: 0x00000001a6e3f508 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 76 frame #39: 0x000000019f442848 AppKit`_DPSNextEvent + 660 frame #40: 0x000000019fda8c24 AppKit`-[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 frame #41: 0x000000019f435874 AppKit`-[NSApplication run] + 480 frame #42: 0x000000019f40c068 AppKit`NSApplicationMain + 888 frame #43: 0x00000001ca56a70c SwiftUI`merged generic specialization <SwiftUI.TestingAppDelegate> of function signature specialization <Arg[0] = Existential To Protocol Constrained Generic> of SwiftUI.runApp(__C.NSResponder & __C.NSApplicationDelegate) -> Swift.Never + 160 frame #44: 0x00000001ca9e09a0 SwiftUI`SwiftUI.runApp<τ_0_0 where τ_0_0: SwiftUI.App>(τ_0_0) -> Swift.Never + 140 frame #45: 0x00000001cad5ce68 SwiftUI`static SwiftUI.App.main() -> () + 224 frame #46: 0x0000000105943104 MyApp Dev.debug.dylib`static MyMacApp.$main() at :0 frame #47: 0x0000000105943c9c MyApp Dev.debug.dylib`main at MyMacApp.swift:24:8 frame #48: 0x000000019b464274 dyld`start + 2840

Summary Recently a number of bugs affecting our Safari extension have been introduced with various Safari 18.X updates. We've submitted feedback for all of these, but most have received no response. We need to raise this to your attention as it has been affecting our developer experience and causing a lot of frustration for our users. It's something that adds a lot of uncertainty for us. These issues affect core web functionalities but seem to be isolated to the Start Page or Extension environments. For example: using window.open, no longer works using window.location.href = ... no longer works Including a tag in our start page causes infinite reloading to occur. registering a content script more than once will crash Safari Details Unable to open new window as as start page extension in Safari 18 FB15879470 What happens: Calling window.open does nothing. This broke our links to our feedback submission, marketing site & help site. When: Nov 18, 2024 - Initial launch of Safari 18 on macOS Status: Open, No response Unable to open app url scheme with window.location.href in start page extension in iOS 18 FB15879596 What happens: Changing the URL in this way does nothing (well actually it does work about 10% of the time). This broke our navigation to in app payment. When: Nov 18, 2024 - Initial launch of Safari 18 on iOS Status: Open, No response New tab extensions broken FB16126043 What happens: Having a tag in your causes an infinite loop of reloading the start page. This broke our entire start page extension. When: Dec 19, 2024 - Safari 18.3 on iOS beta Status: 10 similar tickets found, marked for future OS update. We did get a response and a fix is identified for a future release window.open opens “about:blank” when called from Start Page extension. FB16427985 What happens: calling window.open from the start page opens about blank on iOS 18.3. Similar to the first issue, but slightly different behaviour. This broke our links to our feedback submission, marketing site & help site. When: Jan 30, 2025 - Safari 18.3 Status: Open, No response Registering a content script more than once causes Safari to crash in macOS 15.4 beta FB16831768 What happens: We have an optional content script that we were registering every time it was used. Although somewhat redundant, it was much simpler than checking if one was already registered and tracking if an updated one needed to replace it. This works fine on all other browsers and all prior Safari versions we've released it on. However if a user enables site blocker on the latest version, as soon as they visit any website, our content script registration causes Safari to crash. Essentially preventing users from using Safari until they uninstall our extension. When: Mar 11, 2025 - Safari 18.4 Status: Open, No response In Conclusion Luckily we have been able to isolate and find workarounds for most of these issues so far, but we are not guaranteed to in the future. We are raising this not only to have these issues looked into, but to raise awareness of the rising trend of basic functionality of Safari extensions breaking with Safari updates. We hope that this can influence a shift in your QA & feedback intake practices to ensure these issues are less frequent in the future. We are happy to raise future issues through your provided channels as they are discovered. But to have our feedback ignored and then have to rely solely on workarounds to prevent disruptions to our users' experience is concerning. We submitted this feedback to our developer relations contact, and he suggested we submit a TSI to look into these issues. In response to this, we were advised to post this here.

The “Add to Home Screen” feature for bookmarks is not working in Safari on iOS 26.

Hi, I am trying to find a unix timestamp from a safari bookmark. I have been able to open the Plist file but I am not sure how to find the timestamp. Any help would be great!

As you see in the image, when I fullscreen in WKWebView, it shows black instead of the webpage in full screen. It works fine in Sequoia. It has happened to me since beta 1, but I post it now, because we’re in beta 8 and it’s not fixed. What’s going on? Can somebody tell me if they have the same issue?

I've been unable to successfully get a webpage to send a message to a Safari web extension, no matter what I try doing. I've added the following to my manifest.json file, and it's running manifest v3 { "externally_connectable": { "matches": [ "*://mywebsite.com/*", "*://localhost:3000/*" ] } } My web page executes the following code snippet. I've tried this both while running my site locally (on localhost) and pushed to production. let safariExtensionId = "co.companyname.productname.Extension (ABCD1234)" browser.runtime.sendMessage(safariExtensionId, { greeting: "hello"}, function(response) { console.log("Received response from background page"); console.log(response.farewell); } ); In the Safari web extension's background.js file, I've added the following onMessageExternal listener: browser.runtime.onMessageExternal.addListener((message, sender, sendResponse) => { console.log("Received message from the sender."); console.log(message.greeting); sendResponse({ farewell: "Goodbye!" }); }); This is directly copied from the instructions in this WWDC video: https://developer.apple.com/documentation/safariservices/messaging-between-a-webpage-and-your-safari-web-extension It's also extremely difficult to debug what's happening since the extensions service working frequently does not appear in the Web Extension Background Content menu Is there something I'm doing wrong, or a bug I'm not aware of?

What happens if Safari is uninstalled or disabled on iOS? Will SFafariviewcontroller still work? Kind regards

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.

Hi everyone, My web application has two services: myapp.com and account.myapp.com. The first manages all app content, while the latter handles the authentication, with Sign In with Apple included. The tech stack is mainly composed of React, JS, and Express. We'd like to allow users to authenticate inside a dialog on some pages of myapp.com. To avoid replicating stuff from one service to another, we put an iframe inside the dialog to show the authentication standard page from account.myapp.com. Email and Facebook processes work fine, but we have the following issues with Sign in with Apple: On desktop, not Safari, a pop-up window opens when you click on the Apple button, and it works as expected. On desktop Safari, the pop-up window is blocked. We want the native Apple pop-up to show instead of a generic browser new window. On mobile, nothing happens on click Obviously, outside the iframe, everything works as expected. I can't seem to find anything related to an iframe constraint in the Sign in with Apple docs. Is this feasible?