Slow incremental builds because of planning swift module

[JoeSzymanskiNoom (Joe Szymanski)]

We have been running into a recurring issue causing our builds in Xcode to take significantly longer than expected. Sometimes when generating incremental builds, even ones with zero actual changes, the build can suddenly take 5-6 minutes. Almost all of this time is spent on the “planning swift module” step. In some cases, we’ve seen this issue cause the build to take longer than a clean build typically takes.

Our app has a very large number of individual modules, and the build output indicates this step can take up to 30 seconds for each one.

We originally made almost exclusive use of SPM to defines these local packages and their dependencies, but migrated to Tuist in the hopes that moving the code into Xcode projects with defined target would reduce or eliminate this issue, but we’ve been seeing it again, though I believe less often.

We are running Xcode 26 using the Swift 5 compiler mode. There is nothing in the build output that I can see when these steps are running. The build timeline can be seen below. In this specific example, a file was changed in the App target, but no code in the packages/modules were changed at all.

Has anyone else seen this issue? Does anyone know steps we can take to improve this issue?

[owenv (Owen Voorhees)]

Replanning every module in an incremental build, but scheduling no compiles, is often a sign that inputs to the build are being modified unexpectedly. For example, a misconfigured linter could be updating the timestamp of every source file without changing the content.

If you're running Xcode 26.4 beta, you can narrow this down somewhat by:

1. Opening the scheme editor for the scheme you're building
2. Select the "Build" tab
3. Under "Build Debugging", enable "Task Backtraces"
4. Reproduce the issue in an incremental build
5. Open the build log in the report navigator, and filter to "Recent" and "All Messages". Expanding individual tasks in the log will show a new "Task Backtrace" below the command output describing why a particular task was re-run in that incremental build.

[Jon_Shier]

Yes, this has been a long standing issue, especially since Xcode 26.0, where it became extremely visible. Incremental build performance hugely regressed at the same time, so they could be related, but it's unclear. Some of the incremental regression seems macro related, as the more macros used in a file, the high a chance a trivial change rebuilds a huge number of files. Are you using macros much?

As of Xcode 26.4, Xcode's build system continues to have various issues, in no particular order.

• swift-syntax still builds universally when no prebuilt is available.
  • Prebuilt integration is still opaque and there's no way to force the system to use the prebuilt without having it go through full set up without a cache.
• Under other conditions, packages may be built universally as well. We saw this when we added a watchOS target, which means our packages get built three times, iOS arm64, iOS x86_64, and watchOS arm64.
• As noted here, various "bookkeeping" tasks in the build process take much longer than you'd expect. This includes the planning states, but even sometimes checking for tool versions are preformed slowly and repeatedly.
• Script phases still can't be properly ordered or set to run independently of the rest of the build process, so simple linting steps are blocking.
• Asset catalog compilation is absurdly slow, and you have almost no control over the work is actually does. There's no way to provide a precompiled version.
• Asset catalog compilation is also single threaded, so breaking into multiple catalogs won't help with performance. You have to move them to independent targets to actually improve performance.
• To go along with all these, there isn't enough information in the build logs to take action to improve build times. Swift files are built batched, but the timing info only exists for the entire batch, so there's no way to know if a particular file takes abnormally long. There's also no easy way to visualize how long individual build stages take for batches or files.
• Incremental builds take longer than builds with the Xcode 26 build cache in place, which is thoroughly absurd. A single newline can cause a rebuild of virtually our entire app.
• One of the causes of the big incremental builds is that we can't really modularize our app due to the lack of control over package dependencies and how they link between shared frameworks, especially when those frameworks are shared between iOS and watchOS or other platforms.

I can't report many of these bugs because I can't include the codebase in the report, so they go no where.

[JoeSzymanskiNoom (Joe Szymanski)]

@owenv Thanks for the suggestion. I’ll look into enabling that setting so that I can do further investigation.

@Jon_Shier We are making heavy use of macros, given the widespread use of them in TCA and its dependencies, which are heavily used throughout our codebase.

I’ll update here if I come up with anything specific. I wonder if there’ something causing files to get marked as touched, as was suggested, but I haven’t been able to track down a specific case for that yet.

[JoeSzymanskiNoom (Joe Szymanski)]

@owenv I wasn’t able to find the “Task Backtraces” option, and didn’t see any references to it in a web search. Do you have any documentation links for that setting?

[Jon_Shier]

I found it in the same scheme settings for the build action in Xcode 26.4, but I don't see anything in the build logs for these backtraces or module reports.

[Jon_Shier]

And much of my incremental build time is spent in Emit Swift module. For our app, I added a newline to our AppDelegate file and it took 10.391s in the Planning Swift module step, then took 68.9s to emit the Swift module. As a bonus, the asset catalog was uncached in the incremental build and took 20s to rebuild (and of course rebuilt all the asset catalogs in our packages).

[Jon_Shier]

Even a build with no changes takes about 10s.

• 1.6s to compute dependencies.
• 0.8s to send project description to build service
• 1.72s to compute dependencies.
  • It doesn't say but I'd bet the two "compute dependences" are for our iOS and watchOS targets.
• 0.795s to create build description.
• About 1s to run our linting steps for each target, since there's no way to tell a script target there are no changes.
• 1.4s to sign the app, even though the build output didn't change.
• 0.748s to validate the watchOS app, even though the build output didn't change.

All on an M2 Max with 64GB RAM.

