This conversation was originally flagged on GitHub: Issues · tuist/tuist · GitHub
Should we remove “ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES” from essential settings as Xcode 16 recommended to remove it?
@rowwingman, could you share the resource for Xcode 16 recommending to remove it?
That being said, new Xcode doesn’t set this build settings to YES. Ideally, Tuist’s recommended settings should mostly align with Xcode’s values for fresh projects, unless we have a strong reason not to be aligned.
The main question for me here is the following: changing the default value of ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES can technically be a breaking change. Should we keep a different default until the next major version of Tuist to keep the settings stable? But since we don’t plan to do a major version of Tuist unless we have a really, really strong reason, that might not happen for possibly years.
Alternatively, we change the ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES only for new Tuist projects, but that would add additional complexity on the CLI side for marginal benefits.
I’m leaning to changing the default to align with Xcode and highlighting the change in the release notes. For the majority projects, this change should not be breaking. Thoughts, @core?
I’m leaning to changing the default to align with Xcode and highlighting the change in the release notes. For the majority projects, this change should not be breaking. Thoughts, @core?
If the default of new projects is that one, I’d say that we align with them. Can we think of any side-effects of changing the default? We can also put it out in the wild, and hot-fix if it comes with unexpected consequences.
No, I think it should be a relatively safe change to make.
I created an actionable issue on GitHub: Align ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES with the Xcode default · Issue #6989 · tuist/tuist · GitHub
@rowwingman, would you want to take the lead here and implement the change? 
1 Like
It might be nice to have some way to capture defaults based on Xcode version longer term. I could see value in haveing a default of something like .xcode16 which would be updated to .xcode17 in the future but allow users to stick with prior behavior to allow them to update to a new Tusit version without necessarily needing to take on a migration because defaults changed.
I like this idea. @marekfort do you think it’d be costly to maintain?
I will check on the weekend
1 Like
Not a lot, I think it’s worth exploring and I like the idea as well!
This would be amazing @rowwingman 
Xcode recommend me to remove this setting. I try to remove it like this.
defaultSettings: .recommended(
excluding: [
"ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES",
]
)
However it didn’t work. Maybe the best option in this case will be to make it possible to exclude or maybe remove. As I understand the reason why it doesn’t exclude as “ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES” is part of essential settings. So maybe solution should be just move it to recommended.
I think support multi Xcode versions recommended settings is a good idea. We can provide some variables with recommended settings. for example .recmmended(version: .16). We can provide some concatenation. for example .essential + .recommended(version: .16). What do you think? But this means that .essential are not part of the recommended.
So maybe solution should be just move it to recommended.
We will no longer set the value of this setting at all. WIP PR is here.
To ignore the Xcode’s check on each generate, you can set the lastXcodeUpgradeCheck variable to the latest Xcode. That will ensure that warning will go away until the next Xcode version.
for example .essential + .recommended(version: .16). What do you think? But this means that .essential are not part of the recommended.
I’d be against concatenating settings as it increases the overhead of learning these properties. .recommended(version: .16) should include all .essential settings as well.
ok, remove it all is much simpler, agree.