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

I noticed that on iOS when I tap an already selected List row it calls the selection binding setter again. This is suprising to me because the selection value hasn't changed and results in duplicating unnecessary work to transform the data. Is this behaviour normal or should I report it as a bug? I noticed it when using custom Binding for the selection, i.e. where I implement the get and set closures myself. Thanks!

We have unit test targets that do not need a host app. However, when running snapshot tests (using frameworks such as swift-snapshot-testing), we'd like to read some properties on UIScreen.main. For instance, we'd like to assert that the scale of the simulator that's being used is matching our expectation. Without using a host app, there's no connected UIScene on UIWindow.shared.connectedScenes. Questions: Why UIScreen.main was deprecated? In our case, how can we get the scale property without attaching a host app to our test target? In other words, without using UIWindow.shared.connectedScenes.

I didn't hear any changes to testing in Swift Packages allowing UI tests. Maybe one day. In the meantime what is your recommendation? I see, and have so far chosen to, add an 'example' project inside the package. This is a full fledged app that integrates the package. My next issue is combining the xcresult file of the unit tests of the package, with the ui tests of the example app using the xcresulttool. I don't think it is meant to combine test results from different runs but I could be wrong. I got it working to combine results across different devices and languages of the same test plan but not different ones.

Hi AppKit team, I'm trying to use an NSTextField in an NSTableView where the visible text wraps up to 3 lines, truncates after that, and then shows the full text in an expansion tooltip on hover. The behavior I want is: visible cell: wrapped text, capped at 3 lines hover expansion tooltip: full wrapped text I can get expansion tooltips to appear for non-wrapping text, but I haven't been able to get them to work for wrapped text capped with maximumNumberOfLines. What is the recommended way to implement expansion tooltips for a wrapping, line-capped NSTextField? Here is a minimal repro: import AppKit final class ViewController: NSViewController, NSTableViewDataSource, NSTableViewDelegate { let tableView = NSTableView() let text = String(repeating: "Very long wrapped text ", count: 40) override func viewDidLoad() { view = tableView tableView.addTableColumn(NSTableColumn()) tableView.usesAutomaticRowHeights = true tableView.dataSource = self tableView.delegate = self } func numberOfRows(in tableView: NSTableView) -> Int { 1 } func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { let tf = NSTextField(wrappingLabelWithString: text) tf.maximumNumberOfLines = 3 tf.allowsExpansionToolTips = true tf.cell?.truncatesLastVisibleLine = true return tf } } Thank you.

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?

The primary column sidebar in iPadOS 26 has a 10pt padding (not sure if we can access this value programmatically) which we hard-coded for edge inset calculations of the secondary view. It appears this padding is still present with the new design. Can we derive this property reliably somehow?

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.

Hey Team, In the Finder, the segmented control in the toolbar where the user can choose to display the files as icons, list, columns, or gallery, indicates its selection using a gray background. Is that done via custom drawing or is it a semantic option in AppKit? When I adopt Liquid Glass in my app by removing UIDesignRequiresCompatibility, my segmented control indicates the selections with a strong accent color. This could be distracting to my users and I'd like to duplicate the Finder behavior. Thanks, Ari

Since updating to iPadOS 26.3 and Xcode 26.3, I’ve observed that my testplan suites, that formerly ran 30+ hours and ended with 100% test execution, terminate early at 12-15 hours with an error that suggests an OS-related anomaly is blocking continuation of the test suite. The error in the console is " Wait for accessibility to load" and then a "failure to load accessibility". My tests use the XCUItest framework and accessibility tags to interact with screen elements on the tethered ipad. This never happened on ipadOS 26.2 and earlier. I'm curious if others have seen this behavior and when Apple will get this fixed.

My iPhone App has requirement to be locked to portrait, except on certain screens like when showing a video player or other content. What is the best SwiftUI way to do this?

I added images to all NSMenuItems in my app on macOS 26. Now, with macOS 27 beta 1, most of them are no longer displayed, which seems to be the behavior of NSMenuItem.ImageVisibility.automatic. However, this only happens for images initialized with NSImage(systemSymbolName:accessibilityDescription:). Images initialized with NSImage(named:) are still shown, despite the visibility setting being .automatic. What would be an approach that is consistent for all app-contributed NSMenuItems while still respecting the system default? Even more, how would one set image visibility to also address possible future system settings that decide on menu-item image visibility? As a side note, the documentation for NSMenuItem.ImageVisibility has no description for .automatic, and the documentation for .hidden and .visible seems wrong or misleading (or I'm misunderstanding): .hidden: The item image should always be visible. Note that in some cases, AppKit may still hide the image, overriding this preference. .visible: AppKit should choose whether the item’s image is visible, considering the system configuration.

macOS Tahoe fails to close NSWindows after display sleep, causing window accumulation and performance degradation We have a feedback open for this problem on Tahoe (FB21391882) as well as a DTS track. Our QA team has verified that this is still occurring with the Golden Gate Beta 1. I am wondering if this is going to be prioritized as an issue in Golden Gate, or if this is not going to be looked into any further. Honestly I am not sure this is the forum for this, but I was not sure where else to ask at WWDC this year due to the lack of 1-1 appointments.

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

Hoping to get some clarification here around how the Liquid Glass opt-out via the UIDesignRequiresCompatibility Info.plist flag works with iOS 27. During the Platforms State of the Union at least year's WWDC, it was mentioned that this flag wouldn't be respected on iOS 27. Is this a case where it's not respected for any app that's downloaded from the App Store regardless of if they were compiled against the iOS 27 SDK, or does this only apply for apps compiled with the iOS 27 SDK (and thus any app compiled with an older SDK would still get the previous design styling)?

I am looking at displaying a database record. The layout is designed by the user but typically looks more like an index card than the row of a spreadsheet. There might be 20-30 fields in a record. Multiplying by the number of records that might be on the screen at a time, that could be a lot of fields. Most fields are text, so UITextView is a natural choice. But is UITextView too heavy or expensive to be used in so many copies? I seem to have 3 choices, in ascending order of apparent efficiency and also ascending order of difficulty of implementation: Have one UITextView per field. Have one UIView subclass per field, designed to look like a UITextView but be cheaper. When the user comes to edit, the current field (but no other) can be overlaid with a UITextView to enable editing. Have one UIViewSubclass for the entire record, designed to look like a collection of UITextViews but cheaper (one view per record instead of one view per field). When the user comes to edit, overlay the current field (but no other) with a UITextView to do the editing. I would welcome advice as to how expensive UITextView actually is. Is it in fact so cheap that there is no point in working hard to avoid having many UITextViews?

Hi! I’m struggling a bit with data flows in SwiftUI. Most SwiftUI sample apps I’ve seen use one large app model / store and inject that into the environment. That works for small samples, but I’m not sure how this should scale in a real app where the data is naturally split into multiple models/services. For example, I may have separate types for things like: @Observable final class AuthModel { ... } @Observable final class MediaSourcesModel { ... } @Observable final class UsersModel { ... } final class HTTPClient { ... } Some of these only make sense once the user is logged in. For example, media sources, user data, and the HTTP client may all depend on the current user/session/token. What I’m struggling with is where these objects should be owned and created in a SwiftUI app. I’m trying to avoid creating them directly inside a view body, because that can recreate them as the view updates. I’m also unsure whether putting this setup in custom view initializers is the right direction, since SwiftUI views are lightweight and can be reconstructed. What is the recommended ownership / data-flow pattern for this kind of setup? More specifically, how should a SwiftUI app usually handle several separate models that depend on login state, without turning everything into one large global model? Thank you!

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!

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

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.