We have a status item which works fine on macOS 26 and earlier, which has the following properties: Supports left-click to open main UI (a popover) Supports left-click (while open) to toggle (close) the main UI Supports right-click to show "app" menu (e.g. About, Quit) Supports a drop destination to accept files and folders, which then triggers the main UI for more interaction In macOS 27: left-click seems ok if we use expanded interface session, but otherwise broken left-click while open no longer toggles (event is missing?) right click is no longer operational, to the point that it seems the Menu Bar doesn't forward the event at all. Other (Apple-provided) items work fine, and expose new context menus Dragging now triggers Mission Control, which seems wrong given the destination was in the Menu Bar (FB23018381). Are these interactions now forbidden, and are there lists or documentation of the new rules? As an additional bug, it looks like popovers don't pick up appearance changes. The child scroll view claims to be in light appearance in the View Debugger, but is clearly showing the wrong background color, this is a new (as-yet unreported) issue. One last bug: expanded interface session seems to suppress the popover's animation when shown.

We are experience hundreds of long hitches when volumn is changed, it looks like app stuck on rendering. Is this resolved in iOS27? There is the callstack: Thread 0: 0 QuartzCore -[CALayer animationForKey:] + 172 1 QuartzCore -[CALayer animationForKey:] + 124 2 UIKitCore -[UIViewAnimationState _shouldAnimateAdditivelyForKey:onLayer:forView:] + 356 3 UIKitCore -[UIViewAnimationState actionForLayer:forKey:forView:] + 192 4 UIKitCore +[UIView(Animation) _defaultUIViewActionForLayer:forKey:] + 88 5 UIKitCore -[UIView(UIKitManual) actionForLayer:forKey:] + 328 6 QuartzCore -[CALayer actionForKey:] + 152 7 QuartzCore CA::Layer::begin_change(CA::Transaction*, unsigned int, objc_object*, objc_object*&) + 208 8 QuartzCore CA::Layer::set_bounds(CA::Rect const&, bool) + 348 9 QuartzCore -[CALayer setBounds:] + 132 10 QuartzCore -[CALayer setFrame:] + 408 11 UIKitCore -[UIView _backing_setFrame:] + 244 12 UIKitCore -[UIView(Geometry) setFrame:] + 348 13 UIKitCore -[_UISlideriOSVisualElement _layoutSubviewsForBoundsChange:] + 1144 14 UIKitCore -[_UISlideriOSVisualElement _setValue:andSendAction:] + 248 15 UIKitCore +[UIView(UIViewAnimationWithBlocks) _setupAnimationWithDuration:delay:view:options:factory:animations:start:animationStateGenerator:completion:] + 548 16 UIKitCore +[UIView(UIViewAnimationWithBlocks) animateWithDuration:delay:options:animations:completion:] + 48 17 UIKitCore -[_UISlideriOSVisualElement setValue:animated:] + 628 18 MediaPlayer -[MPVolumeSlider _updateVolumeAnimated:silenceVolumeHUD:] + 148 19 MediaPlayer -[MPVolumeController volumeControllerDataSource:didChangeVolume:silenceVolumeHUD:] + 104 20 MediaPlayer -[MPVolumeControllerSystemDataSource _notifyVolumeDidChage:silenceVolumeHUD:] + 84 21 MediaPlayer -[MPVolumeControllerSystemDataSource updateVolume:silenceVolumeHUD:] + 116 22 MediaPlayer __61-[MPVolumeControllerSystemDataSource _systemVolumeDidChange:]_block_invoke_2 + 260 23 libdispatch.dylib _dispatch_call_block_and_release + 32 24 libdispatch.dylib _dispatch_client_callout + 16 25 libdispatch.dylib _dispatch_main_queue_drain.cold.6 + 832 26 libdispatch.dylib _dispatch_main_queue_drain + 176 27 libdispatch.dylib _dispatch_main_queue_callback_4CF + 44 28 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 29 CoreFoundation __CFRunLoopRun + 1944 30 CoreFoundation _CFRunLoopRunSpecificWithOptions + 532 31 GraphicsServices GSEventRunModal + 120 32 UIKitCore -[UIApplication _run] + 796 33 UIKitCore UIApplicationMain + 332

