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 seeing a reproducible UI bug with Spotlight on macOS 27 RC (26A428). The issue has been present since at least build 26A5416b (Developer Beta 6 / Public Beta 4), persisted through subsequent beta releases, and is still reproducible on RC 26A428. When I open Spotlight using the new Search or Ask interface and begin typing, the entered query text can become completely invisible from approximately the second character onward, even though Spotlight continues searching and displaying results normally. The interesting part is that the issue seems tied to Spotlight updating its search results. For example: Open Spotlight. Type a character that quickly matches something on the Mac. Continue typing. Once the results update, the query text becomes invisible. If I type random characters extremely quickly, before Spotlight has time to return a result for the first few characters, the text may remain visible. Another useful detail: after the query text disappears, pressing Delete/Backspace causes it to become visible again. The search itself is still functioning, the problem appears to be with rendering or state updates in the new Siri-integrated Spotlight query field, rather than with Spotlight search/indexing itself. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by user preferences, caches, login items, or third-party software. I submitted a screen recording through Feedback Assistant that clearly shows the text disappearing as results update. Feedback: FB24462893 Is anyone else seeing this on the RC? The correlation between the text disappearing and the results UI updating makes me suspect a rendering/state-update issue in the new Spotlight interface.

iOS 27, See image below. From top to bottom I'm using: displayName containerDisplayName contentDescription I haven't found a way to remove the transaction amount from my containerDisplayName and display it in the top right with some other CSSearchableItemAttributeSet value. Is it even possible?

I'm trying to understand the intended relationship between OpenIntent and the new .system.open App Intent schema introduced in iOS 27. From the documentation: OpenIntent (available since iOS 16) is described as an intent that opens an associated item. iOS 27 introduces the .system.open schema, which also appears to represent opening an entity or piece of app content. My questions are: For an app that supports iOS 27+, is .system.open intended to replace OpenIntent, or do the two serve different purposes? For apps that support both iOS 26 and iOS 27+, is the recommended approach to have two structs that implement the same opening logic, one with @AppIntent(schema: .system.open) and the other implementing the OpenIntent protocol? Thanks! References: open protocol OpenIntent

I’m trying to understand the intended relationship between IndexedEntity.attributeSet, defaultAttributeSet, and displayRepresentation. For example: struct TrailEntity: IndexedEntity { var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "(trail.name)", subtitle: "(trail.location)" ) } var attributeSet: CSSearchableItemAttributeSet { let attributes = CSSearchableItemAttributeSet() attributes.keywords = trail.keywords return attributes } } Should attributeSet instead be initialized with defaultAttributeSet and then have the additional attributes assigned to it? var attributeSet: CSSearchableItemAttributeSet { let attributes = defaultAttributeSet attributes.keywords = trail.keywords return attributes } The documentation says defaultAttributeSet contains values derived from displayRepresentation, but it also describes precedence between displayRepresentation and attributeSet, which suggests Spotlight reads them separately during indexing. So what is the intended pattern? Does overriding attributeSet require including defaultAttributeSet to preserve title/subtitle/image metadata, or is attributeSet only meant for additional Core Spotlight metadata? If the latter, what is the intended use case for overriding or directly using defaultAttributeSet?

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.

Hi, it seems that something in OS27b3 changed regarding Core Spotlight: Whatever I try, Siri and Spotlight only seem to find the text inside the title or displayName attribute. But attributes like textContent or contentDescription or keywords seem to be ignored. Those attributes are still found, when I do a manual search using CSUserQuery or using the AppEntityDefinition.spotlightQuery(_:) in App Intent Testing. I have already filed a Feedback – but wonder whether anyone else is having this issue? FB23635795 Thanks, Friedrich

