# Are there cases where the values of xcconfig cannot be overridden?

**URL:** <https://community.tuist.dev/t/are-there-cases-where-the-values-of-xcconfig-cannot-be-overridden/105>\
**Category:** Troubleshooting & how to\
**Tags:** projects\
**Created:** [October 17, 2024, 7:26am UTC](https://community.tuist.dev/t/are-there-cases-where-the-values-of-xcconfig-cannot-be-overridden/105 "2024-10-17T07:26:38Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![gustn3965](https://community.tuist.dev/user_avatar/community.tuist.dev/gustn3965/32/85_2.png) [@gustn3965](https://community.tuist.dev/u/gustn3965)\
**Post date:** [October 17, 2024, 7:26am UTC](https://community.tuist.dev/t/are-there-cases-where-the-values-of-xcconfig-cannot-be-overridden/105/1 "2024-10-17T07:26:38Z")

</div>

While configuring a project using Tuist 4.30 (It was happend in Tuist 4.26 also), I encountered instances where xcconfig values were overridden by Tuist. If a key in the build settings exists as a property of the target, I was able to resolve this by specifying the key value or using the settings’ excluding feature. However, for the TEST\_HOST of the UnitTest target, I was unable to prevent the overriding by any means, even with defaultsSettings: .none.

Ultimately, I resolved this by adding code to the settings.

Furthermore, since it seems there are exceptional cases like this, I changed the approach to avoid using xcconfig and instead only add settings through code.

Are there cases where it is impossible to prevent such overriding?

```auto

let project = Project(
    name: "unittest",
    settings: .settings(configurations: [
        .debug(name: "TEST2", xcconfig: .relativeToRoot("test.xcconfig")) // TEST_HOST = "asdfasdf"
    ], defaultSettings: .none),
    targets: [
        .target(
            name: "unittest",
            destinations: .iOS,
            product: .app,
            bundleId: "io.tuist.unittest",
            infoPlist: .extendingDefault(
                with: [
                    "UILaunchScreen": [
                        "UIColorName": "",
                        "UIImageName": "",
                    ],
                ]
            ),
            sources: ["unittest/Sources/**"],
            resources: ["unittest/Resources/**"],
            dependencies: []
        ),
        .target(
            name: "unittestTests",
            destinations: .iOS,
            product: .unitTests,
            bundleId: "io.tuist.unittestTests",
            infoPlist: .default,
            sources: ["unittest/Tests/**"],
            resources: [],
            dependencies: [.target(name: "unittest")],
            settings: .settings(configurations: [
                .debug(name: "TEST", xcconfig: .relativeToRoot("test.xcconfig"))
            ], defaultSettings: .none)
        ),
    ]
)

```

---

<div class="post-metadata">

**Author:** ![marekfort](https://community.tuist.dev/user_avatar/community.tuist.dev/marekfort/32/8_2.png) [@marekfort](https://community.tuist.dev/u/marekfort)\
**Post date:** [October 17, 2024, 10:00am UTC](https://community.tuist.dev/t/are-there-cases-where-the-values-of-xcconfig-cannot-be-overridden/105/2 "2024-10-17T10:00:37Z")

</div>

Hey @gustn3965 👋

This is most likely a bug. We merge the Tuist-generated settings with your settings [here](https://github.com/tuist/tuist/blob/75a215d1d81dc4fdc7c22f18c526f42e4deca952/Sources/TuistGenerator/Generator/ConfigGenerator.swift#L225-L228). I believe instead of taking the new value (`$1`) that’s equal to Tuist’s value, we should respect the value set by you.

Would you mind opening a GitHub issue with a reproducible sample? Additionally, would you want to try and fix this yourself? Happy to help if needed!

> I encountered instances where xcconfig values were overridden by Tuist. If a key in the build settings exists as a property of the target, I was able to resolve this by specifying the key value or using the settings’ excluding feature

Yes, this might be necessary in some cases because we don’t have access to `.xcconfig` values during generation, so we can’t decide whether to apply Tuist’s value or not.