Hey Team, In my app there are bordered toolbar buttons with a button type of toggle. Before Liquid Glass, such a button with an on state would paint its template image in accent color. After removing UIDesignRequiresCompatibility, these buttons no longer show their state. What is the best practice to migrate these buttons to Liquid Glass? Thank, Ari

Previously, the Mac version of my app was built with Mac Catalyst. However, because using the menu bar was inconvenient, I started migrating the Mac version to a native Mac build. Later, I found that starting around macOS 26.4.1, the menu bar that used to appear with my original SwiftUI implementation suddenly stopped showing. As a result, I had to switch back and use an AppKit bridge instead. In addition, I noticed that many visual elements look very strange when built with Mac Catalyst, so I have to adjust each page one by one. I would like to know whether there is a guide for migrating from Mac Catalyst to native Mac, especially regarding style adaptation, so that I can follow the guide and make the necessary changes systematically. Finally, since one of SwiftUI’s advantages is multi-platform deployment, why can’t these styling issues be adapted automatically?

Good morning! Our app uses a dark color scheme regardless of light/dark mode. One issue we’ve had with Liquid Glass has been that buttons in the nav bar do an animation when views are pushed or popped, and the Liquid Glass elements appear to flash during those animations. Are you aware of this behavior? Is there a solution? I suspect that the buttons are mixing in some white even though our background is near black.

I've gotten diagnostics from a couple of my users experiencing a rare issue. The logs in the diagnostics clearly show that the view controller where the issue occurs gets viewDidLoad called twice, and then does not get viewWillAppear or viewDidAppear. This triggers a bug for me because the view controller loads the data it's meant to display in viewWillAppear. I can work around this by changing my data loading logic, but I'd like to know what the underlying issue is. Can anyone point me to some possible ways I could be triggering this weird UIKit behavior?

Is it a bug that when I return toolbarSelectableItemIdentifiers in the NSToolbar delegate, the toolbar title no longer displays and the Liquid Glass effect also appears distorted? *This code worked fine up to macOS 26.

The inspector attached to the multi-column Split View, does not display its navigation elements on iOS 26. How to fix it?

Good morning! Not sure this is strictly a SwiftUI question but it is a UI question. The biggest problems we’ve had in adopting the updated UI in recent releases center around the tab bar. We’re an iOS/iPadOS app with a tabbed UI. Having the tab bar arbitrarily jump from the bottom of the screen to the top at a certain size makes laying out our UI very difficult. We’ve worked around this so far by using a custom bar, but that’s clunky and doesn’t work well with Liquid Glass. Are there any changes to this behavior in the 27 releases given the even greater emphasis on resizability?

Hi. macOS 26.5 introduced a bug involving menu item keyboard shortcuts without modifier keys. For example, it affects a menu item with the keyboard shortcut J, but not the keyboard shortcut ⌘J. This bug is also present in the first beta of macOS 27. When a menu item is invoked with a keyboard shortcut that has no modifiers and its validateMenuItem(_:) method returns false, the system beeps and refuses to perform the operation. This is expected. But then even after validateMenuItem(_:) is returning true again, the app will continue refusing to perform that keyboard shortcut until the app is quit and relaunched. It will also do the same with all other keyboard shortcuts that have no modifiers and are attached to menu items. I filed this with a sample project as FB22762541. I also wrote about it in more detail at: https://virtualsanity.com/202605/bug-involving-keyboard-shortcuts-for-menu-items-that-have-no-modifier-keys-on-macos-265/ I would love to see this issue addressed. Thank you for your work.

The docs for UIWritingToolsCoordinator's isWritingToolsAvailable have been updated in the 27 SDK. Previously, the docs stated: Writing Tools support might be unavailable because of device constraints or because the system isn’t ready to process Writing Tools requests. They now say: Writing Tools support might be unavailable because of device constraints. Is this a change in behaviour between SDK 26 and 27, or have the docs just been updated to more accurately describe the behaviour?

