Dear Apple Developer Support, I am developing and maintaining an iOS application. In iOS 26, we understand that setting UIDesignRequiresCompatibility to true in the Info.plist file allows an app to opt out of the Liquid Glass design. However, we also understand that during WWDC25 Platforms State of the Union, Apple stated: "We intend this option to be removed in the next major release." We would appreciate clarification on the following points. Questions Should the phrase "next major release" be interpreted as iOS 27? Is it currently Apple's plan to make UIDesignRequiresCompatibility unavailable or remove it in iOS 27? Or is the statement above only an intended direction, with the actual removal schedule still subject to change? If there is any publicly shareable information regarding the future availability or deprecation timeline of UIDesignRequiresCompatibility, could you please provide it? Background We develop and maintain a business application that contains a large number of custom screens and UI components. Adapting the entire application to the Liquid Glass design system will require significant design review, implementation effort, and testing. As a result, the future availability of UIDesignRequiresCompatibility is a critical factor in our development planning and resource allocation. For this reason, we would greatly appreciate any guidance you can provide regarding Apple's current plans for this compatibility option. Thank you for your time and assistance. Best regards, Toshiyuki

I work on a universal app that targets both iPhone and iPad. Our iPad app currently requires full screen. When testing on the latest iPadOS 26 beta, we see the following warning printed to the console: Update the Info.plist: 1) `UIRequiresFullScreen` will soon be ignored. 2) Support for all orientations will soon be required. It will take a fair amount of effort to update our app to properly support presentation in a resizable window. We wanted to gauge how urgent this change is. Our testing has shown that iPadOS 26 supports our app in a non-resizable window. Can someone from Apple provide any guidance as to how soon “soon” is? Will UIRequiresFullScreen be ignored in iPadOS 26? Will support for all orientations be required in iPadOS 26?

For a UIKit app based on scenes (UIScene), is it safe to reference UserDefaults in code that is executed from UIApplicationDelegate/application(_: didFinishLaunchingWithOptions:) ? I've read that in iOS 15, there were undocumented scenarios involving app prewarming that would cause UserDefaults reads to fail within a window of time after device reboots, as described at https://christianselig.com/2024/10/beware-userdefaults/ The failure mode is that an app would be released, and months later, a small fraction of users would report failures consistent with UserDefaults reads unexpectedly returning nil, causing a loss of data. The user experience is bad, and debugging this behavior is then challenging because of how rarely it occurs. Apple's https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app/about_the_app_launch_sequence#3894431 seems to suggest that prewarming only executes an app "up until, but not including when main() calls UIApplicationMain(_:_:_:_:), but https://stackoverflow.com/questions/71025205/ios-15-prewarming-causing-appwilllaunch-method-when-prewarm-is-done documents that UIApplicationDelegate/application(_: didFinishLaunchingWithOptions:) has in fact been observed executing during app prewarming in scene-based apps. So, my question: In an app based on scenes, if I'd like to reference UserDefaults within UIApplicationDelegate/application(_: didFinishLaunchingWithOptions:), when is it safe to do this? I'm guessing the answer is one of these: Never. Only in apps that don't support scenes. Only in iOS 16 or later. Only in IOS 17 or later. Is it guaranteed safe to reference UserDefaults in UIWindowSceneDelegate/scene(_:willConnectTo:options:) or later? Is there documentation from Apple regarding this issue? Thank you.

