🚀 Create, maintain, and interact with Xcode projects at scale

Hi

I'm trying to generate the project based on a new feature from Xcode 14 to combine the watch and watchKit extension into a single target, But I'm not able to find a way in the manifest to which support this feature. Any ideas? Attached image for reference

Enviroment: Xcde-beta: 14 tuist: 2.0.2

Bug description

I am using a local swift package in Dependencies.swift. Local swift package have several modules and some of them have resources like XIBs, Assets, LocalizedStrings. I aspect Tuist to generate resource accessors when local swift package is integrated in generated project. But it seems like default resource synthesizers are skipping local swift packages for XIB, Assets and Strings and they only generate Bundle file but not Assets+Target.swift or Strings+Target.swift.

PS: I didn't try a remote swift package and that might be the case for remote packages as well but again I didn't test that case.

Reproduction steps

Use sample project that describes the issue and project structure. It also have description on how to reproduce which I have copied below as well.

1. Use the attached sample project (to be provided when opening the issue)
2. Run tuist fetch
3. Run tuist generate
4. Notice that project Thor which is a local swift package will not contain Assets+Styles.swift, Strings+Styles.swift files for target Styles
5. Same happens to other local package targets that contain some resources

Additional context

• Apple Silicon M1 Machine
• macOS version: 12.3.1 (21E258)
• Tuist version: 3.3.0
• Xcode version: 13.3.1

Resolves https://github.com/tuist/tuist/issues/160

Short description 📝

Supporting more than one configuration is pretty common amongst projects, so this is something we should naturally support. The discussion around the approach can be found on #160.

I really wanted to capture a declarative way to describe configuration so that you really do not care about the underlying implementation. You say what you want and that's what you get.

There were some challenges to deal with:

1. Every project in the workspace has to have the same build configurations.
2. Dependencies probably won't define the same configurations as the root project, they may only care about Debug and Release.
3. Dependencies may care about the configurations defined by the root project but want to provide overrides specific to them.
4. Targets may specify configuration overrides in the form of more build settings, or more xcconfig files.

I managed to solve 1, 2, 3 and part of 4.

In this pull request I do not implement the requirement for adding additional xcconfig overrides at the target level. If this is something you think is worth implementation please open an issue and quote this pull request.

Solution 📦

The root project is important. The root project defines the base set of configurations which will be propagated throughout the rest of the loaded projects.

Each project has the ability to specify an xcconfig file as an override for each configuration.

If your module does not specify the configurations that the root project does by name then it will fall-back and find the configuration which matches the build configuration type (e.g. Debug or Release) and failing that it will not specify anything.

An example root project might look something like the following:

import ProjectDescription

let project = Project(
    name: "MyApp",
    settings: Settings(configurations: [
      .debug(name: "Integration", xcconfig: "Configs/App/Integration.xcconfig"),
      .debug(name: "Private Production", xcconfig: "Configs/App/PrivateProduction.xcconfig"),
      .debug(name: "E02", xcconfig: "Configs/App/E02.xcconfig"),
      .debug(name: "F02", xcconfig: "Configs/App/F02.xcconfig"),
      .release(name: "Automation", xcconfig: "Configs/App/Automation.xcconfig"),
      .release(name: "Production", xcconfig: "Configs/App/Production.xcconfig"),
    ]),
    targets: [
        Target(
            name: "App",
            platform: .iOS,
            product: .app,
            bundleId: "com.oliver.app",
            infoPlist: "Supporting/Info.plist",
            sources: "Sources/**",
            dependencies: [
                .project(target: "LayoutView", path: "Modules/LayoutView"),
                .project(target: "SortedCollection", path: "Modules/SortedCollection"),
            ]
        ),
        Target(
            name: "AppTests",
            platform: .iOS,
            product: .unitTests,
            bundleId: "com.oliver.app-tests",
            infoPlist: "Supporting/Tests.plist",
            sources: "Tests/**",
            dependencies: [
                .target(name: "App"),
            ]
        )
    ]
)

An example module project might look something like the following:

import ProjectDescription

