Safari 18.2 on Sequoia 15.2 sends repeated Authorization header when iCloud Relay is enabled and the page is reloaded.
Inside Safari Preferences -> Privacy -> Hide IP address -> from Trackers and Websites (ensure this is enabled)
Visit a website that uses HTTP Authorization and authenticate oneself
Reload website a couple of times and it will result in an HTTP 400 error due to repeat Authorization header sent by Safari
Explore the integration of web technologies within your app. Discuss building web-based apps, leveraging Safari functionalities, and integrating with web services.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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!
Topic:
Safari & Web
SubTopic:
General
I’m encountering an issue with a Safari extension bundled with our main application (F-Secure). The extension is not appearing consistently in Safari settings on a customer’s iPad running iOS 18.3. Below are the details of the issue:
Issue Description
The Safari extension is bundled with the main app (F-Secure).
After installing the app, the extension should automatically appear in Settings > Safari > Extensions, where the user can enable it.
On the customer’s iPad, the extension is missing from the Safari settings. It briefly appeared once but then disappeared again.
"The Referer header allows a server to identify referring pages that people are visiting from or where requested resources are being used. "
This header is never forwarded to server when the user is browsing the website in a WebView. This is properly maintained by other browsers but not in-app.
How do I include it?
Topic:
Safari & Web
SubTopic:
General
As of IOS 18.3, there browser.tabs.create methods active property which is supposed to determine whether a tab get open in the active window or not is not working as it should. I have the active property set to false but the tab still gets opened and is active on the window. Tested on older ios versions 18.2 and below and it works as it should.
please advise
Bug Report:
Safari refuses to render content that is position: fixed or position: sticky if it goes below the iOS 26 navigation controls at the bottom of the browser. Since the controls are transparent and floating, this is a problem as fixed content is effectively unable to reach the bottom of the page. Attempting to move it below 100vh causes it to be cut off rather than rendering behind the navigation elements.
Here is some code reproducing the issue:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<style>
html,
body {
margin: 0;
padding: 0;
background-color: #363636;
}
#just-a-bird {
position: fixed;
bottom: -100px;
width: 300px;
height: auto;
background: red;
}
</style>
</head>
<body>
<img id="just-a-bird"
src="https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Cattle_tyrant_%28Machetornis_rixosa%29_on_Capybara.jpg/640px-Cattle_tyrant_%28Machetornis_rixosa%29_on_Capybara.jpg">
</body>
</html>
Since Safari requires a macOS app as a container for Web Extensions, is there a way to establish native messaging directly from SafariWebExtensionHandler using stdin/stdout? Or does Safari enforce a different communication mechanism?
I’d like to keep the same approach as other browsers.
Any guidance on making this work would be appreciated!
Hello,
In iOS 26 beta, we are seeing an unexpected behavior when using SwiftUI WebView (or a custom WKWebView via UIViewRepresentable).
When an alert is presented above the WebView, the WebView immediately reloads to its initial page. The alert itself also disappears instantly, making it impossible for the user to interact with it.
This issue occurs both with the new SwiftUI WebView / WebPage API and with a wrapped WKWebView. The problem was not present in previous iOS versions (iOS 17/18).
Steps to reproduce:
Create a SwiftUI view with a WebView (pointing to any URL).
Add a toolbar button that toggles a SwiftUI alert.
Run the app on iOS 26 beta.
Tap the button to trigger the alert.
Expected behavior:
The WebView should remain as-is, and the alert should stay visible until the user dismisses it.
Actual behavior:
As soon as the alert appears, the WebView reloads and resets to the initial page. The alert disappears immediately.
Minimal Example:
struct ContentView: View {
@State private var showAlert = false
var body: some View {
NavigationStack {
WebView(URL(string: "https://apple.com")!)
.toolbar {
ToolbarItem(placement: .topBarTrailing) {
Button("Close") {
showAlert = true
}
}
}
.alert("Confirm close?", isPresented: $showAlert) {
Button("Cancel", role: .cancel) {}
Button("Close", role: .destructive) {}
}
}
}
}
I'm using Xcode Version 26.0 beta 7
Thanks for your help.
PLATFORM AND VERSION
iOS
Development environment: Xcode 16.2, macOS 15.3.2
Run-time configuration: iOS 15-18
This happens in iOS, and leads to to the hybrid home page showing users as wrongly unauthenticated, since the at cookie is missing. For context, we have a JWT token that is stored in the Keychain, and on app launch, before any WKWebViews are created, we synchronize this to the WKWebsiteDataStore as an at cookie.
We have analytics instrumentation on our websitef to show that WKWebView randomly refuses to send out any cookies.
–
The following is a snippet from an explanation to the WebKit Slack:
We are having an issue on iOS, in which WKWebView loads pages (and even subsequent reloads) without any cookies, even though we have stored cookies in WKWebsiteDataStore.default() before hand right after application launch and becoming a key window. We reference this object, store it as a singleton, (as well as a process pool), and then all webview configurations are initialized with the same data store, the same process pool, every call on the main thread. From reading the source code, it seems that if the internal IPC logic fails, the APIs for deleting and setting data records and cookies fail without any feedback in completion handlers.
This bug often happens when returning from the background on iOS after a few hours. Sometimes it happens on cold launches of the app. We have mitigated a similar issue (no cookies being sent) by implementing webViewWebContentProcessDidTerminate and reloading the webview ourselves, we found that whatever webview does to reload if that method is not implemented leads to cookies not being used.
There have been multiple reports of WKWebView losing cookies in recent iOS versions, and we have tried to implement all of the workarounds listed. Setting a maximumAge to the cookies we store, and doing a _ = await websiteDataStore.dataRecords(ofTypes: Set([WKWebsiteDataTypeCookies])) before accessing or modifying websiteDataStore.httpCookieStore
Question: is it safe to work with WKWebsiteDataStore before a WKWebView is added as a view, if so are there any timing considerations? Are there any logs that we can take a look at, this issue is very hard to reproduce, about 2% of our users face it at scale? Is there anything that could be happening within our process (runloop issues, timing) that could be causing this issue?
See multiple reports from other companies that have faced the issue: "Now the Thermonuclear Problem with WKWebViewDataStorage"
https://medium.com/axel-springer-tech/synchronization-of-native-and-webview-sessions-with-ios-9fe2199b44c9
STEPS TO REPRODUCE
They don't exist, because the issue only happens at scale. We just know that no cookies are sent for a small percentage of requests. We believe this to be an issue in which Webkit fails to communicate internally with whatever IPC mechanisms it has.
We have not been able to reproduce this issue consistently. The best we can give is that it happens after a few hours that the app is in the background. This happens regardless of whether the WKWebsiteDataStore is persistent or not, but seems to be much worse when it is persistent. Thus we have disabled persistnet data stores and relied on nonPersistent.
The issue is bad enough that we are trying to move away from relying on cookies for iOS and just use request headers which we can only set on the top level request of WKWebView.
DTS Case-ID: 13154329
Topic:
Safari & Web
SubTopic:
General
I have observed Safari App starts crashing when running with my safari extension.
Our Safari extension polls the host app every 60s. The extension receives and completes requests in
func beginRequest(with context: NSExtensionContext)
(we always call context.completeRequest(...)). The crash is intermittent: beginRequest itself does not throw.
Looking for guidance about likely causes. I am attaching the snippet from crash report.
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace RUNNINGBOARD, Code 3490524077
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x1856f5c34 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x1857083a0 mach_msg2_internal + 76
2 libsystem_kernel.dylib 0x1856fe764 mach_msg_overwrite + 484
3 libsystem_kernel.dylib 0x1856f5fa8 mach_msg + 24
4 CoreFoundation 0x185822cbc __CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x1858215d8 __CFRunLoopRun + 1208
6 CoreFoundation 0x185820a98 CFRunLoopRunSpecific + 572
7 HIToolbox 0x1912c327c RunCurrentEventLoopInMode + 324
8 HIToolbox 0x1912c64e8 ReceiveNextEventCommon + 676
9 HIToolbox 0x191451484 _BlockUntilNextEventMatchingListInModeWithFilter + 76
10 AppKit 0x189745a34 _DPSNextEvent + 684
11 AppKit 0x18a0e4940 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
12 Safari 0x1b801cce4 -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 228
13 AppKit 0x189738be4 -[NSApplication run] + 480
14 AppKit 0x18970f2dc NSApplicationMain + 880
15 Safari 0x1b83dd0b0 SafariMain + 468
16 dyld 0x185396b98 start + 6076
Hello all,
As you may know, the company ProofPoint is an Apple partner, and is engaged (I think) to reduce misuse of icloud emails.
We have two servers solely set up for our web-app, which is a specialised forum for apartment owners.
The new servers were established about the same time, with the same provider, with clean new IP addresses - and as mentioned above, are only used for this web-app.
During a testing phase a YEAR ago, we became aware that our in-house icloud emails weren't receiving notifications via the app, and further investigations revealed that the cause was that ProofPoint had placed a block on that server's IP.
We immediately, via their website form initiated a Support Ticket, which, the site indicated was lodged, BUT we have never received any response to that Ticket, nor have we received any response to four subsequent Tickets we initiated - nothing. In over a year!!
Yesterday, we contacted Apple support, but the devices area of support is the main section and they said it wasn't an issue they could assist with.
Some relevant matters:
SPF: DKIM: DMARC:
are, I believe all configured correctly (and Gmail gives a PASS to all of them).
The IP is not blacklisted by any list we are aware of.
Our other server's IP isn't blocked by ProofPoint.
So, literally at wits end, I'm reaching out to the developer subscribers here to see if they have any suggestions for us.
We currently are unable to accept any new subscriber that is using an icloud email address, and that's an absurd situation to be in.
Surely we don't have to go to the trouble and inconvenience of obtaining a new IP because of this!!! But when we can't get ANY response to the Support Tickets, it's really hard.
Thanks
Topic:
Safari & Web
SubTopic:
General
I recently noticed that putting the app on background for some time, then switching back to it again causes the WKWebView to reload the current page, same with just hitting f5 on it. How do we disable this behavior?
Dear Apple Developer Experts,
We're experiencing an intermittent issue with WKWebView in our macOS application where local HTML file access is occasionally denied by the sandbox, despite proper implementation and permissions. We seek your guidance in understanding and resolving this issue.
Issue Description:
The WKWebView occasionally fails to load local HTML files stored in the app's Contents/Resources directory
Error occurs in WebKit Networking Process with sandbox denial
Issue is intermittent and can be resolved by app restart or WebKit Networking Process restart
Affects all local HTML files in the same directory once the issue occurs
Technical Details:
Error from Kernel Log:
2025-02-07 14:57:17.179821 +0800 kernel Sandbox: com.apple.WebKit.Networking(58661) deny(1) file-read-data /Applications/DingTalk.app/Contents/Resources/webcontent/contact-2024.html
WKWebView Delegate Error (captured in WKNavigationDelegate method):
(void)webView:(WKWebView *)webView didFailProvisionalNavigation:(WKNavigation *)navigation withError:(NSError *)error
Error Details:
Domain: NSPOSIXErrorDomain
Code: 1
Description: "Operation not permitted"
UserInfo: {
networkTaskMetricsPrivacyStance: Unknown,
_NSURLErrorFailingURLSessionTaskErrorKey: LocalDataTask <3694CA1E-481B-4E06-975D-E3A56AD56C0F>.<1>,
_kCFStreamErrorDomainKey: 1,
_kCFStreamErrorCodeKey: 1
}
Key Observations:
Error is captured in WKNavigationDelegate's didFailProvisionalNavigation method
The issue affects all local HTML files in the same directory once it occurs
Temporary workarounds we've discovered:
Restarting the application completely resolves the issue
Without restarting the application, terminating the "WebKit Networking Process" via Activity Monitor causes the process to automatically restart, and this resolves the issue and load works again
Additional Information:
We've collected complete system diagnostics (system_logs.logarchive) at the time of failure
The issue appears similar to discussions in Apple Developer Forums (https://developer.apple.com/forums/thread/110072), though we're uncertain if it's the same root cause
We've prepared a minimal demo project demonstrating:
Our release version app can be downloaded from: https://dtapp-pub.dingtalk.com/dingtalk-desktop/mac_dmg/Release/M1-Beta/DingTalk_v7.6.45_43521682_universal.dmg?spm=0.0.0.0.UuwovG&file=DingTalk_v7.6.45_43521682_universal.dmg for examining our app's codesign, sandbox, and entitlements configurations if needed
Important Investigation Finding:
We attempted to simulate the issue by using chmod 000 /path/to/test.html, but this produces a different error:
CopyError Domain=NSURLErrorDomain
Code=-1102
Description="You do not have permission to access the requested resource."
UserInfo={
NSLocalizedDescription=You do not have permission to access the requested resource.,
NSErrorFailingURLStringKey=file:///Users/sunus/Library/Developer/Xcode/DerivedData/WKWebViewLocalDemo-eumardnlfbmwgnhkaadglsrrhzhs/Build/Products/Debug/WKWebViewLocalDemo.app/Contents/Resources/test.html,
NSUnderlyingError=0x600003aedc50 {Error Domain=kCFErrorDomainCFNetwork Code=-1102 "(null)"}
}
This error is distinctly different from our original issue's "Operation not permitted" error, suggesting that the sandbox denial we're experiencing is not a simple file permission issue.
Questions:
Is this a known issue with the WebKit sandbox in recent macOS versions?
Are there recommended best practices or workarounds to prevent this sandbox denial?
Could this be related to the WebKit Networking Process's sandbox configuration?
Are there additional diagnostics or logs we should collect to help investigate this issue?
We appreciate your assistance in investigating this issue. Please let us know if you need any additional information or clarification.
STEPS TO REPRODUCE
Open App
Then loads the local file in /WKWebViewLocalDemo.app/Contents/Resources/test.html
PS, We also submit a DTS & Feedback
DTS:Case-ID: 11876957
Feedback-ID: FB16493282
sysdiagnose is in the Feedback-ID: FB16493282 is uploaded
Our current iOS application utilizes WKWebView to display a web application. We've observed intermittent deletion of non-expired 1st-party persistent cookies within this web application, leading to session drops.
Here are our environment details and specific questions:
Environment:
App Build: Built with Xcode 16.2.
WebView Class: WKWebView.
Cookie Type: 1st-Party Persistent Cookie (Explicit expiration set, not a session cookie).
Domain Configuration: The content server and the cookie-issuing server are the same (same IP address, same eTLD+1). The Cookie is set via the Set-Cookie HTTP Header on the server side.
Questions:
Automatic Deletion Policy: Are there any scenarios (e.g., related to iOS system behavior, Safari policies, or Intelligent Tracking Prevention (ITP)) where iOS or Safari might automatically delete non-expired 1st-party persistent cookies used by WKWebView?
Deletion Conditions: If the answer to Q1 is Yes, under what specific conditions (e.g., memory pressure, inactivity, storage limits, specific ITP criteria) does this cookie deletion occur, and does the behavior differ significantly across various iOS versions?
OS Update Impact: Are there any known specifications or documented cases where an iOS version update itself triggers the mass deletion of existing cookies stored in the WKWebsiteDataStore?
Mitigation Strategy: If this automatic deletion is a known behavior, what mitigation strategies are officially recommended to ensure the persistence of essential 1st-party authentication cookies (e.g., manual synchronization with WKHTTPCookieStore or Keychain/UserDefaults)?
Official Documentation: If the answer to Q1 is Yes, please provide URLs to any official Apple documentation or technical notes that detail the specifications or behavior of 1st-party persistent cookie deletion within WKWebView.
Topic:
Safari & Web
SubTopic:
General
//Is my post method correct because google and claude are telling me I must use content type for the json and use .setvalue. I thought that my process was correct because I encode the data to turn into json and then make the request
func createTask(_ task: Task) async throws -> Task {
if let url = URL(string: "(baseURL)/todos"){
var request = URLRequest(url: url)
request.httpMethod = "POST"
let encoder = JSONEncoder()
do{
let data = try encoder.encode(task)
request.httpBody = data
let (data, response) = try await URLSession.shared.data(for: request)
return task
//we want to make encoder and then turn the data into json and put it in body
}
catch{
throw JSONErrors.encodingFailed
}
}
else{
throw URLError(.badURL)
}
}
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
We’re encountering an issue when trying to add non-standard headers to outgoing requests using Declarative Net Request (DNR) rules in our Safari Web Extension.
Tested on macOS 15.4 with Safari 18.4.
Specifically, when attempting to add a custom header such as "X-Custom-Header" using a DNR rule, the header does not appear in the request. We are able to add standard headers like "Authorization" and "Cookie" to the request successfully using the same method.
This behavior suggests that Safari may be filtering or blocking non-standard headers when set via DNR rules, unlike other browsers.
In Chrome and Firefox, the same rule adds the "X-Custom-Header" header without any issue.
We are looking for assistance in fixing these issues and having our Safari Extension function the same as it does in Firefox and Chrome.
Hello,
I am experiencing an issue when trying to open the browser on my Apple Watch SE 2 running the latest version, watchOS 11.6. When I attempt to visit any website, the browser opens and displays the URL at the top as if it is loading, but the screen remains black and no content is displayed.
The internet connection is available, and all other apps on the watch work normally. This issue occurs only with the browser.
I would appreciate any guidance or solution to resolve this problem.
Thank you for your assistance.
When the “Use Strong Password?” dialog appears and I select “Not Now” to manually enter my own password, the password I type is displayed in plain text instead of being masked. Since the input field is of type="password", the entered characters should be hidden as is standard for password inputs.
Is there a way to prevent this behavior and ensure that the password is properly hidden even after dismissing the strong password suggestion dialog?
Topic:
Safari & Web
SubTopic:
General
I'm building a macOS Google Chrome extension.
I need to be able to send messages from the Chrome extension to the macOS app
What's the set up flow?
I've heard about native messaging, but I struggle to implement it.
I've heard about XPC, but not sure JS can send messages to a macOS XPC service.