When creating a default macOS document-based Xcode project and using the code below (and wiring the File menu's Print item to printDocument: instead of the default print:, which does nothing), opening the print panel causes PrintView.knowsPageRange(_:) to be called twice. Is this a bug? My app populates PrintView dynamically, and for large documents it can be quite inefficient to populate it once, only for the contents to be immediately discarded and populated again. A workaround that came to my mind would be to check if the print options have changed, though I'm not sure if it's a reliable indicator that the print preview is effectively the same. I created FB17018494. class Document: NSDocument { override func makeWindowControllers() { addWindowController(NSStoryboard(name: NSStoryboard.Name("Main"), bundle: nil).instantiateController(withIdentifier: NSStoryboard.SceneIdentifier("Document Window Controller")) as! NSWindowController) } override func printOperation(withSettings printSettings: [NSPrintInfo.AttributeKey : Any]) throws -> NSPrintOperation { return NSPrintOperation(view: PrintView(frame: CGRect(x: 0, y: 0, width: 100, height: 100)), printInfo: NSPrintInfo(dictionary: printSettings)) } } class PrintView: NSView { override func knowsPageRange(_ range: NSRangePointer) -> Bool { print("knowsPageRange") range.pointee = NSRange(location: 1, length: 1) return true } }

Xcode has been downloading many similar crash reports for my app for some time now, related to an index out of range runtime exception when accessing a Swift array. The crashes always happen in methods triggered by user input or during menu item validation when I try to access the data source array by using the following code to determine the indexes of the relevant table rows: let indexes = clickedRow == -1 || selectedRowIndexes.contains(clickedRow) ? selectedRowIndexes : IndexSet(integer: clickedRow) I was never able to reproduce the crash until today. When the app crashed in the Xcode debugger, I examined the variables clickedRow and selectedRowIndexes.first, which were 1 and 0 respectively. What's interesting: the table view only contained one row, so clickedRow was effectively invalid. I tried to reproduce the issue several times afterwards, but it never happened again. What could cause this issue? What are the circumstances where it is invalid? Do I always have to explicitly check if clickedRow is within the data source range?

For many years I've had the following code to access the active objects of a table view in my App Store app: class MyViewController: NSViewController: NSMenuItemValidation { private var tableView: NSTableView! private var objects = [MyObject]() func numberOfRows(in tableView: NSTableView) -> Int { return objects.count } func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { // make view for row } private var activeObjects: [MyObject] { return tableView?.activeRowIndexes.map({ objects[$0] }) ?? [] } func validateMenuItem(_ menuItem: NSMenuItem) -> Bool { let activeObjects = self.activeObjects ... } } extension NSTableView { var activeRowIndexes: IndexSet { return clickedRow == -1 || selectedRowIndexes.contains(clickedRow) ? selectedRowIndexes : IndexSet(integer: clickedRow) } } In one of the recent updates, I wanted to add some kind of header to the table view, so I decided to add a row at the beginning and offset the indexes by 1. func numberOfRows(in tableView: NSTableView) -> Int { return objects.count + 1 } func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { if row == 0 { // make header view } else { // make view for row - 1 } } private var activeObjects: [MyObject] { return tableView?.activeRowIndexes.subtracting(IndexSet(integer: 0)).map({ objects[$0 - 1] }) ?? [] } But since I added this change, Xcode regularly downloads crash reports from clients crashing during menu item validation in IndexSet.map with reason Code 5 Trace/BPT trap: 5. I assumed that I was accessing an invalid array index, so I added some debug code: the crash report would then show the invalid index beside the crashed thread's name. private var activeObjects: [MyObject] { return tableView?.activeRowIndexes.subtracting(IndexSet(integer: 0)).map({ i in if !objects.indices.contains(i - 1) { Thread.current.name = (Thread.current.name ?? "") + ". Invalid index \(i - 1) for count \(objects.count)" preconditionFailure() } return objects[i - 1] }) ?? [] } But the crash reports for this new app version look just like the old ones and the thread name is not changed. Indeed, when recreating an invalid index access on my Mac, the crash report mentions Array._checkSubscript(_:wasNativeTypeChecked:), which does not appear in the crash reports downloaded by Xcode. Manually symbolicating the crash report also doesn't give any more information: all lines referring to my app code are resolved to either /<compiler-generated>:0 or MyViewController.swift:0. Apparently the problem is not an invalid array index, but something else. Does anybody have a clue what the problem could be? (Note: the crash report mentions Sequence.compactMap because now I'm effectively calling tableView?.activeRowIndexes.compactMap, but the same crash happened before when calling IndexSet.map, which would appear in the crash report as Collection.map.) crash2.crash