Related feedback: FB16995719 This is an old one, that has not been solved in iOS 27. This is very annoying since iOS 27 brings new AI stuff to Spotlight, that can't be used because of this bug. Jennifer has acknowledged this bug during a one-on-one session last year (WWDC25) where we carefully reviewed my code. I simply would like that the app documents content to be indexed. It's simple text that I pass to textContent. ------- try await CSSearchableIndex.default().indexAppEntities([entity]) // How the indexing is called ------- @available(iOS 18, *) /// The IndexedEntity struct DocumentEntity: IndexedEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation { TypeDisplayRepresentation(name: LocalizedStringResource("INTENT_DOCUMENT_DISPLAY_REP")) } static let defaultQuery = DocumentQuery() // A unique identifier for each document let id: NSManagedObjectID let title: String? let thumbnailData: Data? // The document's text to be indexed let textContent: String? let pageCount: Int // A display representation for UI purposes. var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "\(title ?? "")", image: thumbnailData == nil ? nil : .init(data: thumbnailData!) // INDEXED successfully through the use of @available(iOS 18, *) struct DocumentEntity: IndexedEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation { TypeDisplayRepresentation(name: LocalizedStringResource("INTENT_DOCUMENT_DISPLAY_REP")) } static let defaultQuery = DocumentQuery() // A unique identifier for each document (for example, your NSManagedObject's objectID). let id: NSManagedObjectID let title: String? let thumbnailData: Data? // The OCR text to be indexed let textContent: String? let pageCount: Int // A display representation for UI purposes. var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "\(title ?? "")", image: thumbnailData == nil ? nil : .init(data: thumbnailData!) ) } } ) } } @available(iOS 18, *) extension DocumentEntity { // The attributeSet for Spotlight var attributeSet: CSSearchableItemAttributeSet { let attributeSet = defaultAttributeSet attributeSet.title = title attributeSet.displayName = title // THIS ONE IS INDEXED attributeSet.contentType = UTType.plainText.identifier attributeSet.textContent = textContent // THIS ONE IS **NOT** INDEXED attributeSet.pageCount = NSNumber(integerLiteral: pageCount) // THIS ONE IS INDEXED attributeSet.thumbnailData = thumbnailData attributeSet.creator = Constants.APP_NAME return attributeSet } } Related: https://discussions.apple.com/thread/256061571

Hello, In my app, I want to create a CSSearchableItem using the initialiser that accepts an appEntity so I can update the item expirationDate when indexing. This initialiser is marked as iOS 18.0+ but as soon as I launch my app, it crashes. I filed a feedback: FB23270394 Can you help? Thank you Axel dyld[62169]: Symbol not found: _$s10AppIntents13IndexedEntityPAAE15hideInSpotlightSbvg Referenced from: <150E43FA-D9F4-3DF3-88C1-86E3DA3B272B> /Users/axel/Library/Developer/CoreSimulator/Devices/2C645A0F-45E5-429E-82EE-0C71D83407E3/data/Containers/Bundle/Application/18F00389-5CE8-49A2-883A-CDA38DDB03C4/Skipper.app/Skipper.debug.dylib Expected in: <F5744EDB-79CF-333C-A49A-8E9C5C3ACD10> /Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/AppIntents.framework/AppIntents Symbol not found: _$s10AppIntents13IndexedEntityPAAE15hideInSpotlightSbvg Referenced from: <150E43FA-D9F4-3DF3-88C1-86E3DA3B272B> /Users/axel/Library/Developer/CoreSimulator/Devices/2C645A0F-45E5-429E-82EE-0C71D83407E3/data/Containers/Bundle/Application/18F00389-5CE8-49A2-883A-CDA38DDB03C4/Skipper.app/Skipper.debug.dylib Expected in: <F5744EDB-79CF-333C-A49A-8E9C5C3ACD10> /Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/AppIntents.framework/AppIntents dyld config: DYLD_ROOT_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot DYLD_LIBRARY_PATH=/Users/axel/Library/Developer/Xcode/DerivedData/Skipper-gayhthkwqznqqkeoqazrmncvolcq/Build/Products/Debug-iphonesimulator DYLD_INSERT_LIBRARIES=/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libLogRedirect.dylib:/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libViewDebuggerSupport.dylib DYLD_FRAMEWORK_PATH=/Users/axel/Library/Developer/Xcode/DerivedData/Skipper-gayhthkwqznqqkeoqazrmncvolcq/Build/Products/Debug-iphonesimulator:/Users/axel/Library/Developer/Xcode/DerivedData/Skipper-gayhthkwqznqqkeoqazrmncvolcq/Build/Products/Debug-iphonesimulator/PackageFrameworks DYLD_FALLBACK_FRAMEWORK_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib Debug session ended with code 9: killed

