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!

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

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.

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

If I want to implement the "view style" pattern that various SwiftUI components have (like ButtonStyle for Button and PickerStyle for Picker, to name a few) for my own custom components, is there any guidance on how to do that? Specifically, is there a way to do that without having to resort to using AnyView? My attempts to implement this have been fine with retaining type information using some View and generics, up until the point I need to create an interface for specifying a view style to use and propagating that down to the component that I'm styling. Using the SwiftUI environment seems like the natural way to do this propagation, but I seem to run afoul of the type system when trying to use it. If we take ButtonStyle from SwiftUI as an example of the general structure of this pattern, we're talking about having a protocol with an associated Body type, and a corresponding makeBody function that does the actual styling of the component and returns a Body instance. Because of the associated types in this protocol, I'm unsure how to put an instance of something that conforms to the protocol into the environment for propagation. I end up having to create a "sibling" type of sorts that more or less does the same thing as my protocol, but works with AnyView so I can have concrete types to use with the environment and pass around to my view. This doesn't seem ideal because of the use of AnyView and some of the downsides that come with that. I've included a simplified version of this at the end of this post to showcase roughly what I'm doing now that is working, but it feels like there should be some better way to achieve this without needing to reach for AnyView. Is there something that I'm not aware of with Swift or SwiftUI that would let me ditch it, or is this the best way to achieve this right now without improvements to SwiftUI to better support this? protocol MyViewStyle { associatedtype Body: View func makeBody(text: String) -> Body } struct TextMyViewStyle: MyViewStyle { func makeBody(text: String) -> some View { return Text(text) } } struct AnyMyViewStyle { let _makeBody: (String) -> AnyView init<Style: MyViewStyle>(_ style: Style) { self._makeBody = { text in AnyView(style.makeBody(text: text)) } } func makeBody(text: String) -> AnyView { _makeBody(text) } } extension EnvironmentValues { @Entry var myViewStyle: AnyMyViewStyle = AnyMyViewStyle(TextMyViewStyle()) } struct MyView: View { @Environment(\.myViewStyle) private var style let text: String var body: some View { style.makeBody(text: text) } }

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.

Since iOS26 the UISplitViewController is displayed in a way where the primary column (red) overlaps the secondary column (blue) instead of displaying them next to each other like before. Several Apple apps still display the columns next to each other, like Notes, Mail and Photos. What is the correct way to display the columns next to each other again using UIKit and if possible Storyboards.

When I last tried configuring NavigationSplitView about a year ago, it was hard or impossible to configure background. Setting a custom or clear background was not supported, and NavigationSplitViewStyle seemingly did not support custom implementations. Has this been improved?

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.

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

ViewThatFits is a great way to handle large type and resizability. I wonder what are the performance considerations here? What are common pitfalls using it? I appreciate any tip or thing to keep in mind. ✌️

Hey Team, I'm developing an app that normally resides in the menu bar and has no Dock icon (activation policy set to accessory. When the user clicks the status icon, and selects 'Settings' in the menu, I change the activation policy to regular, show the window, and activate the app. Since cooperative activation was introduced, the option to ignore all apps when activating was deprecated, so I activate the app without the option. The result is that in 20% of the times, the window doesn't come to the front, or the app is not activated. The user obviously wants this behavior, so what is the proper way to achieve it? Thanks, Ari

I'm heavily involved in making reusable components for specific features, as well as generic ones as part of a design system / component library. Does Apple have any guidance doing this? There is a lot to be learned from the decisions around the 'style' APIs, as well as the overloaded constrained initializers of views like Label. The design system should be opinionated, but allow a degree of flexibility. I liked Sarah's talk about incorporating brand which is certainly important when building components for 10+ apps, internal and external. The focus on purposeful design, but there isn't much at a technical level for designing (coding) reusable components and embracing strategies using the Environment, making custom EnvironmentValues, leveraging built-in system constructs, etc. Any resources and guidance here would be welcomed!

