import Cocoa @available(macOS 10.13, *) let imagePboardType = NSPasteboard.PasteboardType.fileURL class DragSourceView: NSImageView { weak var dragSourceDelegate: NSDraggingSource? override func mouseDown(with event: NSEvent) { //拖放数据定义 let pasteboardItem = NSPasteboardItem() //设置数据的Provider if #available(macOS 10.13, *) { pasteboardItem.setDataProvider(self, forTypes: [NSPasteboard.PasteboardType.fileURL]) } else { // Fallback on earlier versions } //拖放item let draggingItem = NSDraggingItem(pasteboardWriter: pasteboardItem) draggingItem.draggingFrame = NSRect(x: 100 , y: 10, width: 100, height: 100) //拖放可视化图象设置 draggingItem.imageComponentsProvider = { let component = NSDraggingImageComponent(key: NSDraggingItem.ImageComponentKey.icon) component.frame = NSRect(x: 0, y: 0, width: 16, height: 16) component.contents = NSImage(size: NSSize(width: 32,height: 32), flipped: false, drawingHandler: { [unowned self] rect in { self.image?.draw(in: rect) return true }() } ) return [component] } //开始启动拖放sesson self.beginDraggingSession(with: [draggingItem], event: event, source: self.dragSourceDelegate!) } } extension DragSourceView: NSPasteboardItemDataProvider { func pasteboard(_ pasteboard: NSPasteboard?, item: NSPasteboardItem, provideDataForType type: NSPasteboard.PasteboardType) { // let data = self.image?.tiffRepresentation let data = "/Users/slowdony/Desktop/640.jpeg" let dataUrl = data.data(using: String.Encoding(rawValue: NSUTF8StringEncoding))! item.setData(dataUrl, forType: type) } } import Cocoa class ViewController: NSViewController { @IBOutlet weak var sourceView: DragSourceView! override func viewDidLoad() { super.viewDidLoad() self.sourceView.dragSourceDelegate = self } } extension ViewController: NSDraggingSource { //返回拖放操作类型 func draggingSession(_ session: NSDraggingSession, sourceOperationMaskFor context: NSDraggingContext) -> NSDragOperation { if (context == .outsideApplication){ return .copy } else{ return .generic } } //开始拖放代理回调 func draggingSession(_ session: NSDraggingSession, willBeginAt screenPoint: NSPoint) { print("draggingSession beginAt \(screenPoint)") } //拖放鼠标移动时的代理回调 func draggingSession(_ session: NSDraggingSession, movedTo screenPoint: NSPoint) { print("draggingSession movedTo \(screenPoint)") } //结束拖放代理回调 func draggingSession(_ session: NSDraggingSession, endedAt screenPoint: NSPoint, operation: NSDragOperation) { print("draggingSession endedAt \(screenPoint)") } } I am dragging an image to the desktop through the above code, failed, help

Developing on Monterey 12.7.5 I'm having trouble with updating subitems on NSToolbarItemGroup when selecting the item directly from the NSToolbar items array. I select the group item off the items array on the toolbar, and then call setSubitems: on the item, with a new array of NSToolbarItems. The group item disappears from the toolbar. It seems to leave a blank invisible item in the toolbar taking up space. I can't manually reinsert the item into the toolbar until I drag out the blank item, then drag back in the real item. Once dragged back in from the palette it displays correctly. The workaround I've come up with is to remove the item with NSToolbar removeItemAtIndex: and reinsert it with NSToollbar insertItemWithItemIdentifier:atIndex:. This works to update the subitems. Every other toolbar item property that I've tried has been able to update the item directly in the toolbar. It's only the group item's subitems that don't want to update correctly. Is there a correct way to do this that I'm missing? Calling [toolbar validateVisibleItems] didn't seem to help.

I am using the window.level set to .floating as described here: https://developer.apple.com/documentation/appkit/nswindow/level The setting itself works okay. However, in a multi monitor setup, the floating window is appearing on both the screens. How can I prevent this? My users report that before macOS Sonoma, this used to not happen. Has this behaviour changed? How can I revert back to the old behaviour?

I made an account on this site for the sole reason to post this. I can not stand the IOS 18 photo app, to put it bluntly its sucks, it's made the app unusable. I was nice, I'd thought I'd give it a month or two but no, it still sucks. I wish I could uninstall IOS 18 solely cause of it. I hate the UI, its utterly unintuitive.

I'm seeing a discrepancy in the metrics of the "New York" system font returned from various Macs. Here's a sample (works well in Playgrounds): import Cocoa let font = NSFont(descriptor: .preferredFontDescriptor(forTextStyle: .body).withDesign(.serif)!, size: NSFont.systemFontSize)! print("\(font.fontName) \(font.pointSize)") print("ascender: \(font.ascender)") let layoutManager = NSLayoutManager() print("lineHeight: \(layoutManager.defaultLineHeight(for: font))") When I run this on multiple Macs, I get two types of different results. Some – most Macs – report this: .NewYork-Regular 13.0 ascender: 12.3779296875 lineHeight: 16.0 However, when I run on my own Mac (and also on the one of a colleague), I get this instead: .NewYork-Regular 13.0 ascender: 14.034145955454255 lineHeight: 19.0 It's clearly the same font in the same point size. Yet the font has different metrics, causing a layout manager to also compute a significantly different line height. So far I've found out that neither CPU generation/architecture nor macOS version seem to play a role. This issue has been reproducible since at least macOS 14. Having just migrated to a new Mac, the issue is still present. This does not affect any other system or commonly installed font. It's only New York (aka the serif design). So I assume this must be something with my setup. Yet I have been unable to find anything that may cause this. Anybody have some ideas? Happy to file a bug report but wanted to check here first.

I am trying to understand why I am seeing crash reports for my code that creates a view from a NIB like the code below. The crash occurs when referencing contentView which should have been bound when the NIB was loaded. Am I missing something here other than checking the result of the loadNibNamed function call? class MyView: NSView { @IBOutlet var contentView: NSView! init() { super.init(frame: NSRect(x: 0, y: 0, width: 84.0, height: 49.0)) commonInit() } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } private func commonInit() { Bundle.main.loadNibNamed("MyView", owner: self, topLevelObjects: nil) translatesAutoresizingMaskIntoConstraints = false contentView.translatesAutoresizingMaskIntoConstraints = false addSubview(contentView) contentView.frame = self.bounds }

I have an old Objective-C app that has been running for several years. The last compilation was in February 2024. I just upgraded to Sequoia 15.1. The app has four subviews on its main view. When I run the app only the subview that was the last one instantiated is visible. I know the other subviews are there, because a random mouse click in one invisible view causes the expected change in the visible view. What changed in 15.1 to cause this?

I am creating an iOS app to install on legacy iPads running iOS 9 and up, using XCode 13.4.1 which is the latest version that will support iOS below 11. The app is working fine but I just added a QuickLook Preview extension, and on iOS 10.3.1 it will not install due to the following error: This app contains an app extension that specifies an extension point identifier that is not supported on this version of iOS for the value of the NSExtensionPointIdentifier key in its Info.plist. Domain: com.apple.dt.MobileDeviceErrorDomain Code: -402653007 The NSExtensionPointIdentifier key in Info.plist is set by XCode automatically to "com.apple.quicklook.preview". I want to set the iOS Deployment Target to the lowest iOS version that will support this configuration. The documentation does not provide any guide as to which specific NSExtensionPointIdentifier keys are compatible with which iOS version. It just says 8+ for the whole list. Trial-and-error is limited by availability of legacy Simulators. If anyone can point to documentation that indicates which iOS is supported by which NSExtensionPointIdentifier key com.apple.quicklook.preview, I would be very grateful. Thanks (I understand about lack of App Store support etc, this is an app for my use on old iPads)

This is a post down memory lane for you AppKit developers and Apple engineers... TL;DR: When did the default implementation of NSViewController.loadView start making an NSView when there's no matching nib file? (I'm sure that used to return nil at some point way back when...) If you override NSViewController.loadView and call [super loadView] to have that default NSView created, is it safe to then call self.view within loadView? I'm refactoring some old Objective-C code that makes extensive use of NSViewController without any use of nibs. It overrides loadView, instantiates all properties that are views, then assigns a view to the view controller's view property. This seems inline with the documentation and related commentary in the header. I also (vaguely) recall this being a necessary pattern when not using nibs: @interface MyViewController: NSViewController // No nibs // No nibName @end @implementation MyViewController - (void)loadView { NSView *hostView = [[NSView alloc] initWithFrame:NSZeroRect]; self.button = [NSButton alloc...]; self.slider = [NSSlider alloc...]; [hostView addSubview:self.button]; [hostView addSubview:self.slider]; self.view = hostView; } @end While refactoring, I was surprised to find that if you don't override loadView and do all of the setup in viewDidLoad instead, then self.view on a view controller is non-nil, even though there was no nib file that could have provided the view. Clearly NSViewController has realized that: There's no nib file that matches nibName. loadView is not overridden. Created an empty NSView and assigned it to self.view anyways. Has this always been the behaviour or did it change at some point? I could have sworn that if there as no matching nib file and you didn't override loadView, then self.view would be nil. I realize some of this behaviour changed in 10.10, as noted in the header, but there's no mention of a default NSView being created. Because there are some warnings in the header and documentation around being careful when overriding methods related to view loading, I'm curious if the following pattern is considered "safe" in macOS 15: - (void)loadView { // Have NSViewController create a default view. [super loadView]; self.button = [NSButton...]; self.slider = [NSSlider...]; // Is it safe to call self.view within this method? [self.view addSubview:self.button]; [self.view addSubview:self.slider]; } Finally, if I can rely on NSViewController always creating an NSView for me, even when a nib is not present, then is there any recommendation on whether one should continue using loadView or instead move code the above into viewDidLoad? - (void)viewDidLoad { self.button = [NSButton...]; self.slider = [NSSlider...]; // Since self.view always seems to be non-nil, then what // does loadView offer over just using viewDidLoad? [self.view addSubview:self.button]; [self.view addSubview:self.slider]; } This application will have macOS 15 as a minimum requirement.

When I upgraded to Sequoia 15.1, an app that worked fine under OS 14 stopped working. Out of 4 views on the main screen, only 1 is visible. Yet, if I click where another view should be, I get the expected action so the views are there, just not visible. Only I can't see where I am clicking! I had to upgrade to Xcode 16 to recompile the app and run it in Debug mode. When I do, I get the following: NSBundle file:///System/Library/PrivateFrameworks/MetalTools.framework/ principal class is nil because all fallbacks have failed. Can't find or decode disabled use cases. applicationSupportsSecureRestorableState FWIW - the only view that actually shows up is the last subview added to the main view.

I have a problem with rulers in an NSTextView. My code has worked fine from about Sierra (10.12), up to Ventura (13), it stopped working in Sonoma and continues to fail in the same way in Sequoia (14 - 15). When I display the ruler, the contents of the text area disappears leaving just a pale grey background. When I make the ruler invisible again the text reappears. No errors are reported (at compile or run time). I have tried adding refreshes of the text view in various places with no result. I have (for Sequoia) used Interface Builder to force the text view to use TextKit 1, also with no success. I’m at a loss as to how to proceed because I’m not getting any diagnostics, simply changed behaviour. My app provides a programming IDE. It includes a program editor that uses line numbering code for an NSTextView from WWDC/Noodlesoft. The line numbers are shown in the ruler which is sometimes visible and sometimes not. When I display the ruler, I also set the main text to not editable but removing this setting does not appear to make any difference. Any suggestions would be very wel PLATFORM AND VERSION macOS, Objective C Development environment: Xcode Version 16.0 (16A242d) [and previously Xcode 15], macOS All releases of Sonoma and Sequoia 15.0.1 (24A348) Run-time configuration: macOS Sequoia 15.0.1 (24A348) The sequence is essentially: [editTextView setEditable:NO]; [self showRulerIn:editTextView visible:YES]; Using: -(void)showRulerIn:(NSTextView*)editorTv visible:(BOOL)vis { NSScrollView *scrollV = [editorTv enclosingScrollView]; NSClipView *clipV = [scrollV contentView]; MBEditorTextView *textView = (MBEditorTextView*)[scrollV documentView]; // The actual text [scrollV setRulersVisible:vis]; // Creates the ruler if necessary … return; } LINE NUMBERING CODE The line number code comes from 2 sources but they are so similar that one must be derived from the other: Apple’s WWDC 2010 code at: https://download.developer.apple.com/videos/wwdc_2010__hd/session_114__advanced_cocoa_text_tips_and_tricks.mov Noodlesoft's code at: https://www.noodlesoft.com/blog/2008/10/05/displaying-line-numbers-with-nstextview/

I'm still discovering swift and the various frameworks. So I'm now trying to create scrolling composition with a grid - containing images - and an NSStackView at on top. However, I'm running into a problem that might seem stupid, but when I try to wrap my NSCollectionView in another NSView and pointing the scrollView.documentView to, I can't scroll anymore... Even though it works fine when I set the scrollView.documentView to the NSCollectionView directly. Working case: override func viewDidLoad() { super.viewDidLoad() scrollView = NSScrollView(frame: .zero) scrollView.hasVerticalScroller = true scrollView.hasHorizontalScroller = false scrollView.scrollerStyle = .overlay scrollView.translatesAutoresizingMaskIntoConstraints = false view.addSubview(scrollView) vStack = NSStackView(frame: .zero) vStack.orientation = .vertical vStack.spacing = 12 * 2 vStack.translatesAutoresizingMaskIntoConstraints = false let hStack = NSStackView() hStack.orientation = .horizontal hStack.spacing = 12 hStack.translatesAutoresizingMaskIntoConstraints = false let label1 = NSTextField(labelWithString: "Collection") hStack.addArrangedSubview(label1) let layout = PinterestLayout() layout.delegate = self collectionView = NSCollectionView(frame: .zero) collectionView.collectionViewLayout = layout collectionView.dataSource = self collectionView.delegate = self collectionView .register( ArtCardCell.self, forItemWithIdentifier: NSUserInterfaceItemIdentifier("ArtCardCell") ) collectionView.backgroundColors = [.BG] collectionView.translatesAutoresizingMaskIntoConstraints = false // vStack.addArrangedSubview(hStack) // vStack.addArrangedSubview(collectionView) scrollView.documentView = collectionView NSLayoutConstraint.activate([ scrollView.leadingAnchor.constraint(equalTo: view.leadingAnchor), scrollView.trailingAnchor.constraint(equalTo: view.trailingAnchor), scrollView.topAnchor.constraint(equalTo: view.topAnchor), scrollView.bottomAnchor.constraint(equalTo: view.bottomAnchor), // vStack.leadingAnchor.constraint(equalTo: scrollView.leadingAnchor), // vStack.trailingAnchor.constraint(equalTo: scrollView.trailingAnchor), // vStack.topAnchor.constraint(equalTo: scrollView.topAnchor), // vStack.bottomAnchor.constraint(equalTo: scrollView.bottomAnchor), // vStack.widthAnchor.constraint(equalTo: scrollView.widthAnchor), collectionView.widthAnchor.constraint(equalTo: scrollView.widthAnchor), // vStack.arrangedSubviews[0].leadingAnchor.constraint(equalTo: scrollView.leadingAnchor, constant: 12), // vStack.arrangedSubviews[0].trailingAnchor.constraint(equalTo: scrollView.trailingAnchor, constant: -12), // vStack.arrangedSubviews[0].topAnchor.constraint(equalTo: scrollView.topAnchor, constant: 80) ]) collectionView.postsBoundsChangedNotifications = true NotificationCenter.default.addObserver(self, selector: #selector(didScroll(_:)), name: NSView.boundsDidChangeNotification, object: collectionView.enclosingScrollView?.contentView ) } collectionView height: 3549.0 ScrollView height: 628.0 StackView height: -- Dysfunctional case: override func viewDidLoad() { super.viewDidLoad() scrollView = NSScrollView(frame: .zero) scrollView.hasVerticalScroller = true scrollView.hasHorizontalScroller = false scrollView.scrollerStyle = .overlay scrollView.translatesAutoresizingMaskIntoConstraints = false view.addSubview(scrollView) vStack = NSStackView(frame: .zero) vStack.orientation = .vertical vStack.spacing = 12 * 2 vStack.translatesAutoresizingMaskIntoConstraints = false let hStack = NSStackView() hStack.orientation = .horizontal hStack.spacing = 12 hStack.translatesAutoresizingMaskIntoConstraints = false let label1 = NSTextField(labelWithString: "Collection") hStack.addArrangedSubview(label1) let layout = PinterestLayout() layout.delegate = self collectionView = NSCollectionView(frame: .zero) collectionView.collectionViewLayout = layout collectionView.dataSource = self collectionView.delegate = self collectionView .register( ArtCardCell.self, forItemWithIdentifier: NSUserInterfaceItemIdentifier("ArtCardCell") ) collectionView.backgroundColors = [.BG] collectionView.translatesAutoresizingMaskIntoConstraints = false vStack.addArrangedSubview(hStack) vStack.addArrangedSubview(collectionView) scrollView.documentView = vStack NSLayoutConstraint.activate([ scrollView.leadingAnchor.constraint(equalTo: view.leadingAnchor), scrollView.trailingAnchor.constraint(equalTo: view.trailingAnchor), scrollView.topAnchor.constraint(equalTo: view.topAnchor), scrollView.bottomAnchor.constraint(equalTo: view.bottomAnchor), vStack.leadingAnchor.constraint(equalTo: scrollView.leadingAnchor), vStack.trailingAnchor.constraint(equalTo: scrollView.trailingAnchor), vStack.topAnchor.constraint(equalTo: scrollView.topAnchor), vStack.bottomAnchor.constraint(equalTo: scrollView.bottomAnchor), vStack.widthAnchor.constraint(equalTo: scrollView.widthAnchor), collectionView.widthAnchor.constraint(equalTo: scrollView.widthAnchor), vStack.arrangedSubviews[0].leadingAnchor.constraint(equalTo: scrollView.leadingAnchor, constant: 12), vStack.arrangedSubviews[0].trailingAnchor.constraint(equalTo: scrollView.trailingAnchor, constant: -12), vStack.arrangedSubviews[0].topAnchor.constraint(equalTo: scrollView.topAnchor, constant: 80) ]) } collectionView height: 508.0 ScrollView height: 628.0 StackView height: 628.0

I'm looking at a case where a handler for NSWindowDidBecomeMain gets the NSWindow* from the notification object and verifies that window.isVisible == YES, window.windowNumber > 0 and window.screen != nil. However, window.windowNumber is missing from the array [NSWindow windowNumbersWithOptions: NSWindowNumberListAllSpaces] and from CGWindowListCopyWindowInfo( kCGWindowListOptionOnScreenOnly, kCGNullWindowID ), how can that be? The window number is in the array returned by CGWindowListCopyWindowInfo( kCGWindowListOptionAll, kCGNullWindowID ). I'm seeing this issue in macOS 15, maybe 14, but not 13.

I would like to show a nswindow at a position on screen base on height of the nswindow and its content view. I received zero width and height on macOS 15.0 and xCode 16.1 however they were returned correct width and height on previous macOS version. import Cocoa import SwiftUI class AppDelegate: NSObject, NSApplicationDelegate { private var window: NSWindow! func applicationDidFinishLaunching(_ aNotification: Notification) { window = NSWindow( contentRect: .zero, styleMask: [.miniaturizable, .closable, .resizable], backing: .buffered, defer: false) window.title = "No Storyboard Window" window.contentView = NSHostingView(rootView: ContentView()) // a swiftui view window.center() let windowFrame = window.frame print("window Frame \(windowFrame)") // print width and height zero here window.makeKeyAndOrderFront(nil) } } struct ContentView: View { var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") } .padding() } } I tried window.layoutIfNeeded() after setting contentview but it didn't work How can I get the frame after setting contentview for nswindow on macOS 15.0?

So I was trying to use an NSArrayController to bind the contents of a property , first I tried using NSDictionary and it worked great, here's what I did: @interface ViewController : NSViewController @property IBOutlet ArrayController * tableCities; @end ... @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; NSString* filePath = @"/tmp/city_test.jpeg"; NSDictionary *obj = @{@"image": [[NSImage alloc] initByReferencingFile:filePath], @"name": @"NYC", @"filePath": filePath}; NSDictionary *obj2 = @{@"image": [[NSImage alloc] initByReferencingFile:filePath], @"name": @"Chicago", @"filePath": filePath}; NSDictionary *obj3 = @{@"image": [[NSImage alloc] initByReferencingFile:filePath], @"name": @"Little Rock", @"filePath": filePath}; [_tableCities addObjects:@[obj, obj2, obj3]]; } @end Now for an NSPopUpButton, binding the Controller Key to the ArrayController and the ModelKeyPath to "name" works perfectly and the popupbutton will show the cities as I expected. But now, instead of using an NSDictionary I wanted to use a custom class for these cities along with an NSMutableArray which holds the objects of this custom class. I'm having some trouble going about this.

Hi, I have noticed a major uptick in crash reports, ever since I updated my app for macOS Sequoia. All of them have to do with NSOutlineView, and they all have a similar internal API in the crash log, which shows that the issue is something to do with the framework. They all have references to NSConcreteMapTable and _TtCs12_SwiftObject isEqual. The issue isn't reproducible, but it's reported by many different users, all on macOS15+, and it was never an issue with macOS14 or below, so I'm not sure what to do about it. Here's a couple of examples of the new crash reports: Date/Time: 2024-10-29T06:55:19.999Z Launch Time: 2024-10-29T06:50:08Z OS Version: Mac OS X 15.0.1 (24A348) Report Version: 104 Exception Type: SIGTRAP Exception Codes: TRAP_BRKPT at 0x1a98c9c90 Crashed Thread: 0 Thread 0 Crashed: 0 libswiftCore.dylib 0x00000001a98c9c90 -[_TtCs12_SwiftObject isEqual:] + 240 1 Foundation 0x0000000199ad4e0c probeGC + 408 2 Foundation 0x0000000199b01e6c -[NSConcreteMapTable removeObjectForKey:] + 76 3 AppKit 0x000000019c5966a8 _NSOVFreeRowEntry + 44 4 AppKit 0x000000019c5965c4 _NSOVRecursiveFreeChildrenAndItem + 100 5 AppKit 0x000000019c59649c _NSOVFastRemoveChildRowEntries + 260 6 AppKit 0x000000019c595d40 -[NSOutlineView reloadItem:reloadChildren:] + 1016 7 MyApp 0x0000000104b454fc CJ_CRM.MacCJSidebarViewController.compareContactsDictionariesForPublicGroups() -> () (MacCJSidebarViewController.swift:1611) 8 MyApp 0x0000000104b44518 $s20MyApp26MacCJSidebarViewControllerC27contactsChangedNotificationyySo14NSNotificationCFySo7NSTimerCYbcfU_ (MacCJSidebarViewController.swift:461) 9 MyApp 0x0000000104ba5310 $sSo7NSTimerCIeghg_ABIeyBhy_TR (<compiler-generated>:0) 10 Foundation 0x0000000199b64cfc __NSFireTimer + 100 11 CoreFoundation 0x0000000198988184 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28 12 CoreFoundation 0x0000000198987e28 __CFRunLoopDoTimer + 1008 13 CoreFoundation 0x0000000198987938 __CFRunLoopDoTimers + 352 14 CoreFoundation 0x000000019896d0f0 __CFRunLoopRun + 1852 15 CoreFoundation 0x000000019896c334 CFRunLoopRunSpecific + 568 16 HIToolbox 0x00000001a3da50cc RunCurrentEventLoopInMode + 288 17 HIToolbox 0x00000001a3daaebc ReceiveNextEventCommon + 632 18 HIToolbox 0x00000001a3dab020 _BlockUntilNextEventMatchingListInModeWithFilter + 72 19 AppKit 0x000000019c4b0a70 _DPSNextEvent + 656 20 AppKit 0x000000019cdd67b8 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 684 21 AppKit 0x000000019c4a3b7c -[NSApplication run] + 476 22 AppKit 0x000000019c47a44c NSApplicationMain + 884 23 MyApp 0x0000000104a1e26c main (main.m:24) 24 ??? 0x0000000198504274 0x0 + 0 Another one with a different trigger but same internal API: Date/Time: 2024-10-29T16:49:12.999Z Launch Time: 2024-10-29T15:51:27Z OS Version: Mac OS X 15.1 (24B83) Report Version: 104 Exception Type: SIGSEGV Exception Codes: SEGV_MAPERR at 0x4cde11282080 Crashed Thread: 0 Thread 0 Crashed: 0 libswiftCore.dylib 0x00000001a04efa1c isSubclass(swift::TargetMetadata<swift::InProcess> const*, swift::TargetMetadata<swift::InProcess> const*) + 28 1 libswiftCore.dylib 0x00000001a04ef9f8 _swift_class_isSubclass + 12 2 libswiftCore.dylib 0x00000001a04ffa9c -[_TtCs12_SwiftObject isEqual:] + 252 3 Foundation 0x00000001906b4cec probeGC + 408 4 Foundation 0x00000001906b4adc -[NSConcreteMapTable objectForKey:] + 64 5 AppKit 0x00000001930f8eec -[NSOutlineView _rowEntryForItem:requiredRowEntryLoadMask:] + 48 6 AppKit 0x00000001930f8e80 -[NSOutlineView parentForItem:] + 24 7 MyApp 0x0000000100e2faec MyApp.MacCJSidebarViewController.outlineView(_: __C.NSOutlineView, selectionIndexesForProposedSelection: Foundation.IndexSet) -> Foundation.IndexSet (MacCJSidebarViewController.swift:759) 8 MyApp 0x0000000100e30dbc @objc MyApp.MacCJSidebarViewController.outlineView(_: __C.NSOutlineView, selectionIndexesForProposedSelection: Foundation.IndexSet) -> Foundation.IndexSet (<compiler-generated>:0) 9 AppKit 0x000000019324c4e4 -[NSTableView _userSelectableRowIndexesForProposedSelection:userCanAlreadyChangeSelection:] + 288 10 AppKit 0x00000001933176c4 -[NSTableView _userSelectRowIndexes:withNewSelectedRow:] + 140 11 AppKit 0x00000001933175a0 -[NSTableView _userSelectSingleRow:] + 76 12 AppKit 0x0000000193315c8c -[NSTableView mouseDown:] + 2536 13 AppKit 0x0000000193315120 -[NSOutlineView mouseDown:] + 72 14 MyApp 0x0000000100dabb38 -[CustomNSOutlineView mouseDown:] (CustomNSOutlineView.m:180) 15 AppKit 0x000000019320d98c forwardMethod + 248 16 AppKit 0x000000019320d98c forwardMethod + 248 17 AppKit 0x0000000193213518 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3668 18 AppKit 0x000000019319f00c -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 380 19 AppKit 0x000000019319ecbc -[NSWindow(NSEventRouting) sendEvent:] + 280 20 AppKit 0x00000001939b6bf0 -[NSApplication(NSEventRouting) sendEvent:] + 1652 21 AppKit 0x00000001935c489c -[NSApplication _handleEvent:] + 56 22 AppKit 0x000000019306ab08 -[NSApplication run] + 516 23 AppKit 0x0000000193041364 NSApplicationMain + 884 24 MyApp 0x0000000100d0626c main (main.m:24) 25 ??? 0x000000018f0e4274 0x0 + 0 I just created a Feedback FB15625970. Please let me know if this is a known issue, and/or if there's any ideas out there on how I can do to avoid this. It's causing a lot of instability in my app, that wasn't there before macOS15, so something changed in the internal APIs, and hopefully there's a way to work around it.

Hello fellow developers, I’m posting this short message because I’m trying to add WeatherKit to my application, but I’m running into a problem. I have correctly declared my application on Apple’s website under Certificates, IDs & Profiles, and I have checked WeatherKit. However in Xcode, I do not have the option to add WeatherKit in Signing & Capabilities. The option doesn’t appear even though I have the Automatically manage signing box checked. What can I do to resolve this issue? Thank you for your response.

Does Cocoa have documentation that describes why this functionality is not supported? To try it out is simple, create a default application that uses Objective C in XCode, add a button that toggles the window into fullscreen and opens a modal save-as dialog at the same time. The fullscreen transition will half-complete but kick the application out of fullscreen instantly. Is this expected behavior? The test application is attached below. The XCode test application

My app (Find Any File) behaves strangely on Sequoia: When the code calls the window's makeFirstResponder on the NSSearchField item in the window's toolbar, and if the toolbar is currently showing the small loupe icon, it should: Switch to showing an NSTextView in place of the loupe icon Make the text view the first responder so that the user can type in it. This used to work reliably before macOS 15, but in 15.0.1 and also the current 15.1 beta it often misses step 1 or or step 2. When it misses step 1, then the window's first responder reports back to it's set to the text field, but its frame is very narrow (width is 4 isntead of 192). And when it misses step 2, then the textview is visible but hasn't gained focus - instead, the main window is the first responder. This happening is quite random. I find no pattern. Even worse, after calling makeFirstResponder, if I check the window's first responder, it's always the expected NSTextView, even if I delay the check with dispatch_async(dispatch_get_main_queue(), ^{ …. So I cannot even reliably detect when this goes wrong in order to act on it. Has anyone else noticed this to happen in their apps?

I have Swift code that accepts dragging a lowercase string from the TextEdit app. On the first drop, the text is accepted as is but, on the second drop, the first words are capitalised. Any ideas?