In 2020 I created FB7719215, which I updated several times (including just now) and in 2021 I created FB9204092, but the issue is still there: when I keep Xcode open (currently version 16.3), my battery drains much quicker, even when it's apparently idle. For instance, today I barely did anything in Xcode, but still it has been at a constant 90% CPU for the last hours, and I keep checking the battery percentage to check how much time I have left. Does anyone at Apple has an explanation, workaround and/or fix?

I successfully installed macOS Tahoe 26 in June on a separate external partition. Now I want to update to beta 5, but when the Mac restarts to install the update, it shows the progress indicator for a minute or two, then boots again into the main partition which has macOS 15.6. Am I required to install it from scratch?

I have a table view where each row has two labels, one left-aligned and one right-aligned. I would like to reload a single row, but doing so causes the right-aligned label to hug the left-aligned label. Before the reload: After the reload: Reloading the whole table view instead, or disabling automatic row height, solves the issue. Can a single row be reloaded without resorting to these two workarounds? I created FB13534100 1.5 years ago but got no response. class ViewController: NSViewController, NSTableViewDataSource, NSTableViewDelegate { override func loadView() { let tableView = NSTableView() tableView.translatesAutoresizingMaskIntoConstraints = false tableView.dataSource = self tableView.delegate = self tableView.usesAutomaticRowHeights = true let column = NSTableColumn() column.width = 400 tableView.addTableColumn(column) let scrollView = NSScrollView(frame: CGRect(x: 0, y: 0, width: 500, height: 500)) scrollView.translatesAutoresizingMaskIntoConstraints = false scrollView.documentView = tableView view = scrollView Timer.scheduledTimer(withTimeInterval: 2, repeats: false) { _ in print("reload") tableView.reloadData(forRowIndexes: IndexSet(integer: 2), columnIndexes: IndexSet(integer: 0)) // tableView.reloadData() } } func numberOfRows(in tableView: NSTableView) -> Int { return 5 } func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { let cell = NSTableCellView() let textField1 = NSTextField(labelWithString: "hello") textField1.translatesAutoresizingMaskIntoConstraints = false let textField2 = NSTextField(wrappingLabelWithString: "world") textField2.translatesAutoresizingMaskIntoConstraints = false textField2.alignment = .right let stack = NSStackView(views: [ textField1, textField2 ]) stack.translatesAutoresizingMaskIntoConstraints = false stack.distribution = .fill cell.addSubview(stack) NSLayoutConstraint.activate([stack.topAnchor.constraint(equalTo: cell.topAnchor, constant: 0), stack.leadingAnchor.constraint(equalTo: cell.leadingAnchor, constant: 0), stack.bottomAnchor.constraint(equalTo: cell.bottomAnchor, constant: 0), stack.trailingAnchor.constraint(equalTo: cell.trailingAnchor, constant: 0)]) return cell } }

While preparing automated screenshots with Xcode UI tests for the iOS 26 release, I noticed that this simple line of code app.buttons["myTabItem"].tap() doesn't always work, both on iPhone and iPad Simulator. In fact, it rarely works. Even when repeating the same test, mostly it fails on that line, but a few times it works and I can see the tab item change in the simulator. My main view looks like this: TabView { MyTab1() .tag(tag1) .tabItem { Label("label1", systemImage: "image1") } MyTab2() .tag(tag2) .tabItem { Label("label2", systemImage: "image2") .accessibilityIdentifier("myTabItem") } The error I get is Failed to tap "myTabItem" Button: No matches found for Elements matching predicate '"myTabItem" IN identifiers' from input In the given list of buttons, I see the tab items with their labels, but none of them seem to have an identifier, while other buttons have the correct identifier. I wonder how this can only sometimes work. I tried isolating the issue by iteratively commenting out parts of the SwiftUI code, but unfortunately the behaviour seems erratic. When a change results in the issue not happening anymore, undoing the last X changes often causes the issue to stay away, even with configurations that previously had the issue. I've already spent almost a whole day trying to find the root cause, but with such apparently random behaviour it has proven impossible. Of course, I cannot reproduce the issue with a fresh test project, so the only way to reproduce it with 95% probability is running my original project. Has anyone had the same issue, or does anyone know how I could debug this to find out what causes my UI test to not be able to tap another tab item?

I noticed that when I have a fullscreen window in macOS 26, sidebars look like they are cut off at the top: they suddenly stop where the title bar/toolbar would appear when moving the mouse to the top of the screen, leaving a wide empty gap. Am I the only one who finds this ugly? Is this intended, or is there a workaround? This is how it looks in fullscreen (the sidebar borders are not easy to distinguish, look for the drop shadow): And this when moving the mouse to the top screen border to show the menu bar: I created FB20291636. @main class AppDelegate: NSObject, NSApplicationDelegate, NSWindowDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { let splitViewController = NSSplitViewController() splitViewController.addSplitViewItem(NSSplitViewItem(sidebarWithViewController: ViewController())) splitViewController.addSplitViewItem(NSSplitViewItem(viewController: ViewController())) let window = NSWindow(contentViewController: splitViewController) window.styleMask = [.titled, .closable, .miniaturizable, .resizable, .fullSizeContentView] window.toolbar = NSToolbar() window.delegate = self window.makeKeyAndOrderFront(nil) } func window(_ window: NSWindow, willUseFullScreenPresentationOptions proposedOptions: NSApplication.PresentationOptions = []) -> NSApplication.PresentationOptions { return [.autoHideToolbar, .autoHideMenuBar, .fullScreen] } } class ViewController: NSViewController { override func loadView() { let stack = NSStackView(views: [ NSTextField(labelWithString: "asdf") ]) stack.orientation = .vertical stack.alignment = .leading view = stack view.frame = CGRect(x: 0, y: 0, width: 300, height: 300) } }

I'm using the simplified code below to create a window with 4 split view items, some of them collapsed. I would expect the title bar to be transparent since I'm using window.titlebarAppearsTransparent = true, but it seems that this particular view configuration causes the title bar to be visible until I collapse and expand the sidebar again. Removing any of the split view items, uncollapsing any of them, or changing the view of any of the view controllers, causes the title bar to be consistently visible or hidden, although I don't understand the logic, since I'm telling the window that it should be transparent. When launching the app in light mode, it's more difficult to notice the issue since the title bar background is equal to the content background and only the separator is visible (even though the code sets window.titlebarSeparatorStyle = .none): After collapsing and expanding the sidebar, the separator is gone: In dark mode the title bar is more visible: After collapsing and expanding the sidebar, the title bar background and separator are gone: I created FB20306872. @main class AppDelegate: NSObject, NSApplicationDelegate, NSToolbarDelegate { var splitViewController: NSSplitViewController! func applicationDidFinishLaunching(_ aNotification: Notification) { let splitViewItem1 = NSSplitViewItem(sidebarWithViewController: ViewController1()) let splitViewItem2 = NSSplitViewItem(viewController: ViewController2()) let splitViewItem3 = NSSplitViewItem(viewController: NSViewController()) splitViewItem3.isCollapsed = true let splitViewItem4 = NSSplitViewItem(viewController: NSViewController()) splitViewItem4.isCollapsed = true splitViewController = NSSplitViewController() splitViewController.splitViewItems = [splitViewItem1, splitViewItem2, splitViewItem3, splitViewItem4] let window = NSWindow(contentViewController: splitViewController) window.styleMask = [.titled, .closable, .miniaturizable, .resizable, .fullSizeContentView] window.titlebarAppearsTransparent = true let toolbar = NSToolbar(identifier: "") toolbar.delegate = self toolbar.displayMode = .iconOnly window.toolbar = toolbar window.titlebarSeparatorStyle = .none window.makeKeyAndOrderFront(nil) } func toolbarAllowedItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] { return [.space, .flexibleSpace, .sidebarTrackingSeparator, .init("item")] } func toolbarDefaultItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] { return [.init("item"), .sidebarTrackingSeparator] } func toolbar(_ toolbar: NSToolbar, itemForItemIdentifier itemIdentifier: NSToolbarItem.Identifier, willBeInsertedIntoToolbar flag: Bool) -> NSToolbarItem? { switch itemIdentifier.rawValue { case "item": let item = NSToolbarItem(itemIdentifier: itemIdentifier) item.image = NSImage(systemSymbolName: "sidebar.leading", accessibilityDescription: nil) item.action = #selector(toggleSidebar(_:)) item.target = self return item default: return nil } } @objc func toggleSidebar(_ sender: Any?) { splitViewController.splitViewItems[0].animator().isCollapsed = !splitViewController.splitViewItems[0].isCollapsed } } class ViewController1: NSViewController { override func loadView() { view = NSView(frame: CGRect(x: 0, y: 0, width: 300, height: 200)) } } class ViewController2: NSViewController { override func loadView() { let textView = NSTextView() let scrollView = NSScrollView(frame: CGRect(x: 0, y: 0, width: 400, height: 200)) scrollView.hasVerticalScroller = true scrollView.documentView = textView view = scrollView } }

I have an iOS app with a QuickLook extension. I also added Apple Vision Pro in the target's General > Supported Destinations section. About one year ago, I was able to run the app on iPhone, iPad and Apple Vision Pro Simulators. Today I tried running it again on Apple Vision Pro with Xcode 26.0.1, but Xcode shows this error: Try again later. Appex bundle at ~/Library/Developer/CoreSimulator/Devices/F6B3CCA8-82FA-485F-A306-CF85FF589096/data/Library/Caches/com.apple.mobile.installd.staging/temp.PWLT59/extracted/problem.app/PlugIns/problemQuickLook.appex with id org.example.problem.problemQuickLook specifies a value (com.apple.quicklook.preview) for the NSExtensionPointIdentifier key in the NSExtension dictionary in its Info.plist that does not correspond to a known extension point. I tried again later a couple times, even after running Clean Build Folder Immediately, without any change. I can reproduce this with a fresh Xcode project to which I add a Quick Look Preview Extension and Apple Vision Pro as a supported destination. The error doesn't happen when running on Apple Vision Pro (Designed for iPad) or iPad Pro 13-inch (M4) destinations. What is the problem? I created FB20448815.

When comparing the Assets.car file of the previous and current versions of my app, compiled with Xcode 16 and 26, respectively, with the Terminal command assetutil --info MyApp.app/Contents/Resources/Assets.car I see that the new version contains many more app icons at different sizes, increasing my app's size by 1 MB (not much, but considering that the app is only 6 MB in total...): { "AssetType" : "MultiSized Image", "Name" : "AppIcon", "NameIdentifier" : 6849, "Scale" : 1, "SHA1Digest" : "9D75F76992E9E9E5531A214A4AE282EBD381F7EB903024E00FB25EB42381CC45", "SizeOnDisk" : 308, "Sizes" : [ "16x16 index:1 idiom:universal", "32x32 index:2 idiom:universal", "64x64 index:3 idiom:universal", "128x128 index:4 idiom:universal", "256x256 index:5 idiom:universal", "512x512 index:6 idiom:universal", "1024x1024 index:7 idiom:universal" ] } The previous one allowed me to add only two sizes: { "AssetType" : "MultiSized Image", "Name" : "AppIcon", "NameIdentifier" : 6849, "Scale" : 1, "SHA1Digest" : "AC782A2FFF9A4B2D563EF64DF41A179583440560F8732A176A8376B31000368E", "SizeOnDisk" : 248, "Sizes" : [ "256x256 index:1 idiom:universal", "512x512 index:2 idiom:universal" ] } Is there a way to only ship the strictly necessary app icons sizes while using Xcode 26 Icon Composer, or will all the sizes be required going forward?

It’s very frustrating when in a feedback I specify that I cannot reliably reproduce it and the feedback gets closed with the message “Since this issue cannot be reproduced, this report has been closed”, e.g. FB18985938. Is Apple not interested in hearing about issues that cannot be reliably reproduced? Many issues unfortunately depend on a variety of factors and it’s often impossible for third-party developers or users to figure out how to reliably reproduce them. Usually these kind of issues get addressed by e.g. adding more logging so that the next time it happens it's easier to find out what's causing it. Then the last part of the message “Please file a new report with a sysdiagnose if you encounter this issue again” sounds like I’m being teased, because what use is a new sysdiagnose if I still cannot reproduce it reliably? It will just be closed like the last one. I created FB20595673 for this issue.

I regularly receive emails from my customers asking why my app, which copies files from a source folder to a destination folder, gives an error during the copy operation, usually when some kind of NAS is involved. I then ask if copying the same file works in the Finder and they usually say yes. Then it’s up to me to contact the NAS vendor and ask why their NAS doesn’t work correctly with the copyfile function which my app uses to copy files, and provide them with a sample Xcode project that reproduces the issue. It would be so much easier for me, and probably other developers as well, if my customers could test their NAS with the Finder, then if it doesn’t work, contact their NAS vendor and solve the issue, or if it works, rest assured that file copies will work for any other app that uses the same API as the Finder. I could spend my time doing much more productive and interesting work rather than checking why every other NAS doesn’t work with my app which, after all, uses the most basic file copy mechanism available on macOS. Is there any chance that in the future (hopefully sooner than later) there will be an API to copy files like the Finder with progress information, or is there a reason why this won't ever be possible? I created FB20929181.

A user of one of my apps reported that since the update to macOS 26.1 they are no longer able to scan Macintosh HD: the app used to work, but now always reports that Macintosh HD contains a single empty file named .nofollow, or rather the path is resolved to /.nofollow. Initially I thought this could be related to resolving the file from the saved bookmark data, but even restarting the app and selecting Macintosh HD in an open panel (without resolving the bookmark data) produces the same result. The user tried another app of mine with the same issue, but said that they were able to scan Macintosh HD in other App Store apps. I never heard of this issue before and my apps have been on the App Store for many years, but it looks like I might be doing something wrong, or the APIs that I use are somehow broken. In all my apps I currently use getattrlistbulk because I need attributes that are not available as URLResourceKey in all supported operating system versions. What could be the issue? I'm on macOS 26.1 myself and never experienced it.

Users of my different apps started reporting an issue that could be related to the ones discussed in this other post: paths on an external volume, such as one mounted by "NTFS for Mac", or a path on a Synology volume, are "converted" to / (Macintosh HD) after going through "laundry" (creating the security-scoped bookmark, resolving the URL from it and using this new URL instead of the one returned by the open panel). Because of this issue, users of my apps are unable to select external volumes, which renders the different apps more or less useless. I've already received many emails regarding this issue in the past few days. A timely fix or suggestion for a workaround would be much appreciated, so that they don't have to wait for months before the next minor macOS release. The intention of this post is also to show users of my apps that this is a real issue. I created FB21002290 and TSI 16931637.