I have an iPad app which is trying to support document renaming in the title bar. For IOS 17+ I set the renameDelegate to the document instance and it works fine. For IOS 16 I need to create an actual delegate, but no matter how I structure the code it fails with a permission error: Rename failed: “original_file_name” couldn’t be moved because you don’t have permission to access “Desktop”. It seems to always happen accessing the parent directory. I have tried using the file coordinator as well with the same result. It seems impossible to implement unless the callback contains a security permissioned url for the parent directory. Is there anyway to make this work in IOS 16 in the sandbox? Do I have to create my own rename functionality using a FilePicker? Seems like this should be built in like it is in MacOS, or even IOS17+ Here is the code: extension DocumentWindow : UINavigationItemRenameDelegate { func navigationItem(_ navigationItem: UINavigationItem, didEndRenamingWith title: String) { guard let doc = document else { return } let oldURL = doc.fileURL let newURL = oldURL.deletingLastPathComponent() .appendingPathComponent(title) .appendingPathExtension(oldURL.pathExtension) if newURL == oldURL { return } let access = oldURL.startAccessingSecurityScopedResource() defer { if access { oldURL.stopAccessingSecurityScopedResource() }} do { try FileManager.default.moveItem(at: oldURL, to: newURL) } catch { print("Rename failed: \(error.localizedDescription)") } // // // 1. Jump to a background queue to avoid the deadlock // DispatchQueue.global(qos: .userInitiated).async { // let coordinator = NSFileCoordinator(filePresenter: doc) // var error: NSError? // // // coordinator.coordinate(writingItemAt: oldURL, error: &error) { outOld in // do { // // 2. Perform the actual rename // try FileManager.default.moveItem(at: outOLD, to: newURL) // } catch { // print("Rename failed: \(error.localizedDescription)") // } // } // // if let error = error { // print("Coordination error: \(error.localizedDescription)") // } // } } // 2. Optional: Validation (e.g., prevent empty names) func navigationItem(_ navigationItem: UINavigationItem, shouldEndRenamingWith title: String) -> Bool { return !title.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty } }

Issue Description: On iOS 26 and later, a CoreGraphics crash occurs when rendering images using -[UIImage drawInRect:blendMode:alpha:]. Based on the call stack, the crash happens inside CoreGraphics. Under what circumstances does the function upscale_provider_get_bytes_at_position_inner in the stack get called? When attempting to reproduce locally, this code path is never reached even when scaling images. Steps to Reproduce: There are a large number of crash reports in production, but the issue cannot be reproduced locally/offline. Expected Results: Explain under what conditions calling -[UIImage drawInRect:blendMode:alpha:] will reach the upscale_provider_get_bytes_at_position_inner logic. Ideally, provide a code example or demo. Provide the root cause of the crash and a workaround/mitigation. Current Behavior: Calling -[UIImage drawInRect:blendMode:alpha:] causes intermittent crashes in production. Xcode Version Used: Xcode Version 26.0 (17A324)

Hi everyone, I'm experiencing a weird visual glitch with PickerStyle(.segmented) placed inside a ToolbarItem(placement: .principal). When navigating between views or switching segments, the text doubles/overlaps temporarily during the transition animation (as shown in the screen recording).

Hi everyone, I'm experiencing a weird visual glitch with PickerStyle(.segmented) placed inside a ToolbarItem(placement: .principal). When navigating between views or switching segments, the text doubles/overlaps temporarily during the transition animation (as shown in the screen recording).

The context is partially expressed in an earlier post. In summary: There is an iOS App target that contains minimal code, only to load a Framework explicitly at runtime using dlopen and dlsym, instead of the usual load-time imports in Apple platforms. For iOS app (C++ (primary) and Swift), the entry point is a UIApplicationDelegate conformer class - AppDelegate, marked with @main. But the problem is, the AppDelegate class cannot remain in the App target, which has barely any logic. The App target is a thin loader. The AppDelegate contains some methods such as application(_:didRegisterForRemoteNotificationsWithDeviceToken:) that needs some logical processing, which is not present in the App target. Instead of using dlsym (to hand over to the Framework) for every AppDelegate event that doesn't have a broadcast notification, the thought was to move the AppDelegate class into the Framework, and the entry point in App target is now main.swift. This keeps the Framework clean and minimal with the following steps: Interop to C++ Explicitly loading the MachO binary inside the Framework using dlopen Loading the symbol using dlsym Invoking the Framework entry point Then, the Framework entry point in C++ creates the UIApplication class and the UIApplicationDelegate using UIApplicationMain(_:_:_:_:) method, which doesn't return as it transfers control to the UIApplicationDelegate. This is against the recommended @main entry point, but based on research, @main seems like syntactic sugar to avoid writing boilerplate code. But in my case, which needs to avoid instantiating the UIApplicationDelegate in the App target, using main.swift, even for an iOS app, is the best fit. I understand that main thread has to be returned back to the OS asap for processing user events etc., and the intent is to not execute the entire startup logic of the app in main thread. Wanted to confirm if this approach of using main.swift entry point is valid for iOS, iPadOS and tvOS apps too and in which case, these flows can converge to macOS, which is already using main.swift approach.

Posting here in case other CarPlay developers are hitting the same thing, and to give Apple engineers a forum-side reference for the radar. Filed as FB22828125. Symptom In a CarPlay app using CPListTemplate, UIImage instances assigned to CPListItem.image start rendering as the system placeholder glyph after extended CarPlay use (several hours to a few days of cumulative session time). Text labels and accessory chevrons still render correctly — only the leading image is affected, and it affects every visible template surface at once. Known recovery Once the failure starts, it survives: Killing and relaunching the app Force-quitting and relaunching from CarPlay itself Disconnecting and reconnecting CarPlay The only known recovery is rebooting the iPhone. After reboot, the same code path renders correctly again — until the failure reoccurs. App-side ruling-out UIImage instances passed to CPListItem.image are non-nil at failure time (verified by assertions) Each template rebuild calls UIGraphicsImageRenderer afresh from UIImage(systemName:) — no caching of UIImage across rebuilds Images are baked via withTintColor(_:renderingMode: .alwaysOriginal) then rasterized, so CarPlay receives a finished bitmap rather than a template image relying on its tinting pipeline Same code path renders correctly on launch and for hours afterward — the input bytes are identical before and after the failure boundary Because the failure survives both the app process and the CPTemplateApplicationScene teardown, the corrupted state appears to live in an iOS system process rather than in the app or the CarPlay session. Question for the forum Is there a known workaround on the app side — a different image-supply API, or a way to force the CarPlay rendering pipeline to invalidate its cache without an iPhone reboot?

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

Hello, I am exploring an iPadOS product idea for Apple Pencil users and would like to understand the current public API boundary. The user need is a temporary, user-controlled Apple Pencil annotation layer while the user is working in another app or workspace. For example, a student may be reading in Books, Safari, a PDF app, or another educational app and want to write quick Pencil notes directly over the visible material without taking a screenshot or exporting the content first. I understand that PencilKit works inside an app's own UI, and I also understand that iPadOS sandboxing prevents third-party apps from inspecting or modifying other apps. I am not trying to bypass that model. What I am trying to determine is: Is there any current public API, extension point, or entitlement that allows a user-initiated Apple Pencil overlay session across the current iPadOS workspace? If not, is Feedback Assistant the right place to request a new PencilKit / iPadOS entitlement for this use case? Are there existing Apple-recommended patterns for this workflow beyond Quick Note, Screenshot Markup, Split View, Stage Manager, or importing content into the developer's own app? The privacy model I have in mind would be strict: The overlay is user initiated only. A visible system indicator is shown while active. The developer app receives Pencil stroke data only by default. The app cannot inspect the underlying app's view hierarchy, documents, text, or private data. Screen pixels are not captured unless the user grants separate explicit permission. The user can close or clear the overlay at any time. The closest mental model is a system-mediated Pencil annotation layer, not a background screen recorder or a way to control another app. If this is not possible today with public APIs, I would appreciate confirmation so I can file a clear enhancement request through Feedback Assistant. I also filed this as Feedback Assistant report FB23067750. Thank you.

Hi team, We are seeing a high volume of app terminations (uANRs), with most of them sharing the attached stack trace. I’d love to get your input on potential workarounds or fixes we can explore to mitigate this issue. 0 CoreFoundation -[__NSSingleObjectArrayI countByEnumeratingWithState:objects:count:] + 132 1 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 228 2 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 3 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 4 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 5 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 6 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 7 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 8 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 9 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 10 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 11 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 12 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 13 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 14 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 15 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 16 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 17 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 18 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 19 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 296 20 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 21 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 22 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 23 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 24 ScreenshotServices +[SSScreenshotMetadataHarvester _crawlViewController:executingBlock:] + 196 25 ScreenshotServices +[SSScreenshotMetadataHarvester _contentRectsForMetadata] + 216 26 ScreenshotServices +[SSScreenshotMetadataHarvester harvestScreenshotMetadataAndRespondToAction:] + 628 27 UIKitCore -[UIScreenshotMetadataRequestAction fulfillRequest] + 180 28 UIKitCore -[UIApplication _handleNonLaunchSpecificActions:forScene:withTransitionContext:completion:] + 3432 29 UIKitCore -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 412 30 UIKitCore -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 31 UIKitCore -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 336 32 FrontBoardServices __76-[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke.146 (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 252 33 FrontBoardServices -[FBSScene _callOutQueue_coalesceClientSettingsUpdates:] + 68 34 FrontBoardServices -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] + 712 35 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 + 148 36 FrontBoardServices -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 37 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke.cold.1 + 252 38 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke + 184 39 libdispatch.dylib _dispatch_client_callout + 16 40 libdispatch.dylib _dispatch_block_invoke_direct + 284 41 FrontBoardServices __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 52 42 FrontBoardServices -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 240 43 FrontBoardServices -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] (in 1d4f7bf8-ca62-3218-a074-9187a2d191ae) + 28 44 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in ae3c9338-0166-397a-9643-356b14f6ee58) + 28 45 CoreFoundation __CFRunLoopDoSource0 (in ae3c9338-0166-397a-9643-356b14f6ee58) + 172 46 CoreFoundation __CFRunLoopDoSources0 (in ae3c9338-0166-397a-9643-356b14f6ee58) + 332 47 CoreFoundation __CFRunLoopRun (in ae3c9338-0166-397a-9643-356b14f6ee58) + 840 48 CoreFoundation CFRunLoopRunSpecific (in ae3c9338-0166-397a-9643-356b14f6ee58) + 572 49 GraphicsServices GSEventRunModal (in d372e13f-7505-3add-ae13-062656f0b1f6) + 168 50 UIKitCore -[UIApplication _run] (in 5e794caa-4162-3ff6-861e-45f29f6b8ac0) + 816 51 UIKitCore UIApplicationMain (in 5e794caa-4162-3ff6-861e-45f29f6b8ac0) + 336

I am encountering a consistent, reproducible crash in our app when presenting a UIDatePicker configured with the calendar style. The crash triggers every single time the picker is invoked and points directly to the modern date picker's internal UICollectionView. The Exception: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'UICollectionView internal inconsistency: attempted to set layout with the collection view requiring a reload' let datePicker = UIDatePicker() datePicker.datePickerMode = .date datePicker.preferredDatePickerStyle = .compact This crash is occuring in inline style too when I try to open the calendar. I tried this in other apps. It works fine. I didn't override any collectionView layouts

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

I couldn't decide whether to post this question here or in SwiftUI Q&A as there's a lot of overlaps. We're trying to create something similar to UIViewRepresentable for UIKit. This might not work for complicated cases where the View has many pieces but as long as it works for simple cases, we're happy. The only problem right now is figuring out the correct height. Currently, the height anchor is assigned to CGFloat.greatestFiniteMagnitude, which works but when inspecting the layout in View Hierarchy, it appears the wrapped view is getting stretched all the way down. Also, sometimes View Hierarchy isn't able to draw the wrapped View and I'm unsure if it's a problem of View Hierarchy or our implementation. final public class SwiftUIConfigurationContainerView<T: View>: UIView { private var contentView: UIView? public override var intrinsicContentSize: CGSize { contentView?.intrinsicContentSize ?? super.intrinsicContentSize } private var preferredContentSize: CGSize? public init(@ViewBuilder _ content: @escaping () -> T) { super.init(frame: .zero) setUpContentView(content) } @available(*, unavailable) required init?(coder: NSCoder) { return nil } private func setUpContentView(_ content: @escaping () -> T) { let contentView = UIHostingConfiguration { [weak self] in VStack(spacing: .zero) { content() .onGeometryChange(for: CGSize.self, of: \.size) { size in self?.preferredContentSize = size self?.invalidateIntrinsicContentSize() } .frame(maxWidth: .infinity, alignment: .center) Spacer(minLength: .zero) } } .minSize(width: .zero, height: .zero) .margins(.all, .zero) .makeContentView() self.contentView = contentView addSubview(contentView) contentView.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ contentView.leadingAnchor.constraint(equalTo: leadingAnchor), contentView.trailingAnchor.constraint(equalTo: trailingAnchor), contentView.topAnchor.constraint(equalTo: topAnchor), contentView.heightAnchor.constraint(equalToConstant: CGFloat.greatestFiniteMagnitude), ]) } }

See existing post here: https://developer.apple.com/forums/thread/803378 When I add a UIScrollEdgeElementContainerInteraction to a view at the top of a scroll view, the blur effect doesn't always fill the full bounds of the view. The behavior changed a bit from 26.0 to 26.1 and then again in 27.0 seed 1. It depends on what subviews are there, and particularly (at least between 26.1 and 26.5) if there's a UIVisualEffectView with a glass effect. FB20756572

It seems like the automatic edge effect defaults to hard in iOS 27 and soft on iOS 26. Designing for both of these is actually quite difficult - especially since hard edge effects don't work with pinned views in LazyVStack. Is there a way to set the global default to soft for an app?

I've got an iOS app with a custom top toolbar view that uses a UIScrollEdgeElementContainerInteraction to achieve the iOS 26 progressive blur background. It's over top of a web view, and I've set the top edge effect style on its scroll view to .hard so the toolbar's edges are more defined. I'm noticing that the blur doesn't extend fully to the bottom edge of the toolbar, and I'm curious to know if this is a bug or expected behavior. If the latter, what exactly are the details of what's expected? What determines the bottom extent of the blur? I've got this result in a sample project on iOS 26.0. The white border is the label, and the red border is the title bar view itself. Note that the Daring Fireball logo visible inside the bounds of the bar view, and is cut off at the bottom edge of the label. This is the code from the demo app that produced the screenshot. let config = WKWebViewConfiguration() let webView = WKWebView(frame: .zero, configuration: config) self.view.addSubview(webView) webView.translatesAutoresizingMaskIntoConstraints = false webView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true; webView.bottomAnchor.constraint(equalTo: self.view.bottomAnchor).isActive = true; webView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true; webView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true; webView.scrollView.topEdgeEffect.style = .hard webView.load(URLRequest(url: URL(string: "https://daringfireball.net")!)) let barView = UIView() self.view.addSubview(barView) barView.translatesAutoresizingMaskIntoConstraints = false barView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true; barView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true barView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true let edgeEffect = UIScrollEdgeElementContainerInteraction() edgeEffect.scrollView = webView.scrollView edgeEffect.edge = .top barView.addInteraction(edgeEffect) barView.layer.borderColor = UIColor.red.cgColor barView.layer.borderWidth = 1 let titleLabel = UILabel() barView.addSubview(titleLabel) titleLabel.translatesAutoresizingMaskIntoConstraints = false titleLabel.leftAnchor.constraint(equalTo: barView.leftAnchor).isActive = true titleLabel.rightAnchor.constraint(equalTo: barView.rightAnchor).isActive = true titleLabel.bottomAnchor.constraint(equalTo: barView.bottomAnchor, constant: -20).isActive = true titleLabel.topAnchor.constraint(equalTo: barView.safeAreaLayoutGuide.topAnchor, constant: 8).isActive = true titleLabel.textAlignment = .center titleLabel.text = "Title Here" titleLabel.layer.borderColor = UIColor.green.cgColor titleLabel.layer.borderWidth = 1

There seems to be a regression in the behavior of UIScrollEdgeElementContainerInteraction on iOS 26.1 when it's over a WKWebView. If the web view's scroll view's topEdgeEffect.style is changed to .hard and then back to .soft, it will stop tracking the color of the content underneath it and use the wrong-mix in color in its blur. I've filed this as FB20655398. Here's some sample code to illustrate the issue. The test.html file being loaded is just a bunch of div elements with lorem ipsum. private var webView: WKWebView? = nil override func viewDidLoad() { super.viewDidLoad() let config = WKWebViewConfiguration() let webView = WKWebView(frame: .zero, configuration: config) webView.navigationDelegate = self self.view.addSubview(webView) webView.autoPinEdgesToSuperviewEdges() webView.isInspectable = true self.webView = webView let url = Bundle.main.url(forResource: "test", withExtension: "html")! webView.loadFileURL(url, allowingReadAccessTo: Bundle.main.bundleURL) let blurView = UIView() self.view.addSubview(blurView) blurView.autoPinEdgesToSuperviewEdges(with: .zero, excludingEdge: .bottom) let label = UILabel() label.text = "This is a title bar" blurView.addSubview(label) label.autoAlignAxis(toSuperviewAxis: .vertical) label.autoPinEdge(toSuperviewEdge: .bottom, withInset: 8) label.autoPinEdge(toSuperviewSafeArea: .top, withInset: 8) let interaction = UIScrollEdgeElementContainerInteraction() interaction.scrollView = webView.scrollView interaction.edge = .top blurView.addInteraction(interaction) self.webView?.scrollView.topEdgeEffect.style = .hard DispatchQueue.main.asyncAfterUnsafe(deadline: .now() + .seconds(2)) { self.webView?.scrollView.topEdgeEffect.style = .soft } registerForTraitChanges([UITraitUserInterfaceStyle.self]) { (self: Self, previousTraitCollection: UITraitCollection) in self._updateWebViewColors() } } private func _updateWebViewColors() { let dark = self.traitCollection.userInterfaceStyle == .dark let text = dark ? "#FFFFFF" : "#000000" let bg = dark ? "#000000" : "#FFFFFF" let js = "document.body.style.color = '\(text)';\ndocument.body.style.backgroundColor = '\(bg)';" self.webView?.evaluateJavaScript(js) { res, err in if let err { print("JS error: \(err)") } } } If you run that, then change the system them to dark mode, you get this. Has anyone else seen this before? Know how to work around it?

Since iPadOS 26.1 I notice a new annoying bug when changing the dark mode option of the system. The appearance of the UI changes, but no longer for view controllers which are presented as Popover. For these view controllers the method "traitCollectionDidChange()" is still called (though sometimes with a very large delay), but checking the traitCollection property of the view controller in there does no longer return the correct appearance (which is probably why the visual appearance of the popover doesn't change anymore). So if the dark mode was just switched on, traitCollectionDidChange() is called, but the "traitCollection.userInterfaceStyle" property still tells me that the system is in normal mode. More concrete, traitCollection.userInterfaceStyle seems to be set correctly only(!) when opening the popover, and while the popover is open, it is never updated anymore when the dark mode changes. This is also visible in the standard Apps of the iPad, like the Apple Maps App: just tap on the "map" icon at the top right to open the "Map mode" view. While the view is open, change the dark mode. All of the Maps App will change its appearance, with the exception of this "Map mode" view. Does anyone know an easy workaround? Or do I really need to manually change the colors for all popup view controllers whenever the dark mode changes? Using dynamic UIColors won't help, because these rely on the "userInterfaceStyle" property, and this is no longer correct. Bugreport: FB20928471