Hive Hive
Sign in
Overview
Projects
Domains
Forage
Flights
Specs
Postmortems
Drops

fix(cli): preserve asset symbol generation for buildable-folder xcassets

GitHub issue · Closed

Metadata
Source
tuist/tuist #10911
Updated
Jun 24, 2026
Domains
Generated projects
Details

Summary

  • preserve asset symbol generation for static targets whose .xcassets come from buildableFolders by promoting those catalogs onto the main target’s Sources phase
  • dedupe promoted asset catalogs across nested synchronized groups and folder-level .xcassets while keeping the companion bundle as the runtime resource owner
  • add regression coverage for buildable-folder asset catalogs in the resource mapper and for explicit source file references inside synchronized groups

Note

This intentionally mirrors SwiftPM and swift-build rather than introducing a Tuist-only resource model. SwiftPM adds .xcassets to both the resource bundle target and the main target’s sources for typed symbol generation (SwiftBuildSupport, XCBuildSupport). It also sets PACKAGE_RESOURCE_BUNDLE_NAME on the main target (SwiftBuildSupport). Then swift-build keeps GenerateAssetSymbols on that main target (task creation) while skipping main-target catalog compilation and LinkAssetCatalog when a companion resource bundle exists (bundle detection, link gating). The Tuist-specific part is extending that same treatment to catalogs discovered through buildableFolders, which SwiftPM does not model directly.

Testing

  • tuist install
  • tuist generate --no-open (in /tmp/tuist-buildable-folder-bundle-module-bug)
  • xcodebuild -workspace BugReproApp.xcworkspace -scheme BugReproApp -destination 'generic/platform=iOS Simulator' build (reproduced the reported ImageResource failure before the fix)
  • tuist install (in this worktree)
  • tuist generate tuist TuistGenerator TuistGeneratorTests ProjectDescription --no-open (completed with remote cache warnings)
  • xcodebuild test -workspace Tuist.xcworkspace -scheme Tuist-Workspace -only-testing TuistGeneratorTests/ResourcesProjectMapperTests CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY='' COMPILATION_CACHE_ENABLE_CACHING=NO (blocked by unrelated workspace dependency issues before reaching the targeted tests)
  • xcodebuild build -project Tuist.xcodeproj -target TuistGeneratorTests CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY='' COMPILATION_CACHE_ENABLE_CACHING=NO (blocked by unrelated TuistNooraExtension / dependency resolution failures)
Flights

Investigate, reproduce, or fix this item in an isolated repository. Each Flight preserves its outcome and agent session.

New Flights are paused Configure model inference, GitHub, and a sandbox provider to start another Flight. Existing results remain available below.
No Flights yet

Start a Flight and preserve its objective, outcome, and session here.

Comments
N
nicorichard May 28, 2026

This is wonderful news! My team has been evaluating Tuist overtop our SPM-native modular mono-repo with a funny little tool I created that we use with our project-local CLI which wraps tuist generate https://github.com/nicorichard/PackageToTuistProject.

We were able to start using Tuist and have gained many benefits already, but the thought of porting our symbol calls to a Tuist-native approach was not something that appealed to us.

By using traditional/explicit resource globs we were able to retain symbol generation, but we lost the benefits of buildable folders… this closed the gap, thank you!

Maybe soon we’ll be 100% Tuist and it won’t matter so much anyways, but I appreciate this none-the-less as a much more streamlined route to Tuist adoption.

I’ve updated our funny tool now and we’ll be testing it https://github.com/nicorichard/PackageToTuistProject/pull/2