Xcode downloaded a crash report for my app which I don't quite understand. It seems the following line caused the crash: myEntity.image = newImage where myEntity is of type MyEntity: class MyEntity: NSObject, Identifiable { @objc dynamic var image: NSImage! ... } The code is called on the main thread. According to the crash report, thread 0 makes that assignment, and at the same time thread 16 is calling [NSImageView asynchronousPreparation:prepareResultUsingParameters:]. What could cause such a crash? Could I be doing something wrong or is this a bug in macOS? crash.crash

In macOS 15.4 (24E5238a) and Xcode 16.2, the NSStatus images appear to be missing. To reproduce, add an NSImageView to a Nib or StoryBoard and set the default image to any of the NSStatus images: NSStatusAvailable, NSStatusPartiallyAvailable, etc. Instead of the expected Green, Yellow dots, no image is displayed. The same occurs when setting images programatically. Is the plan to remove these images, or is this just temporary?

Hi. I thought the purpose of UndoManager.setActionIsDiscardable() was for this purpose - but the document still shows as edited. These changes like changing the zoom/viewing area should not cause the document to be considered edited - but you'd still like to be able to undo them. The documentation here https://developer.apple.com/documentation/foundation/undomanager/1415261-undoactionisdiscardable?changes=_6 even describes using it for just this purpose. If this isn't the method, how can I do this? Thanks.

I am trying to make a collection view with self-sizing cells that adapt to SwiftUI content. My test platform is macOS, but it should work on iOS all the same. I chose macOS because on macOS, you can resize the window and cause more interesting scenarios with that. My layout intent is fairly simple: a one-column collection view with cells with SwiftUI content, where the collection view cells should adapt to the height of their SwiftUI content. I got it working almost correctly. The one scenario that I don’t have working is window resizing. When the window resizes, the layout and cells should adapt to the content and change their heights. I feel that I am missing something fairly basic. How do I change this project so that the layout works correctly when I change the macOS window width? Example project and video of the behavior: https://gist.github.com/jaanus/66e3d863941ba645c88220b8a22970e1

With TextKit 1, I was able to “tag” characters with attribute string keys that flagged them to be invisible, then I would use NSLayoutManager’s layoutManager(_:shouldGenerateGlyphs:properties:characterIndexes:font:forGlyphRange:) to strip these characters out, preventing change to the underlying storage. In TextKit 2, I don’t see an opportunity to do this. The best point I think to intercept would be NSTextLayoutFragment, but without being able to see what’s happening, I don’t know if it’s possible to alter the content used to generate the line fragments. My end goal is to be able to hide characters for a Markdown editor, so maybe I’m thinking about this wrong? Any advice would be welcome.

