Safari Version 14.0.1 (16610.2.11.51.8)
I am porting a Chrome/Firefox/Edge extension to Safari Web Extension. Mostly, the process was painless, I am, however, seeing quite different behavior in the tab ids generated by Safari compared to Chrome, Firefox, and Edge. My extension has callbacks for each of these browser.webNavigation events:
browser.webNavigation.onBeforeNavigate
browser.webNavigation.onCommitted
browser.webNavigation.onDOMContentLoaded
In each of these I rely on the tab id for various future tab targeting operations. When opening a new tab, the details object passed to each of these callbacks has a non-zero tabId on Chrome, Firefox, and Edge. However, in Safari, the tabId is always zero. To debug, I added one more callback:
browser.webNavigation.onCompleted
At this point Safari finally has a non-zero tabId in the details param. Needless to say this is causing some consternation with achieving the same outcomes as tab tracking on Chrome, Firefox, and Edge. It's like Safari is treating new tabs as "non tabs" until navigation completes. You can even see it when trying to get the tab by tabId=0:
browser.tabs.get(tabId) // tabId=0 here
	.then(tab => {
		// tab is undefined
	});
Seems like this might be a bug. I can't imagine why the behavior is so different from other browsers. Any ideas on how to work around?
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
My team recently released an app to the iOS app store. We are trying to add the Smart App Banner to our website to promote the app, but the banner is not shown. When the page loads, there is a flash of an empty Smart App Banner before it is automatically dismissed. This happens on every page load. If I put use an app ID of other apps the banner appears. I've triple checked that I'm using the correct app ID. So it seems like it is an issue with my app. I can see my app in the App Store, so I know it's available. I've tested on multiple phones.
1. System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
2. System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
After updating Xcode to the latest version we observed that SFSafariViewController is not loading web pages on Xcode 16 Simulator with iOS 18, whenever it is presented the View Controller is empty (does not load any content) and the app freezes, but other screens that use WKWebView are working normally.
Also, during tests on physical devices with iOS 18 it seems to work just fine, so it might be just a IDE version problem.
Is anyone experiencing the same issue?
If so, did anyone find a solution for it?
As with the adoption of MV3 standards among all major browser vendors that allow browser extensions at the client-side, I understand that this is the same with Safari as well, as mentioned here (https://www.wwdcnotes.com/notes/wwdc22/10099/). However, as with Firefox, browsers may choose to adopt them incompletely and with few changes. I had a few questions regarding how Safari views this transition and what would be the next steps from here.
Thus, it would be really great if the browser team could provide your insights on any or all of the following points:
Would Safari adopt the exact standards proposed by the Chromium ecosystem such as with functionalities like header-based modifications in the coming days.
What would be the general timeline be for this in general?
Does this also translate to the fact that existing standards with MV2 standards would not be allowed to operate any further, as with the timeline with Chromium?
Regards
our company created a web safari extension.
before iOS 26 (beta) release we would archive our extension and install to our devices no problem.
since iOS 26 (beta) (we also tried in beta 4 23A5297m) the extension would archive perfectly but when installing the extension would just not run. its found in settings under safari extension, but when enabled the extension and open safari it will show error message "Ext" is no longer available.
to rule out all code issues, we built a new project from scratch with a new bundle id, tried to archive with no problem, but when installed in an iphone 16 with iOS 26 BETA (23A5297m) same error ocurs it installs but when opening safari it will give an error message saying extension is no longer available.
attached in the google drive link is a zip file of the new project, a zip file with a succesfull build of the ipa file with enterprise distribute, a video of the entire proccess and the error that the iphone gives.
also attached a log file from the iphone that includes the install and the crash of the app.
within the logs there is a log saying Error occurred during transaction: The provided identifier "dev.sacal.ext" is invalid.
before ios 26 the exact steps worked perfectly.
https://drive.google.com/file/d/1PYDOv8IRvRY_ouqiOc0sJdcfh0CHbL72/view?usp=sharing
On iPads after updating to iPadOS 16.4, Safari often "looses" the session cookie provided by PlayFramework: When the browser requests assets (js scripts) or when additional data is fetched by JavaScript, the session cookie is not included in the request.
These secondary requests will redirect through our IAM because no session cookie is present. The IAM redirects back to the original domain with a payload so that the login session can be resumed. A new Set-Cookie header is sent in the response with the new session cookie.
This causes the framework to issue a new CSRF token (that is part of the session cookie) which is different from the old one that was already rendered into a hidden form input. The browser stores this new token and includes it when it POSTs the form. The token in the body of the request is now different from the one in the cookies, causing the CSRF check to fail.
We have tried different devices (Android, Windows, MacBook, and iPads) on different versions. The problem only occurs with Safari on iPad/MacBook running version 16.4, 16.4.1, or 16.5 beta. The problem cannot be reproduced using Chrome on iPad. Furthermore, the problem does not occur with private browsing in Safari.
Some things we ruled out:
Same behaviour on devices managed by MDM and on open devices.
PlayFramework version is now updated to the latest 2.8 version.
Using a separate cookie for the CSRF token (instead of the play session cookie) does not make a difference either.
Modifying the Cache-Control header to cache responses more aggressively or not at all does not help.
Has anyone also experienced this or similar problems?
I'm working on a web browser App that's distributed via the App Store. This app renders web pages using WKWebView.
Our users are requesting a way for us to allow them to play videos in Picture in Picture. After some investigation, we noticed that in order to allow PiP videos in our browser in the sandboxed environment, we need to add the com.apple.PIPAgent entitlement under the com.apple.security.temporary-exception.mach-lookup.global-name option.
We tried to submit our app with this entitlement, but unfortunately, we were rejected:
Guideline 2.4.50) - Performance
We've determined that one or more temporary entitlement exceptions requested for this app are not appropriate and will not be granted:
com.apple.security.temporary-exception.mach-lookup.global-name
com.apple.P|PAgent
We would like to have access to this entitlement so we can offer PiP to our users.
We already created a radar about this as well: FB13814428
Additionally, we have another radar (FB13557716) regarding allowing the usage of a private flag _allowsPictureInPictureMediaPlayback, which would also be required to enable us to use PiP.
Is there any way in which we can currently enable PiP? Would opening a TSI help here?
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 & 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<double> const&, 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<void (WebKit::DocumentEditingContext&&)>::operator()(WebKit::DocumentEditingContext&&) + 64
17 WebKit 0x1a05bb468 WTF::Detail::CallableWrapper<WTF::CompletionHandler<void (IPC::Connection*, IPC::Decoder*)> IPC::Connection::makeAsyncReplyCompletionHandler<Messages::WebPage::RequestDocumentEditingContext, WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>>(WTF::CompletionHandler<void (WebKit::DocumentEditingContext&&)>&&, WTF::ThreadLikeAssertion)::'lambda'(IPC::Connection*, IPC::Decoder*), void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) + 196
18 WebKit 0x19fcf5db8 WTF::Detail::CallableWrapper<WebKit::AuxiliaryProcessProxy::sendMessage(WTF::UniqueRef<IPC::Encoder>&&, WTF::OptionSet<IPC::SendOption>, std::__1::optional<IPC::ConnectionAsyncReplyHandler>, WebKit::AuxiliaryProcessProxy::ShouldStartProcessThrottlerActivity)::$_1, void, IPC::Connection*, IPC::Decoder*>::call(IPC::Connection*, IPC::Decoder*) + 64
19 WebKit 0x19fce54f0 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 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
System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
I wrote a code like the example below to execute javascript code that has no return value.
let webView: WKWebView
// after load complete
let result = await webView.evaluateJavascript("someFunction()") // :0: Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value
but when i use method with completion handler manner, it doesn't be crashed. but Xcode enforces me to use 'await' keyword and warning is bordering me
await webView.evaluateJavaScript("someFunction()", completionHandler: nil) // warning: Consider using asynchronous alternative function
The differnce I found is the different signature. Completion handler version has Optional result type, but async/await version has just Any result type
func evaluateJavaScript(_ javaScriptString: String,
completionHandler: ((Any?, Error?) -> Void)? = nil)
func evaluateJavaScript(_ javaScriptString: String) async throws -> Any
my Xcode version is 13.2.1. Hope to fix it soon.
When WKWebView loads a site that has username and password on different pages, standard "Passwords" button above keyboard does nothing. Reproducible on both physical device and simulator. At the same time, Safari works fine in this case.
Any chance to fix this behavior in the upcoming iOS updates?
Here's video demonstrating the issue:
and a sample code to reproduce it (nothing specific, just bare WKWebView with default configuration):
class ViewController: UIViewController {
private let webView = WKWebView(frame: .zero)
override func viewDidLoad() {
super.viewDidLoad()
view.addSubview(webView)
}
override func viewDidLayoutSubviews() {
super.viewDidLayoutSubviews()
webView.frame = view.bounds
}
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
webView.load(URLRequest(
url: URL(string: "https://accounts.google.com/")!
))
}
}
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>
Hi everyone,
I’m encountering a serious reliability issue with message passing in my Safari extension on iOS 18.4.1 and iOS 18.5
In my extension, I use the standard messaging API where the background script sends a message to the content scrip. The content script is listening using:
browser.runtime.onMessage.addListener(handler);
This setup has been working reliably in previous versions of iOS, but since updating to iOS 18.4.1 and iOS 18.5, I’ve noticed that messages sent from the background script are not consistently received by the content script. From my logs, I can confirm that:
The background script is sending the message.
The content script’s listener is not always triggered.
There are no errors or exceptions logged in either script.
It seems as if browser.runtime.onMessage.addListener is either not getting registered in time or failing silently in some instances.
This issue is intermittent and does not occur all the time.
Has anyone else experienced similar issues in iOS 18.4.1 and 18.5? Are there any known changes or workarounds for ensuring reliable communication between background and content scripts in this version?
Any help or insights would be greatly appreciated.
Thanks!
Recently we started noticing in Safari v18.2 browser an unexpected useragent set for https://www.espn.com pages like -
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36" (recognized as Chrome by most UA detection logic) and breaks our video playback in some scenarios.
When digging into this we came across site specific quirks and the "Disable site-specific hacks" setting which fixed the playback functionality and set a more expected UA - "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.2 Safari/605.1.15".
Is the unexpected UA being set somewhere in Safari/Webkit? Can this be removed so site functionality works without needing to find the "Disable site-specific hacks" setting?
I'm experiencing a Safari Web Extension issue where the non-persistant background script seems to crash after 30 seconds even when the content script is messaging it.
Here is a minimal-reproducible example. When running in an emulator, the background script will stay responsive forever. However, when running on a physical device, the background script becomes non-responsive after 30 seconds of activity. It never becomes responsive again until I toggle the extensions enable/disable toggle, after which it stays active for 30 seconds and then crashes again.
We have an iOS app (which runs on macOS via "Designed for iPad") which renders web content on WKWebView. Our users can select text (standard OS way of click & drag cursor across text) and then perform actions on those discrete pieces of text.
On macOS 15.1, our users can only expand a text selection, they cannot contract the text selection by dragging the cursor to the left. This reduces the usability of our app on macOS 15.1. This is not an issue on macOS 14.
Environment: MacBook Pro (2021 16” M1 Max), macOS 15.1
Submitted Feedback FB15726254.
I’m experiencing a crash in WKWebView on iOS 26 Developer Beta 5 and Beta 6 with the following exception:
CALayer position contains NaN: [nan 65]
The crash occurs when the following CSS properties are applied to content displayed in WKWebView:
-webkit-user-select: none;
-webkit-touch-callout: none;
This issue happens consistently whenever these styles are set, leading to the crash inside WKWebView.
Is this a known bug in the current iOS 26 betas, or is there a recommended workaround?
iOS 26 introduced a significant step back for PWAs - you now need at least five taps to add a PWA to your home screen.
Android has excellent PWA support - it takes 1 tap to install an app, and the platform support is great, and web apps feel amazing. The gap between the platforms has now increased even further.
My team and I were hoping for better PWA support, but now we are very worried about the direction - it puts us in a difficult situation.
I'm sure many developers face a similar challenge.
What's the current status of PWAs in iOS? Is Apple aiming to improve its support in the near future? Is there a roadmap, tech previews, or betas addressing the issue?
Topic:
Safari & Web
SubTopic:
General
If the extension uses manifest v3 and a background script in the form of a service worker, then in Safari it is not possible to open the background script debugging window. If I expand the Developer menu in Safari, there is nothing under Web Extension Background Data (or disappear after click), which is an error. In other browsers (Edge, Chrome, Opera, Firefox) this works correctly.
If I switch the background script back to non-persistent script mode, everything works fine and from the Developer menu and the Web Extension Background Data submenu I am able to open the background script debugging window for the extension. Am I doing something wrong?