Skip to main content

Project.swift

Projects are defined in Project.swift files, which we refer to as manifest files. Manifests need to import the framework ProjectDescription which contains all the classes and enums that are available for you to describe your projects. The snippet below shows an example project manifest:


let project = Project(    name: "MyProject",    organizationName: "MyOrg",    targets: [        Target(            name: "App",            platform: .iOS,            product: .app,            bundleId: "io.tuist.App",            infoPlist: "Config/App-Info.plist",            sources: ["Sources/**"],            resources: [                "Resources/**",                .folderReference(path: "Stubs"),                .folderReference(path: "ODR", tags: ["odr_tag"])            ],            headers: Headers(                public: ["Sources/public/A/**", "Sources/public/B/**"],                private: "Sources/private/**",                project: ["Sources/project/A/**", "Sources/project/B/**"]            ),            dependencies: [                .project(target: "Framework1", path: "../Framework1"),                .project(target: "Framework2", path: "../Framework2")            ]        )    ],    schemes: [        Scheme(            name: "App-Debug",            shared: true,            buildAction: BuildAction(targets: ["App"]),            testAction: TestAction(targets: ["AppTests"]),            runAction: RunAction(executable: "App")        ),        Scheme(            name: "App-Release",            shared: true,            buildAction: BuildAction(targets: ["App"]),            runAction: RunAction(executable: "App")        )    ],    additionalFiles: [        "Dangerfile.swift",        "Documentation/**",        .folderReference(path: "Website")    ])

Project#

A Project.swift should initialize a variable of type Project. It can take any name, although we recommend to stick to project. A project accepts the following attributes:

PropertyDescriptionTypeRequiredDefault
nameName of the project. It's used to determine the name of the generated Xcode project.StringYes
organizationNameName of the organization used by Xcode as copyright when generating new files.StringNo
packagesList of Swift Packages used by the project.[Package]No[]
targetsList of targets within the project.[Target]Yes[]
schemesList of custom schemes within the project, default scheme for each target is generated by default (see The Configuration generationOptions to configure this behavior)[Scheme]No[]
settingsProject build settings and configuration filesSettingsNo[]
fileHeaderTemplateLets you define custom file header template macro for built-in Xcode file templates.FileHeaderTemplateNo
additionalFilesList of files to include in the project - these won't be included in any of the build phases.[FileElement]No[]
resourceSynthesizersList of resource synthesizer for generating accessors for resources.[ResourceSynthesizer]No.default

Package#

You can add Swift Packages very similarly to how you add dependencies in a Package.swift:

For remote:

.package(url: "https://github.com/tuist/XcodeProj", .exact("6.7.0"))
.package(url: "https://github.com/tuist/XcodeProj", from: "6.7.0")
.package(url: "https://github.com/tuist/XcodeProj", "6.6.1"..<"6.8.0")

For local:

.package(path: "MyLibrary")

Targets can then depend on products from these Swift Packages. See Dependencies

Package.resolved

Tuist creates a .package.resolved file, so your team can share the same versions of dependencies without committing your workspace.

Target#

Each target in the list of project targets can be initialized with the following attributes:

PropertyDescriptionTypeRequiredDefault
nameThe name of the target. The Xcode project target and the derivated product take the same name.StringYes
platformThe platform the target product is built for.PlatformYes
productThe type of build product this target will output.ProductYes
productNameThe built product name.StringNo$(TARGET_NAME)
deploymentTargetThe minimum iOS version your product will support.#deployment-targetNo
bundleIdThe product bundle identifier.StringYes
infoPlistRelative path to the Info.plistInfoPlistYes
resourcesList of files to include in the resources build phase. Note that localizable files, *.lproj, are supported.ResourceFileElementsNo
copyFilesCopy files actions allow defining copy files build phases.[CopyFilesAction]No
headersThe target headers.HeadersNo
entitlementsPath to the entitlement file.PathNo
actionsTarget actions allow defining extra script build phases.[TargetAction]No[]
dependenciesList of target dependencies.[TargetDependency] No[]
sourcesSource files that are compiled by the target. Any playgrounds matched by the globs used in this property will be automatically added.SourceFilesListYes
settingsTarget build settings and configuration files.SettingsNo
coreDataModelsCore Data models.[CoreDataModel]No
environmentList of variables that will be set to the scheme that Tuist automatically generates for the target.[String: String]No[:]
launchArgumentsList of launch arguments that will be set to the scheme that Tuist automatically generates for the target.[LaunchArgument]No[]
import ProjectDescription
let target = Target(name: "App",                    platform: .iOS,                    product: .app,                    bundleId: "io.tuist.App",                    infoPlist: "Info.plist",                    sources: "Sources/**",                    dependencies: [])

