I would like for external dependencies to have default dependency caching only for those platforms that are explicitly specified in the external dependency’s Package.swift file or based on PackageSettings.productDestinations.
For some reason, when generating an Xcode project, PackageInfoMapper automatically sets all sorts of destinations for external dependencies, which seems a bit premature.
This also led to some bugs intermittently related to MacCatalyst support, causing some packages to fail to compile: GitHub · Where software is built
I also encountered this problem when trying to cache the SDK which is included via Tuist/Package.swift (via .package(path:))
Building scheme Binaries-Cache-iOS for Mac Catalyst
note: Using codesigning identity override:
⚠️ Target 'VendorPlayerSDK' does not support any of the imposed platforms 'macosx' and a single platform could not be chosen from its own supported platforms 'appletvos appletvsimulator iphoneos iphonesimulator'. For backwards compatibility, it will be built for macOS.
...
...
❌ path/to/vendor-sdk/Modules/SomeModule/Source/Models/ActivityIndicatorComponentStyle.swift:8:8: no such module 'UIKit'
⚠️ `DERIVE_MACCATALYST_PRODUCT_BUNDLE_IDENTIFIER` is not supported. Remove the build setting and conditionalize `PRODUCT_BUNDLE_IDENTIFIER` instead. (in target 'Storage' from project 'VendorPlayerSDK')
⚠️ `DERIVE_MACCATALYST_PRODUCT_BUNDLE_IDENTIFIER` is not supported. Remove the build setting and conditionalize `PRODUCT_BUNDLE_IDENTIFIER` instead. (in target 'PlaylistModule' from project 'VendorPlayerSDK')
Hey 
All Swift packages implicitly support all platforms – and there’s no way to opt-out of that. The platforms property of a package is only there to define the minimum supported version: Package — Swift Package Manager.
However, when caching and generating a project, the platforms of external dependencies should be stripped to the platforms included in downstream targets, such as your app. This logic happens in the ExternalProjectsPlatformNarrowerGraphMapper.
If Tuist is caching/generating dependencies for platforms not included in your own project, then there might be a bug. In which case, I’d suggest creating a GitHub issue with a reproducible sample.
should be stripped to the platforms included in downstream targets, such as your app
But how exactly does he understand which specific application target needs to be cached if we just call the command “tuist cache —external-only”?
We take a look at all the application targets even with that flag passed. For example, if you run tuist cache --external-only in this fixture, we only cache for iOS. You might wanna explore how your project differs from that fixture.
we only cache for iOS
I tried running tuist cache on another fixture – app_with_alamofire – and it also built for Mac Catalyst (tuist 4.53.4)
ernest0n@Ernest0-M1 app_with_alamofire % tuist cache Alamofire
Loading and constructing the graph
It might take a while if the cache is empty
Hashing cacheable targets
Targets to be cached: Alamofire
Loading and constructing the graph
It might take a while if the cache is empty
Using cache binaries for the following targets:
Generating workspace App.xcworkspace
Generating project Alamofire
Building cacheable targets
Building scheme Binaries-Cache-iOS for the simulator
note: Using codesigning identity override:
note: Building targets in dependency order
note: Target dependency graph (1 target)
[Alamofire] Write Auxiliary File module.modulemap
...
[Alamofire] Building library Alamofire
[Alamofire] Create Universal Binary Alamofire
[Alamofire] RegisterExecutionPolicyException Alamofire.framework
[Alamofire] Touching Alamofire.framework
Build Succeeded
Building scheme Binaries-Cache-iOS for Mac Catalyst ❗❗❗❗❗❗❗❗
note: Using codesigning identity override:
note: Building targets in dependency order
note: Target dependency graph (1 target)
[Alamofire] Write Auxiliary File module.modulemap
...
[Alamofire] Building library Alamofire
[Alamofire] Create Universal Binary Alamofire
[Alamofire] RegisterExecutionPolicyException Alamofire.framework
[Alamofire] Touching Alamofire.framework
⚠️ `DERIVE_MACCATALYST_PRODUCT_BUNDLE_IDENTIFIER` is not supported. Remove the build setting and conditionalize `PRODUCT_BUNDLE_IDENTIFIER` instead. (in target 'Alamofire' from project 'Alamofire')
Build Succeeded
Building scheme Binaries-Cache-iOS for device
note: Using codesigning identity override:
note: Building targets in dependency order
note: Target dependency graph (1 target)
[Alamofire] Write Auxiliary File module.modulemap
...
[Alamofire] Touching Alamofire.framework
Build Succeeded
Creating XCFrameworks
Creating XCFramework for Alamofire
Storing binaries to speed up workflows
1 target(s) stored: Alamofire
All cacheable targets have been cached successfully as xcframeworks
I’ve tried running tuist cache in the fixture you mentioned with the latest Tuist version, but it’s not being built for Catalyst:
Loading and constructing the graph
It might take a while if the cache is empty
Hashing cacheable targets
Targets to be cached: Alamofire, Alamofire_Alamofire
Loading and constructing the graph
It might take a while if the cache is empty
Using cache binaries for the following targets:
Generating workspace App.xcworkspace
Generating project Alamofire
Building cacheable targets
Building scheme Binaries-Cache-iOS for the simulator
note: Using codesigning identity override:
note: Building targets in dependency order
note: Target dependency graph (2 targets)
.... (truncated)
[Alamofire] Touching Alamofire.framework
Build Succeeded
Building scheme Binaries-Cache-iOS for device
note: Using codesigning identity override:
note: Building targets in dependency order
note: Target dependency graph (2 targets)
.... (truncated)
[Alamofire] Touching Alamofire.framework
Build Succeeded
Building scheme Bundles-Cache-iOS
note: Using codesigning identity override:
note: Building targets in dependency order
note: Target dependency graph (1 target)
[Alamofire_Alamofire] Processing Alamofire_Alamofire-Info.plist
Build Succeeded
Creating XCFrameworks
Creating XCFramework for Alamofire
Storing binaries to speed up workflows
2 target(s) stored: Alamofire, Alamofire_Alamofire
All cacheable targets have been cached successfully as xcframeworks
Can you try with the latest Tuist CLI?
