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>
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
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?
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.
Hi there,
I'm experiencing several crashes on JavaScriptCore pas_panic_on_out_of_memory_error, only on devices with tvOS 15.4 and 15.4.1. This happens with users using the app for several hours as well as 5 seconds after launching the app.
Devices: AppleTV6,2 and AppleTV5,3
Thread 14 —
JavaScriptCore pas_panic_on_out_of_memory_error (JavaScriptCore)
JavaScriptCore bmalloc_try_iso_allocate_impl_impl_slow (JavaScriptCore)
JavaScriptCore bmalloc_heap_config_specialized_local_allocator_try_allocate_small_segregated_slow (JavaScriptCore)
JavaScriptCore bmalloc_allocate_impl_casual_case (JavaScriptCore)
JavaScriptCore ***::String::String(char16_t const*, unsigned int) (JavaScriptCore)
JavaScriptCore JSC::LiteralParser<char16_t>::parsePrimitiveValue(JSC::VM&) (JavaScriptCore)
JavaScriptCore JSC::LiteralParser<char16_t>::parse(JSC::ParserState) (JavaScriptCore)
JavaScriptCore JSC::jsonProtoFuncParse(JSC::JSGlobalObject*, JSC::CallFrame*) (JavaScriptCore)
JavaScriptCore llint_entry (JavaScriptCore)
JavaScriptCore llint_entry (JavaScriptCore)
JavaScriptCore llint_entry (JavaScriptCore)
JavaScriptCore llint_entry (JavaScriptCore)
JavaScriptCore vmEntryToJavaScript (JavaScriptCore)
JavaScriptCore JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (JavaScriptCore)
JavaScriptCore JSC::boundThisNoArgsFunctionCall(JSC::JSGlobalObject*, JSC::CallFrame*) (JavaScriptCore)
JavaScriptCore vmEntryToNative (JavaScriptCore)
JavaScriptCore JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (JavaScriptCore)
JavaScriptCore JSC::profiledCall(JSC::JSGlobalObject*, JSC::ProfilingReason, JSC::JSValue, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (JavaScriptCore)
JavaScriptCore JSObjectCallAsFunction (JavaScriptCore)
JavaScriptCore -[JSValue invokeMethod:withArguments:] (JavaScriptCore)
ITMLKit -[IKJSObject invokeMethod:withArguments:] (ITMLKit)
ITMLKit -[IKJSEventListenerObject invokeMethod:withArguments:thenDispatchEvent:extraInfo:] (ITMLKit)
ITMLKit __43-[IKJSXMLHTTPRequest setRequestReadyState:]_block_invoke (ITMLKit)
ITMLKit -[IKAppContext _doEvaluate:] (ITMLKit)
ITMLKit -[IKAppContext _evaluate:] (ITMLKit)
ITMLKit __41-[IKAppContext evaluate:completionBlock:]_block_invoke (ITMLKit)
ITMLKit -[IKAppContext _sourcePerform] (ITMLKit)
ITMLKit -[IKConcurrentEvaluator lockSchedulingForEvaluation:] (ITMLKit)
ITMLKit IKRunLoopSourcePerformCallBack (ITMLKit)
CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (CoreFoundation)
CoreFoundation __CFRunLoopDoSource0 (CoreFoundation)
CoreFoundation __CFRunLoopDoSources0 (CoreFoundation)
CoreFoundation __CFRunLoopRun (CoreFoundation)
CoreFoundation CFRunLoopRunSpecific (CoreFoundation)
ITMLKit -[IKAppContext _jsThreadMain] (ITMLKit)
Foundation __NSThread__start__ (Foundation)
libsyste...ad.dylib _pthread_start (libsystem_pthread.dylib)
libsyste...ad.dylib thread_start (libsystem_pthread.dylib)
This issue seems very similar to this existing thread, although not sure its related
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?
After the release of iOS17, our app has collected JavaScriptCore crashes, and the crash has recently appeared in iOS17 and above. The number of crashes collected recently is increasing.
The following are several complete crash log information. Currently, crashes are only collected on iOS17 and above systems.
2024-05-08_20-45-00.5216_+0800-fdb980f66f56d73b944ccc3466922d7fd0690089.crash
2024-05-11_02-42-46.0303_+0800-5ea1f23ba38c4782b80bd6304a9625e305c296a2.crash
2024-05-13_14-30-03.2084_+0800-d9598b08a153f5214b51257400423d4079049578.crash
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
Hi everyone,
I’m working on an app that uses WKWebView. Due to security concerns, our customers want the app to disable copy-paste functionality and similar options (such as Lookup and Share, allowing users to extract text from the app or save it as a file.
I was able to disable copy-paste and remove UIMenu options like Lookup and Share.
Everything worked fine until the iOS 18.1 beta, which introduced a new menu called Writing Tools (Apple Intelligence) that has its own copy and share buttons
I've tried several ways to remove it
Remove all UIMenu items using canPerformAction, and it works for all menus but Writing Tools, which still remains
override func canPerformAction(_ action: Selector, withSender sender: Any?) -> Bool {
return false
}
Remove it from UIMenuBuilder
override func buildMenu(with builder: UIMenuBuilder) {
builder.remove(menu: .lookup)
builder.remove(menu: .share)
}
But unfortunately, UIMenuBuilder does not have an identifier for Writing Tools, and it seems like there are no API changes from Xcode 15 to Xcode 16 (https://developer.apple.com/documentation/uikit/uimenu/identifier)
It seems like the only way to disable it through MDM configuration (key: allowWritingTools), but we don't use MDM
https://developer.apple.com/documentation/devicemanagement/restrictions
Environment
iOS Version: iOS 18.1 beta4
Device: iPhone 15 Pro
App platform: iOS
Xcode version: 16.0
MacOS: 15.0
Thank you
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.
I’m deploying a pac file through jamf using the auto global http proxy. The purpose of this file is to block some traffic on the network level. We’re deploying the pac on iPhones.
I tried to use
|| shExpMatch(url, “*.pdf”)
to block any url with .pdf but iOS seems to just skip that line without implementing it. Am I doing something wrong or is there an apple specific function that I should use?
thanks
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.
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<***::ObjectIdentifierGeneric<WebCore::PageIdentifierType, ***::ObjectIdentifierMainThreadAccessTraits<unsigned long long>, unsigned long long>>) + 360 frame #3: 0x00000001a94f180c WebCoreWebCore::RealtimeMediaSourceCenter::getUserMediaDevices(WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&, ***::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, ***::CrashOnOverflow, 16ul, ***::FastMalloc>&, ***::Vector<WebCore::RealtimeMediaSourceCenter::DeviceInfo, 0ul, ***::CrashOnOverflow, 16ul, ***::FastMalloc>&, WebCore::MediaConstraintType&) + 356
frame #4: 0x00000001a94f22cc WebCoreWebCore::RealtimeMediaSourceCenter::validateRequestConstraintsAfterEnumeration(***::Function<void (***::Vector<WebCore::CaptureDevice, 0ul, ***::CrashOnOverflow, 16ul, ***::FastMalloc>&&, ***::Vector<WebCore::CaptureDevice, 0ul, ***::CrashOnOverflow, 16ul, ***::FastMalloc>&&)>&&, ***::Function<void (WebCore::MediaConstraintType)>&&, WebCore::MediaStreamRequest const&, WebCore::MediaDeviceHashSalts&&) + 356 frame #5: 0x00000001a94fb394 WebCoreWTF::Detail::CallableWrapper<WebCore::RealtimeMediaSourceCenter::enumerateDevices(bool, bool, bool, bool, ***::CompletionHandler<void ()>&&)::$_0, void>::~CallableWrapper() + 164
frame #6: 0x00000001a814bbe8 WebCoreWTF::Detail::CallableWrapper<WebCore::AVCaptureDeviceManager::refreshCaptureDevicesInternal(***::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
Sometimes the Safari App Extension i'm developing does not show up in my Safari Extensions unless i change mu bundle identifier to some unique name.
Even if I delete all other apps i've built with the same (and different) bundle ID, the extension is still does not show up.
The only solution for me is to always change the bundle ID.
For example:
Now it is "kopyl.tab-finder-10"
If i change it to "kopyl.tab-finder-11", the extension does show up in the Safari extensions settings page again.
Is there any other way to fix it?
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.
Everything was working fine for 4 years.
But since Ventura, when the WKWebView is in focus, the keyDown event are not happening. Not only they don't fire inside of web page input box, but they won't register in the app either.
As long as a WKWebView is in focus, the keyboard events won't work.
The app does not receive the key events, and the web page will not receive the js events keyDown and friends. This is particularly painful with auto complete input box.
Test with an empty project with only a WKWebView with this page
https://www.toptal.com/developers/keycode/for/d
It does work fine on iPhone and iPad.
Message to Apple : You force us to use your Safari engine, yet it is always broken. Don't wait for 8 months to fix it this time, we would be tempted to go full web and skip native app with all the store certification problems.
Is ServiceWorker supported on WKWebView? As per Mozilla Developer Network(MDN Web) docs[1] its not supported, but our research shows that ServiceWorker becomes available for a domain in WKWebView 1) if the domain is allowlisted in app-bound domains[2] or 2) if app is registered as default browser(this can not be considered for our app as its not a browser).
How to enable ServiceWorker on WKWebView? Is adding domain as app-bound domain the right/only way to enable ServiceWorker on WKWebView? We didn't find any official documentation about this.
Can WebView get ServiceWorker support by default without enabling app bound domains since that is not an option for our app? Our app needs to support more than 10 domains. Powerful APIs such as JavaScript injection, cookie manipulation, event handlers are by default available to all domains/WebView instances even if App doesn't enable app-bound domains. Is it possible to do same for ServiceWorker?
If ServiceWorker can not be supported by default then can Apple provide a feature by which ServiceWorker will be enabled in App for all the domains?
Apple enforces maximum of 10 app-bound domains. Is it possible to remove this limit and provide a way to dynamically add to this list at the time of a request?
[1] https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker#browser_compatibility
[2] https://webkit.org/blog/10882/app-bound-domains/
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>
My app Frax has long used a mechanism where a local webpage calls out to web-hosted content. In iOS 17.5+ (and iOS 18 beta) this has recently stopped working. The content fails to load, and the console log (running on iOS 17.6.1) contains:
nw_application_id_create_self NECP_CLIENT_ACTION_GET_SIGNED_CLIENT_ID [80: Authentication error]
Failed to resolve host network app id
followed shortly by:
Error acquiring assertion: <Error Domain=RBSServiceErrorDomain Code=1 "((target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.rendering AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.networking AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.webcontent))" UserInfo={NSLocalizedFailureReason=((target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.rendering AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.networking AND target is not running or doesn't have entitlement com.apple.developer.web-browser-engine.webcontent))}>
0x128024480 - ProcessAssertion::acquireSync Failed to acquire RBS assertion 'XPCConnectionTerminationWatchdog' for process with PID=9736, error: (null)
This same code has worked reliably for years, and continues to work properly under iOS 16 and earlier. But there are increasing reports of this new error showing up around the web. Nothing in recent iOS 17 release notes sheds any light on what might have changed, and all my efforts to troubleshoot or mitigate this issue have failed. Any help on how to solve or work around this would be greatly appreciated!
Topic:
Safari & Web
SubTopic:
General
I’m experiencing an issue in WKWebView on iOS 26 Developer Beta 8. If a view's subview contains a WKWebView, using the CALayer's renderInContext method fails to capture the pixel at the current point, and the console outputs "unsupported surface format: &b38".
The following code snippet was functioning as expected on iOS 18 and iOS 26 beta 1. However, it no longer works in the latest beta.
Is this a known bug in the current iOS 26 betas, or is there a recommended workaround?
- (BOOL)isTransparentAtTouchPoint:(CGPoint)point layer:(CALayer *)layer {
unsigned char pixel[4] = {0};
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
CGContextRef context = CGBitmapContextCreate(pixel, 1, 1, 8, 4, colorSpace, (CGBitmapInfo) kCGImageAlphaPremultipliedLast);
CGContextTranslateCTM(context, -point.x, -point.y);
[layer renderInContext:context];
CGContextRelease(context);
CGColorSpaceRelease(colorSpace);
CGFloat alpha = pixel[3] / 255.0f;
return alpha < 0.01;
}
Since probably the late iOS 17.4.x, 17.5.1 and still now in 17.6 beta our extension has been experiencing issues with the accompanying background script or service worker being permanently killed with no warning after about 30-45 seconds after initial installation (installation, not page load!).
In all other browsers (including Safari on MacOS) unloading the service worker is part of the normal lifecycle to save memory and CPU if it is idle. In our extension the service worker is used only during the first 5-10 seconds of every page visit, so we are used to seeing it unload after that and consider this a good thing. However, normally, the service worker is able to wake back up when needed - which is no longer the case in iOS.
Once dead, nothing a normal user would do can wake the service worker back up:
No events like webNavigation or similar will trigger anymore
Any attempt to call sendMessage to it from a content-script also does not wake up the service worker and instead returns undefined to the content script immediately
Closing and opening Safari does not start it again
The only two things that will give the service worker another 30-40 seconds of life is a reboot of the device or disabling and then re-enabling the extension. During those few second the extension is working perfectly.
There are no errors or indications in the logs of what is going on and the extension works just fine in Chrome, Firefox, Edge as well as Safari on MacOS and Safari in the Mobile simulator. Only actual iOS devices fail.
It seems like a temporary workaround is to change the manifest to not load the service worker as a service worker by changing
"background": {
"service_worker": "service.js"
}
to
"background": {
"scripts": ["service.js"],
"persistent": false
}
With this change (courtesy of https://forums.developer.apple.com/forums/thread/721222) the service worker is still unloaded but correctly starts up again when needed. Having to make this change does not seem to be consistent with manifest v3 specs though (see this part in Chrome’s migration guide as an example: https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers#update-bg-field).
According to the release notes of 17.6 beta this bug was supposedly fixed:
“Fixed an issue where Safari Web Extension background pages would stop responding after about 30 seconds. (127681420)”
However, this bug is not fixed - or at least not entirely fixed. It seems to work better for super simple tests doing nothing but pinging the service worker from the content script, but for the full blown extension there is no difference at all between 17.5.1 and 17.6.
Has there been a change in policy about service workers and background scripts for Safari in iOS?
Are anyone else seeing this issue?
Also seemingly related:
https://forums.developer.apple.com/forums/thread/756309
https://forums.developer.apple.com/forums/thread/750330
https://developer.apple.com/forums/thread/757926
https://forums.developer.apple.com/forums/thread/735307