I'm testing code that uses NSMetadataQuery and I noticed some odd behavior. I run a query where the search scope is set to my Desktop directory. The predicate is set to search for a file name that contains 'we' (display name to be precise: kMDItemDisplayName). And I get no results. So I stop the app from Xcode then I create a new folder on the Desktop and name it we exactly. Then I rerun my app and start the query again - still no results. Unfortunately none of the Spotlight based APIs I'm using report errors. There is no delegate method -queryDidFailWithError: or anything like that. So in another place my app uses the lower level MD prefixed APIs in Core Services to read file metadata and I notice that those APIs are failing as well. Specifically I try to load metadata for a PNG image. I create an MDItemRef via MDItemCreateWithURL (and I do get an MDItemRef). Then I call MDItemCopyAttributes with the MDItemRef and an array of metadata attribute names: CFDictionaryRef fetchedData = MDItemCopyAttributes(mdItem, attributeNames); I step through it in the debugger and fetchedData is NULL. Since there is no error handling APIs available for any of this my app just silently fails. I have Console.app open when I step through MDItemCopyAttributes call in the debugger and this logs out every time: com.apple.spotlightserver Bad checksum on fetch attributes reply from store, 0x123ea456.... FWIW I do not have Spotlight indexing turned off on my system. Also jumping to Finder I'm experiencing the same failures (metadata isn't populating and the Desktop search for we produces no results). Actually on further inspection it looks like all searches are producing no results. Spotlight appears to be in a broken state system wide. I'm pretty sure a system restart will 'fix' it - until it starts occurring again. But for obvious reasons I'd like to avoid releasing a feature in my app that results in this kind of experience. Is there anything I can do on my end to workaround or avoid this issue? And tips or advice would be greatly appreciated.

I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.

If the user prohibits Spotlight in System Settings for a given directory and I set that URL as one of the search scopes on an NSMetadataQuery- I believe the query will return no results. Is there an API for detecting Spotlight unavailability? Ideally I would like to display something in the UI for this kind of situation to explain why a feature built on top of this API is not working.

I'm testing iAP in a sandbox account (as configured in App Store Connect under 'Sandbox Testers'). So the in app purchase works. Cool. But I wanted to retry it. So I cleared the purchase history (both in App Store Connect and on my iPad in the 'Developer' section in Settings). But when I relaunch my app the purchase still validates and my app displays the item as 'unlocked'. Figure the receipt must still be cached so I nuke the app and completely reinstall it but it appears StoreKit is still getting the receipt and it isn't being cleared because my app is displaying it as 'purchased.' Also tried rebooting the iPad. But the sandbox purchase doesn't clear. I just did a sandbox test since it is closer to real life than StoreKit Configuration so I just wanted to do it a few times to make sure all is good but making a burner test account for every purchase is kind of tiresome. Anyone know of a workaround? I might just declare victory and go back to StoreKit Configuration.

