Hello Apple engineers and fellow developers, Over the past few weeks I have noticed multiple reports from different developers whose legitimate websites have been classified by Safari as “Fraudulent Website Warning”, despite passing every major public security and reputation check. My websites appear to be affected by the same issue. Domains https://skvoz.net https://skvoz.org Both domains were registered on July 15, 2026. The Fraudulent Website Warning first appeared on July 22, 2026, only one week after registration. Both websites are legitimate services operated by our team. Neither website impersonates another brand, attempts to collect Apple IDs, banking credentials, passwords, or any other sensitive information through deceptive means. Extensive verification performed After the warning appeared, we performed a comprehensive technical and security review. Website security ✅ No malware detected ✅ No phishing content ✅ No unauthorized redirects ✅ No suspicious JavaScript ✅ No mixed-content issues ✅ HTTPS configured correctly ✅ Valid TLS certificates Infrastructure DNS configuration verified SSL certificate chain verified using OpenSSL Server responds correctly over HTTP/2 IPv4 and IPv6 connectivity verified Origin server behaves correctly Cloudflare configuration was thoroughly tested during troubleshooting and ultimately removed from the production setup to eliminate it as a possible cause Reputation checks We verified both domains and the hosting IP address using multiple public reputation services. Results were consistently clean. This included services such as: Google Safe Browsing Google Search Console VirusTotal URLVoid IP reputation databases None of them currently report malware, phishing activity, or any other security issues. Apple-specific actions We have already: submitted a Website Review request; contacted Apple Security via reportphishing @apple.com requesting a manual review. At the time of writing, the warning is still present. One unusual observation One particularly unusual observation is that both of our domains (skvoz.net and skvoz.org) received the warning independently. These are separate domains serving different purposes, yet both appear to have been classified in the same way despite passing the same technical and reputation checks. This made me wonder whether Apple’s reputation system may evaluate related domains or shared infrastructure together. I understand the internal implementation is not public, but I wanted to mention this observation in case it is useful during investigation. Similar reports While investigating this issue, I found several recent reports from other developers describing almost identical behavior. The common pattern is remarkably consistent: Safari displays Fraudulent Website Warning Chrome, Firefox and Edge open the website normally Google Safe Browsing reports the domain as safe VirusTotal reports no malware Google Search Console reports no security issues valid HTTPS certificates relatively new domains no explanation regarding what triggered the warning This suggests the issue may not be isolated to a single website. Questions I would greatly appreciate any guidance from Apple engineers. Does Safari rely solely on Google Safe Browsing, or does Apple maintain an independent reputation database for Fraudulent Website Warning? If Apple maintains its own reputation system, are there any documented technical signals developers should verify? For example: redirects third-party scripts TLS configuration domain age hosting reputation infrastructure characteristics phishing heuristics machine-learning based classification Is there any recommended diagnostic process beyond Website Review? Approximately how long does a manual review usually take? Why I am posting This post is not only about my own websites. Over the past few months I have noticed an increasing number of developers reporting what appear to be false positive Fraudulent Website Warnings affecting legitimate websites. If there have been recent changes to Safari’s reputation or anti-phishing systems, it would be extremely helpful for developers to better understand what technical criteria should be reviewed before requesting reconsideration. Even if the exact detection logic cannot be disclosed, any general guidance on common causes of false positives would help developers resolve issues much more efficiently. Thank you very much for your time.

webkitEnterFullScreen API is supported on iOS for video element, but not for a div element. Also as a fullscreen demo website shown, Safari on macOS supports div element but not on iOS. Is there any plan to add the support in iOS? If not is there any way to fullscreen a div element or make it run as fullscreen on Safari iOS?

I operate a website that offers Sign In with Apple as an authentication option for users. When I originally set this up a couple years ago, I'd created an App ID using my personal Developer account, along with the appropriate Services ID and Key. I'm now in the process of creating an iOS app offering users similar functionality. But for this, I have a new, business Developer account, where I've created an App ID and all the same ids allowing Sign In with Apple. It feels like the first appropriate thing to do—before starting my iOS sign-in—is to get my existing website users migrated from my personal developer team to my new business developer team. I found that process very well documented by technote TN3159, which describes this as a six-step process in terms of Team A handing a project to Team B. Team A obtains access token(s) Team A generates transfer identifiers Team A initiates app transfer to Team B Team B obtains access token(s) Team B exchanges transfer identifiers Team B confirms successful user migration ✓ I'm successfully able to complete steps 1 and 2. ✘ Step 3 doesn't seem possible, as it looks like that applies to a team transferring a published app to another team. But I figured maybe that didn't matter in my case, as my website uses a Services ID, not an App ID. ✓ I'm successfully able to complete step 4. ✘ But step 5—the important part, where I get the transfer ID—fails with an invalid_request error. I suspect this is because step 3 really was important. But I can't find a way to transfer an app that isn't really an app, just a website using the Sign In with Apple service. Anyway, any help would be greatly appreciated.

