I’m observing an intermittent issue with a Safari Web Extension on macOS 15.7 (Safari 26.0.1). After installing the Safari extension from the App Store, it appears under Settings → Extensions, but the enable checkbox is often missing.
Sometimes, after restarting Safari multiple times, the checkbox becomes visible. However, even when I manage to enable the extension, reopening Safari often hides the checkbox again.
However, I don't see this issue in safari 26 with macOS 26
I’d like to know if this behavior is a known issue with Safari 26 or macOS 15.7?
Any workaround available?
General
RSS for tagExplore 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
iOS Safari 18.4/18.5 with IIS Windows Authentication with negotiate hangs after entering credentials
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.
Topic:
Safari & Web
SubTopic:
General
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!
Hey Guys
My PWA video playback and even youtube videos stopped working after updating iOS to 26.0.1.
The video thumnails appear fine and if i try to play the video, it remains stuck.
If i restart the phone, the video plays for a second in the PWA and then stops again and entire app gets stuck.
Request apple team to fix this issue at the earliest. This is hampering all my iOS users who install the PWA on their device homescreen and use it as app.
FYI strangely EVERYTHING WORKS FINE ON iOS SAFARI browser including videos playback If i open it as a web app.
so this seems like a specific PWA issue on latest ios 26.0.1
Topic:
Safari & Web
SubTopic:
General
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
We’re currently working on an OTT-based application where we integrate Google Ad Manager to serve video ads. As part of the ad experience, users often see a “Learn More” CTA (Call to Action) on these ads.
As per our current requirement, when a user taps “Learn More” on an ad:
• The link should open in Safari (i.e., an external browser) on iOS devices
• The Safari browser should ideally open in portrait orientation, as the ad content and layout are optimised for portrait mode
However, based on our understanding and technical constraints on iOS, it appears that:
• Orientation control is restricted to the app’s own context.
• Once Safari is launched via UIApplication.shared.open, we no longer have control over how it behaves in terms of orientation.
• iOS system behaviour determines Safari’s orientation based on the device’s physical orientation and Safari’s own internal configuration.
Could you please confirm if there’s any supported way (via SDK, deep link config, or otherwise) to enforce portrait orientation in Safari when opening such external URLs from within an iOS app?
If this is not technically feasible, we would appreciate any best practices or alternatives you can suggest for ensuring a consistent user experience.
Topic:
Safari & Web
SubTopic:
General
I'm testing web extension to safari on iOS. I've built and added extension application to simulator, but on safari settings shows no extensions.
I'm using Xcode 16.3 beta 2 with Simulator iOS 18.4 (22E5216h), tested on iPhone 16.
https://app.screencast.com/oUq4EMonmfT7u
https://app.screencast.com/MCquvHzmZi8QS
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
Hello,
After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project).
Observed behavior
On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return.
This happens not only for:
evaluateJavaScript("navigator.userAgent")
but also for simple or even empty scripts, for example:
evaluateJavaScript("")
On previous macOS versions, the same calls typically returned in ~200 ms.
Additional testing
I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls.
In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2.
Question
Is this a known issue or regression related to:
iOS Apps on Mac,
Swift + WKWebView, or
behavioral changes in evaluateJavaScript on macOS 26.2?
Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated.
Thank you.
Test Code Swift
class ViewController: UIViewController {
private var tmpWebView: WKWebView?
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
setupUserAgent()
}
func setupUserAgent() {
let t1 = CACurrentMediaTime()
tmpWebView = WKWebView(frame: .zero)
tmpWebView?.isInspectable = true
tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in
let t2 = CACurrentMediaTime()
print("[getUserAgent] \(t2 - t1)s")
self?.tmpWebView = nil
}
}
}
Test Code Objective-C
- (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions {
NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970];
WKWebView *webView = [[WKWebView alloc] init];
dispatch_async(dispatch_get_main_queue(), ^{
[webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) {
NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970];
NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime));
}];
});
}
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?
This is my first post, so please forgive me if it is to the wrong area.
I've been using Tahoe for a few days and, overall, it's very stable. But the one thing that has bothered me to no end is Safari's new behavior with respect to its header (Address bar, Favorite bookmarks bar, tab bar) background color. The web content of the active tab seems to affect everything - and oftentimes makes things completely unreadable - at least in "Dark" mode. For instance, if a web page uses a white background, the Favorites bookmark labels are the same color as the bookmark background, so reading the labels is simply impossible. At other times, they're just very difficult to read.
Similarly, it is almost always impossible to tell which tab is the active one - my only workaround is to try 100% brightness....or to just guess.
When Apple previously experimented with letting content bleed through to the top, there was a setting for stopping it - but I don't see such a setting anymore. Do you you know of any way to stop this effect?
When I open com. apple. developer. web browser, I am unable to inject JavaScript into the webview through methods such as addUserScript. The console will prompt 'ignoring user script injection for non app bound domain'
We are experiencing a compatibility issue with our hybrid app related to the recent update in iPadOS 18.4, specifically concerning HTTPS connections.
What are the key changes introduced in iPadOS 18.4 regarding HTTPS connections? Our app previously managed to bypass the DigitalSignature key usage missing error in the self-signed server certificate within the didReceiveAuthenticationChallenge method, as documented here: https://developer.apple.com/documentation/webkit/wknavigationdelegate/webview(_:didreceive:completionhandler:) . However, since the update to iPadOS 18.4, this method is no longer being called, resulting in direct failure of HTTPS connections.
We are using cordova-ios 7.1.
Thanks in advance for your help.
We are encountering an issue where the Safari extension we are developing stops working while in use on relatively new iOS versions (confirmed on 17.5.1, 17.6.1, and 18). Upon checking the Safari console, the content script is displayed in the extension script, so the background script or Service Worker must be stopping. The time until it stops is about 1 minute on 17.5.1 and about one day on 17.6.1 or 18.
When it stops, we would like to find a way to restart the Service Worker from the extension side, but we have not found a method to do so yet. To restart the extension, the user needs to turn off the corresponding extension in the iPhone settings and then turn it back on.
As mentioned in the following thread, it is written that the above bug was fixed in 17.6, but we recognize that it has not been fixed. https://forums.developer.apple.com/forums/thread/758346
On 17.5.1, adding the following process to the background script prevents it from stopping for about the same time as on 17.6 and above.
// Will be passed into runtime.onConnect for processes that are listening for the connection event
const INTERNAL_STAYALIVE_PORT = "port.connect";
// Try wake up every 9S
const INTERVAL_WAKE_UP = 9000;
// Alive port
var alivePort = null;
// Call the function at SW(service worker) start
StayAlive();
async function StayAlive() {
var wakeup = setInterval(() => {
if (alivePort == null) {
alivePort = browser.runtime.connect({ name: INTERNAL_STAYALIVE_PORT });
alivePort.onDisconnect.addListener((p) => {
alivePort = null;
});
}
if (alivePort) {
alivePort.postMessage({ content: "ping" });
}
}, INTERVAL_WAKE_UP);
}
Additionally, we considered methods to revive the Service Worker when it stops, which are listed below. None of the methods listed below resolved the issue.
①
Implemented a process to create a connection again if the return value of sendMessage is null. The determination of whether the Service Worker has stopped is made by sending a message from the content script to the background script and checking whether the message return value is null as follows.
sendMessageToBackground.js
let infoFromBackground = await browser.runtime.sendMessage(sendParam);
if (!infoFromBackground) {
// If infoFromBackground is null, Service Worker should have stopped.
browser.runtime.connect({name: 'reconnect'}); // ← reconnection process
// Sending message again
infoFromBackground = await browser.runtime.sendMessage(sendParam);
}
return infoFromBackground.message;
Background script
browser.runtime.onConnect.addListener((port) => {
if (port.name !== 'reconnect') return;
port.onMessage.addListener(async (request, sender, sendResponse) => {
sendResponse({
response: "response form background",
message: "reconnect.",
});
});
②
Verified whether the service worker could be restarted by regenerating Background.js and content.js.
sendMessageToBackground.js
export async function sendMessageToBackground(sendParam) {
let infoFromBackground = await browser.runtime.sendMessage(sendParam);
if (!infoFromBackground) {
executeContentScript(); // ← executeScript
infoFromBackground = await browser.runtime.sendMessage(sendParam);
}
return infoFromBackground.message;
}
async function executeContentScript() {
browser.webNavigation.onDOMContentLoaded.addListener((details) => {
browser.scripting.executeScript({
target: { tabId: details.tabId },
files: ["./content.js"]
});
});
}
However, browser.webNavigation.onDOMContentLoaded.addListener was not executed due to the following error.
@webkit-masked-url://hidden/:2:58295
@webkit-masked-url://hidden/:2:58539
@webkit-masked-url://hidden/:2:58539
③
Verify that ServiceWorker restarts by updating ContentScripts
async function updateContentScripts() {
try {
const scripts = await browser.scripting.getRegisteredContentScripts();
const scriptIds = scripts.map(script => script.id);
await browser.scripting.updateContentScripts(scriptIds);//update content
} catch (e) {
await errorLogger(e.stack);
}
}
However, scripting.getRegisteredContentScripts was not executed due to the same error as in 2.
@webkit-masked-url://hidden/:2:58359
@webkit-masked-url://hidden/:2:58456
@webkit-masked-url://hidden/:2:58456
@webkit-masked-url://hidden/:2:58549
@webkit-masked-url://hidden/:2:58549
These are the methods we have considered. If anyone knows a solution, please let us know.
I'd like to know the install state of my iOS safari extension in the associated swift app. Is there any way to get this? As we have seen it is available for macOS here, is there anyway to know iOS Safari extension is enabled or not?
Thanks
We’ve noticed that the ApplePaySession.applePayCapabilities() check has stopped working correctly in Safari over the past couple of days.
Behavior observed:
1.) In Safari Private Window, paymentCredentialStatus behaves as expected and case 1 is triggered.
2.) In a normal Safari window, it always triggers case 3 (paymentCredentialsUnavailable), even when the user has active cards provisioned in Wallet.
We tested across multiple devices, and the behavior is consistent.
if (window.ApplePaySession) {
var merchantIdentifier = 'YOUR MERCHANT IDENTIFIER';
var promise = ApplePaySession.applePayCapabilities(merchantIdentifier);
promise.then(function(capabilities) {
switch (capabilities.paymentCredentialStatus) {
case "paymentCredentialsAvailable":
// Show Apple Pay button as primary option
case "paymentCredentialStatusUnknown":
// Offer Apple Pay
case "paymentCredentialsUnavailable":
// Consider showing Apple Pay button
case "applePayUnsupported":
// Don’t show Apple Pay button
}
})
}
This used to work fine until a few days ago, but now the capability check in non-private Safari windows always indicates unavailable, even with valid active cards.
Has anyone else faced this issue recently? Could this be a Safari regression or a change on Apple’s side?
Thanks in advance!
WKWebView has a new property "isBlockedByScreenTime" since iOS 26. But I do not yet understand when exactly this property could be used.
When I setup content-based restrictions in the ScreenTime settings then WKWebView reports an error 105 via "webView:didFailProvisionalNavigation:" delegate. The isBlockedByScreenTime property still returns false in this case.
If ScreenTime has a time-based limit, the App would not run at all.
Under which circumstances would the property "isBlockedByScreenTime" return the value true? When exactly and for what can this property be actually used?
The "problem" is that I want to find if a web page is blocked and can not be loaded, why this is the case. By simply trial and error I found out that WKWebView returns error codes 104 and 105 for blocked web sites because of content filters and Screen Time restrictions, however these error codes are not documented at all (at least I've not found any documentation or documentation for these error codes and also some other codes like 100, 102, 204 etc), so I'm not really sure if I handle all cases correctly.
I hoped that isBlockedByScreenTime would at least tell me one reason for blocked pages.
If there are documents which explain these error codes (100 and above), where I can find these?
Since iOS 18.1 launched as a beta, we've been getting reports from end users on iPhone 15 Pro and iPhone 15 Pro Max specifically. They're reporting that our WebView is unable to load our local HTML content. I'm curious if anyone else has had their app or users run into this issue?
So far I've tried installing the most recent XCode Beta 16B5014f and installed an 18.1 emulator, but our app worked fine. It's also working fine on all my real devices, but we don't have a 15 Pro to test on. I'm curious if this is related to the processor on these devices and how they are intended to support Apple's new AI coming in 18.1.
Create shortcut to open chrome with url and put it on the desktop.
Tap the shortcut.
Tap the username text field.
When launching Safari from an iOS shortcut on an iOS device with a valid passkey registered, the passkey suggestion does not appear; instead, the password suggestion appears sometimes.
Topic:
Safari & Web
SubTopic:
General
Tags:
WebKit
Safari
Safari and Web
Passkeys in iCloud Keychain
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