let project = Project(
    name: "SortedCollection",
    settings: Settings(
        base: [ "ProjectBase": "YES" ],
        configurations: [
            .debug(name: "Debug", settings: [ "Project": "Debug" ], xcconfig: "Configs/Debug.xcconfig"),
            .release(name: "Release", settings: [ "Project": "Release" ], xcconfig: "Configs/Release.xcconfig"),
        ]
    ),
    targets: [
        Target(
            name: "SortedCollection",
            platform: Platform.iOS,
            product: Product.framework,
            bundleId: "com.bskyb.SortedCollection",
            infoPlist: "Info.plist",
            sources: "Sources/**",
            settings: TargetSettings(
                base: [ "ModuleBase": "YES" ],
                buildSettings: [
                    "Debug" : [ "Target": "Debug" ],
                    "Release" : [ "Target": "Release" ],
                ]
            )
        ),
        Target(
            name: "SortedCollectionTests",
            platform: Platform.iOS,
            product: Product.unitTests,
            bundleId: "com.bskyb.SortedCollectionTests",
            infoPlist: "Tests.plist",
            sources: "Tests/**",
            dependencies: [
                TargetDependency.target(name: "SortedCollection"),
            ],
            settings: TargetSettings(
                base: [ "TestBase": "YES" ],
                buildSettings: [
                    "Debug" : [ "Target": "Debug" ],
                    "Release" : [ "Target": "Release" ],
                ]
            )
        ),
    ]
)

In the above instance, if tuist generate is run on the root project then SortedCollection will inherit the build configurations Integration, Private Production ... and for each of those configurations it will apply the appropriate settings from it's own configuration. e.g. Integration will be assigned the Debug configuration.

This is currently a work in progress, so any feedback on the implementation and design is greatly appreciated.

We need to determine if the pattern described above is worth going for, or if there are any alternatives worth searching.

Problem

Modern applications deal with all kinds of environment variables, from build numbers to api keys that can be injected on CI or with tuist, via the command line. Unfortunately however, tuist doesn't support putting those environment variables in a .env file that can be read in. There's a couple of reasons that tuist should consider adding support for declaring environment variables in this way:

1. tuist is great because it's a standard command; I can run tuist build or tuist generate without worrying about anything else but once you start adding in environment variables, the command becomes VAR=1 VAR2=2 tuist generate and so on and becomes more cumbersome and at that point, I just end up writing a script to run the tuist command that passes in environment variables.

2. Keeping environment variables in a .env file would align more with standard practice around handling of environment variables and enable developers to keep those values locally, not in version control, without the need for intermediary scripts. It would become far easier to store things in the env file such as build numbers for the application, rather than having to remember it.

I actually ended up writing my own library that I'm using in a script:

import Darwin
import ShellOut // [email protected]:JohnSundell/ShellOut.git == 2.3.0
import SwiftDotenv // [email protected]:thebarndog/swift-dotenv.git == 1.1.0

let environment = try Dotenv.load()

guard
    let bundleID = environment["BUNDLE_ID"],
    let teamID = environment["TEAM_ID"],
    let buildNumber = environment["BUILD_NUMBER"] else {
        exit(EXIT_FAILURE)
    }

let output = try shellOut(to: "TUIST_BUNDLE_ID=\(bundleID.stringValue) TUIST_DEVELOPMENT_TEAM=\(teamID.stringValue) TUIST_BUILD_NUMBER=\(buildNumber.stringValue) tuist generate")
print(output)

Describe the bug Bundle.module is not generated for external SPM dependency

To Reproduce Steps to reproduce the behavior:

1. Clone this repo
2. Run tuist generate
3. Open workspace
4. Build project

Expected behavior Project builds.

Screenshots

Desktop (please complete the following information):

• OS: macOS
• Version 12.0

Additional context IS_SPM is a macro added to the dependency's build settings.

Resolves https://github.com/tuist/tuist/issues/265

Short description 📝

When you create a new project in Xcode it no longer gives you an option to use storyboards or not. By default a Main.storyboard will be created along with a Launch Screen.storyboard if the platform supports it.

This PR creates these storyboards when tuist init is called.

Solution 📦

• A decision was consciously made to place the generated storyboards in the Source directory rather than it's own top level Storyboards group.
• As these storyboards will grow and be worked on during development it is important that they are only generated during the init command and not the generate command.
• Two new keys added to Project.swift mainStoryboard & launchScreenStoryboard to allow for custom naming of the storyboards after init.
• They are optional so shouldn't be a braking change.

Implementation 👩‍💻👨‍💻

• [x] Generate an empty storyboard & tests
• [x] Add checks to validate if Launch Screen.storyboard is supported on the platform
• [x] Link the storyboards up in the info.plist
• [x] Generate storyboards for all three supported platforms
• [x] Add the generated .storyboard files into the Sources directory.
• [x] Allow configuration of launch screen & main storyboard names.

