I have been pleased to see SwiftUI’s List performance improve over the years. However, when using a List that contains DisclosureGroup views, expanding and collapsing items becomes significantly slower as the amount of data grows. In my case, I need to control the initial expanded/collapsed state of each disclosure item, so I cannot use the recursive List(_:children:) API. Is there a recommended way to improve the performance of a List containing DisclosureGroup views, or is falling back to AppKit’s NSOutlineView currently the only practical solution? (Yes, for context, my app is for macOS.) The following code shows the relevant portion of my implementation: List(self.summary.files, selection: $selection) { file in DisclosureGroup(isExpanded: $expandedFileURLs.contains(file.id)) { ForEach(file.matches) { match in FolderFindMatchView(match: match) .tag(FolderFind.ResultID.match(fileID: file.id, matchID: match.id)) } } label: { FolderFindFileResultView(file: file) .draggable(item: FolderFindDraggedFile(id: .file(file.id), fileURL: file.fileURL)) } .listRowSeparator(.hidden) .tag(FolderFind.ResultID.file(file.id)) }

Good morning! Our app is currently a mix of UIKit and SwiftUI. All new code is SwiftUI and we’re gradually replacing old code but for now we have SwiftUI views in UIHostingControllers where needed. Our app is a dark color scheme regardless of the device light/dark setting. One issue we’ve have is that some view in the hierarchy of the UIHostingController seems to have a white background. This is not normally visible, but when sliding views on and off in navigation, there’s a hint of white showing at the edge of the view as it moves. It’s subtle but users have noticed. I thought I filed this bug some time ago but I can’t find it. Just wondering if you’re aware and if there’s any update.

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?

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?

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 } }

In my app I have a sheet that has relatively small content inside. I’d like to fit the height of the sheet to the content of it. As I of course also want to support large type and don’t know how text will break to new lines, I can’t simply set a fixed pixel height. Currently I’m using this trick I saw in some blog post to get it to work. This is the view I’m presenting inside my .sheet: struct SheetContentView: View { @State private var contentHeight: CGFloat = .zero var body: some View { VStack { Text("Foo") Text("Bar") // … } .background( // Required for proper calculation of content height GeometryReader { geo in Color.clear .onChange(of: geo.size.height, initial: true) { _, newValue in contentHeight = newValue } } ) .presentationDetents([.height(contentHeight)]) } } Is this a valid way to do it? What are the best practices to handle this properly or is there even a native way to do this?

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?

How does using the new +[UILookToScrollInteraction exclusionRegionInteraction]differ from setting a UIScrollView's lookToScrollAxes to an empty option set? Is UILookToScrollInteraction designed to be applied to scroll edge element containers?

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.