Hello, I have recently discovered that our company website, https://www.cgs.com, displays the message "Website Not Allowed, cgs.com is a restricted website." when accessed via iOS Safari. After investigation, I found that this occurs when the Limit Adult Websites option is enabled under Settings → Screen Time → Content & Privacy Restrictions → App Store,Media, Web, & Games → Web Content. I believe this restriction has been applied incorrectly to our website, and I would like to formally request that https://www.cgs.com be removed from this restricted list. Please let me know if any supporting materials or documentation are required from our side. Best regards

Instead of rejecting the extension with a reasonable, polite error, Safari on Tahoe crashes when the manifest.json file is properly formatted for Firefox instead of Chrome. ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: Safari [88741] Path: /Volumes/VOLUME/*/Safari.app/Contents/MacOS/Safari Identifier: com.apple.Safari Version: 26.4 (21624.1.16.11.4) Build Info: Safari-7624001016011004~1 Code Type: X86-64 (Native) Role: Background Parent Process: launchd [1] Coalition: com.apple.Safari [97627] User ID: 503 Date/Time: 2026-07-19 21:54:12.9042 -0700 Launch Time: 2026-07-18 10:38:48.3440 -0700 Hardware Model: MacBookPro16,2 OS Version: macOS 26.4.1 (25E253) Release Type: User Bridge OS Version: 10.4 (23P4242) Crash Reporter Key: E10AFED8-44D7-B68A-A06B-6237E159410E Incident Identifier: 0E512E91-4C4E-4D10-9518-6F0757C5E943 Sleep/Wake UUID: 5396E9EB-E238-4D56-BE08-D966DCE12528 Time Awake Since Boot: 580000 seconds Time Since Wake: 12175 seconds System Integrity Protection: enabled Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: UNKNOWN_0xD at 0x0000000000000000 Exception Codes: 0x000000000000000d, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 11, Segmentation fault: 11 Terminating Process: exc handler [88741] VM Region Info: 0 is not in any region. Bytes before following region: 4311683072 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 100ff1000-100ff2000 [ 4K] r-x/r-x SM=COW /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app/Contents/MacOS/Safari Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libunwind.dylib 0x7ff821b974b0 _Unwind_RaiseException + 240 1 libc++abi.dylib 0x7ff811ba5db4 __cxa_throw + 61 2 libobjc.A.dylib 0x7ff8117b8131 objc_exception_throw + 317 3 CoreFoundation 0x7ff811c832b7 -[__NSDictionaryM setObject:forKeyedSubscript:] + 1215 4 SafariSharedUI 0x7ffa19bdc6b5 -[WBSSafariExtensionStateObserver _addNamesForExtension:toMap:] + 205 5 SafariSharedUI 0x7ffa19bdc22d -[WBSSafariExtensionStateObserver _handleExtensionWasAdded:] + 208 6 CoreFoundation 0x7ff811cb1434 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 137 7 CoreFoundation 0x7ff811d388da ___CFXRegistrationPost_block_invoke + 88 8 CoreFoundation 0x7ff811d3882d _CFXRegistrationPost + 540 9 CoreFoundation 0x7ff811c8131c _CFXNotificationPost + 769 10 Foundation 0x7ff812ed3cd1 -[NSNotificationCenter postNotificationName:object:userInfo:] + 82 11 SafariSharedUI 0x7ffa19b769b8 -[WBSExtensionsController _loadExtensions:skipEqualityCheck:] + 2505 12 SafariSharedUI 0x7ffa19b74ec7 __59-[WBSExtensionsController loadSuitableDiscoveredExtensions]_block_invoke + 62 13 SafariSharedUI 0x7ffa19b74da0 -[WBSExtensionsController loadSuitableDiscoveredExtensions] + 133 14 SafariSharedUI 0x7ffa19c5cdd2 -[WBSWebExtensionsController loadSuitableDiscoveredExtensions] + 46 15 SafariSharedUI 0x7ffa19b7490f -[WBSExtensionsController _beginMatchingExtensionsWithAttributesCompletedWithMatchingExtensions:] + 537 16 SafariSharedUI 0x7ffa19b7460f -[WBSExtensionsController _extensionDiscoveryHasNewResults:] + 331 17 libdispatch.dylib 0x7ff811a47616 _dispatch_call_block_and_release + 12 18 libdispatch.dylib 0x7ff811a5d8b2 _dispatch_client_callout + 6 19 libdispatch.dylib 0x7ff811a78679 _dispatch_main_queue_drain.cold.6 + 842 20 libdispatch.dylib 0x7ff811a53dc4 _dispatch_main_queue_drain + 107 21 libdispatch.dylib 0x7ff811a53d4b _dispatch_main_queue_callback_4CF + 31 22 CoreFoundation 0x7ff811cf66b3 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 23 CoreFoundation 0x7ff811cbb15c __CFRunLoopRun + 2382 24 CoreFoundation 0x7ff811d828b7 _CFRunLoopRunSpecificWithOptions + 496 25 HIToolbox 0x7ff81e9f1b8b RunCurrentEventLoopInMode + 283 26 HIToolbox 0x7ff81e9f4c4d ReceiveNextEventCommon + 599 27 HIToolbox 0x7ff81eb7d0ba _BlockUntilNextEventMatchingListInMode + 37 28 AppKit 0x7ff816236d34 _DPSBlockUntilNextEventMatchingListInMode + 172 29 AppKit 0x7ff815b2c9d5 _DPSNextEvent + 800 30 AppKit 0x7ff8167dab53 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1265 31 AppKit 0x7ff8167da629 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 67 32 Safari 0x7ff927853839 -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 214 33 AppKit 0x7ff815b1d868 -[NSApplication run] + 472 34 AppKit 0x7ff815af34cd NSApplicationMain + 800 35 Safari 0x7ff92783fac1 SafariMain + 529 36 dyld 0x7ff81182abb8 start + 3240 Thread 1:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x7ff811bbcb4e mach_msg2_trap + 10 1 libsystem_kernel.dylib 0x7ff811bcaf49 mach_msg2_internal + 83 2 libsystem_kernel.dylib 0x7ff811bc3b64 mach_msg_overwrite + 586 3 libsystem_kernel.dylib 0x7ff811bbce54 mach_msg + 19 4 CoreFoundation 0x7ff811cbc2bf __CFRunLoopServiceMachPort + 145 5 CoreFoundation 0x7ff811cbad58 __CFRunLoopRun + 1354 6 CoreFoundation 0x7ff811d828b7 _CFRunLoopRunSpecificWithOptions + 496 7 AppKit 0x7ff815c7e6a0 _NSEventThread + 158 8 libsystem_pthread.dylib 0x7ff811c00d49 _pthread_start + 115 9 libsystem_pthread.dylib 0x7ff811bfc82f thread_start + 15 ...

I'm trying to run a MacOS shortcut using the "Run JavaScript on Active Safari Tab" action. I consistently get the error "Make sure that 'Allow JavaScript from Apple Events' is enabled in the Develop menu in Safari." The Develop menu in Safari does not contain this switch (in Tahoe 26.5.1), but if you go to Developer Settings... a dialog opens that includes the required switch. I've ensured that the switch is set on, but I continue to get the runtime error in the shortcut JavaScript. What am I missing?

Hello, I am investigating a WKWebView cookie reliability issue with WKWebsiteDataStore.default() / persistent website data, and I would like to request a supported public API to force persistent cookie durability. We set persistent cookies from native code through the public WKHTTPCookieStore API: let dataStore = WKWebsiteDataStore.default() let cookieStore = dataStore.httpCookieStore await cookieStore.setCookie(cookie) The cookies have Max-Age / maximumAge set, so these are persistent cookies, not session-only cookies. Reproduction pattern: Use WKWebsiteDataStore.default(). Clear existing cookies. Set a persistent cookie through WKHTTPCookieStore.setCookie. After setCookie completes, terminate WebKit's NetworkProcess soon afterward. Create or reuse a WKWebView with the same WKWebsiteDataStore.default(). Load a same-origin page or trigger a same-origin fetch. I also have reproducible WebKit source-level test cases for this, in the style of TestWebKitAPI / WKHTTPCookieStore tests. The tests exercise persistent WKWebsiteDataStore.default() cookies, terminate the NetworkProcess after the cookie mutation, and then verify that a top-level load, same-origin fetch, and WKHTTPCookieStore cookie read can miss the cookie on an unpatched WebKit build. Observed result: The next top-level HTTP request, and sometimes a same-origin fetch, can omit the cookie that was just set. After the NetworkProcess is relaunched, WKHTTPCookieStore.allCookies() can also fail to show the recently set cookie. If I wait long enough after the cookie mutation before terminating the NetworkProcess, the problem disappears. In local simulator testing, this lines up with CFNetwork appearing to debounce/coalesce persistent cookie writes in an approximately 2-to-10 second window. That makes this look like setCookie completion means the current NetworkProcess / CFNetwork cookie store accepted the cookie in memory, but the persistent cookie backing store has not necessarily been written yet. If the NetworkProcess dies before that delayed write, the replacement NetworkProcess appears to reload stale cookie state from disk. This is especially painful for apps that bridge native authentication state into WKWebView. The app sees setCookie complete, assumes the cookie is ready, and then a later WebKit NetworkProcess termination can cause authenticated web requests to be sent without the expected auth cookie. We believe that, at scale, this is a mechanism causing a baseline of about 5% of our HTTP requests, as measured by HAProxy, to lack cookies that should be present. We know those cookies should be present because we duplicate the same values as URLRequest headers under different keys, and the headers are present while the corresponding Cookie header entries are missing. The API gap is that there does not appear to be a supported public equivalent of Android WebView's CookieManager.flush(). There is no public way for an app to say: "I just mutated persistent WKWebView cookies; please synchronously/asynchronously flush the persistent cookie store before I proceed." Request: Please expose a public flush API for persistent WKHTTPCookieStore / WKWebsiteDataStore cookies, for example an async API shaped like: try await websiteDataStore.httpCookieStore.flush() or: try await websiteDataStore.flushCookies() The important behavior would be: after WKHTTPCookieStore.setCookie / deleteCookie completes, an app can explicitly request durability; the flush completion should mean persistent cookie state has been handed to the backing persistent store, not merely accepted by the current NetworkProcess; if flushing is impossible because the relevant process/state is gone, the API should fail or report that, rather than silently succeeding; the API should be safe for App Store apps and should not require private SPI. Question: Are there any recommended supported patterns today for forcing persistent WKWebView cookies to reach durable storage after native WKHTTPCookieStore mutations? Is there an official supported way to force or observe cookie durability for persistent WKWebsiteDataStore cookies? If not, is the recommended approach simply to re-apply critical cookies before loads and tolerate NetworkProcess loss as unrecoverable app-side state? This issue is not just theoretical. It affects auth/session reliability when WebKit's NetworkProcess is terminated before the backing persistent cookie write completes. Apps can reduce unnecessary cookie churn, but without a flush API there is no supported way to close the durability window after setting important persistent cookies.

Hello, I am developing a Safari extension that uses service workers and all works well. When the extension is updated, a new content script is injected into the current open tabs however the service worker connection with the new content script does not get established. I confirmed both the old content script and new one is on the page, but the new one just doesn't execute which means it will not connect to the service worker. In Chrome a newly injected content script does work and in FireFox it is handled by FireFox automatically. How can this be done in Safari? Any help would be appreciated.

Tested iPhone 16 Pro Max running DB2 Since using iOS 27 Developer Beta, Progressive Web Apps (PWAs) and applications using WKWebView that route live streaming audio (such as Icecast/SHOUTcast streams) through the Web Audio API (AudioContext / MediaElementAudioSourceNode for canvas visualizers) experience silent playback freezes during track changes. The JavaScript context remains active, and the HTMLMediaElement reports no errors or pauses, but the low-level system audio daemon (audiod) disconnects. The logs indicate a state desynchronization in MediaToolbox triggered by inline metadata frame updates, coupled with massive sandbox violations. Steps to reproduce: Run a PWA or WKWebView on iOS 27 Developer Beta that loads a live audio stream using an tag. Route the media element into the Web Audio API (e.g., audioContext.createMediaElementSource(audioElement)). Play the stream and lock the screen or let it run in the foreground. Wait for a track transition to occur on the live stream server (which pushes an inline ICY metadata update). Observed Result: Audio instantly goes silent at the track boundary. JavaScript rendering loops remain active, but the stream is dead. List of important errors: MediaToolbox parsing failure: <<<< FigStreamPlayer >>>> fpfs_CacheRenderChain: Caching unexpected mediatype metadata Reasoning: When the stream updates its inline metadata, MediaToolbox (FigStreamPlayer) fails to handle the frame descriptor correctly, halting the stream decoder render chain. Audio engine state desynchronization: <<<< FigStreamPlayer >>>> fpfs_SetRateOnTrack: [...] setting rate on track before it has reached playing state - 4 instead Reasoning: WebKit attempts to keep playing or setting the playback rate, but MediaToolbox fails because the underlying decoder track is stuck in an uninitialized/stalled state (4). System Audio Daemon Disconnection: Subsystem: com.apple.audioanalytics | Process: audiod Reporter disconnected. ( function=sendMessage, reporterID=... ) Reasoning: Because the rendering stream stalled, the system audio daemon (audiod) forcibly severs the audio session connection to the browser container. Massive Sandbox Log Flooding (WebKit.WebContent): Sandbox: com.apple.WebKit.WebContent(2719) deny(1) syscall-unix 179 Reasoning: WebKit's WebAudio thread tries to log trace markers to XNU's kdebug_trace64 (syscall 179) but is blocked by the WebContent sandbox profile, resulting in a loop of thousands of denials that clog the thread. What needs to be fixed: MediaToolbox (FigStreamPlayer): Fix the regression where incoming live stream metadata frames stall the render chain when connected to a Web Audio node. WebKit Sandbox Profiles: Update the iOS WebContent, Network, and GPU sandbox rules to allow necessary tracing/diagnostic calls (syscall-unix 179 and mach-lookup com.apple.diagnosticd) in developer beta builds to prevent thread-blocking loops.

A customer of my Safari app extension is reporting a strange interaction with a 3rd party content blocker that causes Safari to hang, apparently in code signing. Spindumps of Safari show this: Dispatch Thread Soft Limit Reached: 80 (too many dispatch threads blocked in synchronous operations) Each spindump has over 20 DispatchQueue "Content Blocker Containing App Validation Queue" In one spindump, it seems to be triggered by this: -[WBSExtensionsController _extensionDiscoveryHasNewResults:] + 244 (SafariSharedUI + 149396) In another: __114-[WBSExtensionsController(SafariExtras) safari_validateContainingAppOfExtensionIfNecessary:attemptRetryOnFailure:]_block_invoke.44 + 52 (Safari + 5305260) I can't reproduce the issue, however, so I'm baffled. The actual code signature of the app, which comes from the Mac App Store, appears to be fine, as verified with the codesign command-line utility.

We're handling our universal links (deep links) via our custom router written in express.js. We recently update our .well-known format as per: https://developer.apple.com/documentation/xcode/supporting-associated-domains Our own domain link shows them correctly if we apply cache bust to it: Normal link: https://links.sastaticket.pk/.well-known/apple-app-site-association Cache bust: https://links.sastaticket.pk/.well-known/apple-app-site-association?1 Now, since app-site cache is not updating at: https://app-site-association.cdn-apple.com/a/v1/links.sastaticket.pk Our main domain link is not getting updated response either. Its been more than 72 hours now. Any help, how to push the app-site cache to update? I can provide more context if needed, Thanks

你好，我的app使用的域名在阿里云进行了CDN加速，并配置了80的端口，后来我将端口改成443端口，导致如今app使用异常，是否将端口改回80端口就能恢复访问呢，如有建议，感激回复。

Hello there, Is it possible to customize the appearance of PWA icons for Liquid Glass? There was a similar question regarding the different icon appearances a few years ago (see thread). Though, as there never was a real conclusion I want to check if there are ways to achieve this by now? So, is it possible to define custom PWA icons for the dark and monochrome (now clear) modes? Can we maybe even use a fully custom Icon Composer icon for Safari PWAs? The icons attribute supports a purpose object with the value monochrome. Can this be used in any way here? If there is no way to customize it, is there at least a way to stop the auto conversion? In my case the white background get’s automatically replaced with the dark mode gradient, but for some reason the black logo isn’t converted/inverted to white leading to black on black logo. Which of course is not intended! I’d appreciate any help or pointer to a resource on that.

https://streamable.com/y16s4q When I leave the Spotify Web Player open on its homepage and remain completely idle (without any physical user interaction or clicks), the page somehow self-triggers an active audio stream. Instantly, Safari's standard "This tab is playing audio" speaker icon appears normally on the right side of the URL/Address bar. Simultaneously, the browser emits a 1–2 second burst of extremely accelerated, fast-forwarded, and chaotic audio (resembling a time-stretch or "Alvin and the Chipmunks" effect) before going silent or stabilizing.