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?

I have a Catalyst app that uses popovers frequently, and I'd love to have them stay active when the app loses focus. It appears this is controlled in a native AppKit app via NSPopover.Behavior. Is this functionality exposed somewhere in Catalyst?

I've got a Catalyst app that exposes some custom context menu items via the buildMenu API. When it runs on Tahoe, there's some weirdness with how the images in the menu items are sized. See attached screenshot below. The three items on the bottom are using SF Symbols for their images, and the rest are using custom images from an asset catalog. Is this a bug in Tahoe 26.0? Or should I be resizing my images before giving them to UIAction? If the latter, what should the size be, and is this documented somewhere or available from an API?

In the WWDC 2025 session "Build a UIKit app with the with the new design", at the 23:22 mark, the presenter says: And finally, when you no longer need the glass on screen animate it out by setting the effect to nil. The video shows a UIVisualEffectView whose effect is set to a UIGlassEffect animating away as its effect is set to nil. But when I do this in my app (or a sample app), setting effect to nil does not remove the glass appearance. Is this expected? Is the video out of date? Or is this a bug?

In iOS 26 beta 3, it was possible to have a UIScrollEdgeElementContainerInteraction work with a WKWebView's scroll view. But it stopped working in beta 4, and is still broken in beta 5 today. Is this expected? Or is this a bug that will be fixed before public release? Filed as FB19386650 with a trivial sample app.

I'm experimenting with downloading an audio file of spoken content, using the Speech framework to transcribe it, then using FoundationModels to clean up the formatting to add paragraph breaks and such. I have this code to do that cleanup: private func cleanupText(_ text: String) async throws -> String? { print("Cleaning up text of length \(text.count)...") let session = LanguageModelSession(instructions: "The content you read is a transcription of a speech. Separate it into paragraphs by adding newlines. Do not modify the content - only add newlines.") let response = try await session.respond(to: .init(text), generating: String.self) return response.content } The content length is about 29,000 characters. And I get this error: InferenceError::inferenceFailed::Failed to run inference: Context length of 4096 was exceeded during singleExtend.. Is 4096 a reference to a max input length? Or is this a bug? This is running on an M1 iPad Air, with iPadOS 26 Seed 1.

I've got a UIKit app that displays a lot of text, and we've completely turned off the system text selection menu and we show our own custom thing instead, to increase discoverability of our text selection actions. But now that iOS 26 can show the full menu even on iPhone, we're looking at switching back to the system menu. It still shows a smaller horizontal-layout menu at first, and then you tap the > symbol to expand to the full menu. Is it possible to jump straight to the full menu, and skip the smaller horizontal one entirely?

In the header for UIViewController, the method dismissViewControllerAnimated is declared like this: - (void)dismissViewControllerAnimated: (BOOL)flag completion: (void (^ __nullable)(void))completion NS_SWIFT_DISABLE_ASYNC API_AVAILABLE(ios(5.0)); NS_SWIFT_DISABLE_ASYNC means that there's no async version exposed like there would normally be of a method that exposes a completion handler. Why is this? And is it unwise / unsafe for me to make my own async version of it using a continuation? My use case is that I want a method that will sequentially dismiss all view controllers presented by a root view controller. So I could have this extension on UIViewController: extension UIViewController { func dismissAsync(animated: Bool) async { await withCheckedContinuation { continuation in self.dismiss(animated: animated) { continuation.resume() } } } func dismissPresentedViewControllers() async { while self.topPresentedViewController != self { await self.topPresentedViewController.dismissAsync(animated: true) } } var topPresentedViewController: UIViewController { var result = self while result.presentedViewController != nil { result = result.presentedViewController! } return result }

