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>
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
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?
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
Hello,
I am facing a strange issue on iOS 18. After upgrading to iOS 18, I noticed the following problem:
When connected to mobile data (with Wi-Fi turned off) and trying to upload a file larger than 1MB, the connection times out. However, if I repeat the same action using Wi-Fi, everything works fine.
I have tested this issue in various ways, but nothing seems to resolve it. It appears that iOS 18 might have introduced a bug.
You can replicate the issue using this site: https://video.online-convert.com/convert-to-mp4 (Note: this is not my page, but I found the same issue here).
From the server access logs, I see successful pre-flight requests, but the main POST request never follows, which suggests that the client is not sending the request.
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
I've been having this problem ever since updating my Mac (2024 M3 Macbook Air) to Sequoia where splitscreen basically doesn't work. By "splitscreen," I'm referring to when I hover over the green button in the top left of my browser, go to "full screen", and choose two browsers to see simultaneously. What's happening is that the screens will split, then whichever browser's green button I used will have the tabs stuck in full screen formation. Say I have 5 tabs open on a Chrome browser and I split the screen with finder using the green button on the Chrome browser. The 2 right-most tabs on Chrome will be cut off into oblivion, and only the first 3 will be visible, but if I try to click them, they don't go to the right place. Clicking in the general location of where the 5 tabs SHOULD be in the minimized screen does yield the change of tab, but I can't actually SEE the tabs in their minimized form. I've attached a screenshot because I know it's probably hard to understand what I'm saying. This also doesn't occur 100% of the time, only like 95% of the time. Lol.
Topic:
Safari & Web
SubTopic:
General
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>
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/")!
))
}
}
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.
Hello everyone,
I am currently facing an issue with a Cordova-based app using WKWebView. In our app, we handle page navigation within the WebView. We’ve implemented a back button at the top of the page, which successfully triggers history.goBack() when clicked. However, we also want to support the native left edge pan gesture (swipe back) to trigger history.back().
The issue is that, while the swipe back gesture works most of the time, there are cases where instead of navigating to the immediate previous page, it behaves as if it’s going back to the first page (or initial page). This only occurs on iOS versions 17.5.1 and above. I’ve already set allowsBackForwardNavigationGestures to true, and the back button itself works perfectly.
Has anyone experienced a similar issue, where the swipe back gesture sometimes skips pages and seems to return to the first page on iOS 17.5.1 or later? Any suggestions on how to fix or troubleshoot this would be greatly appreciated.
Thank you!
Title: SafariViewService Recurring "Hard Refresh" Issue on iOS 18.0.1
Hello,
Many of my app users are experiencing a recurring "hard refresh" issue related to SafariViewService, which appears only on iOS 18.0.1 across various iPhone models. Users on earlier iOS versions are not encountering this problem.
Our app relies on SafariViewService, and the logs show an event triggered by an EXC_GUARD exception with a termination reason from LIBXPC, causing the app to stop. Below are key details from the log report:
App Version: 4.1.2 (build 4.1.1.0)
OS Version: iPhone OS 18.0.1
Exception Type: EXC_GUARD
Subtype: GUARD_TYPE_USER
Termination Reason: LIBXPC, XPC_EXIT_REASON_FAULT
Device Model: iPhone 11 Pro Max
Process Path: [Removed]
Here’s an excerpt from the logs:
...
{"codes":"0x6000000000000007, 0x0000000000000009","reason":9,"message":"namespc 7 reason_code 0x0000000000000009","subtype":"GUARD_TYPE_USER","type":"EXC_GUARD","rawCodes":[Removed],"namespc":7},
"termination" : {"flags":518,"code":9,"namespace":"LIBXPC","indicator":"XPC_EXIT_REASON_FAULT"},
...
I would greatly appreciate any guidance on resolving this issue, particularly if there are known concerns with inter-process communication (LIBXPC) in iOS 18.0.1 or advice on how to manage the EXC_GUARD exception more effectively.
Full log details are in the attachment.
Thank you for your help!
ExcUserFault_SafariViewService-2024-10-10-102717 (1).ips
ExcUserFault_OnixWorker.Maui-2024-10-10-102718 (1).ips
Thank you for your help!
Safari cannot open the page due to the error 'WebKit encountered an internal error.' We are using https://github.com/stleamist/BetterSafariView.git, and it was working fine before we updated to Xcode 16.
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?
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!
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.
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