[Dmitriy_Ignatyev]

@Jon_Shier

Asset catalog compilation is absurdly slow, and you have almost no control over the work is actually does.

@Jon_Shier

so breaking into multiple catalogs won't help with performance.

Assets compilation can be parallelized by splitting assets into several bundles, e.g. 6-10 assets for images / icons / illustrations..., 1 separate asset with colors, and separate assets for other resources. I've done it because assets compilation was a bottleneck at some point of compilation.

@Jon_Shier

There's no way to provide a precompiled version

Can you please clarify what do you mean. Resources can be stored in a separate precompiled framework. It is useful for resources that rarely changed.

[Jon_Shier]

@Dmitriy_Ignatyev

Assets compilation can be parallelized by splitting assets into several bundles, e.g. 6-10 assets for images / icons / illustrations..., 1 separate asset with colors, and separate assets for other resources.

Has this changed recently? It wasn't true last I tried back with Xcode 15-ish. Multiple catalogs in the same target were compiled in one single threaded process. It didn't help with incremental builds either, all catalogs were reprocessed even when only a small one was changed. Otherwise yes, I mentioned you could make them technically parallel by splitting them into multiple targets.

@Dmitriy_Ignatyev

Can you please clarify what do you mean. Resources can be stored in a separate precompiled framework. It is useful for resources that rarely changed.

Catalog compilation produces a car file, but there's no way to just provide that car file. You have to do what you mentioned: build a separate target that you precompile and ship as a binary. There should just be a way to automate that process. Or better yet, make the compilation actually performant and parallel.

[Dmitriy_Ignatyev]

As you see, they are compiled in parallel. Xcode 26.3

[Dmitriy_Ignatyev]

I've noticed a significant regression in my Xcode project. The preparation phase now takes around 1 minute, while the project itself takes 45 seconds to compile on Xcode 26.3.

I didn’t encounter this issue previously, as I was mainly working with smaller SPM packages (under 10k lines of code), which compiled in just a few seconds.

[Jon_Shier]

Yes, separate targets compile in parallel. My point was that multiple catalogs in the same target do not. You can see that by the name of the step: "Compile asset catalogs".

[Dmitriy_Ignatyev]

It is one dynamic library (.framework) with several bundles. Each bundle is put to framework at Copy Bundle Resources build phase.

[Jon_Shier]

So you have *.bundle in the target with an asset catalog inside it, which is copied, and that copy triggers the asset catalog build? Can't say I've heard of that before.

[Dmitriy_Ignatyev]

I've created an example project (which includes relatively large asset files) to demonstrate the concept, as it might not be obvious at first glance: GitHub - iDmitriyy/AssetsParallelCompilationExample: Parallel compilation of Assets example

I originally made something like this about 7 years ago, so I don't recall every detail, but as I remember, XCode launches several asset compiler processes that compile these bundles in parallel.
When our assets began to compile 1 minute, I've decide to optimize it. This way I reduced compilation to 8 seconds, so it wasn't a bottleneck anymore.
Similar can be done for storyboard / xib files, if there are a lot of them in the project.

Feel free to ask any questions!

May be it will be good to write some article how to reproduce it step by step if someone interested.

Here’s the cold build graph:

Incremental build with 1 asset catalog changed:

[steffen (Steffen Matthischke)]

We hit both symptoms from this thread in an app with 375 Swift modules (Xcode 26.6), and they turned out to be two separate bugs.

1. Modules re-plan although nothing changed (macro plugins)

When a module loads two or more macro plugins, Swift Build listed the plugin executables among the planning task's inputs in a nondeterministic order. Swift Build treats input order as part of a task's signature, so whenever the build description is regenerated, the order can flip and every such module re-plans with zero files compiled. Regeneration happens after project generation (Tuist, XcodeGen), a branch switch, or an Xcode restart. For us, a no-change build took 127 s instead of 15 s and re-planned 108 modules. That fits the "sometimes, even with zero actual changes" pattern and the heavy macro use mentioned above.

This is fixed in swift-build #1203, which is part of Swift 6.4 / Xcode 27. Xcode 26.x doesn't have it.

To check whether you're affected: copy DerivedData/<Project>/Build/Intermediates.noindex/XCBuildData/<signature>.xcbuilddata/manifest.json after a build, and compare it with the one from the next slow no-change build. The command lines of the SwiftDriver Compilation Requirements tasks will be identical; only the order of the plugin paths in their inputs differs.

Until Xcode 27, it helps to give macro plugins only to the modules that actually use them, because only modules with two or more plugins are affected.

2. Each "Planning Swift module" step takes 10–30 s when many modules re-plan (path cache lock)

Swift Build runs the drivers of all modules in one process (its build service), so they all share one global path cache in swift-driver. Every lookup in it took an exclusive lock, so when many modules plan at the same time, they effectively plan one after another. In our builds, planners spent about 85% of their time waiting on that lock, with about one of eight running at a time. Clean builds rarely show this, because few modules plan at once there.

Details are in swift-driver #2219, and a fix is in #2220. With the patched driver, the median planning step went from 11.6–18.5 s to 2.5–4 s, and an incremental build that re-planned 214 modules went from 390 s to 290–340 s.

Either bug alone makes builds slower; together they explain builds like the one in the first post. The first bug makes many modules re-plan for no reason, and the second makes each of those re-plans slow.

Assisted-by: Claude