I am giving the user a view onto a selection of database records. There could be a handful of these, there could be 10,000 of them. At present I use a UITableView. Cells are therefore created or recycled on demand. When a cell is created, it is displayed with default "empty" contents and it sends a message to the server to request a record. When the record arrives, the cell is then able to change its own contents so that the record appears on the screen. There are of course various optimisations, such as cancelling a request if the cell goes offscreen before a reply is received; or delaying a request if it looks as if the cell will end up being off the screen once scrolling has stopped. All this happens with fixed-height cells. Accordingly the UITableView has all the data it needs to work out where every one of the 10,000 cells is. I now want to extend this to variable-height cells. That is: cells whose height depends on the content received from the database. Accordingly, when a cell receives its data it may find itself having to change its own size. Is this structure practicable with UITableView?

Hi in the CometCal sample they have this: @main struct CometCalApp: App { init() { let dependency = CalendarManager.shared AppDependencyManager.shared.add(dependency: dependency) } var body: some Scene { WindowGroup { CalendarListView() } .modelContainer(CalendarManager.shared.modelContainer) } } However I do not want my manager to init when I am using SwiftUI previews. FYI in SwiftUI previews the App is init but body isn't called. So I require the CalendarManager to be init lazily. Is this a valid way to achieve that: init() { let dependency: @Sendable () async -> (CalendarManager) = { @MainActor in return CalendarManager.shared } AppDependencyManager.shared.add(dependency: dependency) } If so it would be great if the API could be improved to let me just do this: AppDependencyManager.shared.add(dependency: CalendarManager.shared) Which currently fails with Main actor-isolated static property 'shared' can not be referenced from a Sendable closure Thanks!

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!

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?

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.

What is the expected behaviour of UISlider.TrackConfiguration.Tick's title and image properties? On iOS, these seem to be no-ops. The docs also don't indicate what these properties do. let ticks = [ UISlider.TrackConfiguration.Tick(position: 0, title: "Slow", image: UIImage(systemName: "tortoise.fill")), UISlider.TrackConfiguration.Tick(position: 1, title: "Fast", image: UIImage(systemName: "hare.fill")) ] let configuration = UISlider.TrackConfiguration(ticks: ticks) let slider = UISlider() slider.trackConfiguration = configuration

UITabBarController's new prominentTabIdentifier property is a really nice addition! Thank you! Will there be official support via the UITab API for using the underlying _UITabBarAuxiliaryView as a primary action as many apps, such as the Apple Design Award Finalist, Structured, does for presenting a sheet, for example?

What improvements have been made in iOS27, and what can we expect to see in terms of performance enhancements in UIKit this year? How would these changes help enhance our app’s user experience?

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.

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

Is there any documentation on the NSText* features supported by the various document types NSAttributedString can encode in AppKit? For example if I create an NSTextTable (which works fine in RTF), how can I can know if it's supported in the following types: DocFormat WordML OfficeOpenXML OpenDocument They mostly are not, and if I use merged cells (row/col spans) the support is even lower. Similarly, if I wanted to use Markdown decoding support to encode to the HTML type, does AppKit provide translation from PresentationIntent to the NSText* implementations?

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