Ability to Disable Indexing Per Target in Xcode

[chiragramani]

When working on large-scale projects, we often have modules that are indexing-heavy but do not require code completion, navigation, or other indexing-related features in Xcode. These modules may be generated code, third-party libraries, or internal tools that are rarely edited directly.

Currently, Xcode allows global indexing settings,(defaults write com.apple.dt.XCode IDEIndexDisable 1) but there is no fine-grained control to disable indexing on a per-target or per-module basis. Disabling indexing entirely is not ideal, as most of the project still benefits from it.

Feature request: It would be nice to have an option to opt-out of indexing, which SWBTaskConstruction / Product Planning phases can take into account and not produce indexing / preparingForIndex tasks.

[jakepetroules]

Interesting idea. @bnbarham do you think there are cases where this could meaningfully improve performance? And if so, whether changes in Swift Build would be the right layering for that?

[bnbarham]

When working on large-scale projects, we often have modules that are indexing-heavy but do not require code completion, navigation, or other indexing-related features

Could you expand on this? While the modules themselves may not be edited, presumably they have dependents where they would be required. If so, the modules still need to be produced when preparing for semantic functionality in the dependent targets.

Index while building can be disabled through a build setting today (COMPILER_INDEX_STORE_ENABLE), so this request is really for disabling background indexing. This seems a little strange to have in the build system though, since it has nothing to do with the build itself.

[chiragramani]

Thanks @jakepetroules and @bnbarham and apologies I missed this thread!
A couple of follow-up thoughts here:

@bnbarham From my experience, there are two categories of scenarios:

Category 1: No meaningful semantic consumers – For example, in projects using uber/needle, a DI tool generates a single target that depends on all other targets in the app. It’s not intended for interactive development or navigation, so we’d want to completely opt out of both foreground and background indexing for it.

Category 2: Limited semantic relevance - Many internal codegen modules or utility modules do have dependents, but in practice, they’re rarely interacted by developers. In these cases, background indexing consumes resources without improving the developer experience. Even when semantic data is needed, we’d love the ability to configure a “minimal semantic set” - essentially trading off full semantic resolution for performance/memory savings.

While setting COMPILER_INDEX_STORE_ENABLE=NO helps during the build, the key point is background indexing, as you mentioned. Would it be possible for the build system - or perhaps the indexing engine - to support a per-target configuration that controls this behavior more granularly? For example, providing options to completely disable background indexing or switch to a lightweight mode that performs only minimal semantic work.

Speaking of background indexing - Feature Request:
It would also be helpful to have the ability to influence the order in which targets are picked up for background indexing. We know the intent for which the dev generated a specific project, we understand the layout, patterns, have enough context - so, being able to prioritize certain targets could improve responsiveness and IDE usability for a dev session.

This kind of control would help ensure that the most relevant semantic functionality is available sooner, while deferring or skipping lower-priority indexing work.