I am encountering a systemic issue on macOS where NSViewRepresentable (and some native container views like Table) completely discard explicit SwiftUI animations when the state change is handled via an .onChange modifier. While the exact same reactive architecture produces fluid animations on iOS, the AppKit bridge on macOS snaps the frame updates instantly. I have filed a formal bug report for this behavior, but I want to open this up to the community to see if anyone has found a cleaner architectural workaround. The Problem When observing a state change (e.g., via @AppStorage, @SceneStorage, or local state) using .onChange, applying a withAnimation block fails to animate the underlying layer changes in an AppKit representable view. // The Reactive Pattern that breaks on macOS .onChange(of: toggle) { newValue in withAnimation(.easeInOut(duration: 0.5)) { self.targetColor = newValue ? .systemBlue : .systemRed } } The Diagnostic Anomaly If you inspect context.transaction inside the updateNSView(_:context:) method during this lifecycle pass, SwiftUI reports that the transaction is animated: func updateNSView(_ nsView: NSView, context: Context) { // Prints 'true', indicating SwiftUI thinks it's animating print("Is Animated: \(context.transaction.animation != nil)") // Result: Snaps instantly. No animation occurs. nsView.layer?.backgroundColor = targetColor.cgColor } Why It Happens (The Double-Commit) It appears that on macOS, .onChange flushes a static layout transaction to the window layer immediately upon the state mutating. By the time the withAnimation block evaluates inside the closure, the AppKit backing layer has already processed a implicit setDisableActions(true) directive. The GPU pipeline for that transaction frame is effectively closed, despite what the context.transaction metadata claims. The Low-Level Workaround To force the AppKit bridge to respect the animation intent, I have to manually drop into Core Animation inside updateNSView and explicitly veto SwiftUI's action-disabling behavior: func updateNSView(_ nsView: NSView, context: Context) { CATransaction.begin() if context.transaction.animation != nil { // Explicitly override SwiftUI's implicit frame lock CATransaction.setDisableActions(false) CATransaction.setAnimationDuration(0.5) // Hardcoded fallback match } else { CATransaction.setDisableActions(true) } nsView.layer?.backgroundColor = targetColor.cgColor CATransaction.commit() } My Questions: Is this intentional behavior due to how AppKit's layer-backed architectures handle frame integrity vs. iOS's fluid layout engine? Has anyone found a way to bridge SwiftUI's Animation type curves (like .spring()) cleanly down into the CATransaction or NSAnimationContext layer without hardcoding durations inside updateNSView? Is there a purely "Reactive" paradigm that avoids mutating state at the primary action source (e.g., forcing a Button to own the animation logic) while maintaining fluid transitions on macOS?

Received a response from Quinn @ DTS on FB23017010 regarding the com.apple.spaces plist restructure in Golden Gate. He confirmed no public Spaces API exists and suggested the plist change may be treated as a compatibility bug. He recommended filing an Enhancement Request for a proper API. Two follow-up questions for AppKit engineers: (1) Which Feedback component gets an ER for a public Spaces management API in front of the right team — AppKit, CoreOS, or Mission Control? (2) Is there any timeline visibility on the compatibility bug determination for the Monitors key removal?"