I have a SwiftUI based app. For lots of reasons I was forced to use NSDocument instead of using DocumentGroup. I configure the main menu in my AppDelegate. It has the following code: let fileMenuItem = NSMenuItem() let fileMenu = NSMenu(title: "File") fileMenu.addItem(withTitle: "New", action: #selector(NSDocumentController.newDocument(_:)), keyEquivalent: "n") fileMenu.addItem(withTitle: "Open...", action: #selector(NSDocumentController.openDocument(_:)), keyEquivalent: "o") The New and Open work as expected. It is my understanding that the NSDocumentController should automatically add the "Open Recent" menu when it sees the Open action based on the NSDocumentController. It is not appearing. When I print the state of the recent documents using print("recent documents \(NSDocumentController.shared.recentDocumentURLs), maximum \(NSDocumentController.shared.maximumRecentDocumentCount)") I see the recent document urls and a count of 10. What can I do to make the menu appear? Thanks for the help.

It seems that NSTextView has an issue with deleting text and setting any attribute at the same time, when it also has a textContainerInset. With the code below, after 1 second, the empty line in the text view is automatically deleted and the first line is colored red. The top part of the last line remains visible at its old position. Selecting the whole text and then deselecting it again makes the issue disappear. Is there a workaround? I've created FB16897003. class ViewController: NSViewController { @IBOutlet var textView: NSTextView! override func viewDidAppear() { textView.textContainerInset = CGSize(width: 0, height: 8) let _ = textView.layoutManager textView.textStorage!.setAttributedString(NSAttributedString(string: "1\n\n2\n3\n4")) textView.textStorage!.addAttribute(.foregroundColor, value: NSColor.labelColor, range: NSRange(location: 0, length: textView.textStorage!.length)) DispatchQueue.main.asyncAfter(deadline: .now() + 1) { [self] in textView.selectedRange = NSRange(location: 3, length: 0) textView.deleteBackward(nil) textView.textStorage!.beginEditing() textView.textStorage!.addAttribute(.foregroundColor, value: NSColor.red, range: NSRange(location: 0, length: 2)) textView.textStorage!.endEditing() } } }

Consider the code from my previous question: https://developer.apple.com/forums/thread/776592 How can I change the background color of a focused item?

I just made a simple AppKit app, but don't know how to remove borders of rows when they're swiped. SwiftUI's list does not have this problem though. Attaching gif demo and code: import SwiftUI struct NSTableViewWrapper: NSViewRepresentable { @State var data: [String] class Coordinator: NSObject, NSTableViewDataSource, NSTableViewDelegate { var parent: NSTableViewWrapper weak var tableView: NSTableView? init(parent: NSTableViewWrapper) { self.parent = parent } func numberOfRows(in tableView: NSTableView) -> Int { self.tableView = tableView return parent.data.count } func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { let cell = tableView.makeView(withIdentifier: NSUserInterfaceItemIdentifier("Cell"), owner: nil) as? NSTextField ?? NSTextField(labelWithString: "") cell.identifier = NSUserInterfaceItemIdentifier("Cell") cell.stringValue = parent.data[row] cell.isBordered = false return cell } func tableView(_ tableView: NSTableView, rowActionsForRow row: Int, edge: NSTableView.RowActionEdge) -> [NSTableViewRowAction] { guard edge == .trailing else { return [] } let deleteAction = NSTableViewRowAction(style: .destructive, title: "Delete") { action, index in self.deleteRow(at: index, in: tableView) } return [deleteAction] } private func deleteRow(at index: Int, in tableView: NSTableView) { guard index < parent.data.count else { return } NSAnimationContext.runAnimationGroup({ context in context.duration = 0.3 tableView.removeRows(at: IndexSet(integer: index), withAnimation: .slideUp) }, completionHandler: { DispatchQueue.main.async { self.parent.data.remove(at: index) tableView.reloadData() } }) } } func makeCoordinator() -> Coordinator { return Coordinator(parent: self) } func makeNSView(context: Context) -> NSScrollView { let scrollView = NSScrollView() let tableView = NSTableView() let column = NSTableColumn(identifier: NSUserInterfaceItemIdentifier("Column")) column.width = 200 tableView.addTableColumn(column) tableView.delegate = context.coordinator tableView.dataSource = context.coordinator tableView.backgroundColor = .clear tableView.headerView = nil tableView.rowHeight = 50 tableView.style = .inset scrollView.documentView = tableView scrollView.hasVerticalScroller = true scrollView.additionalSafeAreaInsets = .init(top: 0, left: 0, bottom: 6, right: 0) return scrollView } func updateNSView(_ nsView: NSScrollView, context: Context) { (nsView.documentView as? NSTableView)?.reloadData() } } struct ContentView: View { @State private var itemsString = Array(0..<40).map(\.description) var body: some View { NSTableViewWrapper(data: itemsString) } } func createAppWindow() { let window = NSWindow( contentRect: .zero, styleMask: [.titled], backing: .buffered, defer: false ) window.title = "NSTableView from AppKit" window.contentViewController = NSHostingController(rootView: ContentView()) window.setContentSize(NSSize(width: 759, height: 300)) window.center() window.makeKeyAndOrderFront(nil) } class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ notification: Notification) { createAppWindow() } } let delegate = AppDelegate() NSApplication.shared.delegate = delegate NSApplication.shared.run()

When I present a view controller, whose view is a SwiftUI View, via presentAsModalWindow(_:) the presented window is no longer centered horizontally to the screen, but rather its origin is there. I know this issue occurs for macOS 15.2+, but can't tell if it is from 15.0+. I couldn't find any documentation on why was this changed. Here's an example code that represents my architecture: class RootViewController: NSViewController { private lazy var button: NSButton = NSButton( title: "Present", target: self, action: #selector(presentView)) override func viewDidLoad() { super.viewDidLoad() // Add button to tree } @objc func presentView() { presentAsModalWindow(PresentedViewController()) } } class PresentedViewController: NSViewController { override loadView() { view = NSHostingView(rootView: MyView()) } } struct MyView: View { /* impl */ }

In the new beta, NSStatusNone et. al. are either missing or not rendered. Example screenshot is from Xcode, but other apps are also affected. Filed as FB16822441

Where from and how does an NSRulerView get its magnification from? I am not using the automatic magnification by NSScrollView but using my own mechanism. How do I relay the zoom factor to NSRulerView?

In the good old days, it was possible to retrieve dynamically the UnknownFSObjectIcon.icns icon using: [[NSWorkspace sharedWorkspace] iconForFileType:NSFileTypeForHFSTypeCode(kUnknownFSObjectIcon)]; Now, this solution is considered to be deprecated (but is still working) by recent macOS SDKs. [Q] What is the modern equivalent of this solution? Notes: Yes, reading the file directly works but is more fragile than using a System API. Yes, Xcode suggests to use the iconForContentType: method but I haven't found which UTType should be used.

All the threads only contain system calls. The crashed thread only contains a single call to my app's code which is main.swift:13. What could cause such a crash? crash.crash

It appears that on all recent versions of macOS when adding a new InputSource in /Library/Input Methods (or modifying an existing one there) the user needs to logoff and log back in in order for Keyboard/Input Sources in System Settings and Input Menu in menu bar to pick up the changes. Is there a way to avoid this? That is, some notification to send or API to call to tell both of these "hey, things might have changed on disk, please re-read the info, and update the UI". 🙂

I am revising my app to support NSWritingToolsCoordinator/ NSWritingToolsCoordinatorDelegate. When proofreading some paragraphs, it works well. But, when proofreading many paragraphs (for example, 56 paragraphs), it can't complete the proofreading. I am not sure which is wrong with my app or macOS API. I think I implemented all NSWritingToolsCoordinatorDelegate methods. Is there any information for such an issue? Phenomenon For paragraphs 1-9, text animation completed. But, for paragraphs 10-56, text animation does not complete. It shows 5 corrected items, but I can't jump to items 3, 4, 5, when I click the ">" button in the "Proofread" window. Items 3, 4, 5 were not corrected actually. Log For each NSWritingToolsCoordinatorDelegate method, the method name and main arguments are output by NSLog. requestsContextsForScope willChangeToState newState:2 requestsPreviewForTextAnimation range:(0, 18233) prepareForTextAnimation range:(0, 18233) willChangeToState newState:3 requestsPreviewForTextAnimation range:(0, 18233) finishTextAnimation range:(0, 18233) requestsPreviewForRect requestsPreviewForTextAnimation range:(0, 1837) replaceRange proposedText:an range:(208, 2) replaceRange proposedText:you range:(443, 4) prepareForTextAnimation range:(1836, 16396) requestsPreviewForTextAnimation range:(0, 1836) requestsBoundingBezierPathsForRange range:(208, 2) requestsBoundingBezierPathsForRange range:(443, 3) requestsPreviewForRect prepareForTextAnimation range:(0, 1836) prepareForTextAnimation range:(1836, 0) finishTextAnimation range:(1836, 16396) requestsPreviewForTextAnimation range:(1836, 16396) requestsBoundingBezierPathsForRange range:(208, 2) requestsBoundingBezierPathsForRange range:(443, 3) prepareForTextAnimation range:(1836, 16396) finishTextAnimation range:(0, 1836) finishTextAnimation range:(0, 1836) replaceRange proposedText:an range:(208, 2) requestsUnderlinePathsForRange range:(208, 2) requestsUnderlinePathsForRange range:(443, 3) selectRanges ranges.count:1 requestsBoundingBezierPathsForRange range:(208, 2) replaceRange proposedText:an range:(208, 2) requestsUnderlinePathsForRange range:(208, 2) requestsUnderlinePathsForRange range:(443, 3) selectRanges ranges.count:1 replaceRange proposedText:you range:(443, 3) requestsUnderlinePathsForRange range:(208, 2) requestsUnderlinePathsForRange range:(443, 3) selectRanges ranges.count:1 requestsBoundingBezierPathsForRange range:(443, 3) replaceRange proposedText:you range:(443, 3) requestsUnderlinePathsForRange range:(208, 2) requestsUnderlinePathsForRange range:(443, 3) selectRanges ranges.count:1 macOS version is 15.3.1 (24D70)

Hi all, I am trying to allow users of my app to select extra options when opening documents, and to remember those options when re-opening documents at launch. So far best idea I have is: Subclass NSDocumentController to provide an NSOpenPanel.accessoryView with the options Create a URL bookmark for each opened file and keep a mapping of bookmarks to options On launch and when the recent documents list changes, prune the stored mappings to match only the recent items Has anyone done this before, or know of a better approach? Thank you.

TLDR: NSLayoutManager's textContainer(forGlyphAt:effectiveRange:) and lineFragmentRect(forGlyphRange:effectiveRange:) are returning inconsistent results. Context: I'm developing a word processing app that paginates from an NSTextStorage using NSLayoutManager. My app uses a text attribute (.columnType) to paginate sub-ranges of the text at a time, ensuring that each columnRange gets a container (or series of containers across page breaks) to fit. This is to support both multi-column and standard full-page-width content. After any user edit, I update pagination data in my Paginator model class. I calcuate frames/sizes for the views/containers, along with what superview they belong to (page). The UI updates accordingly. In order to determine whether the columnRange has overflowed from a container due to a page break OR whether the range of text hasn't overflowed its container and is actually using less space than available and should be sized down, I call both: layoutManager.textContainer(forGlyphAt: lastGlyphOfColumn, effectiveRange: &actualGlyphRangeInContainer)` // and `layoutManager.lineFragmentRect(forGlyphAt: lastGlyphOfColumn, effectiveRange: nil) Apple Documentation notes that both these calls force glyph generation and layout. As I'm in early development, I have not set non-contiguous layout. So these should be causing full layout, assuring accurate return values. Or so I'd hoped. This does work fine in many cases. I edit. Pagination works. But then I'll encounter UI-breaking inconsistent returns from these two calls. By inconsistent, I mean that the second call returns a line fragment rect that is in the container coordinates of A DIFFERENT container than the container returned by the first call. To be specific, the line fragment rect seems to be in the coordinates of the container that comes next in layoutManager.textContainers. Example Code: if !layoutManager.textContainers.indices.contains(i) { containerToUse = createTextContainer(with: availableSize) layoutManager.addTextContainer(containerToUse) } else { // We have a container already but it may be // the wrong size. containerToUse = layoutManager.textContainers[i] if containerToUse.size.width != availableSize.width { // Mandatory that we resize if we don't have // a matching width. Height resizing is not // mandatory and requires a layout check below. containerToUse.size = availableSize } } let glyphRange = layoutManager.glyphRange(forCharacterRange: remainingColumnRange, actualCharacterRange: nil) let lastGlyphOfColumn = NSMaxRange(glyphRange) - 1 var containerForLastGlyphOfColumn = layoutManager.textContainer(forGlyphAt: lastGlyphOfColumn, effectiveRange: &actualGlyphRangeInContainer) if containerForLastGlyphOfColumn != containerToUse && containerToUse.size.height < availableSize.height { // If we are here, we overflowed the container, // BUT the container we overflowed didn't use // the maximum remaining page space (this // means it was a pre-existing container that // needs to be sized up and checked once more). // NOTE RE: THE BUG: // at this point, prints show... // containerToUse.size.height // =628 // availableSize.height // =648 containerToUse.size = availableSize containerForLastGlyphOfColumn = layoutManager.textContainer(forGlyphAt: lastGlyphOfColumn, effectiveRange: &actualGlyphRangeInContainer) } // We now check again, knowing that the container we // are testing flow into is the max size it can be. if containerForLastGlyphOfColumn != containerToUse { // If we are here, we have overflowed the // container, so containerToUse size SHOULD be // final/accurate, since it is fully used. actualCharRangeInContainer = layoutManager.characterRange(forGlyphRange: actualGlyphRangeInContainer, actualGlyphRange: nil) // Start of overflow range is the first character // in the container that was overflowed into. let overflowLoc = actualCharRangeInContainer.location remainingColumnRange = NSRange(location: overflowLoc, length: remainingColumnRange.length - overflowLoc) // Update page count as we have broken to a new page currentPage += 1 } else { // If we are here, we have NOT overflowed // from the container. BUT... // THE BUG: // ***** HERE IS THE BUG! ***** lineFragmentRectForLastChar = layoutManager.lineFragmentRect(forGlyphAt: lastGlyphOfColumn, effectiveRange: nil) let usedHeight = lineFragmentRectForLastChar.maxY // BUG: ^The lines of code above return a // fragment rect that is in the coordinates // of the WRONG text container. Prints show: // usedHeight // =14 // usedHeight shouldn't be just 14 if this is // the SAME container that, when it was 628 // high, resulted in text overflowing. // Therefore, the line fragment here seems // to be in the coordinates of the ENSUING // container that we overflowed INTO, but // that shouldn't be possible, since we're in // a closure for which we know: // // containerForLastGlyphOfColumn == containerToUse // // If the last glyph container is the container // we just had to size UP, why does the final // glyph line fragment rect have a maxY of 14!? // Including ensuing code below only for context. if usedHeight < containerToUse.size.height { // Adjust container size down to usedRect containerToUse.size = CGSize(width: containerToUse.size.width, height: usedHeight) } else if usedHeight == availableSize.height { // We didn't force break to a new page BUT // we've used exactly the height of our page // to layout this column range, so need to // break to a new page for any ensuing text // columns. currentPage += 1 } else if usedHeight > containerToUse.size.height { // We should have caught this earlier. Text // has overflowed, but this should've been // caught when we checked // containerForLastGlyphOfColumn != // containerToUse. // // Note: this error has never thrown. throw PaginationError.unknownError("Oops.") } } Per my comments in the code block above, I don't understand why the very same text container that just overflowed and so had to be sized up from 628 to 648 in order to try to fit a glyph would now report that same glyph as both being IN that same container and having a line fragment rect with a maxY of just 14. A glyph couldn't fit in a container when it was 628 high, but if I size it up to 648, it only needs 14? There's something very weird going on here. Working with NSLayoutManager is a bit of a nightmare given the unclear documentation. Any help or insight here would be massively, massively appreciated.

Starting from Sequoia release 15.2 apps crash with following call stack, when adding static text controls. First call to [NSTextField setStringValue] causes following crash 0 libobjc.A.dylib 0x19f2f5820 objc_msgSend + 32 1 AppKit 0x1a3355460 -[NSCell _objectValue:forString:errorDescription:] + 144 2 AppKit 0x1a3355348 -[NSCell setStringValue:] + 48 3 AppKit 0x1a33af9fc -[NSControl setStringValue:] + 104 4 AppKit 0x1a3d1f190 -[NSTextField setStringValue:] + 52 It happens on specific MacBook Pro models(16 in MacBook Pro). Crash analysis found that isa pointer of the object was corrupted for the object NSCell. Enabled Zombies in debugging, not found any issue. Also tried address sanitizer. Since the issue started with a recent release of macOS, any changes in the Appkit in the recent releases trigger the crash? Any help/suggestions would be appreciated.

macOS: 15.0 macFUSE: 4.8.3 I am using rclone + macFUSE and mount my netdisk where it has created three subdirectories in its root directory: /user, /share, and /group. When I save a file to /[root]/user using NSSavePanel and name it test.txt, I expect the file to be saved as: /[root]/user/test.txt However, occasionally, the delegate method: - (BOOL)panel:(id)sender validateURL:(NSURL *)url error:(NSError **)outError { } returns an incorrect path: /[root]/test.txt This issue only occurs when selecting /user. The same operation works correctly for /share and /group. Is there any logs I could provide to help solving this issue? Many thanks!