Related Documentation

Checked 1 published document(s) in 0 knowledge base(s). No updates required.

^{How did I do? Any feedback?}  

🛠️ Tuist Run Report 🛠️

Previews 📦

App	Commit	Open on device
Tuist	8418865b2

Tests 🧪

Builds 🔨

Bundles 🧰

I've been looking at Tuist for our very large brownfield project. We use local swift packages as the vehicle for modularity, and also happen to use generated accessors across many different modules.

This will do so much towards allowing us to evaluate Tuist without bloodshed. Thank you.

I've been looking at Tuist for our very large brownfield project. We use local swift packages as the vehicle for modularity, and also happen to use generated accessors across many different modules.

@nicorichard I'll have this one merged today ;)

Just reporting back to say that I pulled the new release (CLI 4.122.2) and my codebase just ran its first successful build using a Tuist generated project 🎉

@pepicrft @fortmarek Thank you for doing this! I've been waiting for this for a long time.

After testing this change I spotted a couple of issues I think you might want to take a look at though.

One thing is I think there's an issue with the generated module Bundle extension in unit tests.
The check for canImport(XCTest) fails when running from a test target even if it explicitly depends on xctest. It only passes if the main target depends on xctest. I think a more robust choice would be to check if ProcessInfo.processInfo.processName == "xctest".
If I manually change the check so it passes, the logic for stepping outside into the build folder to find the bundle seems incorrect as well.
I think Bundle(for: UnitTestBundleFinder.self) seems to return the main bundle in a static framework (which is the test bundle in an XCTest). Then resourceURL?.appendingPathComponent("..") steps out one level from the Resources folder, which puts you in the Contents folder of the test bundle.
If we start with the bundleURL.appending(component: ".."), it finds the framework successfully from a unit test.

Another issue seems to be with Metal files in a static framework. A framework with Metal files will also contain a default.metallib as a generated resource, therefore the framework needs to be copied into the app bundle, but it currently isn't.

Thanks @adarhef. I'm taking a look at it.

Hello. Would some of you help me with a link to documentation about how to set the resources synthesiser?
Unfortunately Strings catalog resources are not generated. I read that as long as string catalogs are in the resources configured folder, Tuist should automatically generate accessors.
Is that correct?

This is my configuration:

• Tuist CLI 4.130.2
• Static frameworks
• String catalogs under Resources folder
• String catalogs are properly included in the Bundle Copy phase of the framework.
• if I use String(localized: “my.string.key”, bundle: .module) the translation is properly read
• I can not use Text(MyFrameworkNameReources.Strings.myStringkey) since Strings are not generated at all.

If someone could hint me with ideas that would be great.