I have an NSTextView that displays several NSTextAttachmentCells. I notice this weird behavior. Sometimes if I just click in an empty area of the text view the entire text content selects. So I implemented the delegate method to catch it: - (NSRange)textView:(NSTextView *)textView willChangeSelectionFromCharacterRange:(NSRange)oldSelectedCharRange toCharacterRange:(NSRange)newSelectedCharRange { if (newSelectedCharRange.length > 1 && newSelectedCharRange.length > oldSelectedCharRange.length) { NSEvent *currentEvent = NSApp.currentEvent; NSLog(@"Selection expanded from %@ to %@. Event type: %ld, click count: %ld, modifier flags: %lu, current selected ranges: %@", NSStringFromRange(oldSelectedCharRange), NSStringFromRange(newSelectedCharRange), (long)currentEvent.type, (long)currentEvent.clickCount, (unsigned long)currentEvent.modifierFlags, self.selectedRanges); // put a break point here. } return newSelectedCharRange; } And I reproduced the issue and this logs out: Selection expanded from {0, 0} to {0, 6}. Event type: 2, click count: 1, modifier flags: 0, current selected ranges: ( "NSRange: {0, 6} Click count is only 1 so I didn't accidentally triple click. I know on Golden Gate use of NSEvent.currentEvent isn't the way (but I'm not there yet). A simple workaround would be to block the selection right here in the delegate method when clickCount != 3 (but again I know NSEvent.currentEvent in Golden Gate won't be reliable). Anyone run into this and have any ideas? It seems to happen after I did a triple click in the text view at some point previously (but not this click). So I got the feeling that maybe the text view isn't resetting some private properties and is treating this single click as a triple click. But I really don't know. Edit: Hmm maybe it has nothing to do with a previous triple click. May have to do with text selection not accounting for the geometry of the NSTextAttachmentCells. Not sure. But I still have to figure out a way to workaround this because a random select all is really annoying! Call stack looks like: ** -[MyTextView textView:willChangeSelectionFromCharacterRange:toCharacterRange:] at MyTextView.m -[NSTextView(NSSharing) setSelectedRanges:affinity:stillSelecting:] () -[MyTextView setSelectedRanges:affinity:stillSelecting:] MyTextView.m +[NSInputAnalytics(TrackedActionsManager) allowActionTrackingAnalyticsWithName:forAction:] () n -[NSTextView mouseDown:] () -[MyTextView mouseDown:] ** If you're wondering what my -mouseDown: override does it just calls super. I realize this is not a whole lot to go on but any help would be appreciated.

I'm working on this UI where I present a popover and user fills in some brief information. There are various buttons and a single editable text field in the UI. When 'Full Keyboard access' is disabled in System Settings and the popover is presented the editable NSTextField is the initial first responder and the user can begin typing immediately. This is the behavior that I expect and want. Now when full keyboard access is enabled the text field does not become the immediate first responder (and none of the buttons in the popover have 'focus' state either) so initially hitting a key does nothing. To me this feels unnatural and is not the expected behavior. To interact with the text field with full keyboard access I have to do one of the following: Use the mouse to click the text field (which is an extra step). Or Press tab several times to move 'Focus' (initially no button has it) all the way down to the textfield. Both requirements slow down the user. Is this expected behavior? Shouldn't the initial key view follow the natural first responder (in this case an editable text field) and the user can tab away from that starting location? instead nobody has key focus when the popover is first presented until tabbing is initiated. I can currently 'workaround' this it seems by manually setting the text field as first responder in viewDidAppear [self.view.window makeFirstResponder:self.theTextField]; Then the text field accepts keyboard input immediately. But when 'Full keyboard access' is disabled (which I assume is the more typical configuration) this is not required, the text field just gets first responder by default. If this is not the expected behavior let me know and I may file a feedback.

I have this local agent using Qwen 3.6 (the version that is ~17 GB). Last time I tried using this a couple months ago it worked ok. Now the agent frequently does not know how to edit a file. It takes its proposed changes and completely overwrites the entire source file with the change instead of just modifying the portion of the source code. Sometimes the agent thinks it doesn't have permission to make a change and wants me to copy and paste code. Is there an Xcode skill provided somewhere that I can use with the Agent so it knows how to work in this environment properly? Currently I have it set up via "Chat" with "Tools Enabled" and "Automatically apply changes" is on.

I have a localized description of an app. I'm trying to add it in App Store Connect. Every time I save a red exclamation point is displayed with no explanation. Then all my edits disappear on reload. So I try to add a different screenshot in the new language before saving. But that fails with a red exclamation point as well but this time with an explanation: "Please save new locales before uploading screenshots or previews." Well I can't because of the first failure. In the web inspector I can see the following error: "status" : "400", "code" : "PARAMETER_ERROR.REQUIRED", "detail" : "The parameter 'filter[appStoreVersion]' is required but was not provided",

I'll try to ask a question that makes sense this time :) . I'm using the following method on NSFileManager: (BOOL) getRelationship:(NSURLRelationship *) outRelationship ofDirectoryAtURL:(NSURL *) directoryURL toItemAtURL:(NSURL *) otherURL error:(NSError * *) error; Sets 'outRelationship' to NSURLRelationshipContains if the directory at 'directoryURL' directly or indirectly contains the item at 'otherURL', meaning 'directoryURL' is found while enumerating parent URLs starting from 'otherURL'. Sets 'outRelationship' to NSURLRelationshipSame if 'directoryURL' and 'otherURL' locate the same item, meaning they have the same NSURLFileResourceIdentifierKey value. If 'directoryURL' is not a directory, or does not contain 'otherURL' and they do not locate the same file, then sets 'outRelationship' to NSURLRelationshipOther. If an error occurs, returns NO and sets 'error'. So this method falsely returns NSURLRelationshipSame for different directories. One is empty, one is not. Really weird behavior. Two file path urls pointing to two different file paths have the same NSURLFileResourceIdentifierKey? Could it be related to https://developer.apple.com/forums/thread/813641 ? One url in the check lived at the same file path as the other url at one time (but no longer does). No symlinks or anything going on. Just plain directory urls. And YES calling -removeCachedResourceValueForKey: with NSURLFileResourceIdentifierKey causes proper result of NSURLRelationshipOther to be returned. And I'm doing the check on a background queue.

I'm trying to use NSTokenField for the first time. So my custom 'representedObject' for a token has additional model data tied to it (not just the editing/display string). I noticed when I edit an existing token, type text, and hit the enter key I get the following delegate callback: - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString; This same delegate method is called when I type a brand new token. Is there a way to distinguish if I'm editing a token vs. creating a new one? My expectation is to be able to do something like this (made up enhancement): - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString atIndex:(NSUInteger)existingTokenIndex { if (existingTokenIndex == NSNotFound) { // Token is new, create a new instance MyTokenObject *newToken = //create and configure. return newToken; } else { // This would update the editing string but wouldn't discard existing data held by the token. MyTokenObject *tokenObj = [self existingTokenAtIndex:existingTokenIndex]; tokenObj.editingString = editingString; return tokenObj; } }

I have an NSTextView subclass and implements drag and drop for custom draggable data, so I override -writablePasteboardTypes and add my own type as described in the header file: // Returns an array of pasteboard types that can be provided from the current selection. Overriders should copy the result from super and add their own new types. @property (readonly, copy) NSArray<NSPasteboardType> *writablePasteboardTypes; Now my textview also accepts the drop. Drag and drop can be used to move the custom data to a different location in the text view's character range. Like grabbing a block of text and moving it. So I accept the drop in -readSelectionFromPasteboard:type: I have a variable I cache at the start of dragging like: _myDraggingItem = // Set at the start of dragging. Then when I accept the drop I just use _myDraggingItem to move it to the drop location in the text view. I don't need to actually serialize the entire object and write it on the pasteboard I can just use _myDraggingItem to move from the source location to destination location. This is local only drag and drop. it works, except when the mouse leaves the text view briefly during the dragging session. This is because I override NSTextView's - (void)cleanUpAfterDragOperation // If you set up persistent state that should go away when the drag operation finishes, you can clean it up here. Such state is usually set up in -dragOperationForDraggingInfo:type:. You should probably never need to call this except to message super in an override. - (void)cleanUpAfterDragOperation; So documentation indicates -cleanUpAfterDragOperation is for clean up after drag operation finishes so I nil out _myDraggingItem here. But -cleanUpAfterDragOperation is getting called from [NSDragDestination _draggingExited]. -draggingExited: means the drag location moved outside the view it does not mean that the dragging session is over. The drag can move back inside the view after briefly exiting, so this isn't a usable place to clean up state tied to the dragging session as the header file indicates. I must override -draggingEnded: instead. If that sounds like a bug let me know.

I typically avoid NSMetadataQuery because I always found the API to be a bit peculiar but for this feature I'm working on I'm not sure it is worth the effort to implement this functionality in my own way. Plus it seems pretty fast. What I find strange is I set the operationQueue to get notifications off the main thread. But also when I set the queue the system yells at me anytime I make a change to NSMetadataQuery that alters the query. So I found this recommendation (requirement) in the documentation : NSMetadataQuery *query = // Initialize and set up a query [query.operationQueue addOperationWithBlock:^{ [query startQuery]; }]; I find this API design to be odd, but maybe I'm just weird. So there are a bunch of properties that can be changed while the query is already running (predicate etc.) and they implicitly stop/start the query and it seems all these calls need to be routed through the query.operationQueue like above? For example if I change the predicate while the query is already started it seems I have to: [query.operationQueue addOperationWithBlock:^{ query.predicate = predicate; }]; The query already knows its operationQueue. Why does the caller have to plumb these calls through the operation queue manually? -stopQuery does not result in an error/warning when called off the operationQueue but is doing so safe? Or do I have to do: [query.operationQueue addOperationWithBlock:^{ [query stopQuery]; }]; Really what I was expecting was to provide a queue for the notification callbacks. I wasn't expecting to manually have to confine the query to its own queue.

I probably should know the answer to this but I don't, so I'll ask. When I enable state restoration and have like three windows open, and I quit the app (via Quit menu, not 'Stop In Xcode') the following happens: -NSApplication calls _closeForTermination on all the windows and this causes state restoration to fail to restore these open windows on next app launch. This behavior is not aligned with the behavior of apps like Mail. If I have two "Viewer Windows" open in Mail and I quit the app, when I relaunch the two viewer windows are restored. I can of course track this and write data to restore for these auto closed window myself but shouldn't there be an easy way to opt in to this behavior?

So after binding to NSBrowser selectionIndexPaths: https://developer.apple.com/library/archive/documentation/Cocoa/Reference/CocoaBindingsRef/BindingsText/NSBrowser.html this causes NSBrowser to do some weird stuff that seems completely unrelated to this particular binding. It starts calling NSBrowserCell methods on my cells but my cell is not a NSBrowserCell. My cell is actually a subclass of NSTextFieldCell. But NSBrowser starts sending setIsLeaf: (which I don't implement). In any case if I implement the -setLeaf: that solves that unrecognized selector, but now my cells don't draw titles. Not sure why binding to selectionIndexPaths causes this behavior? The cell stuff seems unrelated to this particular binding. I am of course using the newer but still pretty old item based APIs... do these bindings only support using NSMatrix? I do set the binding after calling -setCellClass: but makes no difference. I also just tried overriding -setSelectionIndexPaths: but NSBrowser does not use the setter.

I'm trying to get the count of how many windows an iPadOS app has 'open' (open from the user's perspective in the app switcher). This is for the sake of determining whether I should show or hide a button that takes action on every window (if there is only 1 window, the button will be hidden). According to the documentation the proper API for this is this property on UIApplication: // All of the representations that currently have connected UIScene instances or had their sessions persisted by the system (ex: visible in iOS' switcher) @property(nonatomic, readonly) NSSet<UISceneSession *> *openSessions So I print the count (only sessions with role UIWindowSceneSessionRoleApplication) when scenes are added/removed etc via appropriate lifecycle notifications like -sceneDidDisconnect: -sceneDidBecomeActive: and so forth. What I noticed is when I add a new window scene, the count increases by one so cool, that works. But when I kill a window in the App switcher the count does not decrease. I can end up in a situation where the app has only 1 window in the app switcher but the count prints 8, so this is wrong. So am I using the wrong API? How can I just get scene count in the app switcher? The documentation makes it seem like using 'connectedScenes' for this would be wrong because that property is not supposed to include 'archived' scenes in the app switcher (or is it?)? I do know I can't take action on an archived scene 'yet' but I would still show the button because whether or not the scene is archived in the app switcher is a fact that remains hidden from the user. My code will take care of that later after state restoration. Is iPadOS 26 potentially keeping scene sessions open for too long? Is there a good way to reliably detect how many scenes I have in the app switcher? Is a scene session explicitly killed by the user supposed to remain the .openSessions set? I am testing on the Simulator FWIW. iPad 26.5.