Hello everyone, I am using an iPhone 11 Pro running iOS 27 Beta 1. Since installing the beta, the message "Indexing in Progress" has remained active for approximately 7 days and never completes. I have already tried: Restarting the iPhone multiple times Keeping the device connected to power overnight Keeping Wi-Fi enabled Disabling Low Power Mode Ensuring enough free storage space Despite trying all of these steps, the indexing process is still stuck and does not finish. Is anyone else experiencing the same issue on iOS 27 Beta 1? At this point, I believe this may be a bug affecting Spotlight/Search indexing. Any feedback would be appreciated. Thank you.

In visionOS 2, the system search displays the icon of each App Entity registered. It used to work up to visionOS 26 beta 7. But since visionOS 26 beta 8, visionOS 26.x , and still in the current visionOS 27 Beta 2 the system search no longer display the right icon. Instead it displays the icon of an AppShortcut declared by the source code which uses the AppEntities. This does not help the users to find the right AppEntity in a search with multiple results as they all have the same AppShortcut icon. This "bug" also make the search result differ from the experience with iOS and iPadOS which display each AppEntity icon. You can use the Apple sample to see this bug on visionOS 27 Beta 2 and 26. Accelerating app interactions with App Intents AppEntities are an important part of Apple Intelligence, the system integration is really important for a great user experience. FB19915478

Hello, I’m indexing content in my app using Core Spotlight. On iOS, I notice that I can only search using the title or displayName even if I index more content in Spotlight using CSSearchableItem or IndexedEntity. On macOS, I can search for any content or attributes of the CSSearchableItem or IndexedEntity. See attached screenshots (the item id on iOS is 708 and the item id on macOS is 741). On both platforms, the content can be fetched using a CSSearchQuery. I filed a feedback with an attached project: FB23317556 Regards Axel

Hello, I’m using Core Spotlight in my app. I notice that if I use CSSearchableIndex to index the content, it cannot be found in Spotlight on macOS 27. if I use instead an IndexedEntity (from the AppIntents framework), the content can be found on macOS 27. The content seems to correctly be saved because I can fetch the content using a CSSearchQuery in both cases. I filed a feedback with a project attached: FB23317414 Regards, Axel

I'm trying to get an NSMetadataQuery to work using an NSPredicate build with: [NSPredicate predicateFromMetadataQueryString:@"InRange(kMDItemFSCreationDate,$time.today,$time.today(+1))"] That string is the one I copied from Finder's Get Info window after saving a search of "Created is Today". It at least parses and runs without exceptions, but the results are totally wrong. It only returns files created on 12/31/2000. I've tried dozens of different attempts at building a predicate that uses these $time functions, but they all fail parsing and throw an exception. What I really need to be able to do is build the predicate with a format string, because the attribute is stored in a property: [NSPredicate predicateWithFormat:@"InRange(%K,$time.today,$time.today(+1))", self.attr]; That throws an exception. [NSPredicate predicateFromMetadataQueryString:[NSString stringWithFormat:@"InRange(%@,$time.today,$time.today(+1))", self.attr]]; That does not throw an exception, but it gives the same 12/31/2000 results.

