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%

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.

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

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.

We’re seeing a change in Spotlight search behavior on iOS 17 and later: Observation: User‑visible keywords we index (e.g. via Core Spotlight / CSSearchableItemAttributeSet with keywords) only start appearing in Spotlight suggestions after the user has typed more than 3 characters. With 1–3 characters, our app’s content often doesn’t show up at all, even when it clearly matches. Before iOS 17: The same indexed content could appear with fewer characters (e.g. 1–3 characters). Environment: Reproduced on multiple devices running iOS 17.x / 18.x; behavior is consistent. We’d like to confirm: Is this a documented change in iOS 17 (e.g. minimum character threshold for third‑party Spotlight results)? If yes, where is it documented? If it’s not intentional, could this be treated as a bug and considered for a fix in a future release? We’re happy to provide a sample project or more detail if that would help. Thank you.

Problems searching in mail after upgrade to Tahoe 26.4 Beta (25E5218f). Removing the index files and requesting rebuild results in a hung rebuild process. In the activity monitor I see Indexing... and a bar that is stuck at 0%. I have rebooted and restarted mail. No change. I was able to rebuild the spotlight search, and it is working properly.

Apple has repeatedly ignored my reports about a critical privacy issue in Spotlight on macOS 26, and the problem persists in version 26.3 RC. This is not a minor glitch, it is a fundamental breach of user trust and privacy. Several aspects of Spotlight fail to respect user settings: • Hidden apps still exposed: In the Apps section (Cmd+1), Spotlight continues to display apps marked with the hidden flag, even though they should remain invisible. • Clipboard reactivation: The clipboard feature repeatedly turns itself back on after logout or restart, despite being explicitly disabled by the user. • Excluded files revealed: Most concerning, Spotlight exposes files in Suggestions and Recents (Cmd+3) even when those files are explicitly excluded under System Settings > Spotlight > Search Privacy. This behavior directly violates user expectations and system settings. It is not only a major privacy issue but also a security risk, since sensitive files can be surfaced without consent. Apple must address this immediately. Users rely on Spotlight to respect their privacy configurations, and the current behavior undermines both trust and security.

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.

I remember this integration being demoed at WWDC25. Ability to trigger app intent for iOS application from Spotlight search on MacOS. How Do I extend my iOS Application to be able to do this? Where is the documentation for implementing this mechanism? Thank you in advance for your help. I believe this integration is a powerful productivity unlock!

I'm developing an iOS app that handles custom file types (e.g., .k files), and I want to ensure my app's icon appears in Core Spotlight search results, similar to how 两步路户外助手's icon shows up for associated files (as shown in the attached screenshot from iOS search). I know one standard way is to configure CFBundleDocumentTypes in the Info.plist to declare supported document types, which allows the system to associate files with my app and display the icon in search. However, I'm looking for alternative approaches or additional configurations that could achieve this without relying solely on CFBundleDocumentTypes, or perhaps in combination with it for better integration. For context: This is for iOS 26+ (or latest versions). The goal is to have the app icon visible directly in Spotlight/Core Spotlight results when searching for files or content indexed by my app. I've tried basic NSUserActivity and CSSearchableItem indexing, but the icon doesn't always appear as expected for file associations. Has anyone implemented this through other means, like exported UTIs, Launch Services, or custom searchable attributes? Any code snippets, documentation links, or best practices would be appreciated! (Attach your Figure 2 screenshot here to illustrate the desired behavior, e.g., the .k file with the app icon in search results.)

I read this thread https://developer.apple.com/forums/thread/788979 thoroughly, but I’m still confused regarding indexing files content. I'm building a notes app where the notes are stored in files. A file can contain several notes (think paragraphs). Each note and the file document itself have a unique ID, all embedded in the file. So far so good, when the user opens a file in the app, I index all the notes in it using several CSSearchableItem, one for each note. Each CSSearchableItem gets a unique ID based on the note and file IDs. The notes are then visible in Spotlight search and when the user taps one of them, the app is called with a Spotlight activity and I present the note. I learned that I should create a CSImportExtension to allow the system to index files when app is not running. But the only method is update(_:forFileAt:), which allows to provide back to the system a single attributes set. How can I index the notes in a file as separate items? What happens if an iCloud document file is edited remotely and the app is not running, or is editing another file? Does the system detect it and run CSImportExtension on the file? All the notes and documents IDs are unique, and when the user duplicates the document file from within the app, new unique IDs are set in the duplicate file. But the user can also duplicate files outside the app, in which case the IDs remain the same in the duplicate file. How does Spotlight react to indexing two distinct items, with the same ID, but different 'contentURL'? What if I index a note from a file, and set the current contentURL of the file, and then the user moves the file. Next time when I index a note from this file, Spotlight will get an item with the same uniqueIdentifier but with a different contentURL. Won't this confuse the system? How to handle the case of deleted files: Unless a file is pending editing, the app doesn’t know it has been deleted, so it won’t remove the corresponding items from Spotlight. I should mention that I use a Core Data database, which stores the mapping from file document IDs to file URLs, actually to bookmarks, so I can track the files even if the user renames or moves them.

