I think that it would be helpful to have better interoperability between Swift and JavaScript. There are a lot of useful packages on NPM that don't have equivalents for Swift. It would be helpful if Apple provided easier ways to use NPM packages in a Swift project. Currently, the JavaScriptCore framework is missing many standard things used in many packages, like the fetch API. It would be helpful to be able to run sandboxed JavaScript code inside of a Swift app but allow access to specific domains, folders, etc., using a permissions system similar to Deno.
WebKit
RSS for tagDisplay web content in windows and implement browser features using WebKit.
Posts under WebKit tag
200 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Running print operation on WKWebView I hit EXC_BREAKPOINT and there is all kinds of console spew that looks concerning:
ERROR: The NSPrintOperation view's frame was not initialized properly before knowsPageRange: returned. (WKPrintingView)
** CGContextClipToRect: invalid context 0x0. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable.**
WebContent[7743] networkd_settings_read_from_file Sandbox is preventing this process from reading networkd settings file at "/Library/Preferences/com.apple.networkd.plist", please add an exception.
CRASHSTRING: XPC_ERROR_CONNECTION_INVALID from launchservicesd
CRASHSTRING: rdar://problem/28724618 Process unable to create connection because the sandbox denied the right to lookup com.apple.coreservices.launchservicesd and so this process cannot talk to launchservicesd.
WebContent[7921] The sandbox in this process does not allow access to RunningBoard.
Safe to ignore all this?
Hi, we were recently approved for the com.apple.developer.web-browser.public-key-credential entitlement and have added it to our app. It initially worked as expected for a couple of days, but then it stopped working. We're now seeing the same error as before adding the entitlement:
Told not to present authorization sheet: Error Domain=com.apple.AuthenticationServicesCore.AuthorizationError Code=1 "(null)"
ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)"
Do you have any insights into what might be causing this issue?
Thank you!
Hi everyone,
I’m building a React Native iOS app where I’m integrating Wazo (native WebRTC) and Jitsi (WebView / WebRTC).
Use case:
Wazo is used to maintain a background call session (mainly signaling + audio keep-alive).
Jitsi is used in the foreground for video calls.
Problem:
When Jitsi starts, it takes control of the microphone and camera.
The Wazo call disconnects after ~5 minutes (likely due to media / audio session conflict).
Even if Wazo audio/video is muted or tracks are disabled, the session still drops.
My questions:
Is it officially supported or recommended to run two WebRTC stacks (Wazo + Jitsi) simultaneously on iOS?
Can Wazo stay connected without active audio/video tracks while Jitsi uses mic/camera?
Is there a way to release Wazo media streams temporarily (but keep signaling alive) while Jitsi is loading or active?
Are there any AVAudioSession / background mode limitations on iOS that make this impossible by design?
If this is not supported, what is the recommended architecture (single WebRTC pipeline, switching media ownership, etc.)?
Environment:
iOS (React Native)
Wazo SDK (native WebRTC)
Jitsi Meet (WebView)
CallKit + PushKit enabled
Any guidance, documentation, or real-world experience would be greatly appreciated.
Thanks in advance 🙏
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?
Hello,
I am implementing video calling on iOS and need to support Picture in Picture (PiP) behavior similar to FaceTime or WhatsApp.
What works
Audio continues correctly in background
CallKit UI works as expected
Video works correctly while the app is in the foreground
What I’m trying to achieve
When the user presses the Home button or switches apps, I want to show a system Picture in Picture window (floating video outside the app).
Current setup
Video is rendered via WebRTC
The video is displayed inside a WKWebView (HTML / JavaScript)
PiP works only while the app is foregrounded
When the app backgrounds, the video disappears (only audio remains)
Questions
Does iOS support system Picture in Picture for:
WebRTC video
WKWebView / HTML video
2 Is AVPictureInPictureController limited only to:
AVPlayerLayer
AVSampleBufferDisplayLayer
3 If PiP requires native rendering:
Is it mandatory to render WebRTC frames natively using AVSampleBufferDisplayLayer?
Is PiP explicitly unsupported for WebView / HTML video?
📌 Clarification
Apps like FaceTime and WhatsApp are able to show PiP outside the app.
I want to understand whether this behavior is achievable only with native video pipelines, or if WebView-based video is fundamentally restricted by iOS.
Any official clarification or documentation reference would be appreciated.
Thank you.
I’m currently developing an application using WKWebView.
After updating to iOS 26.2 Developer Beta, the following Web API started returning false:
isUserVerifyingPlatformAuthenticatorAvailable
MDN: https://developer.mozilla.org/ja/docs/Web/API/PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable_static
This issue did not occur on iOS 26.1 — it only happens on the beta version.
Has anyone else encountered this problem or is aware of any related changes?
OS: iOS 26.2 beta 3 (23C5044b)
The passkey authentication dialog appears, and after unlocking with Touch ID, the dialog closes without any notification of success or failure.
This issue occurs with high frequency.
access to the https://passkeys-demo.appspot.com/
register account and create passkey.
logoff
access to the url again
you can see the passkey dialog
unlock device then the dialog disappears
nothing happens
reload the page
proceed 5) to 6)
nothing happens or success webauthn.
Topic:
Safari & Web
SubTopic:
General
Tags:
WebKit JS
WebKit
Safari and Web
Passkeys in iCloud Keychain
Hi all. Thanks in advance for any guidance you’re able to offer.
We’ve had an issue reported by multiple customers where, following an iOS update, our app crashes on the next launch. When this happens, users briefly see a split screen: half of the view shows the app background, while the other half is completely black. After this point, the app is unusable.
Here’s what we’ve uncovered so far during our investigation:
We believe this occurs when a user is already signed into the app at the time they install the iOS update. For context, we intentionally do not force users to log out of the app, as it’s primarily used for customer support and assistance. This is a firm business decision and not something we plan to change.
We suspect the issue is related to our Flutter WebView and how it restores or reloads session state following an iOS update. In the past, updating the Flutter version has resolved similar issues, but we are currently on the latest available version.
Once the half-screen issue occurs, all app functionality is blocked. At present, the only workaround is for the user to delete and reinstall the app.
The most frustrating part is that this does not affect all users. Some customers have updated to iOS 26.2 without any issues at all. We’ve been unable to reproduce the problem internally, despite extensive testing and attempts to force the conditions. That said, our IT Director did experience the issue firsthand on his own device.
For our next release, we’re planning to try the following changes, though we won’t know for certain whether they resolve the issue until the update is in the wild.
First, disabling iOS state restoration:
func application(_ application: UIApplication,
shouldSaveApplicationState coder: NSCoder) -> Bool {
return false
}
func application(_ application: UIApplication,
shouldRestoreApplicationState coder: NSCoder) -> Bool {
return false
}
This was recommended to us as it’s apparently a common approach to addressing post-update freezes or broken restore states.
Second, detecting an iOS version change and resetting the WebView / Flutter state on first launch after an update:
let lastOS = UserDefaults.standard.string(forKey: "lastOSVersion")
let currentOS = UIDevice.current.systemVersion
if lastOS != currentOS {
// Clear WebView data
WKWebsiteDataStore.default().removeData(
ofTypes: WKWebsiteDataStore.allWebsiteDataTypes(),
modifiedSince: Date.distantPast,
completionHandler: {}
)
// Force Flutter engine restart
// OR route user through a native splash/login screen
UserDefaults.standard.set(currentOS, forKey: "lastOSVersion")
}
The idea here is to ensure the WebView and Flutter engine start cleanly after an iOS update, rather than attempting to restore potentially incompatible state.
We’d really welcome any ideas, suggestions, or feedback from others who may have encountered something similar. Apologies in advance if any details are vague — I’m not deeply technical, so this is based on the research and guidance we’ve gathered so far.
Thanks again for your time and help,
Chris Brodier
I'm building a progressive web app (PWA) and came to the conclusion that almost nobody knows that this feature exists - Add to Home Screen. Not many people even understand what a PWA is or that you can add it to the home screen. This feels unnatural compared to installing an app from a store. Why do we make it so hard for users? Could we not make this easier by having the ability to call this installation or show an install notification?
Right now, when users visit a PWA on iOS, there's no way for developers to let them know they can install it. The "Add to Home Screen" option is tucked away in the Share menu, and most users never find it. I'd really like to be able to show them a friendly prompt.
Comparing to other browsers, this is possible via the beforeinstallprompt event. This would make a huge difference for user experience. Right now the only way is to show iOS users a separate set of instructions with screenshots, which feels clunky compared to what's possible on other platforms.
I'm curious - is there any reason why this hasn't been added to Safari yet? Other browsers have supported this for years now. Is there any progress being made on this, or is it being considered for the roadmap? It would be really helpful to know if this is something that will be worked on in the future.
I know there's a lot on the roadmap, but this would really help developers create better installation experiences for our users.
Thanks for considering this!
Fatal Exception: NSInternalInconsistencyException
Cannot remove an observer <WKWebView 0x135137800> for the key path "configuration.enforcesChildRestrictions" from <STScreenTimeConfigurationObserver 0x13c6d7460>, most likely because the value for the key "configuration" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the STScreenTimeConfigurationObserver [class.]
I noticed that on iOS 26, WKWebView registers STScreenTimeConfigurationObserver, Is this an iOS 26 system issue? What should I do?
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));
}];
});
}
I'm being faced with an issue when using SwiftUI's WebView on iOS 26. In many websites, the top/bottom content is unaccessible due to being under the app's toolbars. It feels like the WebView doesn't really understand the safe areas where it's being shown, because the content should start right below the navigation bar, and only when the user scrolls down, the content should move under the bar (but it's always reachable if the users scroll back up).
Here's a demo of the issue:
Here's a 'fix' by ensuring that the content of the WebView never leaves its bounds. But as you can see, it feels out of place on iOS 26 (would be fine on previous OS versions if you had a fully opaque toolbar):
Code:
struct ContentView: View {
var body: some View {
NavigationStack {
WebView(url: URL(string: "https://apple.com")).toolbar {
ToolbarItem(placement: .primaryAction) {
Button("Top content covered, unaccessible.") {}
}
}
}
}
}
Does anyone know if there's a way to fix it using some sort of view modifier combination or it's just broken as-is?
The crash is specific to iOS 26.2 prior versions working fine.
WKScriptMessageHandler delegate func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage)
Name attribute is accessible but WKScriptMessage body attribute causes crash
The object seems to be not accessible(not in memory)
self.webkit.configuration.userContentController.add(self, name: "sampleHandler")
self.webkit.load(request)
func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
print(message.name) // works print(message.body) // crashes
}
The crash is specific to iOS 26.2 WKScriptMessageHandler delegate func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage)
Name attribute is accessible but WKScriptMessage body attribute causes crash
The object seems to be not accessible
Safari/WebKit Crashes on Johnson Controls Website Across Multiple iOS Versions (Actual devices only)
Here we are facing issue, which is mentioned in detail below:
Safari on iOS consistently crashes when loading https://johnsoncontrols.com/. The error shown is:
“A Problem repeatedly occurred on https://johnsoncontrols.com/”
This happens with multiple iPhone models and iOS versions, suggesting a WebKit rendering or JavaScript execution issue. This occurs occasionally similar behavior on Android, iPhone (Chrome)
Environment
• Devices: Any iPhone model, we are tested on available models like iPhone 12 mini, iPhone 14, iPhone 15
• iOS Versions: Latest stable releases, occasional occurrence on iOS 13
• Browser: Safari (WebKit)
• Network: Both Wi-Fi and cellular tested
• Additional Occurrences: Rarely reproduced on Chrome (iPhone, Narzo Android)
• Occurs only on physical devices (not observed in Simulator)
Steps to Reproduce
Open Safari on any affected iOS device.
Navigate to https://johnsoncontrols.com/.
Sroll page up and down for some time
Observe page automatically get reloads, crashed and show error message (A problem repeatedly occurred on “https://johnsoncontrols.com/").
Expected Result
Page should be rendered normally without crashing.
Actual Result
Safari reloads page / blank / crashed and displays errors.
Troubleshooting Done
• Cleared cache and cookies
• Disabled content blockers
• Tested in Private mode
• Reset Experimental Features
• Issue persists across different networks
Technical Notes
• Suspect JavaScript memory leak or DOM manipulation causing WebKit crash.
• Intelligent Tracking Prevention (ITP) or site scripts may conflict.
Questions for Community
• Can Apple confirm whether this aligns with any known WebKit bugs?
• Are there recommended diagnostic steps (e.g., Web Inspector, crash logs, sysdiagnose specifics) for reproducing Safari scroll-related site crashes?
• Should the site’s development team adjust JavaScript, rendering approach, or resource handling to improve stability on WebKit?
Here we are facing issue, which is mentioned below:
On https://johnsoncontrols.com/, tapping the blue “Scroll to Top” button (up arrow icon) causes the entire page to reload instead of smoothly scrolling back to the top. This issue occurs only on physical iOS devices and is reproducible across multiple models and iOS versions. Similar behavior is rarely/occasionally seen in Chrome on iPhone and some Android devices.
Environment
• Devices: Any iPhone model, we are tested on available models like iPhone 12 mini, iPhone 14, iPhone 15
• iOS Versions: Latest stable releases
• Browser: Safari (WebKit)
• Network: Both Wi-Fi and cellular tested
• Additional Occurrences: Rarely reproduced on Chrome (iPhone, Narzo Android)
• Occurs only on physical devices (not observed in Simulator)
Steps to Reproduce
Open Safari on a physical iPhone.
Navigate to https://johnsoncontrols.com/.
Scroll down until the blue “Scroll to Top” button appears on the right side.
Then tap on ‘Scroll to top’ button.
The page reloads instead of scrolling to the top.
Expected Result
Tapping the Scroll to Top button should smoothly move the user to the top of the page without reloading.
Actual Result
Safari reloads the entire page when the button is tapped.
Troubleshooting Done
• Replaced # with javascript:void(0) in the button’s anchor tag
• Tested with e.stopPropagation()
• Switched button position from fixed to sticky
• Tried overflow-y: scroll; and -webkit-overflow-scrolling: touch; on body
• Updated scrollTop logic to match iOS‑compatible standards.
Questions for Community
• Is this a known WebKit issue on physical iOS devices?
• Any recommended debugging or profiling steps to better understand the cause?
• Are there best practices or example implementations to improve Safari compatibility for scroll to top interactions?
Hello,
We are experiencing a behavior change with WKWebView related to upgradeKnownHostsToHTTPS.
Current application, we explicitly disable automatic HTTPS upgrades:
let config = WKWebViewConfiguration()
config.upgradeKnownHostsToHTTPS = false
Observed behavior
iOS 17.5 (built with Xcode 15.3)
http:// image URLs are not automatically upgraded to https://, and the behavior works as expected.
iOS 18.5 / 18.6.x (built with Xcode 16.4)
http:// image URLs appear to be automatically upgraded to https:// by WebKit, even when upgradeKnownHostsToHTTPS is explicitly set to false.
This behavior occurs for subresource requests such as <img src="http://..."> inside a WKWebView.
Question
Has the behavior of upgradeKnownHostsToHTTPS changed in iOS 18 / Xcode 16?
Is this property now ignored for certain types of subresource requests (e.g. images), or overridden by new WebKit security policies such as mixed-content HTTPS upgrades?
Any clarification or official guidance would be greatly appreciated!.
We are developing a hybrid iOS app where Angular content is rendered inside a WKWebView, hosted by a native Swift application.
We use the GameController framework to detect whether an external Bluetooth keyboard is connected to an iPad. The following code is executed when the app enters the foreground and also when requested by the web layer:
func keyboardStatusHandler(){
let isKeyboardConnected = GCKeyboard.coalesced != nil
if(!isKeyboardConnected){
//sent status to Angular
} else {
//sent status to Angular
}
}
Crash details
We are seeing intermittent crashes on iPad with the following stack trace:
Crashed: GCDeviceSession.HID
0 libobjc.A.dylib 0x7db8 objc_retain_x8 + 16
1 libsystem_blocks.dylib 0xfb8 void HelperBase<ExtendedInline>::copyCapture<(HelperBase<ExtendedInline>::BlockCaptureKind)3>(unsigned int) + 48
2 libsystem_blocks.dylib 0xbc4 HelperBase<GenericInline>::copyBlock(Block_layout*, Block_layout*) + 108
3 libsystem_blocks.dylib 0xc94 _call_copy_helpers_excp + 60
4 libsystem_blocks.dylib 0xef8 _Block_copy + 412
5 libdispatch.dylib 0x1a70 _dispatch_Block_copy + 32
6 libdispatch.dylib 0x792c dispatch_async + 56
7 libdispatch.dylib 0x792c dispatch_channel_async + 56
8 GameController 0xea6dc -[GCKeyboardInput _handleKeyboardEvent:] + 324
9 GameController 0x22508 __53-[_GCKeyboardEventHIDAdapter initWithSource:service:]_block_invoke + 376
10 GameController 0x11d30 -[_GCHIDEventSubject publishHIDEvent:] + 268
11 GameController 0xb79cc __40-[_GCHIDEventUIKitClient initWithQueue:]_block_invoke_3 + 44
12 libdispatch.dylib 0x1b584 _dispatch_client_callout + 16
13 libdispatch.dylib 0x12088 _dispatch_async_and_wait_invoke_and_complete_recurse + 272
14 libdispatch.dylib 0x8448 _dispatch_async_and_wait_f + 108
15 GameController 0xb7984 __40-[_GCHIDEventUIKitClient initWithQueue:]_block_invoke_2 + 132
16 GameController 0xb746c __48-[__GCHIDEventUIKitClient _initWithApplication:]_block_invoke + 256
17 UIKitCore 0x11fd394 __61-[UIEventFetcher _setHIDGameControllerEventObserver:onQueue:]_block_invoke_3 + 40
18 libdispatch.dylib 0x1aac _dispatch_call_block_and_release + 32
19 libdispatch.dylib 0x1b584 _dispatch_client_callout + 16
20 libdispatch.dylib 0xa2d0 _dispatch_lane_serial_drain + 740
21 libdispatch.dylib 0xadac _dispatch_lane_invoke + 388
22 libdispatch.dylib 0x151dc _dispatch_root_queue_drain_deferred_wlh + 292
23 libdispatch.dylib 0x14a60 _dispatch_workloop_worker_thread + 540
24 libsystem_pthread.dylib 0xa0c _pthread_wqthread + 292
25 libsystem_pthread.dylib 0xaac start_wqthread + 8
Observed scenarios
Crash occurs when the app transitions from background to foreground
Crash also occurs when the Angular layer requests keyboard status, triggering the same code path
Questions
Has anyone encountered crashes related to GCKeyboard.coalesced or GCKeyboardInput like this?
Are there known issues with the GameController framework when querying keyboard state during app lifecycle transitions?
Is there a recommended or safer way to detect external keyboard connection status on iPad (especially when using WKWebView)?
Any insights, known platform issues, or suggested workarounds would be greatly appreciated.
Thanks!
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?