Describe the bug

When importing AppCenterDistribute from the AppCenter package there are a number of errors:

1. It looks like we're parsing the option here incorrectly as APP_CENTER_C_VERSION="4.4.1" in the Xcode project build settings which leads to a compiler error. This can be resolved by instead changing the setting to be APP_CENTER_C_VERSION="\"4.4.1\"". I'm guessing the first quotes get stripped during Xcode build phase and as such the variable is read as a float and not the expected string, by wrapping it another set of quotes we get the correct string type.
2. Once the above is resolved we see some duplicate header errors (these don't show up using the legacy package mechanism in Tuist)

/Users/luis.padron/development/AppCenterBugExample/Tuist/Dependencies/SwiftPackageManager/.build/checkouts/appcenter-sdk-apple/AppCenter/AppCenter/include/MSACDevice.h:16:1: Duplicate interface definition for class 'MSACDevice'

To Reproduce Steps to reproduce the behavior:

1. Download zip
2. Run tuist dependencies fetch
3. Run tuist focus
4. See error 1
5. Fix error 1
6. See error 2

AppCenterBugExample.zip

This allows the graph command to export the project graph into JSON format. Users can then parse the JSON data and perform operations such as changeset detection, detecting which Xcode project is affected if a dependency is affected.

For example, given a PR, we can detect which Swift packages are affected by the files changed in the PR. Assuming the repository contains multiple Xcode projects, we then need to figure out which Xcode project is affected by the changed Swift packages. Finally we can then run tests on these affected Xcode projects.

Resolves N/A Request for comments document (if applies): N/A

Short description 📝

RFC https://github.com/tuist/tuist/discussions/3629

This allows the graph command to export the project graph into JSON format. Users can then parse the JSON data and perform operations such as changeset detection, detecting which Xcode project is affected if a dependency is affected.

Checklist ✅

• [✅] The code architecture and patterns are consistent with the rest of the codebase.
• [✅] The changes have been tested following the documented guidelines.
• [✅] The CHANGELOG.md has been updated to reflect the changes. In case of a breaking change, it's been flagged as such.
• [✅] In case the PR introduces changes that affect users, the documentation has been updated.
• [✅] In case the PR introduces changes that affect how the cache artifact is generated starting from the TuistGraph.Target, the Constants.cacheVersion has been updated.

Describe the bug When generating project with SPM dependencies in Dependencies.swift, and using Apollo and opening generated workspace in Xcode 13, the build fails because Apollo is not built with bitcode, I checked the Tuist generated Apollo project build settings and bitcode is enabled.

It works fine in Xcode 12!

Example project: https://github.com/zdnk/tuist-apollo-dependency-example

It only occurs when:

• building with Xcode 13
• building for device or archiving
• the Apollo dependency is linked in framework which is linked in the app

Last tested on Tuist 2.0.2, Xcode 13

UPDATE: seems to happening for any dependency linked to framework which is then linked to app.

To Reproduce Project.swift

import ProjectDescription

let baseSettings = SettingsDictionary()
    .bitcodeEnabled(true)

let project = Project(
    name: "TuistApollo",
    settings: .settings(base: baseSettings),
    targets: [
        // App
        .init(
            name: "App",
            platform: .iOS,
            product: .app,
            productName: "TuistApollo",
            bundleId: "com.TuistApollo.application",
            deploymentTarget: .iOS(targetVersion: "14.0", devices: .iphone),
            infoPlist: .default,
            sources: [
                "Targets/TuistApollo/Sources/*.swift",
            ],
            dependencies: [
                .external(name: "Apollo"),
                .target(name: "API"),
            ]
        ),

        .init(
            name: "API",
            platform: .iOS,
            product: .framework,
            productName: "API",
            bundleId: "com.TuistApollo.api",
            deploymentTarget: .iOS(targetVersion: "14.0", devices: .iphone),
            infoPlist: .default,
            sources: [
                "Targets/TuistAPI/Sources/*.swift",
            ],
            dependencies: [
                .external(name: "Apollo"),
            ]
        ),

    ]
)

Dependencies.swift

import ProjectDescription

let dependencies = Dependencies(
    swiftPackageManager: [
        .remote(url: "https://github.com/apollographql/apollo-ios.git", requirement: .upToNextMajor(from: "0.43.0")),
    ],
    platforms: [.iOS]
)

Generate the project/workspace:

tuist dependencies fetch

tuist generate

Desktop (please complete the following information):

• Tuist: 1.51.1
• OS: macOS Monterey
• Version 12.0 Beta (21A5506j)

Describe the bug

Dependency (Carthage binary FirebaseAnalytics) is not (signed and) embedded by the app causing linking problem.

Note that Tuist does not expose any interface to explicitly configure how a framework is embedded.

To Reproduce

I created a sample project to present the problem: https://github.com/pokryfka/tuist-demo

Its the template project generated by tuist (version 2.1.0) plus a Carthage binary package in Tuist/Dependencies.swift:

import ProjectDescription

let dependencies = Dependencies(
    carthage: [
        .binary(path: "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json", requirement: .exact("8.9.0")),
    ],
    platforms: [.iOS]
)

and then adding it in Tuist/ProjectDescriptionHelpers/Project+Templates.swift

--- a/Tuist/ProjectDescriptionHelpers/Project+Templates.swift
+++ b/Tuist/ProjectDescriptionHelpers/Project+Templates.swift
@@ -21,6 +21,10 @@ extension Project {

     /// Helper function to create a framework target and an associated unit test target
     private static func makeFrameworkTargets(name: String, platform: Platform) -> [Target] {
+        // hack just for the demo
+        // note that the dependency is not embeeded in the target (which is ok)
+        // nor in the app (even if added explicitly as a dependency in the app target)
+        let dependencies: [String] = name == "MyAppKit" ? ["FirebaseAnalytics"] : []
         let sources = Target(name: name,
                 platform: platform,
                 product: .framework,
@@ -28,7 +32,8 @@ extension Project {
                 infoPlist: .default,
                 sources: ["Targets/\(name)/Sources/**"],
                 resources: [],
-                dependencies: [])
+                dependencies: dependencies.map { .external(name: $0) }
+            )
         let tests = Target(name: "\(name)Tests",
                 platform: platform,
                 product: .unitTests,

Expected behavior

FirebaseAnalytics.xcframework is Embedded and Signed by MyApp.

Desktop (please complete the following information):

• OS: macOS
• Version 12.0.1

Resolves https://github.com/tuist/xcodeproj/issues/438 Resolves https://github.com/tuist/tuist/issues/215

Short description 📝

This PR adds support for defining a new type of dependency, .package:

.package(url: "https://github.com/tuist/XcodeProj", productName: "xcodeproj", version: .exact("6.7.0"))

Implementation 👩‍💻👨‍💻

• [x] Add models.
• [x] Add the genreation logic.
• [x] Add linting rules considering that the package is a static library by default.
• [x] Find a way to have the Package.resolved file outside the repository.
• [x] Add tests
• [x] Add documentation
• [x] Update CHANGELOG.

Note: This PR needs to be merged first.

Related issue: https://github.com/tuist/tuist/issues/4556 Related comment: https://github.com/tuist/tuist/issues/4556#issuecomment-1213154001

Short description 📝

Adds support for aria2 to download cached artifacts improving speed and reliability compared to apple's URLSession.

This a work in progress PR as I'd like to gather feedback about what's the best way to approach this and even if this addition make sense for tuist.

Of course this can be fully tested (following below section steps) and from my tests, aria2 is bit faster and reliable that URLSession. I'm preparing a full range of tests to back up my assertions comparing gains versus URLSession so stay tuned for that.

How to test the changes locally 🧐

• Install aria2 through brew:

brew install aria2

• Prepare a project with remote cache configured.
• Run tuist generate adding --aria2 or -a.

Contributor checklist ✅

• [X] The code has been linted using run ./fourier lint tuist --fix
• [ ] The change is tested via unit testing or acceptance testing, or both
• [X] The title of the PR is formulated in a way that is usable as a changelog entry
• [ ] In case the PR introduces changes that affect users, the documentation has been updated

Reviewer checklist ✅

• [ ] The code architecture and patterns are consistent with the rest of the codebase
• [ ] Contributors have checked that, if needed, the PR includes the label changelog:added, changelog:fixed, or changelog:changed, and the title is usable as a changelog entry

Adds releasUrl parameter to remote plugins for direct downloads. It also adds support for downloading plugins from gitlab release.

Before: .git(url: "https://github.com/tuist/tuist-plugin-lint", tag: "0.3.0") Now : .git(url: "https://github.com/tuist/tuist-plugin-lint", tag: "0.3.0", releaseUrl: "https://download_url"),

What happened?

I added an App Intent Extension the same way I have declared other extensions, for example an Intents Extension.

let appIntentExtension = Target(
    name: "\(appName)AppIntent",
    platform: .iOS,
    product: .appExtension,
    bundleId: "${CUSTOM_BUNDLE_ID}.AppIntent",
    deploymentTarget: deploymentTarget,
    infoPlist: "\(appName)AppIntent/Sources/Info.plist",
    sources: [
        "\(appName)AppIntent/Sources/**",
    ],
    dependencies: [
        .target(name: repositoryName),
    ],
    settings: Settings.settings(configurations: [
        .debug(
            name: "Debug",
            settings: ["GENERATE_INFOPLIST_FILE": "YES"],
            xcconfig: "Configs/Base+Debug.xcconfig"
        ),
        .release(
            name: "Release",
            settings: ["GENERATE_INFOPLIST_FILE": "YES"],
            xcconfig: "Configs/Base+Release.xcconfig"
        )
    ])
)

but when compiling I get this warning:

SomeAppAppIntent.appex is an ExtensionKit extension and must be embedded in the parent app bundle's Extensions directory, but is embedded in the parent app bundle's PlugIns directory.

and then the app fails to install on the target device.

I checked the build phases and saw that there's a phase that embeds the extensions:

And for the project to compile correctly, it should embed the App Intent Extension in a different step with Destionation set to ExtensionKit Extensions

I looked a bit and I think that maybe a new type of product is required .extensionKitExtension (🙈) instead of .appExtension in order to add the correct build phase but maybe I missed something and tuist already supports App Intent Extensions and I am doing something wrong or missing some parameter.

How do we reproduce it?

1. Create an app project
2. Add App Intent Extension
3. Generate project with tuist and try to compile

Error log

SomeAppAppIntent.appex is an ExtensionKit extension and must be embedded in the parent app bundle's Extensions directory, but is embedded in the parent app bundle's PlugIns directory.

macOS version

13.1

Tuist version

3.12.1

Xcode version

14.2.0

Resolves https://github.com/tuist/tuist/issues/4939

Short description 📝

Expose dependencyFile property that exists in PBXShellScriptBuildPhase by adding it to Tuist.TargetScript and ProjectDescription.TargetScript.

How to test the changes locally 🧐

Using the new property in any of the .pre - .post functions, it should set the value in Xcode build phase.

Contributor checklist ✅

• [x] The code has been linted using run ./fourier lint tuist --fix
• [x] The change is tested via unit testing or acceptance testing, or both
• [x] The title of the PR is formulated in a way that is usable as a changelog entry
• [x] In case the PR introduces changes that affect users, the documentation has been updated

Reviewer checklist ✅

• [x] The code architecture and patterns are consistent with the rest of the codebase
• [x] Contributors have checked that, if needed, the PR includes the label changelog:added, changelog:fixed, or changelog:changed, and the title is usable as a changelog entry

What happened?

Support setting a dependency file path when defining a run script phase (similar to input-output paths).

How do we reproduce it?

1. Try to declare a new run script phase
2. No way to set .d file.

Error log

There is no log.

macOS version

13.0.1

Tuist version

3.15.0

Xcode version

14.2

What happened?

When trying to execute the tuist generate command, a problem is obtained with the loading of the libswiftCore.dylib file

** NOTE ** The tuist binary is locally in the project to avoid version problems, this file upload problem occurs since the update to MacOS Ventura.

How do we reproduce it?

1. Run tuist generate command.
2. See error

Error log

Library not loaded: @rpath/libswiftCore.dylib\n Referenced from: <DA20D160-B01E-33FC-8074-2FC4EAA479BA> /Users/aylwing.olivas/Developer/ios-monorepo-tuist/.tuist-bin/libswift_Concurrency.dylib\n Reason: tried: \'/Users/aylwing.olivas/Developer/ios-monorepo-tuist/.tuist-bin/libswiftCore.dylib\' (no such file), \'/Users/aylwing.olivas/.tuist/Cache/ProjectDescriptionHelpers/b27bd22/617dab8cbcfb7ab38360c94147cfcd01/libswiftCore.dylib\' (no such file), \'/System/Volumes/Preboot/Cryptexes/OS@rpath/libswiftCore.dylib\' (no such file), \'/usr/local/lib/libswiftCore.dylib\' (no such file), \'/usr/lib/libswiftCore.dylib\' (no such file, not in dyld cache)\nzsh:cd:1: not a directory

macOS version

13.1

Tuist version

3.14.0 and 3.15.0

Xcode version

14.1