How can I make a background image take the entire screen in ios26? I've tried position fixed, sticky, env() css variables but nothing worked. It does it when in PWA mode, but I would like to do so in the browser too.

Hello there, back in the old WebKit API there was the WKDownloadDelegate to handle download actions in WebViews. I was wondering how to handle download actions within the new WebKit in SwiftUI. Is there anything to use already or are there workarounds to handle downloads? Greetings, Thorben

Body:
Hi all, I’m seeing a puzzling discrepancy in behavior between NSURLSession (with multipathServiceType = NSURLSessionMultipathServiceTypeInteractive) and WKWebView when the device is connected to a Wi-Fi SSID that has no internet (e.g., a hardware device’s AP). I have the Multipath entitlement properly enabled, and in this scenario: NSURLSession requests automatically fall back to cellular and succeed (no user intervention, fast switch). WKWebView loads fail or stall: the web content does not appear, and it seems like the web view is not using the cellular path even though the system network path becomes satisfied and real Internet reachability is confirmed. Environment: iOS version: (e.g., iOS 18.4) Device: (e.g., iPhone 15 Pro) Multipath entitlement: enabled in the app, using NSURLSessionMultipathServiceTypeInteractive Connected SSID: hardware device Wi-Fi with no external internet Expected fallback: automatic to cellular once the Wi-Fi has no internet, as observed with NSURLSession What I’ve done / observed: NSURLSession using Multipath works as expected:
NSURLSessionConfiguration *cfg = [NSURLSessionConfiguration defaultSessionConfiguration];
cfg.multipathServiceType = NSURLSessionMultipathServiceTypeInteractive;
NSURLSession *session = [NSURLSession sessionWithConfiguration:cfg];
NSURLRequest *req = [NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.apple.com/library/test/success.html"]];
NSURLSessionDataTask *task = [session dataTaskWithRequest:req completionHandler:^(NSData *data, NSURLResponse *resp, NSError *err) {
NSLog(@"NSURLSession result: %@, error: %@", resp, err);
}];
[task resume];
When connected to the device Wi-Fi (no external internet), the session quietly shifts to cellular and completes successfully. WKWebView fails to load under the same conditions:
[self.webView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"https://www.apple.com/library/test/success.html"]]];
The web view either shows a load failure or just hangs, even though lower-level monitoring reports that the network path is satisfied and real Internet connectivity is available. Network path monitoring logic: I use the C API nw_path_monitor to watch for nw_path_status_satisfied. Once satisfied is observed, I perform a true connectivity check using nw_connection (e.g., connecting tohttps://www.apple.com/library/test/success.html) to verify that real Internet traffic can flow over cellular. That check passes, confirming fallback to cellular, but WKWebView still does not load content. Meanwhile, NSURLSession requests in the same condition succeed immediately. Sample logging trace:
[+] nw_path_status_satisfied=1, hasWiFi=1, hasCellular=1
[+] Internet connectivity test: ready (via nw_connection)
[-] WKWebView load failed / stalled
[+] NSURLSession request completed successfully Questions: Why does NSURLSession with the multipath service type seamlessly use cellular when the Wi-Fi has no internet, but WKWebView does not exhibit the same fallback behavior? Is WKWebView not honoring the system’s multipath fallback the same way? Does it use a different networking stack or ignore the multipath entitlement in this scenario? Is there a supported way to force WKWebView to behave like NSURLSession here? For example, can I bridge content through a multipath-enabled NSURLSession and inject it into WKWebView via a custom scheme? Are there any WKWebView configuration flags, preferences, or policies that enable the same automatic interface switching? Are there known limitations or documented differences in how WKWebView handles network interface switching, path satisfaction, or multipath compared to raw NSURLSession? What I’ve ruled out / tried: Verified the Multipath entitlement is included and active. Confirmed network path is “satisfied” and that real Internet reachability succeeds before calling [webView loadRequest:]. Delayed the WKWebView load until after connectivity verification. Observed that NSURLSession requests succeed under identical connectivity conditions. Any insight into internal differences, recommended workarounds, or Apple-recommended patterns for making web content robust in a “Wi-Fi with no internet” + automatic fallback-to-cellular scenario would be greatly appreciated. Thank you!

I don't think the issue is specific iOS 18. We have a web application that runs with IIS Authentication of Windows and Anonymous. Initially the app opens and the user clicks a button and triggers the "401 Challenge" via ASP.NET. The browser presents the Active Directory login, user enters credentials, clicks Sign In, and the browser hangs (may actually be negotiating something). After a few minutes the user is logged into the application. We have done a number of google searches/AI to try to determine what to change and there is no clear solution. Is there anything else to try? This problem is not seen in Chrome on iOS or on a Windows machine. Strangely it is also not seen using BrowserStack with one of their "real" devices. We have other apps that run with just Windows Authorization and this problem is not observed.

Hello, I am developing a website which starts a web worker using the js code: const zarrWorker = new Worker('./zarr_file.js', { type: 'module' });. The script 'zarr_file.js' is served from the same origin with Cross-Origin-Embedder-Policy: require-corp and Cross-Origin-Opener-Policy: same-origin and it is importing external modules through the import statement (e.g. import * as zarr from "https://cdn.jsdelivr.net/npm/zarrita/+esm";). All the external modules are blocked by Safari with the error Worker load was blocked by Cross-Origin-Embedder-Policy, although I can see (by running curl on them) that they correctly set cross-origin-resource-policy: cross-origin`. The same website works fine in Chrome and Firefox. Is it a bug or is Safari implementing stricter policies? In the latter case what would be the solution?

I am trying to setup web sign in with apple, I have an active apple subscription and have set up all necessary things. I made a service id in apple Identifiers, connected to existing primary id (also has apple sign in enabled). I have my domain set up also correctly but still I cant generate the code due to invalid client. What do I need to do? I have also tried recreating the service ids multiple times with no luck. my init is AppleID.auth.init({ clientId : '[CLIENT_ID]',//used the service id one not app id redirectURI : '[REDIRECT_URI]', usePopup : true }); link to generate codes now is: https://appleid.apple.com/auth/authorize?client_id=com.crmtournest.sigin&redirect_uri=https%3A%2F%2Fwww.tournestcrm.com%2Fauth%2Fcallback&response_type=code%20id_token&state=saciy7rn1km&scope=name%20email&response_mode=web_message&frame_id=03487c22-abb4-48cd-8613-d6bf5836e9eb&m=11&v=1.5.5 Also tried: https://appleid.apple.com/auth/authorize?client_id=com.crmtournest.sigin&redirect_uri=https%3A%2F%2Fwww.tournestcrm.com%2Fauth%2Fcallback&response_type=code%20id_token (not working) I get invalid_client setup on apple below:

Our app, VitalSource Bookshelf, is an EPUB reader that uses a WKWebView to display book content. The EPUB content format is XHTML and uses namespaces (for the epub:type declaration). On beta 4, the webkit process repeatedly crashes when loading our content. The crash appears to be in the XML parser. Here's what's at the top of the stack trace: 0 WebCore 0x19166a878 WebCore::XMLDocumentParser::startElementNs(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) + 4968 1 libxml2.2.dylib 0x19c5a2bd0 xmlParseStartTag2 + 3940 2 libxml2.2.dylib 0x19c59e730 xmlParseTryOrFinish + 2984 3 libxml2.2.dylib 0x19c59d8e4 xmlParseChunk + 708 4 WebCore 0x191668ec8 WebCore::XMLDocumentParser::doWrite(WTF::String const&) + 636 5 WebCore 0x191665b78 WebCore::XMLDocumentParser::append(WTF::RefPtr<WTF::StringImpl, WTF::RawPtrTraits<WTF::StringImpl>, WTF::DefaultRefDerefTraits<WTF::StringImpl>>&&) + 304 6 WebCore 0x190105db0 WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter&, std::__1::span<unsigned char const, 18446744073709551615ul>) + 268 7 WebCore 0x190861c3c WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) + 1488 8 WebKit 0x18e07ca3c WebKit::WebLocalFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, WebCore::SharedBuffer const&) + 52 9 WebCore 0x190869db4 WebCore::DocumentLoader::commitLoad(WebCore::SharedBuffer const&) + 228 10 WebCore 0x1909521e4 WebCore::CachedRawResource::notifyClientsDataWasReceived(WebCore::SharedBuffer const&) + 268 I was able to reproduce this in Safari on beta 4 just by opening the following trivial xhtml file from the file system - it does the same thing it does in our app, which is reloads and crashes several times, followed by the "A problem repeatedly occurred with..." error message. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="vst: http://vitalsource.com/"><head></head><body class="dash" epub:type="chapter" data-begin-o="0" data-begin-o2="0" data-begin-o3="0" data-o="0" id="eid1844" data-end-o="14703" data-end-o2="14703" data-end-o3="14703"><h2 class="title" data-o="0" id="eid1845" data-out="33"><span class="label" data-o="0" id="eid1846"><span class="label-inner"><b data-o="0" id="eid1847">CHAPTER X</b> </span></span>THE SUBMARINE COAL-MINES</h2></body></html> I've also filed a feedback. But posting here just to raise the visibility - this is critical for us. I think it was introduced in beta 4; that's at least when we first noticed it. It was working in the earlier betas, I just don't remember if I tried beta 3 or not. It happens on iOS, macOS, and iPadOS. This has never been a problem in any earlier release of macOS / iOS.

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

Trying to implement my own forward/back buttons for the new SwiftUI WebView and reading the documentation I’m totally lost. What’s the recommended way of implementing forward/back behavior with this component?

Hi guys, I'm trying to use sign in with apple in javascript, I followed the guider in the website, and almost find everything I can find in Google, but nothing help, here is my situation: I create a new App: com.yuhan.test.app I create a new service ID: com.yuhan.test.service configure a domain and return url domain: tts.perterpon.com returnURL: https://tts.perterpon.com/login create a new key for Sign In with Apple. my html code is here, it's easy, but it always told me invalid_client, I think I have done anything I need to do, can somebody help me? Thank you so much. you can test my online web site: https://tts.perterpon.com/login.html ` const buttonElementNew = document.getElementById('appleid-signin'); buttonElementNew.addEventListener('click', async () => { try { const data = await AppleID.auth.signIn() console.log('Try/Catch Data', data.authorization.id_token); const formData = new FormData(); formData.append("token", data.authorization.id_token); await fetch("", { method: "POST", body: formData, }); // Handle successful response. } catch (error) { // Handle error. } }); </script>

How did you test apple-app-site-association in non-production environments that are usually not public?

I am a newby to JavaScript, suggested to me to use to automate the task of opening of a Web page, selecting three internal buttons in sequence to download the underlying chart data. I have created the App via Automator on macOS, to run the Script, successfully open the Web Page, but cannot find a way to select and click() on the buttons. Can someone please help me. Robert. This is the code suggested by Grok 3 Beta, but I see this error: Error: First parameter passed to Document Constructor must be an object. function run(input, parameters) { var Safari = Application('Safari'); Safari.activate(); // Open the AEMO data dashboard (Grok 3 Beta recomendation opens the web page correctly) Safari.Document().make(); Safari.windows[0].currentTab.url = 'https://www.aemo.com.au/energy-systems/electricity/national-electricity-market-nem/data-nem/data-dashboard-nem'; delay(10); // Wait for page to load // Click the Fuel Mix tab (target the active in the tabs) Safari.Document(0).doJavaScript("document.querySelector('.tabs .active').click()"); delay(5); // Wait for tab content to load // Select 48 hrs from the dropdown Safari.Document(0).doJavaScript("document.querySelector('#interval').value = '48H'; document.querySelector('#interval').dispatchEvent(new Event('change'))"); delay(5); // Wait for selection to take effect // Click the download button Safari.Document(0).doJavaScript("document.querySelector('.visualisation-icon-button').click()"); return input; }

On my native app, will open a wkWebview to display some content. And it will crash on iOS26: *** Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan 103.667]. Layer: <CALayer:0x14c2457d0; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x14c273980; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x14c2457d0>>; sublayers = (<CALayer: 0x1306320a0>, <CALayer: 0x14c245a70>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0>'

iOS18的app中加载了自己开发的H5页面，H5页面有个input输入框，每次输入框聚焦的时候，都会弹出键盘滑行键入的提示：“滑动手指将字母拼成词以快速键入”，应该怎么修改，达到不每次都弹出这个提示呢

version:26.0-23A5308g Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan 103.667]. Layer: <CALayer:0x15793f720; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x10f962f80; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x15793f720>>; sublayers = (<CALayer: 0x155964e70>, <CALayer: 0x15793eaf0>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0>'

Our iOS app uses React Native Webview (based on top of WKWebView) to display content. This webview stays in memory throughtout the app's lifecycle. We are observing a high number of webview content process terminations - around 15% of our sessions. (https://developer.apple.com/documentation/webkit/wknavigationdelegate/webviewwebcontentprocessdidterminate(_:)) What could be the reasons for it? Is there a way to know for sure? Is the 15% of sessions number something that other apps also experience, or should this be lower? Thanks!

Environment • Device: iOS 26 Developer Beta 5 (23A5308g) • Xcode: 16.3 Short description The app crashes the moment the user tries to long-press to select text inside a WKWebView, double-tap an image with Text (magnifier appears) The exception is CALayer position contains NaN. frame = (nan,0;0,48) chorPoint=(inf, 0) and it is thrown in the UI process. Build &amp; run any project that hosts a WKWebView. Inject the following CSS via script (this is what we do to suppress the native callout menu): WKWebView *webView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:[WKWebViewConfiguration new]]; NSString *js = @"document.documentElement.style.webkitUserSelect='none';" "document.documentElement.style.webkitTouchCallout='none';"; [webView evaluateJavaScript:js completionHandler:nil]; [self.view addSubview:webView]; Incident Identifier: EE6FB046-5087-4F15-A72D-A74965347A30 CrashReporter Key: 29e8e58e02a07557adb4ce3f463d764f3ce8bbd5 Hardware Model: iPhone16,1 Process: wallet [642] Path: /private/var/containers/Bundle/Application/4B4E609A-C8BF-4C56-AB2A-1638249B98A5/wallet.app/wallet Identifier: xxxx Version: xxxx AppStoreTools: 16F7 AppVariant: 1:iPhone16,1:18 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: xxxxx Date/Time: 2025-08-06 12:05:24.0732 +0800 Launch Time: 2025-08-06 11:49:40.3802 +0800 OS Version: iPhone OS 26.0 (23A5308g) Release Type: Beta Baseband Version: 3.02.02 Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: wallet [642] Triggered by Thread: 0 Application Specific Information: abort() called Last Exception Backtrace: 0 CoreFoundation 0x185e058c8 __exceptionPreprocess + 164 1 libobjc.A.dylib 0x182d797c4 objc_exception_throw + 88 2 CoreFoundation 0x185e908d4 -[NSException initWithCoder:] + 0 3 QuartzCore 0x18678a874 CA::Layer::set_position(CA::Vec2&lt;double&gt; const&amp;, bool) + 160 4 QuartzCore 0x1869a7270 -[CALayer setPosition:] + 52 5 UIKitCore 0x18c4ac564 -[UIView _backing_setPosition:] + 176 6 UIKitCore 0x18cefdf0c -[UIView setCenter:] + 220 7 UIKitCore 0x18cd9f794 -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] + 936 8 UIKitCore 0x18cd9f3c0 __54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke + 104 9 UIKitCore 0x18ced1060 -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] + 384 10 UIKitCore 0x18cd9f2e4 -[_UIEditMenuContentPresentation _displayMenu:reason:] + 304 11 UIKitCore 0x18cd9f0d8 -[_UIEditMenuContentPresentation displayMenu:configuration:] + 64 12 UIKitCore 0x18ced0344 __58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke + 260 13 UIKitCore 0x18ced1f8c __80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke + 80 14 UIKitCore 0x18cc8403c __109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke + 180 15 UIKitCore 0x18cc84584 __107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke + 148 16 WebKit 0x1a05ae5d4 WTF::CompletionHandler&lt;void (WebKit::DocumentEditingContext&amp;&amp;)&gt;::operator()(WebKit::DocumentEditingContext&amp;&amp;) + 64 17 WebKit 0x1a05bb468 WTF::Detail::CallableWrapper&lt;WTF::CompletionHandler&lt;void (IPC::Connection*, IPC::Decoder*)&gt; IPC::Connection::makeAsyncReplyCompletionHandler&lt;Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler&lt;void (WebKit::DocumentEditingContext&amp;&amp;)&gt;&gt;(WTF::CompletionHandler&lt;void (WebKit::DocumentEditingContext&amp;&amp;)&gt;&amp;&amp;, WTF::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*&gt;::call(IPC::Connection*, IPC::Decoder*) + 196 18 WebKit 0x19fcf5db8 WTF::Detail::CallableWrapper&lt;WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef&lt;IPC::Encoder&gt;&amp;&amp;, WTF::OptionSet&lt;IPC::SendOption&gt;, std::__1::optional&lt;IPC::ConnectionAsyncReplyHandler&gt;, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*&gt;::call(IPC::Connection*, IPC::Decoder*) + 64 19 WebKit 0x19fce54f0 IPC::Connection::dispatchMessage(WTF::UniqueRef&lt;IPC::Decoder&gt;) + 340 20 WebKit 0x19fcf5aa0 IPC::Connection::dispatchIncomingMessages() + 536 21 JavaScriptCore 0x19a8f85d4 WTF::RunLoop::performWork() + 552 22 JavaScriptCore 0x19a8f838c WTF::RunLoop::performWork(void*) + 36 23 CoreFoundation 0x185da6230 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 24 CoreFoundation 0x185da61a4 __CFRunLoopDoSource0 + 172 25 CoreFoundation 0x185d83c6c __CFRunLoopDoSources0 + 232 26 CoreFoundation 0x185d598b0 __CFRunLoopRun + 820 27 CoreFoundation 0x185d58c44 _CFRunLoopRunSpecificWithOptions + 532 28 GraphicsServices 0x224ce0498 GSEventRunModal + 120 29 UIKitCore 0x18b6c84b8 -[UIApplication _run] + 792 30 UIKitCore 0x18b66cbc0 UIApplicationMain + 336 31 wallet 0x1046f8558 0x1046f4000 + 17752 32 dyld 0x182dcdb18 start + 6332

Hello, We are developing a Safari Web Extension that uses a cookie-based authentication mechanism. The extension makes a request to an endpoint e.g. /login, and this endpoint expects a cookie (e.g., sessionId) to be included with the request. Everything works correctly when running in the default Safari profile. However, when I install and run the same extension in a new, non-default profile, the behaviour changes: The request to /login is still made The cookie sent is not as expected As a result, the response returns null user data I confirmed that logging into the site in the new profile (in a tab) works, but the extension does not appear to share the session/cookie state with the login tab We’ve tried explicitly setting "credentials": "include" in the request but that still didn’t share the cookie in the extension context in the non-default profile. My questions: Is there away to allow cookie-based session sharing between a tab and an extension in non-default profiles in safari? Would switching to a token-based auth mechanism (e.g., Bearer tokens ) be the recommended workaround? I’d appreciate any insights or guidance from those who’ve run into similar issues. 
 Thanks in advance!

Our app encountered a new crash since beta5(23A5308g) released last week,and it seems the crash is not solved yet in beta6(23A5318c).The crash stack below `-[UIView _backing_setPosition:] -[UIView setCenter:] -[_UIEditMenuContentPresentation _displayPreparedMenu:titleView:reason:didDismissMenu:configuration:] ___54-[_UIEditMenuContentPresentation _displayMenu:reason:]_block_invoke -[UIEditMenuInteraction _editMenuPresentation:preparedMenuForDisplay:completion:] -[_UIEditMenuContentPresentation _displayMenu:reason:] -[_UIEditMenuContentPresentation displayMenu:configuration:] ___58-[UIEditMenuInteraction presentEditMenuWithConfiguration:]_block_invoke ___80-[UIEditMenuInteraction _prepareMenuAtLocation:configuration:completionHandler:]_block_invoke ___109-[UITextContextMenuInteraction _editMenuInteraction:menuForConfiguration:suggestedActions:completionHandler:]_block_invoke ___107-[UITextContextMenuInteraction _querySelectionCommandsForConfiguration:suggestedActions:completionHandler:]_block_invoke WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&) WTF::Detail::CallableWrapper<IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)> >(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::{lambda(IPC::Connection*, IPC::Decoder*)#1}, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRefIPC::Encoder&&, WTF::OptionSetIPC::SendOption, std::__1::optionalIPC::ConnectionAsyncReplyHandler, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) IPC::Connection::dispatchMessage(WTF::UniqueRefIPC::Decoder) IPC::Connection::dispatchIncomingMessages() WTF::RunLoop::performWork() WTF::RunLoop::performWork(void*) _CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION ___CFRunLoopDoSource0 ___CFRunLoopDoSources0 ___CFRunLoopRun __CFRunLoopRunSpecificWithOptions _GSEventRunModal -[UIApplication _run] _UIApplicationMain main main.m start

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