Is this the right way to pass data to a sheet for editing? struct Detail: View { ... // The single atomic source of truth for our sheet presentation @State var editorConfig: EditorConfig? // Completely encapsulated local configuration package struct EditorConfig: Identifiable { var id: PersistentIdentifier { item.persistentModelID } let context: ModelContext let item: Item } var body: some View { ... Button("Edit") { // 1. Spin up a separate scratchpad container layer let context = ModelContext(modelContext.container) context.autosaveEnabled = false // 2. Safely resolve our model inside the new isolated playground if let sandboxItem = context.model(for: item.persistentModelID) as? Item { // 3. Package it up to trigger the sheet presentation editorConfig = EditorConfig(context: context, item: sandboxItem) } } } } // 4. SwiftUI tracks value replacement accurately without ghost state bugs .sheet(item: $editorConfig) { config in // Inject the isolated context into the sheet's environment chain EditorView(item: config.item) .environment(\.modelContext, config.context) } } }

In the SwiftUI group lab, an engineer mentioned that there were new ways to customize SwiftUI screen transitions. They mentioned there is a crossfade, which I see in the docs, but they also mentioned other customizations. Did they misspeak, or are there custom screen transitions? I'd love a modern, SwiftUI replacement for custom presentation controllers from UIKit!

I'm wondering what the easiest way to reordering a view in a stack is whilst maintaining structural identity, so that it animates/transitions correctly + state is maintained. Ideally if in a LazyVStack it would maintain the laziness too. Think of a stack where if a normal ForEach was used the view may end up being a switch over up to 20 different types of views. I know custom Layouts can be used but they currently cannot be lazy and it seems like a fair bit of work for something that seems fairly simple. Can the below approach be optimised? import SwiftUI struct GroupDemoView: View { @State private var animatesChanges = false @State private var shouldReorder = false private let reorderAnimation = Animation.spring(duration: 3, bounce: 0.5) var body: some View { VStack(spacing: 28) { VStack(spacing: 12) { Toggle("Animate changes", isOn: $animatesChanges) Toggle("Reorder subviews", isOn: animatesChanges ? $shouldReorder.animation(reorderAnimation) : $shouldReorder) } .frame(maxWidth: 240) ScrollView { ReorderingVStack(shouldReorder: shouldReorder) { Text("A") SimpleCard(name: "Card B") Text("B") Text("C") Text("D") Text("E") Text("F") Text("G") Text("H") Text("I") Text("J") Text("K") } } .font(.title3.weight(.semibold)) } .padding() } } private struct ReorderingVStack<Content: View>: View { let shouldReorder: Bool let content: Content init( shouldReorder: Bool, @ViewBuilder content: () -> Content ) { self.shouldReorder = shouldReorder self.content = content() } var body: some View { Group(subviews: content) { subviews in VStack(spacing: 12) { ForEach(rearranged(subviews)) { subview in subview } } } } private func rearranged(_ subviews: SubviewsCollection) -> [Subview] { var subviews = Array(subviews) if shouldReorder { subviews.insert(subviews.remove(at: 1), at: 9) } return subviews } }

I have not yet completed the migration to scene delegate. If I still build with Xcode 26, will my app continue to launch on iOS 27 even if I release updates (still built with Xcode 26) after the iOS 27 release?

I’m developing a text editor. In the main pane of a window managed by NSSplitViewController, I place an NSTextView enclosed in an NSScrollView alongside a custom NSView subclass that displays line numbers. The issue is that the line number view sits outside the scroll view, so it does not participate in the visual effects applied by the title bar or by an NSSplitViewItemAccessoryViewController attached to the parent view controller. This problem has existed since around macOS 26, but it appears to be more noticeable in macOS 27 Beta 1. Due to various implementation requirements, my line number view cannot be implemented as a subclass of NSRulerView. In this situation, is there any supported way to ensure that accessory view and toolbar effects are also properly applied to views that are outside the scroll view? The attached screenshot demonstrates a case where the edge effect is not applied correctly. The line number view on the left side does not participate in the effect and instead appears to visually break through it.

With iOS 27's automatic resizability for iPhone apps on iPad and in iPhone Mirroring, what's the recommended pattern for views that need genuinely different layouts at different size classes — is ViewThatFits the intended tool, or should we still branch on size class for larger structural changes? — Divya Ravi, Senior iOS Engineer

For apps still using UIKit view controllers presented over a SwiftUI hierarchy (or vice versa), what's the recommended approach in iOS 27 for finding the correct presenting context across the new window scene configurations, especially with resizable windows? — Divya Ravi, Senior iOS Engineer

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

I've been adopting SwiftUI into a legacy UIKit app. Individual views work great, but when I try to intermix SwiftUI and UIKit navigation things go bad fast. What is the best practice here?