While running my application on macOS 27 today, it crashed in a strange way. The backtrace for the thread that crashed looks like it was some kind of Spotlight search indexing thread. The strange part is that my app makes no use of Spotlight and is not mentioned anywhere in the Spotlight section of System Prefs. Here is the backtrace, maybe something in here is enough of a clue as to what happened and why my App was running a Spotlight-related thread. This was on 27 beta 1 (26A5353q), and the app is a video streaming app that uses both Qt 6.11.1 and SDL 3 and was rendering some frames with Metal at the time. The most unusual thing in the backtrace is the existence of ObjC params spelled both updatingDonationProgress as well as updatingDonationProgres. Thread 8 Crashed:: Dispatch queue: com.apple.root.user-initiated-qos 0 libobjcMsgSend.dylib 0x19e7f0808 objc_msgSend + 8 1 CoreFoundation 0x1970fe300 __NSSetM_new + 368 2 CoreFoundation 0x19711cd64 -[NSSet initWithArray:range:copyItems:] + 304 3 LaunchServices 0x1976bc144 -[_LSLocalizedStringRecord _missingBundleLocsWithContext:tableID:unitID:unitBytes:] + 104 4 LaunchServices 0x197700628 objc_object* __strong __LSRECORD_GETTER__<objc_object* __strong>(LSRecord*, objc_selector*, objc_selector*) + 288 5 LaunchServices 0x1976bc854 -[_LSLocalizedStringRecord _detachFromContext:tableID:unitID:unitBytes:] + 68 6 LaunchServices 0x197701cac -[LSRecord detach] + 240 7 LaunchServices 0x197773720 -[UTTypeRecord _detachFromContext:tableID:unitID:unitBytes:] + 68 8 LaunchServices 0x1977756fc -[_UTDeclaredTypeRecord _detachFromContext:tableID:unitID:unitBytes:] + 52 9 LaunchServices 0x197701cac -[LSRecord detach] + 240 10 LaunchServices 0x197702c74 +[LSRecord(LSDetachable) resolveAllPropertiesOfRecords:count:andDetachOnQueue:] + 392 11 UniformTypeIdentifiers 0x19cd1bc80 +[UTType _typeWithTypeRecord:detachTypeRecord:findConstant:installInConstant:] + 232 12 UniformTypeIdentifiers 0x19cd19d38 _UTTypeGetForIdentifier(NSString*, bool) + 148 13 SpotlightKnowledge 0x2a7596adc -[SKGProcessor(EmbeddingsUtils) needsEmbeddingsForRecord:bundleID:] + 604 14 SpotlightKnowledge 0x2a7590bd4 -[SKGAttributeProcessor processorAttributesForRecord:bundleID:protectionClass:isUpdate:] + 500 15 CoreSpotlight 0x1a79bfa84 -[CSSearchableItemAttributeSet(CSPrivateAttributes) _standardizeProcessorAttributesForBundle:protectionClass:isUpdate:] + 292 16 CoreSpotlight 0x1a79b11a4 -[CSSearchableItem(Internal) standardizeAttributesForBundle:protectionClass:] + 780 17 CoreSpotlight 0x1a799f218 __39-[CSSearchableIndex _standardizeItems:]_block_invoke + 248 18 CoreFoundation 0x19712e56c __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 19 CoreFoundation 0x197277604 ____NSCollectionHandleConcurrentEnumerationIfSpecified_block_invoke + 116 20 libdispatch.dylib 0x196ed45d4 _dispatch_client_callout2 + 16 21 libdispatch.dylib 0x196ecf2d4 _dispatch_apply_invoke3 + 336 22 libdispatch.dylib 0x196ed45bc _dispatch_client_callout + 16 23 libdispatch.dylib 0x196ebd624 _dispatch_once_callout + 32 24 libdispatch.dylib 0x196ecf974 _dispatch_apply_invoke_and_wait + 364 25 libdispatch.dylib 0x196ecea70 _dispatch_apply_with_attr_f + 1312 26 libdispatch.dylib 0x196ecebf4 dispatch_apply + 96 27 CoreFoundation 0x197277548 __NSCollectionHandleConcurrentEnumerationIfSpecified + 184 28 CoreFoundation 0x19712e350 -[__NSArrayM enumerateObjectsWithOptions:usingBlock:] + 188 29 CoreSpotlight 0x1a78d99b4 -[CSSearchableIndex _standardizeItems:] + 144 30 CoreSpotlight 0x1a799d4b0 -[CSSearchableIndex indexSearchableItems:deleteSearchableItemsWithIdentifiers:clientState:expectedClientState:clientStateName:updatingDonationProgress:protectionClass:forBundleID:options:reason:completionHandler:] + 824 31 CoreSpotlight 0x1a799d024 -[CSSearchableIndex indexSearchableItems:deleteSearchableItemsWithIdentifiers:clientState:expectedClientState:updatingDonationProgress:protectionClass:forBundleID:options:reason:completionHandler:] + 52 32 CoreSpotlight 0x1a799ca64 __131-[CSSearchableIndex endIndexBatchWithExpectedClientState:newClientState:critical:reason:updatingDonationProgres:completionHandler:]_block_invoke + 188 33 libsystem_trace.dylib 0x196d957e8 _os_activity_initiate_impl + 64 34 CoreSpotlight 0x1a799c91c -[CSSearchableIndex endIndexBatchWithExpectedClientState:newClientState:critical:reason:updatingDonationProgres:completionHandler:] + 448 35 AppKit 0x19c7a3568 0x19b5b6000 + 18797928 36 AppKit 0x19c4d8584 0x19b5b6000 + 15869316 37 libdispatch.dylib 0x196ebaa30 _dispatch_call_block_and_release + 32 38 libdispatch.dylib 0x196ed45bc _dispatch_client_callout + 16 39 libdispatch.dylib 0x196ec3018 _dispatch_lane_serial_drain + 744 40 libdispatch.dylib 0x196ec3b4c _dispatch_lane_invoke + 448 41 libdispatch.dylib 0x196ecdf70 _dispatch_root_queue_drain_deferred_wlh + 284 42 libdispatch.dylib 0x196ecd874 _dispatch_workloop_worker_thread + 720 43 libsystem_pthread.dylib 0x197076f78 _pthread_wqthread + 292 44 libsystem_pthread.dylib 0x197075cc4 start_wqthread + 8

