Target bundleID mandatory supersets Project flavors (setting configurations)

[dvmrmc]

What problem or need do you have?

Current Situation

I'm setting up a project where there is a set of project configurations that create different product flavors. In my case, depending on the target API. The structure is that Project defines configurations that define base settings for each product flavor. These should contain different BundleIDs to make them distinguishable on install.

However, Target object's bundleID parameter is mandatory and upon tuist generate, the mandatory (single) bundleID supersets the desired flavors bundleIDs.

To resolve this situation and define multiple bundleIDs in a single target (one per config) you have to duplicate code and create some confussion pasing a bundleID to the Target although it'll never be used, because you'll have to write something like:

let mockSettings = settingsData.bundleId("my.project.mock")
let sandboxSettings = settingsData.bundleId("my.project.sandbox")
let productionSettings = settingsData.bundleId("my.project")

let settings: ProjectDescription.Settings = .settings(base: settingsData, configurations: [
    .debug(name: "Mock Debug", settings: mockSettings),
    .release(name: "Mock Release", settings: mockSettings),
    .debug(name: "Sandbox Debug", settings: sandboxSettings),
    .release(name: "Sandbox Release", settings: sandboxSettings),
    .debug(name: "Production Debug", settings: productionSettings),
    .release(name: "Production Release", settings: productionSettings)
])

// ...

let project = Project(
    (......)
    settings: settings,
    targets: [
        Target(
            (......)
            bundleId: .appBundleId(for: "SOMETHING IRRELEVANT"), 
            (......)
            settings: settings
        ),

note that settings have to be passed twice (one at Project and other at Target levels, making the target passed bundleId irrelevant, as it'll be superseded by the settings ones.

Potential solution

I found 2 possible approaches that could be taken here

Make bundleID an optional parameter at target level

This would mean that we don't require setting BundleID at target level, but I am not sure of the implications at project generation level, in the case of caching and setting the project I assume there may be some nasty consequences.

Type BundleID parameter and give a static .notDefined

This would mean that bundleID would be a typed citizen of tuist so that you can interop with String literals, but also provide background value to the type like parallel UID for the project that we may need for other generation/caching needs.

I fond the first option to be the best one as it is the one the provides the best flexibility and provides the most transparent platform experience as you'll operate it as you do with your project info plist files.

macOS version

13.4

Tuist version

3.20.0

Xcode version

14.3

[aashvetsov]

Here is a workaround for this (assuming that you specified bundleid for target as "NOT.SET")
Just execute this shell script:

project_file="<path_to_project_file>/project.pbxproj"
tmp_file="${PWD}/tuist.tmp"
grep -v "PRODUCT_BUNDLE_IDENTIFIER = NOT.SET" $project_file > $tmp_file
mv -f $tmp_file $project_file

If bundle_id is specified in your .xcconfig files - it will be used after this fix

[kwridan]

Thanks for raising this @dvmrmc and @aashvetsov

The way to solve this is to use a variable

e.g.

Target(
    // ...
    bundleId: "${CUSTOM_BUNDLE_ID}",
    // ...
),

and from within the xcconfig files define a different CUSTOM_BUNDLE_ID for each configuration.

xref:

• Multiple bundle IDs based on configuration for one Target #927
• Bundle Id Prefix #1291