Target Dependency xcframework and path specified in xcconfig

Troubleshooting & how to
1

Question or problem

I am working on a migration of a huge project (a PoC rather than a set in stone migration) and I am facing difficulties adding an xcframework dependency with a path that is specified in the xcconfig.

So, I have multiple configurations and depending on a config I have different paths for my xcframeworks.

Let’s put it this way:
Debug.xcconfig
MY_DEPENDENCY_PATH=$(PROJECT_DIR)/Deps/Debug/MyDep.xcframework
Release.xcconfig
MY_DEPENDENCY_PATH=$(PROJECT_DIR)/Deps/Release/MyDep.xcframework

In my current setup, in the pbxproj file I have it as:
SomeRandomId /* MyDep.xcframework */ = { isa PBXFileReference; lastKnownType = wrapper.xcframework; name = MyDep.xcframework; path = $MY_DEPENDENCY_PATH; sourceTree = “”; };

Expectation

I expected that I’d have a way to specify an
.xcframework("$MY_DEPENDENCY_PATH") dependency for my target and it let it be resolved at the build time. But I don’t see any option to pass a string instead of a Path there.
But it seems there’s no such possibility. Am I missing anything? Or do I have to find another way of dealing with the dependency?

Context

  • Tuist version: 4.34.3
2

Correct, you can’t use build settings variables to specify your xcframework.

I’d be curious what’s the need for using a Debug xcframework? Usually, a prebuilt binary should be built in the Release configuration and integrated that way.

If this is a strict requirement for your project, you can use Tuist’s environment variables instead to change the xcframework path at the generation-time, instead of build-time.

The usage would then roughly be TUIST_CONFIGURATION=release tuist generate and in your manifest, you could do let xcframeworkPath = Environment.configuration == "release" ? releasePath : debugPath. You can find an example with environment variables here.

3

Yeah well, it’s a huge modular project with lots of dependencies and lots of requirements. And we have “debug” and “release” pre-compiled versions of a framework from one of our vendors. Just a historical thing.
And it was dealt with via xcconfig files. Now that we’re exploring our options in alternative build systems and Tuist, all those decisions start to affect the workflow :slight_smile:
Thanks for the suggestion. I’ll give it a try!