Source file list#

It represents a list of source files that are part of a target:

PropertyDescriptionTypeRequiredDefault
globsPath to the source files. They are represented by a glob pattern and the compiler flags.[SourceFileGlob]No
ExpressibleByStringLiteral and ExpressibleByArrayLiteral

The list of source files can be initialized with a string that represents the glob pattern, or an array of strings, which represents a list of glob patterns. In both cases the comiler flags will have no value.

Patterns matching the same paths

If multiple patterns match the same paths, the latest one takes preference over the others. That also means that the latest compiler flags will be applied.

Source file glob#

It represents a glob pattern that refers to source files and the compiler flags (if any) to be set in the build phase:

PropertyDescriptionTypeRequiredDefault
globGlob pattern to the source files.PathYes
excludingGlob patterns for source files that will be excluded.[Path]No[]
compilerFlagsThe compiler flags to be set to the source files in the sources build phase.StringNo

Copy Files Action#

Copy files actions, represented as target copy files build phases, are useful to associate project files and products of other targets with the target and copies them to a specified destination, typically a subfolder within a product. This action may be used multiple times per target.

CaseDescription
.productsDirectory(name: String, subpath: String?, files: [FileElement])A copy files action for the products directory.
.wrapper(name: String, subpath: String?, files: [FileElement])A copy files action for the wrapper directory.
.executables(name: String, subpath: String?, files: [FileElement])A copy files action for the executables directory.
.resources(name: String, subpath: String?, files: [FileElement])A copy files action for the resources directory.
.javaResources(name: String, subpath: String?, files: [FileElement])A copy files action for the java resources directory.
.frameworks(name: String, subpath: String?, files: [FileElement])A copy files action for the frameworks directory.
.sharedFrameworks(name: String, subpath: String?, files: [FileElement])A copy files action for the shared frameworks directory.
.sharedSupport(name: String, subpath: String?, files: [FileElement])A copy files action for the shared support directory.
.plugins(name: String, subpath: String?, files: [FileElement])A copy files action for the plugins directory.

The following example shows the definition of a copy files action that copy template files to the shared support directory and adds it inside a subfolder Templates:

.sharedSupport(name: "Copy Templates", subpath: "Templates", files: "MyTemplates/**")

The following example shows the definition of a copy files action that copy font files to the resources directory and adds it inside a subfolder Fonts:

.resources(name: "Copy Fonts", subpath: "Fonts", files: "MyFonts/**")

Headers#

It represents the target headers:

PropertyDescriptionTypeRequiredDefault
publicRelative glob pattern that points to the public headers.FileListNo
privateRelative glob pattern that points to the private headers.FileListNo
projectRelative glob pattern that points to the project headers.FileListNo

File List#

It represents a list of glob patterns that refer to files:

PropertyDescriptionTypeRequiredDefault
globsGlob pattern to the files.[Path](#path)Yes

Core Data Model#

The CoreDataModel type represents a Core Data model:

PropertyDescriptionTypeRequiredDefault
pathRelative path to the Core Data model.PathYes
currentVersionCurrent version without the extension.StringYes

Platform#

The platform type represents the platform a target is built for. It can be any of the following types:

CaseDescription
.iOSThe iOS platform
.macOSThe macOS platform
.tvOSThe tvOS platform
.watchOSThe watchOS platform

Product#

The type of build product this target will output. It can be any of the following types:

CaseDescription
.appAn application.
.staticLibraryA static library.
.dynamicLibraryA dynamic library.
.frameworkA dynamic framework.
.staticFrameworkA static framework.
.unitTestsA unit tests bundle.
.uiTestsA UI tests bundle.
.bundleA custom bundle. (currently only iOS resource bundles are supported).
.appExtensionAn application extension.
.stickerPackExtensionA sticker pack extension.
.watch2AppA Watch application. (watchOS platform only) .
.watch2ExtensionA Watch application extension. (watchOS platform only).
.messagesExtensionAn iMessage extension. (iOS platform only)
.appClipAn appClip. (iOS platform only).

InfoPlist#

The InfoPlist model represents a target Info.plist file. It can have any of the following values:

CaseDescription
.file(path: Path)The path to an existing Info.plist file.
.dictionary([String: InfoPlist.Value])A dictionary with the Info.plist content. Tuist generates the Info.plist file at the generation time.
.extendingDefault(with: [String: InfoPlist.Value])It indicates Tuist to provide the default content for the target the InfoPlist belongs to, and extend it with the given values.
ExpressibleByStringLiteral

The InfoPlist model conforms the ExpressibleByStringLiteral protocol, which means that it can be initialized with a String. In that case, the string is the path to the Info.plist file.

InfoPlist.Value#

It represents the values of the InfoPlist file dictionary. The reason this type exists is to ensure that the values used to define the content of the dynamically generated Info.plist files are valid:

CaseDescription
.string(String)It represents a string value.
.integer(Int)It represents an integer value.
.boolean(Bool)It represents a boolean value.
.dictionary([String: InfoPlist.Value])It represents a dictionary value.
.array([InfoPlist.Value])It represents an array value.
ExpressiveByLiteral

InfoPlist.Value conforms to the ExpressiveByLiteral protocols and therefore, it can be initialized with an instance of the primitive type that they encapsulate.

Target Action#

Target actions, represented as target script build phases, are useful to define actions to be executed before of after the build process of a target.

CaseDescription
.pre(tool: String, arguments: String..., name: String, inputPaths: [Path], inputFileListPaths: [Path], outputPaths: [Path], outputFileListPaths: [Path], basedOnDependencyAnalysis: Bool, runForInstallBuildsOnly: Bool)Action executed before the target-specific build phases where tool is the name of the tool to be executed.
.pre(path: Path, arguments: String..., name: String, inputPaths: [Path], inputFileListPaths: [Path], outputPaths: [Path], outputFileListPaths: [Path], basedOnDependencyAnalysis: Bool, runForInstallBuildsOnly: Bool)Action executed before the target-specific build phases where path is the path to the tool to be executed.
.pre(script: String, name: String, inputPaths: [Path], inputFileListPaths: [Path], outputPaths: [Path], outputFileListPaths: [Path], basedOnDependencyAnalysis: Bool, runForInstallBuildsOnly: Bool)Action executed before the target-specific build phases where script is an embedded script to run. It is advised to keep embedded scripts as small as possible.
.post(tool: String, arguments: String..., name: String, inputPaths: [Path], inputFileListPaths: [Path], outputPaths: [Path], outputFileListPaths: [Path], basedOnDependencyAnalysis: Bool, runForInstallBuildsOnly: Bool)Action executed after all the target-specific build phases where tool is the name of the tool to be executed.
.post(path: Path, arguments: String..., name: String, inputPaths: [Path], inputFileListPaths: [Path], outputPaths: [Path], outputFileListPaths: [Path], basedOnDependencyAnalysis: Bool, runForInstallBuildsOnly: Bool)Action executed after all the target-specific build phases where path is the path to the tool to be executed.
.post(script: String, name: String, inputPaths: [Path], inputFileListPaths: [Path], outputPaths: [Path], outputFileListPaths: [Path], basedOnDependencyAnalysis: Bool, runForInstallBuildsOnly: Bool)Action executed after all the target-specific build phases where script is an embedded script to run. It is advised to keep embedded scripts as small as possible

The following example shows the definition of an action that runs the my_custom_script.sh passing the argument "hello":

.pre(path: "my_custom_script.sh", arguments: ["hello"], name: "My Custom Script Phase")

The following example shows the definition of an action that runs the my_custom_script.sh defining input and output files:

.pre(path: "my_custom_script.sh", name: "My Custom Script Phase", inputFileListPaths: [ "Data/Cars.raw.json", "Data/Drivers.raw.json" ], outputFileListPaths: [ "Data/Cars.swift", "Data/Drivers.swift" ])

The following example shows the definition of an action that runs the my_custom_script.sh on all incremental builds, regardless of whether or not something has changed:

.pre(path: "my_custom_script.sh", name: "My Custom Script Phase", basedOnDependencyAnalysis: false)

The following example shows the definition of an action that runs the my_custom_script.sh only for install builds:

.pre(path: "my_custom_script.sh", name: "My Custom Script Phase", runForInstallBuildsOnly: true)

Preset Build Configuration#

It represents the default build configurations available:

CaseDescription
.debugDebug build configuration, traditionally used during local development.
.releaseRelease build configuration.

Scheme#

A Scheme defines a collection of targets to Build, Run, Test, Profile, Analyze and Archive:

PropertyDescriptionTypeRequiredDefault
nameThe name of the scheme.StringYes
sharedMarks the scheme as shared (i.e. one that is checked in to the repository and is visible to xcodebuild from the command line).BoolNotrue
buildActionAction that builds the project targets.BuildActionNo
runActionAction that runs project built products.RunActionNo
testActionAction that runs the project tests.TestActionNo
archiveActionAction that runs the project archive.ArchiveActionNo
profileActionAction that profiles the project.ProfileActionNo
analyzeActionAction that analyze the project.AnalyzeActionNo
Auto-generation of schemes

Tuist will auto-generate a scheme for each target by default in addition to any defined schemes. This however can be disabled if needed via the Configuration generationOptions.

Schemes & Configurations

When generating the default target schemes, the 'Debug' configuration is used for the Run, Test and Analyze actions and the 'Release' configuration is used for the Profile & Archive actions. If those configurations aren't specified, the first (alphabetically ordered) custom configuration with the corresponding variant is selected in their place.

Extension Schemes

Schemes for extensions have additional properties and settings, Tuist automatically applies those to any scheme in which the first Target in the Build Action's list of targets is an extension.

Archive, profile & analyze actions definition

Take in count that ArchiveAction, ProfileAction and AnalyzeAction when are defined in a Scheme in isolated or in set, needs also a definition of BuildAction in the signature of the scheme. Without the previously option commented the scheme will have the these their definitions by default.

Build Action#

It represents the scheme action that builds targets:

PropertyDescriptionTypeRequiredDefault
targetsA list of targets to build, which are defined in the project.[TargetReference]No
preActionsA list of actions that are executed before starting the build process.[ExecutionAction]Yes[]
postActionsA list of actions that are executed after the build process.[ExecutionAction]Yes[]
runPostActionsOnFailureWhether the post actions should be run in the case of a failureBoolNofalse

Run action#

It represents the scheme action that runs the built products on the supported platforms:

PropertyDescriptionTypeRequiredDefault
configIndicates the build configuration the product should run with.PresetBuildConfigurationNo.debug
executableThe name of the executable or target to run.TargetReferenceNo
argumentsCommand line arguments passed on launch and environment variables.ArgumentsNo
optionsList of options to set to the action.RunActionOptionsNo.options()
diagnosticsOptionsList of diagnostics options to set to the action.[SchemeDiagnosticsOption]No[.mainThreadChecker]

Alternatively, when leveraging custom configurations, the configuration name can be explicitly specified:

PropertyDescriptionTypeRequiredDefault
configurationNameIndicates the build configuration the product should run with.StringYes

Test Action#

You can create a test action with either a set of test targets or test plans.

Test Plans

Test plans do not support all properties (those are part of the plan itself). Use the testPlans factory method instead of the initializer to create a test action using test plans instead of test targets (details below).

PropertyDescriptionTypeRequiredDefault
targetsA list of testable targets, that are targets which are defined in the project with testable information.[TestableTarget]Yes[]
argumentsCommand line arguments passed on launch and environment variables.ArgumentsNo
buildConfigurationBuild configuration to run the test with.PresetBuildConfigurationNo.debug
coverageWhether the scheme should or not gather the test coverage data.BoolNofalse
codeCoverageTargetsA list of targets you want to gather the test coverage data for them, which are defined in the project.[TargetReference]No[]
expandVariableFromTargetA target that will be used to expand the variables defined inside Environment Variables definition (e.g. $SOURCE_ROOT)TargetReferenceNo
preActionsA list of actions that are executed before starting the tests-run process.[ExecutionAction]No[]
postActionsA list of actions that are executed after the tests-run process.[ExecutionAction]No[]
diagnosticsOptionsList of diagnostics options to set to the action.[SchemeDiagnosticsOption]Yes[.mainThreadChecker]
languageLanguage used to run the tests.StringNo
regionRegion used to run the tests.StringNo

Alternatively, when leveraging custom configurations, the configuration name can be explicitly specified:

PropertyDescriptionTypeRequiredDefault
configurationNameIndicates the build configuration to run the test with.StringNo

When using test plans:

PropertyDescriptionTypeRequiredDefault
defaultPath to a xctestplan file.PathNo
otherPaths to other xctestplan files.[Path]No[]
Launch Arguments & Environment

By default the Test & Profile actions will inherit the Run action's Launch & Environment when not explicitly specified.

Execution Action#

Scheme run scripts can be defined with the following attributes:

PropertyDescriptionTypeRequiredDefault
titleName of a script.StringNo"Run Script"
scriptTextAn inline shell script.TargetReferenceNo
targetName of the build or test target that will provide the action's build settings.StringNo

Testable Target#

Testable target descibe target and tests information.

PropertyDescriptionTypeRequiredDefault
targetThe target name and its project path.TargetReferenceYes
skippedSkip test target from TestAction.BoolNofalse
skippedSkip test target from TestAction.BoolNofalse
parallelizableExecute tests in parallel.BoolNofalse
randomExecutionOrderingExecute tests in random order.BoolNofalse

Arguments#

Arguments contain commandline arguments passed on launch and Environment variables.

PropertyDescriptionTypeRequiredDefault
environmentThe environment variables that are passed by the scheme when running a scheme action.[String: String]No[:]
launchArgumentsCommand line launch arguments that are passed by the scheme when running a scheme action.[LaunchArgument]`No[]

Launch Argument#

It represents an argument that is passed when running a scheme's action:

PropertyDescriptionTypeRequiredDefault
nameThe name of the launch argumentStringYes
isEnabledWhether the argument is enabled or notBoolYes

Run Action Options#

Run action options represent the configuration of a run action.

PropertyDescriptionTypeRequiredDefault
storeKitConfigurationPathPath of the StoreKit Configuration file that is used to control and debug StoreKit purchases. It only works with Xcode 12 and above.PathNo
simulatedLocationA simulated GPS location to use when running the app.SimulatedLocationNo

Simulated Location#

Simulated location represents a GPS location that is used when running an app on the simulator.

PropertyDescriptionTypeRequiredDefault
identifierThe identifier of the location (e.g. London, England)StringNo
gpxFilePath to a .gpx file that indicates the locationPathNo

SimulatedLocation provides convenient initializers for the following locations:

LocationInitializer
London, England.london
Johannesburg, South Africa.johannesburg
Moscow, Russia.moscow
Mumbai, India.mumbai
Tokyo, Japan.tokyo
Sydney, Australia.sydney
Hong Kong, China.hongKong
Honolulu, HI, USA.honolulu
San Francisco, CA, USA.sanFrancisco
Mexico City, Mexico.mexicoCity
New York, NY, USA.newYork
Rio De Janeiro, Brazil.rioDeJaneiro

Scheme Diagnostics Option#

Diagnostics options represent the configurable diagnostics-related settings in the schemes' run and test actions.

CaseDescription
.mainThreadCheckerEnable the main thread checker.

Archive Action#

PropertyDescriptionTypeRequiredDefault
configurationNameIndicates the build configuration to run the archive with.StringYes
revealArchiveInOrganizerIf set to true, Xcode will reveal the Organizer on completion.BoolNoYes
customArchiveNameSet if you want to override Xcode's default archive name.StringNo
preActionsA list of actions that are executed before starting the archive process.[ExecutionAction]No[]
postActionsA list of actions that are executed after the archive process.[ExecutionAction]No[]

Profile action#

It represents the scheme action that profiles the built products on the supported platforms:

PropertyDescriptionTypeRequiredDefault
configIndicates the build configuration the product should be profiled with.PresetBuildConfigurationNo.release
executableThe name of the executable or target to profile.TargetReferenceNo
argumentsCommand line arguments passed on launch and environment variables.ArgumentsNo

Alternatively, when leveraging custom configurations, the configuration name can be explicitly specified:

PropertyDescriptionTypeRequiredDefault
configurationNameIndicates the build configuration the product should be profiled with.StringNo
Launch Arguments & Environment

By default the Test & Profile actions will inherit the Run action's Launch & Environment when not explicitly specified.

Analyze action#

It represents the scheme action that analyzes the built products:

PropertyDescriptionTypeRequiredDefault
configIndicates the build configuration the product should be analyzed with.PresetBuildConfigurationNo.debug

Alternatively, when leveraging custom configurations, the configuration name can be explicitly specified:

PropertyDescriptionTypeRequiredDefault
configurationNameIndicates the build configuration the product should be analyzed with.StringYes

Settings#

A Settings object contains an optional dictionary with build settings and relative path to an .xcconfig file. It is initialized with the following attributes:

PropertyDescriptionTypeRequiredDefault
baseA dictionary with build settings that are inherited from all the configurations.SettingsDictionaryNo[:]
debugThe debug configuration settings.ConfigurationNo
releaseThe release configuration settings.ConfigurationNo
defaultSettingsAn enum specifying the set of default settings.DefaultSettingsNo.recommended

To specify multiple configurations beyond the default Debug and Release configuration (e.g. Debug, Beta, Release), Settings can alternatively be initialized with the following attributes:

PropertyDescriptionTypeRequiredDefault
baseA dictionary with build settings that are inherited from all the configurations.SettingsDictionaryNo[:]
configurationsA list of custom configurations.[CustomConfiguration]Yes
defaultSettingsAn enum specifying the set of default settings.DefaultSettingsNo.recommended
Custom Configurations

The list of custom configurations should have unique names and can't be empty. Please use the alternate settings initializer to leverage the default Debug & Release configurations.

SettingsDictionary#

SettingsDictionary is a typealias for the [String: SettingValue] dictionary, which is used to define a map of xcodebuild settings.

Besides the ability to define typed strings for these settings, Tuist has methods to avoid having typos when using strings for the keys. For example, instead of defining your dictionary this way:

let baseSettings: [String: SettingValue] = [  "ENABLE_BITCODE": "YES",  "SWIFT_COMPILATION_MODE": "wholemodule",]

It can be written this way as well:

let baseSettings = SettingsDictionary()    .bitcodeEnabled(true)    .swiftCompilationMode(.wholemodule)
Dictionary Literal

When using dictionary literals, it's necessary to set the type of the dictionary to SettingsDictionary to satisfy the compiler, as in let mySettings: SettingsDictionary = [:]

Here is the list of functions provided by Tuist:

SubjectFunction SignatureDescription
Code Signingfunc manualCodeSigning(identity: String? = nil, provisioningProfileSpecifier: String? = nil) -> SettingsDictionarySets "CODE_SIGN_STYLE" to "Manual", "CODE_SIGN_IDENTITY" to identity, and "PROVISIONING_PROFILE_SPECIFIER" to provisioningProfileSpecifier
Code signingfunc automaticCodeSigning(devTeam: String) -> SettingsDictionarySets "CODE_SIGN_STYLE" to "Automatic" and "DEVELOPMENT_TEAM" to devTeam
Code signingfunc codeSignIdentityAppleDevelopment() -> SettingsDictionarySets "CODE_SIGN_IDENTITY" to "Apple Development"
Code signingfunc codeSignIdentity(_ identity: String) -> SettingsDictionarySets "CODE_SIGN_IDENTITY" to identity
Versioningfunc currentProjectVersion(_ version: String) -> SettingsDictionarySets "CURRENT_PROJECT_VERSION" to version
Versioningfunc appleGenericVersioningSystem() -> SettingsDictionarySets "VERSIONING_SYSTEM" to "apple-generic"
Versioningfunc versionInfo(_ version: String, prefix: String? = nil, suffix: String? = nil) -> SettingsDictionarySets "VERSION_INFO_PREFIX" to version. If prefix and suffix are not nil, they\'re used as "VERSION_INFO_PREFIX" and "VERSION_INFO_SUFFIX" respectively.
Swift Settingsfunc swiftVersion(_ version: String) -> SettingsDictionarySets "SWIFT_VERSION" to version
Swift Settingsfunc otherSwiftFlags(_ flags: String...) -> SettingsDictionarySets "OTHER_SWIFT_FLAGS" to flags
Swift Settingsfunc swiftCompilationMode(_ mode: SwiftCompilationMode) -> SettingsDictionarySets "SWIFT_COMPILATION_MODE" to the available SwiftCompilationMode ("singlefile" or "wholemodule")
Swift Settingsfunc swiftOptimizationLevel(_ level: SwiftOptimizationLevel) -> SettingsDictionarySets "SWIFT_OPTIMIZATION_LEVEL" to the available SwiftOptimizationLevel ("-O", "-Onone" or "-Osize")
Bitcodefunc bitcodeEnabled(_ enabled: Bool) -> SettingsDictionarySets "ENABLE_BITCODE" to "YES" or "NO"

Notice that you don't depend exclusively on Tuist's built-in functions. You can create your own SettingsDictionary extension methods and add them to your Project description helpers this way:

public extension SettingsDictionary {  func setSomeBuildSetting(_ value: String) -> SettingsDictionary {      merging(["SOME_BUILD_SETTING": SettingValue(stringLiteral: value)])  }}

Configuration#

A Configuration object describes the build settings and the .xcconfig file of a project or target. It is initialized with the following attributes:

PropertyDescriptionTypeRequiredDefault
SettingsA dictionary that contains the build settings.SettingsDictionaryNo[:]
PathThe path to the xcconfig file.PathNo

Custom Configuration#

A CustomConfiguration allows specifying a named build configuration.

This is similar to Configuration, however allows specifying a custom name (e.g. "Beta") and configuration variant (.debug or .release) to help Tuist select the most appropriate default build settings.

For example, a .debug configuration would get SWIFT_OPTIMIZATION_LEVEL = -Onone whereas a .release would get SWIFT_OPTIMIZATION_LEVEL = -Owholemodule.

CaseDescription
.debug(name: String, settings: SettingsDictionary, xcconfig: Path?)A custom debug configuration.
.release(name: String, settings: SettingsDictionary, xcconfig: Path?)A custom release configuration.

SettingValue#

A SettingValue can be one of the following options:

CaseDescription
.string(String)A single setting value for example "DEBUG=1".
.array([String])Multi-value setting value for example ["$(inherited)", "DEBUG=1"].

It conforms the ExpressibleByStringLiteral and ExpressibleByArrayLiteral protocols and therefore it can be initialized with a string or an array directly.

FileElement#

A FileElement can be one of the following options:

CaseDescription
.glob(pattern: Path)A file path (or glob pattern) to include. For convenience, a string literal can be used as an alternate way to specify this option.
.folderReference(path: Path)A directory path to include as a folder reference.

Resource Synthesizer#

A ResourceSynthesizer creates accessors, so you can use your resources in a type-safe way. To read more about them, head over to resource documentation.

ResourceFileElements#

List of files to include in the resources build phase.

PropertyDescriptionTypeRequiredDefault
resourcesResources list.[ResourceFileElement]Yes[]

It conforms the ExpressibleByStringLiteral and ExpressibleByArrayLiteral protocols and therefore it can be initialized with a string or an array directly.

ResourceFileElement#

A ResourceFileElement can be one of the following options:

CaseDescription
.glob(pattern: Path, tags: [String])A file path (or glob pattern) to include and ODR tags list. For convenience, a string literal can be used as an alternate way to specify this option.
.folderReference(path: Path, tags: [String])A directory path to include as a folder reference and ODR tags list.

DefaultSettings#

A DefaultSettings can be one of the following options:

CaseDescription
.recommended(excluding: Set<String>)Recommended settings including warning flags to help you catch some of the bugs at the early stage of development. If you need to override certain settings in a CustomConfiguration it's possible to add those keys to excluding.
.essential(excluding: Set<String>)A minimal set of settings to make the project compile without any additional settings for example 'PRODUCT_NAME' or 'TARGETED_DEVICE_FAMILY'. If you need to override certain settings in a CustomConfiguration it's possible to add those keys to excluding.
.noneTuist won't generate any build settings for the target or project.
Essential Settings

The .essential option can be used in the event all warnings are defined in an xcconfig file to prevent Tuist from overriding them at the project or target level.

None settings

Projects may fail to compile if some essential settings are missing. Use .none only if you are specifying all the necessary build settings manually or via xcconfig files.

Deployment Target#

The DeploymentTarget model represents the minimum operating system version your product will support. It can have any of the following values:

CaseDescription
.iOS(targetVersion: String, devices: DeploymentDevice)The minimum iOS version and the list of devices your product will support.
.macOS(targetVersion: String)The minimum macOS version your product will support.

Deployment Device#

The DeploymentDevice model represents the device your product will support. It can have any of the following values:

CaseDescription
.iphoneAn iPhone device.
.ipadAn iPad device.
.macA mac device.

Path#

A path represents a path to a file, directory, or a group of files represented by a glob expression. Paths can be relative and absolute. We discourage using absolute paths because they create a dependency with the environment where they are defined.

CaseDescription
.relativeToCurrentFile(String)Initialize a path that is relative to the file that defines the path.
.relativeToManifest(String)Initialize a path that is relative to the directory that contains the manifest file being loaded, for example the directory that contains the Project.swift file.
.relativeToRoot(String)Initialize a path that is relative to the closest directory that contains a Tuist or a .git directory.
ExpressibleByStringLiteral

The path can be initialized with a plain string. It's equivalent to using .relativeToManifest. except when the path starts with //, in which case the path is considered relative to the root directory.

Target Reference#

A target within a specified project. The project is specified through the path and should contain the target name.

PropertyDescriptionTypeRequiredDefault
pathPath to the target's project directory.PathNoWorkspace or project path.
nameName of the target.StringYes

File Header Template#

Lets you define custom file header template for built-in Xcode templates, e.g. when you create new Swift file you can automatically have your custom define file header.

Tuist automatically performs several template transformations for you

  • if your template starts with comment slashes (//) we remove them as they are added automatically by Xcode
  • if your template doesn't start with comment and whitespace or newline, we add a space - otherwise your header would be glued to implicit comment slashes which you probably do not want
  • if your template has trailing newline, we remove it as it is implicitly added by Xcode
CaseDescription
.file(Path)Use file at given path as file header template.
.string(String)Use given inline string as file header template.
ExpressibleByStringInterpolation

File header template can be initialized with a plain string, it is equivalent to using .string(...)