I Check my Index, sing progress on my iPhone 16 with my Mac console and it is stuck at 86% and I made a Check so I checkt the Progress yesterday and Charged it over Night also it was in a Wi-Fi Bad It no progress it’s still at 86%

Using SpotlightSearchTool with a custom LanguageModel backend (Apple’s ChatCompletionsLanguageModel from foundation-models-utilities, pointed at an OpenAI-compatible server), every tool call fails with ToolCallError → "Failed to parse generated content." The model follows the tool’s documented "Call format" and emits { root, modelComposition, … }. But the generated parameters schema (FullArguments) requires { "query": { "type": "search", "value": { root, modelComposition, … } } }. Query is a QueryType union and a search must be wrapped in DiscriminatedSearch. Wrapping the args manually makes it parse and search correctly. So the description omits the query + type:"search" envelope the schema demands, which makes the tool uninvokable by any model that follows the documentation (it presumably works only with the on-device model trained on the real format). Is this a known issue / intended? Anyone gotten SpotlightSearchTool working with a non-Apple model? Secondary: CoreSpotlightSource.fetchAttributes seems to have no effect on returned attributes. kMDItemDescription only comes back when the in-query fetchAttributes requests it. Bug or expected?

Hello, I'm facing an unusual App Store Search issue and would appreciate guidance from Apple staff or developers who have experienced something similar. App Details App Name: Logistos – Logistics Platform Apple ID: 6759841195 Category: Business Availability: Available in all supported storefronts, including India Publicly available for: More than 2 months Latest version: Released and live for more than 5 days Issue The app is accessible through its direct App Store URL and is indexed by Google Search. However, it does not appear in App Store Search results. I have tested the following search terms on multiple devices and storefronts: Logistos Logistos – Logistics Platform Logistos Logistics Platform 6759841195 (Apple ID) In all cases, the app does not appear in the search results. Additional Information The app name contains "Logistos". The subtitle is "Logistics & Shipment Tracking". The keywords include "logistos". Metadata changes have already been released and enough time has passed for propagation. App Store Analytics shows the app is receiving impressions, product page views, and downloads. Direct App Store links work normally. I have already opened a support case with Apple Developer Support. Case ID: 102908696756 Has anyone encountered a similar App Store Search indexing issue? Could this indicate that the app requires manual reindexing by Apple? Any guidance would be greatly appreciated. Thank you.

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.

On macOS Tahoe 26.5 and happening since 26.0 each time I search for document inside iCloud I get a jetsam event.