We've been getting stack overflows in code we don't control, in the background AsyncRenderer thread in a chain of calls to updateInheritedViewAsync. But the stack is less than 200 calls deep, presumably because it's a background thread with a smaller stack limit. Is it possible to adjust AsyncRenderer's stack limit? Or otherwise, what limits should we be aware of to prevent running into this issue? com.apple.SwiftUI.AsyncRenderer: EXC_BAD_ACCESS (code=2, address=0x16f5ebe30) #0 0x000000019c6b4460 in function signature specialization <Arg[3] = Dead> of static SwiftUI.DisplayList.ViewUpdater.Model.merge(item: inout SwiftUI.DisplayList.Item, index: SwiftUI.DisplayList.Index, into: inout SwiftUI.DisplayList.ViewUpdater.Model.State) -> SwiftUI.DisplayList.ViewUpdater.Model.MergedViewRequirements () #1 0x000000019c7c2850 in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #2 0x000000019c7c3ef0 in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #3 0x000000019c7c3ef0 in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #4 0x000000019c7c3ef0 in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () ... #147 0x000000019c7c364c in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newItem: SwiftUI.DisplayList.Item, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #148 0x000000019c7c2074 in SwiftUI.DisplayList.ViewUpdater.updateAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldList: SwiftUI.DisplayList, oldParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>, newList: SwiftUI.DisplayList, newParentState: Swift.UnsafePointer<SwiftUI.DisplayList.ViewUpdater.Model.State>) -> Swift.Optional<SwiftUI.Time> () #149 0x000000019c7c1a78 in renderAsync () #150 0x000000019c60fc68 in renderDisplayList () #151 0x000000019c612094 in protocol witness for SwiftUI.ViewGraphRenderHost.renderDisplayList(_: SwiftUI.DisplayList, asynchronously: Swift.Bool, time: SwiftUI.Time, nextTime: SwiftUI.Time, targetTimestamp: Swift.Optional<SwiftUI.Time>, version: SwiftUI.DisplayList.Version, maxVersion: SwiftUI.DisplayList.Version) -> SwiftUI.Time in conformance SwiftUI.ViewGraph : SwiftUI.ViewGraphRenderHost in SwiftUI () #152 0x000000019c7c0dd0 in renderAsync () #153 0x000000019c7be6c8 in SwiftUI.ViewGraphHost.displayLinkTimer(timestamp: SwiftUI.Time, targetTimestamp: SwiftUI.Time, isAsyncThread: Swift.Bool) -> () () #154 0x000000019c7beab8 in SwiftUI.ViewGraphDisplayLink.displayLinkTimer(__C.CADisplayLink) -> () () #155 0x000000019c7be5a8 in @objc SwiftUI.ViewGraphDisplayLink.displayLinkTimer(__C.CADisplayLink) -> () () #156 0x0000000192fdbb24 in CA::Display::DisplayLinkItem::dispatch_ () #157 0x0000000192fb9164 in CA::Display::DisplayLink::dispatch_items () #158 0x0000000192f91870 in display_timer_callback () #159 0x000000019256d4cc in __CFMachPortPerform () #160 0x000000019259d0b0 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ () #161 0x000000019259cfd8 in __CFRunLoopDoSource1 () #162 0x0000000192574c1c in __CFRunLoopRun () #163 0x0000000192573a6c in _CFRunLoopRunSpecificWithOptions () #164 0x0000000190533f54 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] () #165 0x000000018fb9a51c in -[NSRunLoop(NSRunLoop) run] () #166 0x000000019c7cd5b0 in function signature specialization <Arg[1] = Dead> of static SwiftUI.ViewGraphDisplayLink.asyncThread(arg: Swift.Optional<Any>) -> () () #167 0x000000019c7cd288 in @objc static SwiftUI.ViewGraphDisplayLink.asyncThread(arg: Swift.Optional<Any>) -> () () #168 0x000000018fbf321c in __NSThread__start__ () #169 0x00000001ef0d044c in _pthread_start ()

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?

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!

First of all, thank you for updating the sidebar visuals in macOS 27! However, in macOS 27, an NSSearchField subclass placed in a sidebar or inspector appears with the same Liquid Glass button-like styling as toolbar items and other buttons. This behavior seems specific to NSSearchField; for example, a plain NSTextField does not exhibit the same appearance. While this styling may be appropriate in a toolbar, it feels out of place for a search field embedded in a sidebar or inspector. This appearance makes the search field visually indistinguishable from adjacent buttons and reduces its affordance as a text input control. Is there a supported way to control or override the appearance of an NSSearchField placed in a sidebar or inspector in macOS 27, so that it uses a more traditional search field style instead of the Liquid Glass button-like appearance? As a point of reference, Xcode 27 Beta 1 on macOS 27 Beta 1 does not appear to apply the Liquid Glass–style appearance to search fields in its sidebar. This may be because those fields are not implemented as direct subclasses of NSSearchField; however, I believe it also suggests that the Liquid Glass style is not well suited to search fields in this context.