onContinueUserActivity(CSSearchableItemActionType, perform) works as expected on iOS when we search and select an item from Spotlight, but nothing happens when we do the same on a SwiftUI macOS app. var body: some Scene { WindowGroup { MyView() .onContinueUserActivity(CSSearchableItemActionType, perform: handleSpotlight) } } func handleSpotlight(_ userActivity: NSUserActivity) { // Is not called... } How can we respond to a user clicking a Spotlight result from our apps on macOS?

Hi all, I'm trying to add Spotlight support to a macOS app that handles custom virtual machine bundles with the .vpvm extension. I’ve followed the current documentation and used the modern CSImportExtension approach with a Spotlight Importer extension target. Here’s what I’ve done: App Info.plist: Declared com.makeprog.vpvm as a UTI conforming to com.apple.package. Registered it under UTExportedTypeDeclarations and CFBundleDocumentTypes. Spotlight Importer Extension: Added a new macOS target using the Spotlight Import Extension template. Set the NSExtensionPointIdentifier to com.apple.spotlight.import. Used CSSupportedContentTypes = com.makeprog.vpvm. Implemented a minimal update(_ attributes:forFileAt:) method that sets displayName, title, and contentDescription. Other steps: Verified that the .appex is embedded under Contents/PlugIns/. Confirmed it appears in mdimport -e output with correct UTI. Used mdimport -m -d2 -t /path/to/file.vpvm, but I still get: Imported '/path/to/file.vpvm' of type 'com.makeprog.vpvm' with no plugIn. The extension is never invoked. I’ve also tried: Ensuring the .vpvm file is a valid directory bundle. Restarting Spotlight / rebuilding index. Ensuring the app and extension are properly signed. Tried installing the app in test virtual machine Question: Has anyone successfully used CSImportExtension for custom UTIs? Is there something additional I need to do for the extension to be recognized and triggered? Any advice or examples would be greatly appreciated! Thanks in advance.

We are planning on renaming our app. The new name is not like the current name. It will be renamed in the App Store as well as the App display name. Yet, we still want new and existing users to be able to find the app by using the old name in search/spotlight under iOS. A great example of this is entering Twitter to find the X app and it shows up in the App section in the Spotlight search. Are there any guidelines, settings, or tricks for doing this? Some have suggested adding a Spotlight search term but that will not have it show up in the App section I fear.

With macOS Tahoe, Launchpad has been replaced by an App Library–style mode within Spotlight. While the alleged intention is UX consistency across the Apple ecosystem, the result is both a catastrophic usability regression and a radical break in consistency with iOS and iPadOS. Predefined App Library categorization is functionally incoherent: On iOS and now macOS, Apple’s predefined App Library categories place apps with seemingly identical functionality into unrelated groups—for example, 3D scanning tools scattered across Education, Utilities, and Productivity. Instead of making apps easier to find, this effectively creates a labyrinth that users must traverse to locate apps whose names and icons they may not recall. However Apple defines its app categories, they are not only inconsistent but also hopelessly inadequate for the long tail of real-world applications and user workflows. Loss of user control: Launchpad enabled users to group and organize applications according to their workflows. This aligns with Apple’s own Human Interface Guidelines, which emphasize user control, discoverability, and predictable behavior. The new Spotlight interface removes that flexibility, locking users into predefined categories that both impede and mislead—and cannot be overridden. Consistency across platforms is broken: If the goal was to unify iOS, iPadOS, and macOS, this approach actually undermines consistency. On iOS and iPadOS, users can still rely on a customizable Home Screen—a Launchpad-like experience—as their primary way of launching apps. In Tahoe, that option has been removed. macOS now forces users to depend exclusively on Spotlight with App Library categories, while eliminating the very feature that was consistent across platforms. Catastrophic impact on my workflow: As an interdisciplinary artist working in 2D, 3D, and time-based media, as well as coding, I make extensive use of a constantly changing array of AI tools and experiment with many new apps and web services, which I often turn into Web Apps. I cannot possibly recall the names of every native and web app on my system. I need predictable access to groups of related tools. Tahoe’s new auto-categories split those apps apart arbitrarily, slowing me down and interrupting established workflows, forcing me to navigate the aforementioned labyrinth just to find what I need. Proposal: A constructive way forward High-level objective: Simply restore Launchpad—or restore the ability to customize app categories/folders and manually assign apps to them, overriding or augmenting the predefined categories. This ensures users can launch apps according to their workflow, without needing to remember exact names or icons. Possible solutions: Allow manual subfolders within Applications, represented hierarchically in Spotlight. Provide a fullscreen Launchpad-like organizer (with uninstall via long-click, etc.), either as a replacement or toggleable option. Retain Apple’s auto-categories for those who prefer them, but let users override or augment them with their own. In summary: Tahoe eliminates a working, consistent paradigm (Launchpad/Home Screen) and forces reliance on an App Library system that categorizes poorly and cannot be customized. This is both a step backwards in functionality and a break in cross-platform consistency. A constructive solution is to restore Launchpad—or at least restore the ability for users to organize apps in ways that fit their workflows.

On iOS 18, I'm trying to index documents in Spotlight using the new combination of AppIntents+IndexedEntity. However, I don't seem to be able to index the textContent of the document. Only the displayName seems to be indexed. As recommended, I start with the defaultAttributeSet: /// I call this function to index in Spotlight static func indexInSpotlight(document: Document) async { do { if let entity = document.toEntity { try await CSSearchableIndex.default().indexAppEntities([entity]) } } catch { DLog("Spotlight: could not index document: \(document.name ?? "")") } } /// This is the corresponding IndexedEntity with the attributeSet @available(iOS 18, *) extension DocumentEntity { var attributeSet: CSSearchableItemAttributeSet { let attributeSet = defaultAttributeSet attributeSet.title = title attributeSet.displayName = title attributeSet.textContent = docContent attributeSet.thumbnailData = thumbnailData attributeSet.kind = "document" attributeSet.creator = Constants.APP_NAME return attributeSet } } How can I have more that the displayName to be indexed? Thanks :-)