When configuring a Per-App VPN payload with 250+ Safari domains under a managed app, the VPN does not trigger for the other managed apps(like chrome etc). However, the same VPN successfully starts and works when used with Safari. Reducing the number of Safari domains in the VPN payload resolves the issue, allowing the VPN to trigger for the managed app as expected.
Has anyone else faced this issue, and what's the workaround for it?
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
Background
On iOS 18.4 beta, setting a content inset on a WKWebView causes touch events inside the web view to be offset by the content inset amount. In other words, if the web view has a top content inset of 75 points, I must tap 75 points above the intended element for the touch to register correctly. This makes any web content unusable when a content inset is present.
A sample app demonstrating the issue is available here: GitHub - iOS18.4-Webview-Bug.
The issue does not occur in iOS 18.3 or 18.2.
Bug Report
The bug has been reported and fixed at WebKit Bug 289715 and also filed as rdar://147075945.
Question
Will the fix be included in the upcoming iOS 18.4 beta release (Beta 5) or soon thereafter?
Safari 26 close and Refresh buttons not working in Compact tab layout
Topic:
Safari & Web
SubTopic:
General
Hi everyone,
We’ve recently run into an issue with Apple Pay on the web and would appreciate some clarification.
Background:
Previously, we integrated Apple Pay without using the Apple Pay JS SDK.
We relied on ApplePaySession.canMakePayments() to check availability, and it worked fine.
After Apple announced support for browsers beyond Safari, we switched to the Apple Pay JS SDK.
According to Apple’s documentation, we should now use applePayCapabilities() for capability checks in third-party browsers.
Our current behavior:
We implemented applePayCapabilities().
Initially, it was returning either paymentCredentialStatusUnknown or paymentCredentialsUnavailable.
Based on those values, we displayed the Apple Pay button.
The problem:
About a week ago, on the same device/browser, applePayCapabilities() started returning applePayUnsupported.
Setup: MacBook Pro 13-inch (M1, 2020), Google Chrome Version 136.0.7103.93.
The Apple documentation says: “Don’t show an Apple Pay button or offer Apple Pay” when the result is applePayUnsupported.
However, at the same time, canMakePayments() is returning true.
This creates a direct conflict between the two recommendations:
canMakePayments() → true ⇒ show the button.
applePayCapabilities() → applePayUnsupported ⇒ don’t show the button.
Question:
What’s the correct approach here?
Should we prioritize applePayCapabilities() and hide the button, or is it acceptable to continue relying only on canMakePayments() as the source of truth for showing Apple Pay?
Any insights from others who’ve run into this contradiction would be very helpful.
Thanks in advance!
Summary:
Content scripts injected via manifest continue to receive and respond to chrome.tabs.sendMessage() calls even after the user has navigated away from the original page, causing messages intended for the current tab to be handled by zombie contexts from previous pages.
Environment:
Safari/iOS Version: 18.5
Extension Manifest: Version 3
Expected Behavior:
When a user navigates from Page A to Page B:
Page A's content script context should be destroyed.
chrome.tabs.sendMessage(currentTabId, message) should only reach Page B's content script
Only Page B should be able to respond to action button clicks (or other background to content messages).
Actual Behavior:
When navigating from Page A to Page B:
Page A's content script context persists as a "zombie".
chrome.tabs.sendMessage(currentTabId, message) reaches zombie context instead of the Page B's one. Hence, it looks like the extension is broken because the content script does not respond to the background messages.
Details:
Tab ids are properly recognized by both background and content script
The problem does not always occur; it occurs on random occasions. It's quite easy to have it reproduced.
It can be reproduced easier if user clicks ext icon during site loading (before it fully loaded), triggering ActionClick (ext icon click) event and then sending a msg upon it to the content script
Regardless of whether the content script is injected into the tab using manifest.json, registerContentScripts, or executeScript, the problem is still there
Once the problem occurs, e.g. user is on macys.com but zombie injected content script believes it's google.com (a previous page), even refreshing the tab doesnt change anything - zombie context is still there (thinking it's still google.com) . Changing a domain to something completely different one could help though. Then going back to macys.com could still lead to the described issue.
A zombie content script does not have access to the page's console function and others.
Example communication
Sending following message from the background to the content script using chrome.tabs.sendMessage()
{
"tab": {
"id": 155,
"active": true,
"url": "https://www.macys.com/",
"title": "Macys.com"
}
}
Results in the content-script zombie context response (the url is taken from the window.location.href)
"message": {
"type": "ActionClicked",
"data": {}
},
"response": {
"data": {
"windowUrl": "https://www.google.com/",
"contentReached": true,
"timestamp": "1,753,138,945,272",
}
}
}
When I download specific files (not limited to a single website), even if I find that the downloaded file size matches the original file size and the downloaded file size no longer changes, Safari still does not stop the download thread, but continues to wait indefinitely.
This results in the Safari not terminating the download thread even after the file download is completed, making it impossible to complete the download; The file has not been landed and cannot be obtained. This prevents me from downloading some files. Please fix this problem.
In addition, I found that in iOS 18.2, during the process of downloading files on Safari, the synchronization and backup flags appear in the upper right corner of the notification bar. I am not sure if this is an unexpected behavior, but the flag still lingers for a long time after manually canceling the download thread.
(the download thread is waiting indefinitely)
Feedback Number: [FB16124044]
We enabled WebGPU feature flag on Safari on iOS 18.2. This does give Safari an access to GPU but WKWebView still doesn't have GPU access.
Can WKWebView not access GPU through Safari feature flag? Is there some other mechanism through which we can enable GPU access for WKWebView?
We are testing gpu access by loading : https://webgpureport.org/
Regards
Saalis Umer
Microsoft
Safari Feature Flag - webgpu = true
Safari GPU Access:
WKWebView GPU Access:
navigator.permissions.query -> permissionStatus.onchange
is Supposed to listen to the event of a change in permissions in the
browser settings.
This works for all browsers, but in Safari for iOS and MacOS this seems to be broken in the currently recent versions 17.x
Example:
navigator.permissions.query({ name: 'notifications' }).then((permissionStatus) => {
permissions = permissionStatus.state; // this value gets set correctly
permissionStatus.onchange = () => {
// This will not get executed when permissions have been changed
// within the safari settings app, or iOS Settings for PWA or Safari
};
});
Can someone from Apple's Webkit Team please comment on this?
Thank you.
T.
Adding Stack Trace for your reference:
thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1a6efe5b8)
frame #0: 0x00000001a6efe5b8 WebCoreWebCore::BaseAudioSharedUnit::BaseAudioSharedUnit() + 668 frame #1: 0x00000001a6efe044 WebCoreWebCore::CoreAudioSharedUnit::singleton() + 80
frame #2: 0x00000001a9521fe4 WebCoreWebCore::CoreAudioCaptureSource::create(WebCore::CaptureDevice const&, WebCore::MediaDeviceHashSalts&&, WebCore::MediaConstraints const*, std::__1::optional<WTF::ObjectIdentifierGeneric<WebCore::PageIdentifierType, WTF::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>>) + 360 frame #3: 0x00000001a94f180c WebCoreWebCore::RealtimeMediaSourceCenter::getUserMediaDevices(WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&, WTF::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WTF::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WebCore::MediaConstraintType&) + 356
frame #4: 0x00000001a94f22cc WebCoreWebCore::RealtimeMediaSourceCenter::validateRequestConstraintsAfterEnumeration(WTF::Function<void (WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&, WTF::Vector<WebCore::CaptureDevice, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&&)>&&, WTF::Function<void (WebCore::MediaConstraintType)>&&, WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&) + 356 frame #5: 0x00000001a94fb394 WebCoreWTF::Detail::CallableWrapper<WebCore::RealtimeMediaSourceCenter::enumerateDevices(bool, bool, bool, bool, WTF::CompletionHandler<void ()>&&)::$_0, void>::~CallableWrapper() + 164
frame #6: 0x00000001a814bbe8 WebCoreWTF::Detail::CallableWrapper<WebCore::AVCaptureDeviceManager::refreshCaptureDevicesInternal(WTF::CompletionHandler<void ()>&&, WebCore::AVCaptureDeviceManager::ShouldSetUserPreferredCamera)::$_0::operator()()::'lambda'(), void>::call() + 520 frame #7: 0x00000001ab7f1aac JavaScriptCoreWTF::RunLoop::performWork() + 524
frame #8: 0x00000001ab7f1880 JavaScriptCoreWTF::RunLoop::performWork(void*) + 36 frame #9: 0x00000001935e7d0c CoreFoundationCFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28
frame #10: 0x00000001935e7ca0 CoreFoundation__CFRunLoopDoSource0 + 172 frame #11: 0x00000001935e6a24 CoreFoundation__CFRunLoopDoSources0 + 232
frame #12: 0x00000001935e5c64 CoreFoundation__CFRunLoopRun + 840 frame #13: 0x000000019360a730 CoreFoundationCFRunLoopRunSpecific + 572
frame #14: 0x00000001e0fb5190 GraphicsServicesGSEventRunModal + 168 frame #15: 0x0000000196239f34 UIKitCore-[UIApplication _run] + 816
frame #16: 0x0000000196238164 UIKitCore`UIApplicationMain + 336
frame #17: 0x000000010811bec4 AppName.debug.dylibmain at AppDelegate.swift:25:13 frame #18: 0x00000001bae06a58 dyldstart + 5964
Device: iPhone 15pro, ios26.0 (23A 341)
IOS version: 26.0 (23A 341)
When using position: sticky; bottom: 0, the div is expected to stick to the bottom of the viewport when the browser toolbar hides while scrolling. However, it stops at the height where the toolbar was, instead of moving down with the disappearing toolbar.
In the image below, the red-bordered navigation shows the situation where it does not stick to the bottom.
i
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
Title: Content Overlapping Address Bar After Clicking Links in Safari, tested on iPhone 11 (iOS 18.1.1)
Description:
When browsing in Safari on iPhone (iOS 18.1.1), the one-tab bar (address bar) collapses as expected when scrolling down a page. However, after clicking on a link and loading the next page, the content appears to overlap the collapsed address bar. This results in parts of the content being hidden or obscured by the address bar, which affects the user experience, especially on mobile devices with limited screen space. This issue is reproducible on Next.js applications and can be observed on websites such as rotterdam.nl and halderberge.nl.
Steps to Reproduce:
Enable the One-Tab Bar: Go to Settings > Safari and enable the one-tab bar feature.
Open the website rotterdam.nl or halderberge.nl in Safari on an iPhone 11 (iOS 18.1.1).
Scroll down the page so that the top address bar collapses.
Click on any link on the page to load a new one.
Once the new page loads, observe that the content appears on top of the collapsed address bar, causing parts of the content to be hidden or obscured.
Expected Result:
The content should not overlap or be hidden behind the collapsed address bar after the page reloads. The layout should adjust properly without interference from the address bar, providing a smooth user experience.
Actual Result:
When the new page loads, the content overlaps or appears on top of the collapsed address bar, causing parts of the content to be hidden or obscured.
Device(s) Affected:
iPhone 11 running iOS 18.1.1.
OS Version:
iOS 18.1.1
Technical Notes:
To address this issue, the following solutions have been attempted with no success:
Viewport Meta Tag:
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
This was added to help ensure proper layout on mobile devices, but did not resolve the issue.
CSS Safe Area Insets:
body {
padding-top: env(safe-area-inset-top);
}
This CSS rule was applied to account for the safe area and prevent content from being hidden under the address bar, but it did not solve the overlapping issue.
Scroll Position Adjustment (for scroll-to-top button):
Adjusting the scroll behavior by changing the scroll position to {top: 1} instead of {top: 0} was a successful workaround to keep the address bar collapsed when clicking the "scroll to top" button. However, this did not resolve the issue when navigating between pages or changing routes, where the content still overlaps the collapsed address bar.
The issue of fixed elements with
{ bottom: 0 }
moving up when scrolling still persists.
It seems to be a general issue with the IOS 26 release.
It affects other browser too. I tested on browsers such as Safari, Chrome, Firefox, Edge and Bravo.
With the exception of Edge, all the others display the behavior.
Device: iPhone 15 Pro
IOS Version: 26.0.1
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
Enhancement in managing tabs in Safari
It would really be awesome to bring the fascinating tab management feature of Arc Browser to Safari across iOS, iPadOS and macOS.
Especially below listed features;
Multitask
Create
Organize
Rev Up
Release Notes
For further info , here is the official link of Arc Browser, https://resources.arc.net/hc/en-us/categories/16435255982103-Features.
Hello Apple Developer Community,
I'm experiencing an issue with PDF link interaction in WKWebView that appears to be specific to iOS 26.
Problem Description:
I'm loading a PDF in WKWebView.The links may vary widely and are not necessarily DPF, so I need to load them using WKWebView. On iOS versions prior to 26, links within the PDF are clickable and work correctly. On iOS 26, the same links are not clickable (no response when tapped). Expected Behavior:
PDF links should remain clickable and functional across all iOS versions.
What I've Tried:
Tested opening the PDF directly in Safari on iOS 26 - links still not clickable This suggests the issue might be related to changes in the system's PDF rendering engine Reproduction Steps:
Load the PDF URL in WKWebView Navigate to page 12 Attempt to tap the link Environment:
Test Devices: iPhone 15(26.0 ) / iPhone 16 Pro Max(18.0.1 ) Xcode: 16.2
Questions:
Is this an intentional change in iOS 26's PDF handling or WKWebView? If so, is there a new API or configuration to restore link interactivity?
Any guidance or suggestions would be greatly appreciated!
Hi,
I'm encountering an issue with the Clipboard API's writeText() method in Safari. It throws a NotAllowedError even when triggered by a user action (selecting an option from a <select> element). Is this expected?
This issue seems specific to Safari, as the same code works perfectly in Firefox and Chrome.
Perhaps I should send feedback to Apple, but I'd like to post it here first in case I misunderstand something.
Problem
In Safari, when I try to copy text to the clipboard using navigator.clipboard.writeText() within an input event listener attached to a <select> element, it fails with the following error:
NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
Environment
Safari
18.2 (20620.1.16.11.8)
Technology Preview 210
macOS Sequoia 15.2 (24C101)
Example
I've created a minimal reproducible example on CodePen: https://codepen.io/mshibanami/pen/LEPdxXZ
Here's the relevant JavaScript code from the example:
selectElement.addEventListener('input', async (event) => {
const selectedText = event.target.options[event.target.selectedIndex].text;
try {
await navigator.clipboard.writeText(selectedText);
alert(`Text copied to clipboard: ${selectedText}`);
} catch (err) {
alert('Failed to copy text to clipboard: ' + err);
}
});
Firefox and Chrome handle this code without any issues, successfully copying the text to the clipboard, but not Safari.
Possible Cause
I suspect this issue might be related to WebKit's User Activation API. It seems like Safari is not correctly recognizing the input or change event on a <select> element as a valid user activation for the Clipboard API, even though it is initiated by a user gesture.
Questions
Is this behavior unexpected? Should Safari allow the Clipboard API to work in this context?
(Technically, this might be expected as of now, as such events are not explicitly described in https://webkit.org/blog/13862/the-user-activation-api/.)
Any insights or suggestions would be greatly appreciated. Thanks!
When CHIPS was introduced in 18.4 it worked well, however on 18.5 it does not appear to work. There do not appear to be release notes about this in 18.5, so can someone provide definitive if this is a defect that will be fixed, or have they already been deprecated?
hi
Testing on OS26 Public Beta 6.
In Safari, if you enter x homepage and scroll, the tab bar sticks to the bottom and moves.
Make the keyboard appear in the search window
When scrolling down on the Safari homepage again, the issue of not being able to stick to the bottom appears.
Is it because the liquid glass UI was applied this time? and safari bug?
Please let me know if I'm missing anything
Topic:
Safari & Web
SubTopic:
General
Hello,
I've got Smart App Banner set up on my website. However, I want to be able to measure the traffic coming from this banner to the app store / app (i.e. measure impressions/downloads).
Apple documentation (https://developer.apple.com/help/app-store-connect/view-app-analytics/manage-campaigns/) says you can set up a campaign link and use it in the Smart Banner to track those who download / open the app store page using your smart banner (so that we can get attribution).
However, there is no documentation at all in terms of how this should be added to the tag when implementing a Smart App Banner.
I've tried so many different variations and none have tracked downloads. This includes a structure based on an example taken from WWDC from a few years back which also did not work.
I would appreciate any help!