# Support for prebuilt Swift-Syntax
**URL:** https://community.tuist.dev/t/support-for-prebuilt-swift-syntax/634
**Category:** Ideas
**Tags:** dependencies
**Created:** [June 23, 2025, 8:27pm UTC](https://community.tuist.dev/t/support-for-prebuilt-swift-syntax/634 "2025-06-23T20:27:51Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@MartinStrambach](https://community.tuist.dev/u/MartinStrambach)
#### Post date: [June 23, 2025, 8:27pm UTC](https://community.tuist.dev/t/support-for-prebuilt-swift-syntax/634/1 "2025-06-23T20:27:52Z")
Is there a plan to support prebuilt Swift-Syntax when using Tuist dependencies without Tuist cache? Is this even feasible with current Tuist implementation?
Some resources for the reference
> **[Swift Macros at scale](https://tuist.dev/blog/2024/08/26/swift-macros/)**
>
> Swift Macros, while powerful, can hinder build times. This blog post explains why and what we can do to mitigate the issue.
> **[\[Preview\] Swift-Syntax Prebuilts for Macros](https://forums.swift.org/t/preview-swift-syntax-prebuilts-for-macros/80202/2)**
>
> I'm glad to finally see this, thank you for the work you put into this feature!
> **[Mitigating SwiftSyntax build times](https://www.pointfree.co/blog/posts/171-mitigating-swiftsyntax-build-times)**
>
> Learn how to mitigating long build times when using Swift macros by leveraging the new prebuilt SwiftSyntax binaries in your project.
---
### Author:  [@marekfort](https://community.tuist.dev/u/marekfort)
#### Post date: [June 24, 2025, 6:44am UTC](https://community.tuist.dev/t/support-for-prebuilt-swift-syntax/634/2 "2025-06-24T06:44:05Z")
Hey!
This is certainly a need, but not a strong priority of the Tuist team right as teams using Tuist can already benefit from prebuilt macros by using the binary cache. We understand the prebuilt version from Xcode would result in a slightly better experience than what we have right now as explained [here](https://community.tuist.dev/t/issue-10-june-6th/561/30). We would definitely still like to support this in the future, but there’s currently no timeline. As always, contributions are more than welcome 😉
---
### Author:  [@PaulTaykalo](https://community.tuist.dev/u/PaulTaykalo)
#### Post date: [September 22, 2025, 8:04am UTC](https://community.tuist.dev/t/support-for-prebuilt-swift-syntax/634/3 "2025-09-22T08:04:16Z")
> [@MartinStrambach](#):
>
> [Mitigating SwiftSyntax build times](https://www.pointfree.co/blog/posts/171-mitigating-swiftsyntax-build-times)
Right. I is more like suggestion idea of possible implementation. But it could work like that (I’m not sure if it is feasable change form the Tuist Architectures standpoint).
Currently, when we have an external dependency of SPM, all transitive dependencies are re-mapped to the frameworks.
So, for example, if someone has dependency on swift-syntax, there’ll be a project, with all the targets of the swift-syntax.
```auto
• SwiftBasicFormat.framework
• SwiftCompilerPlugin.framework
• SwiftCompilerPluginMessageHandling.framework
• SwiftDiagnostics.framework
• SwiftOperators.framework
• SwiftParser.framework
• SwiftParserDiagnostics.framework
• SwiftSyntax.framework
• SwiftSyntax509.framework
• SwiftSyntax510.framework
• SwiftSyntax600.framework
• SwiftSyntax601.framework
• SwiftSyntaxBuilder.framework
• SwiftSyntaxMacroExpansion.framework
• SwiftSyntaxMacros.framework
• _SwiftSyntaxCShims.framework
```
The idea here is to:
Allow developer to leave package dependencies as-is for the extenal depencies.
So, for example, if I have a depedncy A, which depends on swift-syntax, I could opt-in, to prevent tuist from creating project for swift-syntax.
This would create swift package reference in the A. project
And, basically will leave resolance of the package to the Xcode/xcodebuild.
swift syntax is one of the cases, though. but having this option (at least as experimental) would drastically reduce the amount of time, needed for building external depedencies, dependent on the swift-syntax.
@marekfort Will this pass review, or does it completely break how Tuist is supposed to work?
I mean, is there even a possibility that this solution could be merged?
---
### Author:  [@pepicrft](https://community.tuist.dev/u/pepicrft)
#### Post date: [September 22, 2025, 3:29pm UTC](https://community.tuist.dev/t/support-for-prebuilt-swift-syntax/634/4 "2025-09-22T15:29:24Z")
This is something Tuist can certainly support. Perhaps with a setting in `PackageSettings`:
```swift
#if TUIST
let packageSettings = PackageSettings(
packagePreBuilts: .all
// Or individual opt-in: ["foo", "bar"]
)
#endif
```
This will require setting the right build settings in those targets such that the SwiftSyntax modules can be looked up (cc [@core](https://community.tuist.dev/groups/core) to get their thoughts). Would you be interested in giving it a shot?
---
### Author:  [@marekfort](https://community.tuist.dev/u/marekfort)
#### Post date: [September 22, 2025, 4:34pm UTC](https://community.tuist.dev/t/support-for-prebuilt-swift-syntax/634/5 "2025-09-22T16:34:20Z")
> [@PaulTaykalo](#):
>
> And, basically will leave resolance of the package to the Xcode/xcodebuild.
I don’t think this is the right way to approach the XcodeProj-based installation. One of the benefits of the XcodeProj-based installation is that everything is resolved at the generation time and leaving the resolution to Xcode would break that. Additionally, you’d resolve `swift-syntax` twice – once during `tuist install` and once when you open Xcode.
Instead, we can integrate the prebuilts directly. To get prebuilds, we can modify the `swift package resolve` command to `swift package --enable-experimental-prebuilts resolve`. Once you do that, you’ll get paths to the prebuilts in the `.build/workspace-state.json` which is the file we use when mapping the package info to our Tuist definitions. Here’s an example of how `swift-syntax` is referenced in that file when running the mentioned command against our `app_with_composable_architecture` fixture:
```auto
"prebuilts" : [
{
"cModules" : [
],
"checkoutPath" : "/Users/marekfort/Developer/tuist/cli/Fixtures/app_with_composable_architecture/Tuist/.build/checkouts/swift-syntax",
"identity" : "swift-syntax",
"includePath" : [
"Sources/_SwiftSyntaxCShims/include",
"Sources/_SwiftLibraryPluginProviderCShims/include"
],
"libraryName" : "MacroSupport",
"path" : "/Users/marekfort/Developer/tuist/cli/Fixtures/app_with_composable_architecture/Tuist/.build/prebuilts/swift-syntax/600.0.1/swiftlang-6.2.0.19.9-MacroSupport-macos_aarch64",
"products" : [
"swift-syntaxPackageTests",
"SwiftBasicFormat",
"SwiftCompilerPlugin",
"SwiftDiagnostics",
"SwiftIDEUtils",
"SwiftOperators",
"SwiftParser",
"SwiftParserDiagnostics",
"SwiftRefactor",
"SwiftSyntax",
"SwiftSyntaxBuilder",
"SwiftSyntaxMacros",
"SwiftSyntaxMacroExpansion",
"SwiftSyntaxMacrosTestSupport",
"SwiftSyntaxMacrosGenericTestSupport",
"_SwiftCompilerPluginMessageHandling",
"_SwiftLibraryPluginProvider"
],
"version" : "600.0.1"
}
]
```
We can take this information and integrate these prebuilts directly without having to depend on the vanilla Xcode \<\> SwiftPM integration.
If we do it like that, then this shouldn’t be configurable in `PackageSettings` (and it shouldn’t be configurable on a per-product basis), instead, you would specify that in `Tuist.swift`. We already support using arbitrary `swift package` arguments, so this would require _no_ changes in `ProjectDescription`: [https://docs.tuist.dev/en/references/project-description/structs/config.installoptions#passthroughswiftpackagemanagerarguments](https://docs.tuist.dev/en/references/project-description/structs/config.installoptions#passthroughswiftpackagemanagerarguments)
In other words, we need to add support for integrating the packages referred to in `.build/workspace-state.json`’s `prebuilts` field.
---
### Author:  [@pepicrft](https://community.tuist.dev/u/pepicrft)
#### Post date: [September 29, 2025, 9:36am UTC](https://community.tuist.dev/t/support-for-prebuilt-swift-syntax/634/6 "2025-09-29T09:36:21Z")
> [@marekfort](#):
>
> Instead, we can integrate the prebuilts directly. To get prebuilds, we can modify the `swift package resolve` command to `swift package --enable-experimental-prebuilts resolve`. Once you do that, you’ll get paths to the prebuilts in the `.build/workspace-state.json` which is the file we use when mapping the package info to our Tuist definitions. Here’s an example of how `swift-syntax` is referenced in that file when running the mentioned command against our `app_with_composable_architecture` fixture:
This part I was not aware of. I created an [issue](https://github.com/tuist/tuist/issues/8329). @PaulTaykalo would you like to take a stab at implementing it?