The Composable Architecture compatibility issues

[iharandreyev]

What problem or need do you have?

When using Tuist 4.12.1 and linking TCA as .staticFramework, the following errors occured when running tests.

After updating to Tuist 4.14.0, the aforementioned errors have gone away, but now runtime crashes started occuring.

TCA uses environment checks in runtime to determine which logic to use under the hood. For iOS 17 and upwards, it uses Apple's ObservationRegistrar to observe changes. For anything below -> _PerceptionRegistrar.

However there is an issue with these checks if the project is generated with tuist.

When instantiating the registrar, everything is going according to plan:

However, when trying to mutate the registrar, non-iOS 17 if branch is used, even though when inspecting app state through lldb, the picture is different:

Updating to Tuist 4.1.15 does not help. Changing product type to .dynamicLibrary does not help. Linking TCA as project package instead of target dependency causes even more linking issues (similar to initial errors).

I've asked Brandon for help, but he suggested to seek for help here. He claims this is not the first time people are having issues with marrying Tuist and TCA, so I hope someone here may have the expertise.

The sample project can be found here

Please help

Potential solution

No response

macOS version

14.5

Tuist version

4.1.15

Xcode version

15.4

[mbrandonw]

I've asked Brandon for help, but he suggested to seek for help here. He claims this is not the first time people are having issues with marrying Tuist and TCA, so I hope someone here may have the expertise.

Just to clarify a bit, this code does not crash when run as a regular Xcode or SPM project. It seems to only happen when run in a Tuist project.

[iharandreyev]

@mbrandonw Correct. I've created a project manually and pushed it into the sample repo. It works as expected. But when running the same code from twist-generated project, the aforementioned crash occurs

[iharandreyev]

One more note, the crash occurs only on iOS 17.5 (and I assume anything 17.0 and above), but not 15.5 (an I assume anything below 17.0, as mentioned in the TCA issue discussion)

[pepicrft]

Thanks for reporting this, @iharandreyev, and thanks, @mbrandonw, for chiming in.

I marked this as a high priority, and we'll look into it next week. For context, we convert Swift Packages into Xcode native targets with build settings and phases. The standard integration of Swift Package Manager into Xcode sometimes infers some build and linking configurations that are resolved at build-time to make the integration work, and we have to look into those settings to make sure we use the same ones in our integration.

When these issues happen, we usually debug them by:

• Integrating the project through Xcode's standard integration and looking at the compiler flag that's used with the file whose compilation is failing.
• Integrating it via Tuist using native Xcode targets and seeing the compilation flag that's being used with the same file.
• Compare the two and see where the differences are.

It'd be awesome if you could help us with that part. Otherwise, we'll do that ourselves next week. Apologies @iharandreyev for the invonveniences.

[iharandreyev]

The first thing I notice is that for manually created project Xcode lists dependencies explicitly, while for tuist generated project - implicitly.
Don't know how it's supposed to be.
The logs are enormous, so digging deeper will take some time

Build Tuist-TCA-LinkingIssue_2024-05-24T11-55-27.txt

Build Tuist-TCA-LinkingIssue_Created_Manually_2024-05-24T11-56-08.txt

[kapitoshka438]

@iharandreyev I don't know if these experiments can help but I've run tests for two versions of your sample project:

Regular XCode+SPM project:

Test Suite 'LinkingIssueSampleAppTests' started at 2024-05-24 11:29:59.804.
Test Case '-[TCAIssueTests.LinkingIssueSampleAppTests testReducer]' started.
/Users/EMiniakhmetov/Documents/TCAIssue/TCAIssueTests/TCAIssueTests.swift:14: error: -[TCAIssueTests.LinkingIssueSampleAppTests testReducer] : Expected state to change, but no change occurred.

The trailing closure made no observable modifications to state. If no change to state is expected, omit the trailing closure.
Test Case '-[TCAIssueTests.LinkingIssueSampleAppTests testReducer]' failed (0.660 seconds).
Test Suite 'LinkingIssueSampleAppTests' failed at 2024-05-24 11:30:00.464.
	 Executed 1 test, with 1 failure (0 unexpected) in 0.660 (0.660) seconds

Tuist generated project:

objc[42120]: Class _TtC22ComposableArchitecture6Logger is implemented in both /Users/EMiniakhmetov/Library/Developer/CoreSimulator/Devices/614101E6-FC56-4123-BA43-1E5368DC06B6/data/Containers/Bundle/Application/556C4807-55D9-4FF7-8DCE-8E73BBEF47A6/Tuist_TCA_LinkingIssue.app/Tuist_TCA_LinkingIssue (0x102941da0) and /Users/EMiniakhmetov/Library/Developer/CoreSimulator/Devices/614101E6-FC56-4123-BA43-1E5368DC06B6/data/Containers/Bundle/Application/556C4807-55D9-4FF7-8DCE-8E73BBEF47A6/Tuist_TCA_LinkingIssue.app/PlugIns/Tuist_TCA_LinkingIssueTests.xctest/Tuist_TCA_LinkingIssueTests (0x106a8cc80). One of the two will be used. Which one is undefined.
Test Suite 'All tests' started at 2024-05-24 11:39:43.137.
Test Suite 'Tuist_TCA_LinkingIssueTests.xctest' started at 2024-05-24 11:39:43.137.
Test Suite 'LinkingIssueSampleAppTests' started at 2024-05-24 11:39:43.138.
Test Case '-[Tuist_TCA_LinkingIssueTests.LinkingIssueSampleAppTests testReducer]' started.
Could not cast value of type 'Observation.ObservationRegistrar' (0x210440b10) to 'Perception._PerceptionRegistrar' (0x10293dfd8).

Then I added "-ObjC" flag to OTHER_LDFLAGS to the main target build settings for the Tuist generated project and the result became similar to the regular project:

Test Suite 'All tests' started at 2024-05-24 11:41:36.561.
Test Suite 'Tuist_TCA_LinkingIssueTests.xctest' started at 2024-05-24 11:41:36.561.
Test Suite 'LinkingIssueSampleAppTests' started at 2024-05-24 11:41:36.562.
Test Case '-[Tuist_TCA_LinkingIssueTests.LinkingIssueSampleAppTests testReducer]' started.
/Users/EMiniakhmetov/Downloads/Tuist-CTA-LinkingIssue-main/Tuist-TCA-LinkingIssue/Tests/Tuist-TCA-LinkingIssueTests.swift:14: error: -[Tuist_TCA_LinkingIssueTests.LinkingIssueSampleAppTests testReducer] : Expected state to change, but no change occurred.

The trailing closure made no observable modifications to state. If no change to state is expected, omit the trailing closure.
Test Case '-[Tuist_TCA_LinkingIssueTests.LinkingIssueSampleAppTests testReducer]' failed (0.044 seconds).
Test Suite 'LinkingIssueSampleAppTests' failed at 2024-05-24 11:41:36.606.
	 Executed 1 test, with 1 failure (0 unexpected) in 0.044 (0.044) seconds
Test Suite 'Tuist_TCA_LinkingIssueTests.xctest' failed at 2024-05-24 11:41:36.606.
	 Executed 1 test, with 1 failure (0 unexpected) in 0.044 (0.045) seconds
Test Suite 'All tests' failed at 2024-05-24 11:41:36.606.
	 Executed 1 test, with 1 failure (0 unexpected) in 0.044 (0.045) seconds

[pepicrft]

@hisaac and @thedavidharris added some documentation recently explaining some additional configuration that might required for packages that have Objective-C code.
Note that dependency managers like Swift Package Manager, might try to make things work at build-time. We tried to do the same too by applying those flags automatically, but as @thedavidharris pointed out, that's not a good idea because it can cause an increase in the binary size or duplicated symbols.

[pepicrft]

@iharandreyev do you mind trying the change suggested by @kapitoshka438 and reporting back?

[Narsail]

@pepicrft I'm curious about the design decision to deviate from what swift package manager is doing (including -ObjC and risk possible side effects)?

For me, the missing -ObjC resulted in a 3 day long venture into testing multiple different setups to modularise my codebase with tuist. I'd rather put it in as a default (something iOS developers are used to working with swift packager manager) and remove it when it causes side-effects.

Going a different way than the package manager might cause onboarding friction to tuist (and has for me).

^ Can someone elaborate on the possible side effects that including -ObjC has? The documentation wasn't clear on that point.

[fortmarek]

@Narsail

