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.

Hey Team, System-provided quick actions in Finder sport a template image that adapts correctly to light and dark modes. However when I add a quick action extension in my app, the icon I refer to in the Info.plist renders in full color, even if it is defined in the asset catalog as a template image. This forces me to either use my app icon or a gray icon that will work in either appearance. How can I get the system-provided quick actions treatment? Thanks, Ari

For developing an iOS fully-featured code editor (i.e line numbers + color pass for syntax highlighting + collapsible sections + debug markers/highlights) what would be the best strategy for iOS 27? UITextView with new viewport control delegate Custom TextKit2 UIView Custom TextKit1 UIView (this was the recommendation I got as of WWDC25)

I have an app where CoreData is working great - but I want to add widgets. I'm following a tutorial where they create an AppGroup and in the migration they use appendingPathComponent(_:) which is deprecated (iOS 8.0–26.1) however the recommended replacement appending(path:directoryHint:) starts support at iOS 16. I'm hanging on to iOS 15 for some users who don't want to upgrade their phones - but is it time to give up on that for widgets running on released iOS 26 and beyond? I assume I'll need to use if #available(iOS 16.0, *) for the new code. How does this work for the CoreData migration for the older phones? So far this is just in TestFlight. Any recommendations?

Is it possible to remove the ugly sidebar and inspector chrome with AppKit? I don't care if it's a hack or a swizzle or something, but I need to get rid of this. I want to convert this: Into this (photoshopped): Thanks for your help!

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 past few years, there hasn't been much updates around Storyboards and yet it seems like Xcode supports them. Even before the first release of SwiftUI, many developers stopped using Storyboards for compelling reasons such as: They introduce two sources of truth for the UI It's not easy to read the content during code-review They can cause merge conflicts Often they fail to load, especially after a new major release of Xcode, without any error I was wondering whether there's a dedicated team working on Storyboards or if they're just abandoned. I understand this question may overlap with what the Xcode team does; so, let me rephrase it: in a large project, what are the pros and cons of using Storyboards when building views using UIKit? For instance, do they work well with things such as navigation by employing segues, the liquid glass or the new resizing feature? Finally, one of the benefits of using Storyboards is the fact that they visualize the UI, including the constraints. However, since now we can UIViewController in Preview, can we safely say that Previews can deliver the same thing?

In macOS 27, document-based applications appear to gain a new feature where, when Autosave in Place is enabled, draft document titles are automatically suggested based on the document’s content. I was surprised to see this, but I think it is a great feature. (Interestingly, I have received similar feature requests from users of my own application in the past, but I declined them because I felt they would add unnecessary complexity.) My question is mostly out of curiosity: how is this feature implemented? My assumption is that the system may be reusing the new Spotlight indexing infrastructure to extract document content, perhaps by combining the Data returned from NSDocument.data(ofType:) during autosave with the document’s fileType. Is that understanding correct, or is a different mechanism involved? Are there any articles, WWDC sessions, or other documentation that explain this new draft title suggestion feature? I have not been able to find any information about it. Also, is there currently any way to disable this behavior? I am not personally looking to turn it off, but I suspect some users of my application may eventually ask for that option.

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