I have an app that uses UITextView for some text editing. I have some custom operations I can do on the text that I want to be able to undo, and I'm representing those operations in a way that plugs into NSUndoManager nicely. For example, if I have a button that appends an emoji to the text, it looks something like this: func addEmoji() { let inserting = NSAttributedString(string: "😀") self.textStorage.append(inserting) let len = inserting.length let range = NSRange(location: self.textStorage.length - len, length: len) self.undoManager?.registerUndo(withTarget: self, handler: { view in view.textStorage.deleteCharacters(in: range) } } My goal is something like this: Type some text Press the emoji button to add the emoji Trigger undo (via gesture or keyboard shortcut) and the emoji is removed Trigger undo again and the typing from step 1 is reversed If I just type and then trigger undo, the typing is reversed as you'd expect. And if I just add the emoji and trigger undo, the emoji is removed. But if I do the sequence above, step 3 works but step 4 doesn't. The emoji is removed but the typing isn't reversed. Notably, if step 3 only changes attributes of the text, like applying a strikethrough to a selection, then the full undo chain works. I can type, apply strikethrough, undo strikethrough, and undo typing. It's almost as if changing the text invalidates the undo manager's previous operations? How do I insert my own changes into UITextView's NSUndoManager without invalidating its chain of other operations?

If I have a Catalyst app with a WKWebView and I select text, I can drag forward to extend the selection, but I can't reduce the length of the selected range by dragging backwards. I've reproduced this in a trivial sample app. Is there some property I need to set somewhere? I've filed this as FB15645411.

As of macOS Sequoia 15.1 (and probably earlier), in System Settings under Accessibility -> Display, there's a Text Size option that looks an awful lot like Dynamic Type on iOS: I have an iOS app with robust support for Dynamic Type that I've brought to the Mac via Catalyst. Is there any way for me to opt this app into supporting this setting, maybe with some Info.plist key? Calendar's Info.plist has a CTIgnoreUserFonts value set to true, but the Info.plist for Notes has no such value.

I have a Catalyst app that supports multiple scenes / windows. It has one "main" window type and lots of other secondary windows that can be opened. I'm using the system window restoration functionality via NSQuitAlwaysKeepsWindows to restore windows with their user activity data after the app is quit and restarted. Normally, this works great. If I open my app, change the size and position of my window, quit, and reopen it, the window size and position comes back as expected. But if I close the window using the red stoplight button and then click the app icon to bring it back, it comes back at the default position and size. This isn't how other system apps work - if I close the system Calendar app with the stoplight button, it comes back at the same size and position. How do I get this behavior with my Catalyst app? Is there some identifier property I need to set somewhere? I don't see such a property on UISceneConfiguration. If it matters, I'm using the configurationForConnectingSceneSession method to configure my windows when they open, instead of setting it up in the Info.plist.

I've got a UIKit app with a collapsible trailing-edge child view controller, implemented sort of like UISplitViewController but it's got a bunch of custom behavior - moving to the bottom edge in portrait orientation, etc. It exposes a couple of different app functions via a UITabBar on the bottom edge on iOS. When I run the app on visionOS, that tab bar transforms to a leading-edge ornament. This would be great, but that means it tries to overlap the trailing-edge content of its parent view controller, which isn't ideal. Is there a way to get the tab bar to lay out on the trailling edge of the child view controller? Or can I create a custom ornament that has the same auto-expand behavior as the tab bar, where it shows a vertical column of icons that expands to show titles when you're gazing at it?

I've got a UIKit app and I want to add some buttons in a top-edge window ornament. I'm looking at the WWDC23 talk Meet UIKit for Spatial Computing, and it does exactly what I think I want to do: extension EditorViewController { func showEditingControlsOrnament() { let ornament = UIHostingOrnament(sceneAlignment: .bottom, contentAlignment: .center) { EditingControlsView(model: controlsViewModel) .glassBackgroundEffect() } self.ornaments = [ornament] editorView.style = .edgeToEdge } } But the thing I really want to know is what is in EditingControlsView. Is it a toolbar? How do you make a toolbar in SwiftUI without something to attach the .toolbar modifier to?