This is amazing
When porting the project to Tuist, I turned each local Swift package into a static library target.
Previews work better with dynamic frameworks – you can use Tuist’s support for environment variables to switch between dynamic and static frameworks easily by running a command such as TUIST_DEFAULT_FRAMEWORK_TYPE="static" tuist generate
and then reading the environment variable in your Project.swift
or Package.swift
manifest to change the type at generation time. @pepicrft described this approach in more detail here.
In static-UITools, failed to materialize { _$sSS15SwiftRichStringE3set5style5rangeSo019NSMutableAttributedC0CSgSS_So8_NSRangeVSgtF }
This suggests to me that some of the static symbols are stripped. This is because SwiftPM by default passes GENERATE_MASTER_OBJECT_FILE=YES
. What this build setting does is that it disables code stripping of static libraries. This does help with some runtime failures but it also unnecessarily increases your binary size. We don’t recommend setting that value across the board, but some libraries end up working better with it. We considered making that a default to align with SwiftPM or at least adding an easy opt-in but we haven’t got around doing that, yet. There’s an issue for this, however: Include a generation option to enable the generation of the master object file · Issue #6777 · tuist/tuist · GitHub
What you can do and what I would recommend trying is setting that flag for the particular dependency in your Package.swift
using Tuist’s PackageSettings:
// Tuist/Package.swift
import PackageDescription
#if TUIST
import ProjectDescription
let packageSettings = PackageSettings(
targetSettings: ["SwiftRichString": ["GENERATE_MASTER_OBJECT_FILE": true]]
)
#endif
let package = Package(...)
I am quite sure either switching your libraries to dynamic or adding the GENERATE_MASTER_OBJECT_FILE
setting should fix your issue – but preview failures are sometimes hard to pin down, so let me know if neither works for you.