I'm curious about the design decision to deviate from what swift package manager is doing (including -ObjC and risk possible side effects)?

@thedavidharris went into this here. Applying -ObjC flag whenever a target has ObjC sources is not the best path forward. We'd love to include when it's necessary but there's not really a good way to do that.

Going a different way than the package manager might cause onboarding friction to tuist (and has for me).

We're trying to stay as close to SPM as possible. But applying -ObjC whenver a target has objc sources is actually not what SPM does. In fact, it doesn't seem SPM applies the -ObjC flag directly at all. We haven't been able to figure out why SPM integration doesn't need the linker flag in some cases whereas we do. Ideally, we'd investigate further and see if we can apply some default that would actually align with SPM.

[Narsail]

Thank you. That was helpful 🙏

[iharandreyev]

@iharandreyev do you mind trying the change suggested by @kapitoshka438 and reporting back?

I've tried the method, and it did work. What worries me is that I don't understand why (mostly since I am not knowledgeable about the ways of Xcode linking and building things)

I've also tried setting the flag manually to individual dependency targets (swift-perception and swift-composable-architecture), but no luck.

@pepicrft Are we still interested in contents of Xcode logs? I've started building logs diffing tool, but was not able to finish it. And don't know if there's any necessity in it anymore.

[pepicrft]

I debugged a few projects with TCA, and noticed that the crashes happen when the Pointfree packages are linked statically, the default one that Tuist sets to packages integrated via Tuist. If you set the product to be dynamic (i.e., .framework), then it works. Here's the code snippet:

#if TUIST
import ProjectDescription

let packageSettings = PackageSettings(
    productTypes: [
            "ComposableArchitecture": .framework,
            "Dependencies": .framework,
            "Clocks": .framework,
            "ConcurrencyExtras": .framework,
            "CombineSchedulers": .framework,
            "IdentifiedCollections": .framework,
            "OrderedCollections": .framework,
            "_CollectionsUtilities": .framework,
            "DependenciesMacros": .framework,
            "SwiftUINavigationCore": .framework,
            "Perception": .framework,
            "CasePaths": .framework,
            "CustomDump": .framework,
            "XCTestDynamicOverlay": .framework
        ]
)
#endif

I was quite surprised that the packages wouldn't work with static linking, but then I checked how SPM integrates the packages into projects, and they do it dynamically too, something that makes me think that the packages might be strongly coupled to the dynamic linking through their usage of APIs.

[iharandreyev]

I debugged a few projects with TCA, and noticed that the crashes happen when the Pointfree packages are linked statically, the default one that Tuist sets to packages integrated via Tuist. If you set the product to be dynamic (i.e., .framework), then it works. Here's the code snippet:

#if TUIST
import ProjectDescription

let packageSettings = PackageSettings(
    productTypes: [
            "ComposableArchitecture": .framework,
            "Dependencies": .framework,
            "Clocks": .framework,
            "ConcurrencyExtras": .framework,
            "CombineSchedulers": .framework,
            "IdentifiedCollections": .framework,
            "OrderedCollections": .framework,
            "_CollectionsUtilities": .framework,
            "DependenciesMacros": .framework,
            "SwiftUINavigationCore": .framework,
            "Perception": .framework,
            "CasePaths": .framework,
            "CustomDump": .framework,
            "XCTestDynamicOverlay": .framework
        ]
)
#endif

I was quite surprised that the packages wouldn't work with static linking, but then I checked how SPM integrates the packages into projects, and they do it dynamically too, something that makes me think that the packages might be strongly coupled to the dynamic linking through their usage of APIs.

It turns out that for this specific case only a subset of dependencies should be dynamic:

let packageSettings = PackageSettings(
    productTypes: [
        "ComposableArchitecture": .framework,
        "Perception": .framework
    ]
)

results in crash-free test.
However tuist generate outputs a warning

The following warnings need attention:
 · Target 'XCTestDynamicOverlay' has been linked from target 'ComposableArchitecture' and target 'Perception', it is a static product so may introduce unwanted side effects.

Adding this dependency as dynamic framework

let packageSettings = PackageSettings(
    productTypes: [
        "ComposableArchitecture": .framework,
        "Perception": .framework,
        "XCTestDynamicOverlay": .framework
    ]
)

results in to tuist warnings an a crash-free test execution.