baegteun - iOS

Tuist 4 버전 업그레이드

baegteun — Sun, 21 Apr 2024 16:48:45 +0900

24년 2월 8일, Tuist 4.0.0이 공식적으로 릴리즈되었습니다.
Tuist가 4.0.0 Major 버전이 업그레이드되면서 변경된 점을 알아보겠습니다.

https://github.com/tuist/tuist/releases/tag/4.0.0

tuistenv를 통한 버전 관리 Drop

https://github.com/tuist/tuist/pull/5556

Tuist 4 이전에는 tuist install tuist uninstall 등의 명령어를 통해 로컬에 있는 Tuist의 버전을 변경하거나, .tuist-version 파일에 버전을 정의해놓아서 프로젝트에서 사용할 Tuist 버전을 고정해놓아서 사용할 수 있었습니다. 그리고 이런 기능을 제공하는 것이 tuistenv라는 도구였습니다. (tuist 설치 시 같이 설치되었습니다.)

하지만 tuistenv는 Tuist 4에는 완전히 삭제가 되었습니다.

Tuist 4로 업그레이드했다면 기존의 tuistenv는 curl-Ls https://uninstall.tuist.io | bash 로 제거하고 Mise를 사용하기를 적극적으로 권장한다고 하네요.
혹은 Homebrew 또한 지원한다고 합니다.

ProjectDescription 모델들의 init 생성자 Drop

https://github.com/tuist/tuist/pull/5843

Target, Scheme과 같은 ProjectDescription 모델들의 init 생성자를 제거합니다.
대신 static constructor를 통해 인스턴스 생성을 할 수 있도록 제공한다고 합니다.
생성자 API의 가독성과 표현력을 개선하기 위해 static constructor로 변경하게 되었다고 하네요.

e.g.

Target(name: ...)

->

Target.target(name: ...)

static constructor는 모델 이름을 사용하여 작명합니다.
e.g.
Target.target(…)
Arguments.arguments(…)
Path.path(…)

--no-cache 가 --no-binary-cache로 rename

tuist generate tuist build 등의 명령어에서 사용할 수 있었던 --no-cache argument가 --no-binary-cache로 rename되었습니다.
--no-cache의 flag가 명확하지 않아 binary로 rename되었다고 합니다.

tuist fetch 가 tuist install 로 rename

https://github.com/tuist/tuist/pull/5857

의존성을 가져오는 명령어였던 tuist fetch가 tuist install로 rename되었습니다.
tuist와 결이 비슷한 툴과의 컨벤션을 맞추기 위함이라고 합니다.
npm install, yarn install 같은 이런 툴들을 말하는거같네요.

의존성 정의 방식을 Package.swift를 통한 방식으로 변경

Package.swift 파일 위치 - https://github.com/tuist/tuist/pull/5862
Package.swift 지원 - https://github.com/tuist/tuist/pull/5503

Tuist 4 이전에는 Tuist/Dependencies.swift 에서 혹은 프로젝트의 packages에 package를 추가해주어서 (Native SPM방식 사용) 서드파티 의존성을 가져올 수 있었으나 Dependencies.swift를 완전히 제거했습니다.

그 이유는 Dependabot, Renovatebot같은 툴을 사용할 수 없었고 사용자에게 불필요한 간접 참조?를 제공했기 때문이라네요.

새로운 방식으로는 Package.swift에 의존성을 정의해야합니다.

Package.swift의 경로는 Tuist/Package.swift가 아닌 프로젝트의 루트에 위치해야한다고 합니다.

사실 Package.swift를 통한 의존성을 정의하는 방식은 3.31.0부터 지원을 했습니다. 3버전 후반에는 Dependencies.swift는 deprecated처리만 되고 4버전부터는 사용이 완전히 불가능하게 되었습니다.

Dependencies.swift에서 할 수 있었던 의존성의 productType을 바꾸거나 사용 platform을 지정하는 설정은 #if TUIST 안에서 정의해야한다고 합니다.
자세한건 이 문서에서 확인할 수 있습니다.

// swift-tools-version: 5.8
import PackageDescription

#if TUIST
    import ProjectDescription
    import ProjectDescriptionHelpers

    let packageSettings = PackageSettings(
        productTypes: [
            "Alamofire": .framework, // default is .staticFramework
        ],
        platforms: [.iOS]
    )
#endif

let package = Package(
    name: "PackageName",
    dependencies: [
        .package(url: "https://github.com/Alamofire/Alamofire", from: "5.0.0"),
    ]
)

tuist cache warm이 tuist cache로 rename

tuist cache warm가 tuist cache로 더 짧게 사용할 수 있게 되었습니다.

tuist cache print-hashes가 tuist cache --print-hashes로 rename

print-hashes가 cache캐시 명령어의 플래그임을 명확히 하기 위해 tuist cache --print-hashes로 rename된다고 합니다.

Caching Profile 제거

https://github.com/tuist/tuist/pull/5833

Tuist 4 이전에는 Config.swift에서 cache의 profile을 지정할 수 있었습니다.

보통 debug, release의 configuration별로 profile을 분리해서 각각 cache이 적용되도록 하는 느낌으로 사용되는거같네요.

이 cache profile이 제거된다고 합니다.

제거하기로 한 이유는 프로젝트 생성 과정 중 생성에 사용된 프로필이 아닌 다른 프로필을 사용할 때 혼동을 일으킬 수 있다고 합니다.
또한 사용자가 debug 프로필로 릴리즈 버전을 빌드할 때 예상할 수 없는 결과가 발생할 수 있어서 제거한다고 합니다.

대신 cache 명령어의 옵션에--configuration를 추가하여 프로젝트를 생성할 때 configuration을 지정할 수 있게 되었습니다.

--skip-cache 제거

tuist generate 를 할 때 --skip-cache와 대상을 지정해서 캐시를 건너뛸 대상을 지정할 수 있었습니다.
하지만 Tuist 4 부터는 tuist generate Foo 와 같이 argument로 명시하는 대상이 캐시 스킵 대상으로 지정됩니다.

Signing Capabilities 기능 Drop

https://github.com/tuist/tuist/pull/5716

Tuist 3 버전대에서는 Tuist/Signing 디렉토리에 인증서와 프로비저닝 프로필을 넣어놓으면 tuist generate를 할 때 자동으로 Signing이 되는 기능을 제공해주었습니다.
하지만 Tuist 4 에서는 이 기능이 Drop되었습니다.

이유는 Fastlane이나 Xcode 자체 기능같이 커뮤니티 툴이 위 문제를 더 잘 해결하고 있기 때문입니다.
Signing은 Tuist의 장기적인 목표이기에 핵심 기능에 집중하는 것이 낫다고 생각하여 Drop했다고 합니다.

Dependencies.swift(Package.swift)를 통한 Carthage 지원 중단

https://github.com/tuist/tuist/pull/5740

Tuist 4 이전에는 Dependencies.swift에서 Carthage를 통한 의존성을 정의하고 가져올 수 있었지만 Tuist 4 부터는 직접적으로 Tuist를 통한 관리는 되지 않습니다.

* Carthage 사용이 불가능한게 아닙니다.

이유는 SPM이 의존성 관리 방법으로 선호될 미래를 고려할 때 Carthage는 장기적인 목표라고 생각하여 Drop했다고 합니다.

Carthage를 사용하기 위해서는 Carthage를 직접 사용하여 framework와 xcframework를 가져온 다음 TargetDependency.framework 또는 TargetDependency.xcframework로 바이너리를 참조해야한다고 합니다.

자세한건 이 문서에서 알아보실 수 있습니다.
Carthage만이 아닌 Cocoapods를 사용하여 서드파티 의존성을 가져올 수 있는 방법도 알려주네요.

TargetDependency.packagePlugin API Drop

https://github.com/tuist/tuist/pull/5555
https://github.com/tuist/tuist/pull/5719

Tuist 4 이전에는 TargetDependency.packagePlugin을 통해 패키지 플러그인을 의존성으로 정의할 수 있었지만 SPM이 새로운 패키지 유형을 도입한 것을 보고 유연하고 미래에 대비할 수 있는 방향으로 API를 변경했습니다.

TargetDependency.packagePlugin을 사용하고 있었다면 TargetDependency.package를 사용하고 argument에 패키지 타입을 전달하면된다고 합니다.

e.g.
TargetDependency.package(product: ..., type: .plugin)
TargetDependency.package(product: ..., type: .macro)

여기서 새로운 패키지 유형은 PR을 봤을 때 macro인듯하네요.

deprecated API Drop

https://github.com/tuist/tuist/pull/5560

deprecate 처리 된 API들이 삭제되었습니다.

예를들어 DeploymentTarget이 Destinations, DeploymentTargets로 분리되며 deprecate된 DeploymentTarget이 삭제된게 있겠네요.

References By

https://docs.tuist.io/guide/introduction/from-v3-to-v4.html

Tuist - Modular Architecture 개선하기

baegteun — Mon, 1 May 2023 19:49:45 +0900

이 글은 Tuist 버전 3.19.0을 기준으로 작성되었습니다.

이 글은 https://baegteun.tistory.com/11 해당 글에서 이어집니다.

UserInterface 레이어 추가
협업할 때 XCConfig 불편함 개선
CI인지 여부를 Environment에서 관리하도록 변경

UserInterface 레이어 추가

기존 레이어의 문제점

Feature - Domain - Core - Shared 의 레이어를 가짐
Core안에 DesignSystem 모듈이 있어 핵심적인 기능으로 쓰일 모듈이 있다는 의미에서 약간 애매해짐

-> UI에 관련한 모듈들을 넣을 레이어로 UserInterface 레이어를 새로 분리하였습니다.
해당 레이어에서 디자인 시스템, 다국어 적용 등의 처리를 하는 모듈들이 위치해있을겁니다.

협업할 때 XCConfig 불편함 개선

.gitignore에 XCConfig/ 를 등록해놓았기에 새 모듈이 생기면, 같이 협업하는 사람은 새 XCConfig를 추가로 만들어주거나 공유해줘야 했습니다.

-> XCConfig/Shared.xcconfig 를 .gitignore에서 해재해놓고 기본적으로 모듈의 xcconfig 연결을 Shared에 연결해놓고, makeModule 생성자에서 configurations를 직접 커스텀하여 넣을 수 있게 해서 아무것도 없이 clone해도 바로 작업할 수 있도록 만들었습니다.

CI인지 여부를 Environment에서 관리하도록 변경

CI여부를 파악하려고 그때그떄 Process에서 값을 받아오는 것을 Environment struct에 추가하여 env.isCI로 간단하게 접근할 수 있게 했습니다.

바뀐 결과물은 확인할 수 있습니다.
https://github.com/baekteun/Tuist_Modular_Template

Tuist 사용법 - 9. Micro Feature, uFeature(The Modular Architecture, TMA)로 확장성 높이기

baegteun — Mon, 3 Apr 2023 10:33:42 +0900

이 글은 Tuist 버전 3.17.0 기준으로 작성되었습니다.

2024년 5월 21일
MicroFeatures 아키텍쳐가 The Modular Architecture로 rename 되었습니다.

document - https://docs.tuist.io/guide/scale/tma-architecture

The Modular Architecture (TMA) | Tuist

docs.tuist.io

PR - https://github.com/tuist/tuist/pull/6305

Micro Feature?

Micro Feature는 확장을 가능하게 하고, 빌드 및 테스트 주기를 최적화하며, 팀의 모범 사례를 보장하기 위해 Apple OS 애플리케이션을 구성하는 아키텍처 접근 방식입니다.
핵심 아이디어는 명확하고 간결한 API를 사용하여 상호 연결된 독립적인 기능을 구축하여 앱을 빌드하는 것입니다.
앱에는 여러 기능이 들어갈 수 있습니다. 로그인, 회원가입, 검색 등등 기능들이 모여서 사용자가 앱을 사용할 수 있게 합니다.
Micro Feature는 이런 작은 기능을 분리하고, 기본적으로 구현체를 interface 뒤에 숨긴 DIP의 형태를 띠게 됩니다.
각 feature는 블록이라 생각할 수 있습니다. 각 블록은 각자의 특정한 용도에만 사용되고 이 블록을 결합하면 온전한 기능을 갖춘 실제 앱이 구축되는 방식이라 생각할 수 있습니다.

What?

Micro Feature는

Interface
Source
Testing
Tests
Example

로 5개의 타겟으로 조합됩니다.
각 Target에 대한 자세한 설명은

Interface : 해당 feature의 공개 interface랑 model이 포함된 Target입니다.
Source : 해당 feature의 공개 interface의 구현체가 포함된 Target입니다.
Tests : 해당 feature의 Unit Test, Integration Test등이 포함된 Target입니다.
Testing : Test나 Example에 사용할 수 있는 해당 feature의 테스트 더블 객체 등이 포함된 Target입니다.
Example : 해당 feature의 예제 앱을 만들어놓을 수 있는 Target입니다. 개발자가 특정 조건 (화면 사이즈, 언어) 등의 기능을 시험하기 위한 용도로도 사용합니다.

또한 이 Target 간의 의존 관계는 아래와 같이 그릴 수 있습니다.

Why?

왜 Micro Feature를 사용할까요?

명확하고 간결한 API
작은 모듈
재사용성

명확하고 간결한 API

단일 Target으로 소스 코드를 작성하게 된다면 코드에 암시적으로 의존성을 구축하기가 매우 쉬워집니다.
모든 것이 강하게 결합되고, 상태를 예측할 수 없으며, 새로운 변경 사항이 도입하는 것은 악몽이 됩니다.
Micro Feature라면 공개용 interface모듈과 구현체 모듈을 분리해야 하기 때문에 무엇을 공개해야 하는지, 무엇을 비공개로 해야 하는지 생각해야 하기 때문에 feature가 기능을 사용하는 방식을 더 잘 제어하고 안전한 API를 설계할 수 있습니다.

작은 모듈

Divide and conqure.
작은 모듈에서 작업하면 feature에 더 많이 집중을 하고, 테스트하고, 기능을 독립적으로 시도할 수 있습니다.
그리고 기능을 작동시키는데 필요한 구성 요소만 컴파일하는 선택적인 컴파일을 할 수 있기 때문에 개발 주기를 훨씬 빠르게 진행할 수 있습니다.

재사용성

프레임워크 또는 라이브러리를 사용하여 앱과 Extension과 같은 다른 제품에서 코드를 재사용할 것을 권장합니다. Micro Feature를 구축하면 재사용이 매우 간단합니다.
기존 Micro Feature를 결합하고 필요한 경우 플랫폼별 UI 레이어를 추가하기만 하면 iMessage Extension, Today Extension 또는 watchOS 앱을 구축할 수 있습니다.

Micro Feature의 목표

Micro Feature는 feature 전반에 걸쳐 수평적인 의존성 구조를 구축하는 것입니다. 어떠한 feature도 다른 feature의 구체적인 구현 세부 사항에 의존하지 않습니다. 단지 interface 모듈에 의존할 뿐입니다.
이렇게 하면 느슨하게 결합된 종속성이 생성되고, 또한 interface가 구현보다 변경될 가능성이 적고 이를 기반으로 캐시를 구축하여 빌드 시간을 단축할 수 있습니다.
큰 규모의 개별 기능 팀이 서로 독립적으로 작업할 수 있습니다. 모듈 A의 인터페이스가 정의되면 모듈 A에 의존하는 모든 팀이 모듈 A의 구현을 기다릴 필요 없이 인터페이스를 사용할 수 있으므로 팀의 작업 속도가 빨라지고 전체 제품 개발 속도가 빨라질 수 있습니다.

적용 사례

실제로 제가 적용해 본 거로는
Tuist 템플릿을 만들 때 Micro Feature를 하도록 유도하였습니다.
https://github.com/baekteun/Tuist_Modular_Template
그리고 실제로 Dotori라는 프로젝트를 진행하며 적용해 놓고 개발하고 있습니다.
https://github.com/Dotori-app/Dotori-iOS

References By

https://docs.tuist.io/building-at-scale/microfeatures/
https://alexanderweiss.dev/blog/2022-01-12-scale-up-your-app-with-microfeatures

Scale up your app with Microfeatures

With an app becoming bigger in terms of people working on them as well as adding more features, the question arises of how to organize the growing complexity. Imagine multiple features that need to be implemented simultaneously by different teams. I...

alexanderweiss.dev

https://github.com/tuist/tuist/pull/6305

Some documentation adjustments by pepicrft · Pull Request #6305 · tuist/tuist

This PR introduces some documentation changes: In preparation for the consolidation of Tuist and Tuist Cloud, I renamed Projects to Tuist Projects, and merge Scale and Automation into that section...

github.com

https://docs.tuist.io/guide/scale/tma-architecture

Swift로 웹사이트를 만드는 방법

baegteun — Tue, 21 Feb 2023 12:01:50 +0900

Vapor + Leaf
Publish
SwifWeb
swift-web
SwiftWebUI
Tokamak

Vapor + Leaf

Server side 프레임워크인 vapor와 leaf를 사용하는 방법입니다.
leaf를 사용해 dynamic html 페이지를 렌더링할 수 있습니다.
https://github.com/vapor/vapor
https://github.com/vapor/leaf
https://docs.vapor.codes/leaf/getting-started

Publish

해외쪽에서 iOS 개발자 분들의 블로그들을 보다보면 가끔 만나볼 수 있는 프레임워크입니다.
Static site를 생성하고, 블로그쪽에서 유명한것같습니다.
디자인 퀄리티를 높이면 순수 Swift만 사용하여 만들기는 어렵고 css같은거를 만들고 건드려야합니다.
run을 하면 Output/ 에 html로 변환시킨 결과물이 나옵니다.
Publish로 만들어진 대표적인 블로그는 아래가 있습니다.
Publish를 만드신 장본인이기도 합니다.
https://swiftbysundell.com
https://github.com/johnsundell/publish

SwifWeb

유명하지는 않은데 Single Page Application(SPA)을 만들 수 있고, Progressive Web Apps(PWA)도 만들 수 있는 꽤나 흥미롭게 봤던 프레임워크입니다.
어쩌다보니 제 개인 웹 포트폴리오를 이거로 만들어버렸습니다(?).
순수 Swift코드만을 작성하여 만들 수 있습니다.
단, 시작점의 로딩 애니메이션이나 트위터카드같은거를 바꾸기 위해서는 index.html을 건드려야합니다.
release를 하면 wasm로 변환시켜서 결과물이 나옵니다.
https://github.com/swifweb/web

swift-web

The Composable Architecture를 만든 Pointfreeco에서 만든 프레임워크입니다.
뭔가 생긴게 신기하네요.
https://github.com/pointfreeco/swift-web

SwiftWebUI

SwiftUI 작성하듯 코드를 작성하여 웹페이지를 만들 수 있습니다.
실행하고 네트워크 탭을 보니 스타일 관련해서 뭔가 엄청나게 많이 요청이 갔던 기억이 있습니다.
https://github.com/SwiftWebUI/SwiftWebUI

Tokamak

위에서 SwiftWebUI와 같이 SwiftUI같이 코드를 작성하여 웹페이지를 만들 수 있습니다.
그리고 패키지로 있는 TokamakStaticHTML을 사용하여 Vapor나 Publish와 같은 프레임워크에 static 렌더링이 필요한 경우 사용할 수도 있다고 하더군요.
결과물은 wasm로 나옵니다.
https://github.com/TokamakUI/Tokamak
이 정도가 제가 알아본 Swift로 웹페이지를 만드는 방법들입니다.
혹시 이 글을 보는 지금, 한 번 Swift로 웹페이지를 만들어보는거 어떤가요?

Tuist 사용법 - 8. Scaffold, Template를 사용하여 새로운 모듈 만들기

baegteun — Wed, 15 Feb 2023 00:16:25 +0900

이 글은 Tuist 버전 3.16.0 기준으로 작성되었습니다.

Scaffold?

프로젝트에서 새로운 컴포넌트나 기능 만드는 것을 시작할 때 사용할 수 있는 기능입니다.
파일을 만들 때 tuist scaffold를 사용하면 템플릿으로부터 파일을 만들 수 있습니다.
템플릿은 Tuist에서 기본으로 제공해주는 템플릿을 사용할 수도 있고, 직접 만들어 사용할 수도 있습니다.

https://docs.tuist.io/commands/scaffold

tuist scaffold 사용법

tuist scaffold <template> [--json] [--path <path>] <subcommand>

사용 예시

tuist scaffold ribs --name Example

이렇게만 본다면 단순히 Xcode Template 다른게 없거나 오히려 더 불편한거 아닌가? 싶을 수 있는데, scaffold는 이미 만들어진 모듈에 새로운 파일들을 만들 때 보다는 새로운 모듈을 만들 때에 더 적합한거같습니다.

앞서 사용 예시의 상황을 더 구체화시켜보면

...
- Features
    - AboutFeature
    - UserFeature
    - SettingsFeature
    - CompeteFeature
...

위와같이 Feature를 분리하는데, 이 기준을 RIB를 기준으로 분리한다 했을때. 위의 tuist scaffold ribs --name Example을 하면 Project.swift의 내용물도 채우며 새로운 ExampleFeature 모듈을 만들것입니다.

템플릿 만들기

Tuist로 프로젝트를 하나 만들고, 그 안에 Template를 하나 만들어보겠습니다.

먼저 tuist init --platform ios으로 tuist 프로젝트 하나를 init하고 tuist edit으로 edit을 시작하겠습니다.

Plugin은 무시해주고 Manifests/Tuist 에 'Templates' 라는 이름의 Group을 하나 만듭니다. Templates는 Tuist에서 정해놓은 이름이기에 다르게 입력한다면 안에 템플릿이 있어도 인식되지 않습니다.

새로운 템플릿을 만들 때는 Templates/<템플릿이름>/<템플릿이름>.swift 로 <템플릿이름>.swift에 해당 템플릿을 나타낼 수 있습니다.

샘플을 하나 한 번 만들어보겠습니다.

Templates/ 아래에 example/ 와 example.swift를 만들어줍니다.

Attribute

다름으로 example.swift안에 내용물을 채워주는데, 첫번째로는 Attribute라고 하는 해당 커맨드의 옵션을 받는 변수를 선언해줍니다.

// example.swift

import ProjectDescription

let nameAttribute = Template.Attribute.required("name")

이렇게하면 scaffold를 사용해 템플릿을 불러올때 tuist scaffold example --name Example 로 --<attribute명> <값> 으로 값을 전달 받을 수 있습니다.

Attribute는 필수와 옵셔널 두 종류로 받을 수 있습니다.
옵셔널은 입력하지 않으면 default값을 사용합니다.

Template

Tuist로 프로젝트나 플러그인을 만들 때처럼 템플릿도 정의합니다.

// example.swift

import ProjectDescription

let nameAttribute = Template.Attribute.required("name")

let template = Template(
    description: <#String#>,
    attributes: <#[Template.Attribute]#>,
    items: <#[Template.Item]#>
)

description: 템플릿의 설명입니다. 평소에는 딱히 볼일은 없긴하지만 tuist scaffold list를 하면 표시됩니다.
attributes: scaffold 커맨드가 실행될때 받을 attribute리스트를 넣으면 됩니다.
items: 여기에 넣어준 아이템을 기반으로 결과물이 나옵니다. 타입은 string, file, directory 3종류를 만들어 낼 수 있습니다.

Item

directory는 그냥 보면 디렉토리를 만드는건가, 싶지만 사실 디렉토리는 만드는 것이 아니라 sourcePath의 디렉토리를 내용물채로 복사해서 옮겨줍니다.
파일을 만드는것은 string과 file이 있는데 이 둘의 차이는 string은 직접 문자열 "" 안에 내용물을 작성하는 것이고, file은 stencil 이라고하는 Swift를 위한 템플릿 언어를 사용하여 만드는 것입니다.

string

파라미터가 받는 그대로, path안에 파일명까지 포함해서(ex. Features/\(nameAttribute)Feature/Project.swift) 보내주시고, contents안에 해당 파일안의 내용물을 작성하시면 됩니다.

file

위와 거의 동일하게 파일명까지 포함해서 path를 넘겨주고, templatePath를 받아 해당 경로에 있는 파일의 내용물을 넣습니다.
코드를 뜯어보니 stencil만 따로 템플릿 렌더링 과정을 거치고 나머지 파일은 무슨 파일이든 읽힌 그대로 넘기는 듯 합니다.

stencil에 대한 자세한건.. stencil github에 여러모로 있으니 살펴봐주세요. Swift를 위한 Template 언어인 점을 제외하고는 뭔가 특별한 목적이 없으니 사실 별로 배울것도 없습니다. 변수, for, if 정도면 충분합니다.
여담으로 vscode extension에 stencil언어 extension도 있답니다.

References By

https://docs.tuist.io/commands/scaffold/

Tuist 모듈화하기 - Modular Architecture 설계하기

baegteun — Thu, 5 Jan 2023 01:12:53 +0900

이 글은 Tuist 버전 3.15.0을 기준으로 작성되었습니다.

전체 소스코드는 https://github.com/baekteun/Tuist_Modular_Template 에 공개 + 템플릿 으로 사용가능합니다.

~~스타 한번씩 눌러주시면 매우 감사합니다..!~~

레이어
모듈화
- Micro Feature
Tuist 설계
- Plugin
- Project 생성
- 자동화

레이어

모듈보다 더 큰 관점에서 레이러를 먼저 분리해보도록 하겠습니다.
Feature, Domain, Core, Shared로 아래와 같은 기준으로 분리하였습니다.

Feature
- Presentation 부분
- ex) AuthFeature, ProfileFeature
Domain
- Business Logic 부분
- ex) AuthDomain, ProfileDomain
Core
- 앱의 비즈니스를 포함하지 않고 순수 기능성 모듈이 위치한 레이어
- ex) NetworkingModule, DatabaseModule
Shared
- 모든 계층에서 사용 가능한 모듈
- 더 넓은 의미의 공통적
- ex) UtilityModule, LoggingModule

모듈화

모듈을 분리하는 기준은 가장 크게 도메인 관점에 따른 분리와 재사용 관점에 따라 분리할 수 있습니다.

Feature와 Domain은 도메인 관점에 따라 분리하고, Core와 Shared는 재사용 관점에 따라 분리하였습니다.

Micro Feature

Tuist의 공식 문서에는 Micro Feature에 대한 문서가 있습니다.

https://docs.tuist.io/building-at-scale/microfeatures/#what-is-a-µfeature

Micro Feature는 확장을 가능하게 하고, 빌드 및 테스트 주기를 최적화하며, 팀의 모범 사례를 보장하기 위해 Apple OS 애플리케이션을 구성하는 아키텍처 접근 방식입니다.
이 방식을 따라서 각 모듈을 구성할 것입니다.

Tuist 설계

Plguin

Tuist관리도 용이하게 하기 위해서 Plugin도 분리해주겠습니다.
Plugin은

Configurtaion 관리를 위한 ConfigurationPlugin
디펜던시 관리를 위한 DependencyPlugin
프로젝트 환경을 관리하기 위한 EnvironmentPlugin

으로 3종류의 Plugin을 만들겠습니다.

여기에서 더 자세한 내용을 볼 수 있습니다!

Project 생성

Project.swift에서 모듈을 만들때 쓸 함수를 만들겠습니다.
우선 CI일때를 처리 하기 위해

let isCI = (ProcessInfo.processInfo.environment["TUIST_CI"] ?? "0") == "1" ? true : false

를 위에 선언해놓겠습니다.
기본적으로 빌드는하면 SwiftLint를 돌리게 했는데, CI/CD를 할때는 SwiftLint를 돌릴 필요가 없기에 이후에 분기점을 둬서 CI일때는 실행하지 않도록 하기 위해서입니다.
또한 앞서 말했듯 Micro Feature를 적용할 것인데 이를 편하게 하기 위해

public enum MicroFeatureTarget {
    case interface
    case testing
    case unitTest
    case uiTest
    case demo
}

를 선언해놓겠습니다.

static func makeModule(
    name: String,
    platform: Platform = env.platform,
    product: Product,
    targets: Set<MicroFeatureTarget>,
    packages: [Package] = [],
    externalDependencies: [TargetDependency] = [],
    internalDependencies: [TargetDependency] = [],
    interfaceDependencies: [TargetDependency] = [],
    testingDependencies: [TargetDependency] = [],
    unitTestDependencies: [TargetDependency] = [],
    uiTestDependencies: [TargetDependency] = [],
    demoDependencies: [TargetDependency] = [],
    sources: SourceFilesList = .sources,
    resources: ResourceFileElements? = nil,
    settings: SettingsDictionary = [:],
    additionalPlistRows: [String: ProjectDescription.InfoPlist.Value] = [:],
    additionalFiles: [FileElement] = []
) -> Project

Project의 extension으로 makeModule 함수를 만들겠습니다.
각 파라미터의 의미는

name: 모듈 이름
platform: 플랫폼
product: 모듈의 product type (framework, staticFramework 등)
targets: 사용할 Micro Feature (Interface, testing, unitTests, uiTests, demo)
packages: 패키지들
externalDependencies: 외부 디펜던시
internalDependencies: 내부 디펜던시
interfaceDependencies: interface Target모듈의 디펜던시
testingDependencies: testing Target모듈의 디펜던시
unitTestDependencies: unitTests Target모듈의 디펜던시
uiTestDependencies: uiTests Target모듈의 디펜던시
demoDependencies: demo Target 모듈의 디펜던시
sources: 소스폴더의 경로
resources: 리소스폴더의 경로
settings: 모듈의 빌드 세팅
additionalPlistRows: info plist의 추가 Row
additionalFiles: Xcode에서 추가적으로 인식할 파일(ex README.md)

입니다.
이후부터 Project를 구성할것입니다.

let scripts: [TargetScript] = isCI ? [] : [.swiftLint]

앞서서 했던 isCI를 사용해서 scripts를 정의해줍니다. CI라면 없이, CI가 아니라면 SwiftLint를 포함시켜거 스크립트를 돌립니다.

let ldFlagsSettings: SettingsDictionary = product == .framework ?
["OTHER_LDFLAGS": .string("$(inherited) -all_load")] :
["OTHER_LDFLAGS": .string("$(inherited)")]

product가 framework (dynamic framework)라면 staticLibrary에 작성된 모든 멤버를 적재하도록 링커에 -all_load 옵션을 달아줍니다.

import ProjectDescription

public extension SettingsDictionary {
    static let codeSign = SettingsDictionary()
        .codeSignIdentityAppleDevelopment()
        .automaticCodeSigning(devTeam: "\(Apple Team Identifier)")
}

let settings: Settings = .settings(
    base: env.baseSetting
        .merging(.codeSign)
        .merging(settings)
        .merging(ldFlagsSettings),
    configurations: [
        .debug(name: .dev, xcconfig: .relativeToXCConfig(type: .dev, name: name)),
        .debug(name: .stage, xcconfig: .relativeToXCConfig(type: .stage, name: name)),
        .release(name: .prod, xcconfig: .relativeToXCConfig(type: .prod, name: name))
    ],
    defaultSettings: .recommended
)

프로젝트의 세팅에 사용할 변수입니다.
baseSetting에 파라미터로 받은 settigns와 방금 위에만든 ldFlagsSettings, 그리고 따로 extension으로 뺴놓은 codeSign merging 해줍니다.
그리고 configuration은 dev, stage, prod로 분리해놓고, defaultSettings는 recommended로 해놓았습니다.

var allTargets: [Target] = []
var dependencies = internalDependencies + externalDependencies

// MARK: - Interface
if targets.contains(.interface) {
    dependencies.append(.target(name: "\(name)Interface"))
    allTargets.append(
        Target(
            name: "\(name)Interface",
            platform: platform,
            product: .framework,
            bundleId: "\(env.organizationName).\(name)Interface",
            deploymentTarget: env.deploymentTarget,
            infoPlist: .default,
            sources: .interface,
            scripts: scripts,
            dependencies: interfaceDependencies,
            additionalFiles: additionalFiles
        )
    )
}

이후부터는 Micro Feature를 위한 Target을 설정하는 건데 위와 거의 비슷한 흐름을 가집니다.
모든 Feature를 거치고나면

let schemes: [Scheme] = targets.contains(.demo) ?
[.makeScheme(target: .dev, name: name), .makeDemoScheme(target: .dev, name: name)] :
[.makeScheme(target: .dev, name: name)]

...

extension Scheme {
    static func makeScheme(target: ConfigurationName, name: String) -> Scheme {
        return Scheme(
            name: name,
            shared: true,
            buildAction: .buildAction(targets: ["\(name)"]),
            testAction: .targets(
                ["\(name)Tests"],
                configuration: target,
                options: .options(coverage: true, codeCoverageTargets: ["\(name)"])
            ),
            runAction: .runAction(configuration: target),
            archiveAction: .archiveAction(configuration: target),
            profileAction: .profileAction(configuration: target),
            analyzeAction: .analyzeAction(configuration: target)
        )
    }
    static func makeDemoScheme(target: ConfigurationName, name: String) -> Scheme {
        return Scheme(
            name: name,
            shared: true,
            buildAction: .buildAction(targets: ["\(name)DemoApp"]),
            testAction: .targets(
                ["\(name)Tests"],
                configuration: target,
                options: .options(coverage: true, codeCoverageTargets: ["\(name)DemoApp"])
            ),
            runAction: .runAction(configuration: target),
            archiveAction: .archiveAction(configuration: target),
            profileAction: .profileAction(configuration: target),
            analyzeAction: .analyzeAction(configuration: target)
        )
    }
}

scheme을 만듭니다.
그리고 마지막으로

return Project(
    name: name,
    organizationName: env.organizationName,
    packages: packages,
    settings: settings,
    targets: allTargets,
    schemes: schemes
)

Project를 만들어서 리턴합니다.

모듈을 만들때 Project.makeModule 을 사용해서 사용할 수 있습니다.

다만, App 모듈을 만들때는 따로 Target을 만들지 않고, Scheme만 dev, stage, prod 3개 만들어주겠습니다.

자동화

프로젝트를 만드는 방법은 만들었지만 실제로 만들게 된다면 모듈 하나를 복사하고 이름을 바꾸고 필요없는 Target은 지우고 DependencyPlugin에 경로 넣어주고 하는 등 귀찮은 과정들이 좀 있습니다.
이런 반복작업같은거 조금 자동화를 시켜보려합니다.
우선 모듈 생성을 자동화해야할 때 입력해야 하는 것은 레이어(Feature, Domain, Core, Shared), 모듈 이름, Micro Feature 중 포함하는 Target을 선택하는 것을 입력받는 것이 필요합니다.

enum LayerType: String {
    case features = "Features"
    case services = "Services"
    case core = "Core"
    case shared = "Shared"
}

print("Enter layer name\n(Features | Services | Core | Shared)", terminator: " : ")
let layerInput = readLine()
guard 
    let layerInput, 
    !layerInput.isEmpty ,
    let layerUnwrapping = LayerType(rawValue: layerInput)
else {
    print("Layer is empty or invalid")
    exit(1)
}
let layer = layerUnwrapping
print("Layer: \(layer.rawValue)\n")

print("Enter module name", terminator: " : ")
let moduleInput = readLine()
guard let moduleNameUnwrapping = moduleInput, !moduleNameUnwrapping.isEmpty else {
    print("Module name is empty")
    exit(1)
}
var moduleName = moduleNameUnwrapping
print("Module name: \(moduleName)\n")

print("This module has a 'Interface' Target? (y\\n, default = n)", terminator: " : ")
let hasInterface = readLine()?.lowercased() == "y"

print("This module has a 'Testing' Target? (y\\n, default = n)", terminator: " : ")
let hasTesting = readLine()?.lowercased() == "y"

print("This module has a 'UnitTests' Target? (y\\n, default = n)", terminator: " : ")
let hasUnitTests = readLine()?.lowercased() == "y"

print("This module has a 'UITests' Target? (y\\n, default = n)", terminator: " : ")
let hasUITests = readLine()?.lowercased() == "y"

print("This module has a 'Demo' Target? (y\\n, default = n)", terminator: " : ")
let hasDemo = readLine()?.lowercased() == "y"

시간을 들여서 만든건 아니라서 지금 보기에는 상당히.. 더러운거같습니다만. 일단은 넘어,,갑시다..!
이후에 enum ModulePaths에 새로운 모듈의 경로를 추가해주고, xcconfig를 만들고, 각 Micro Feature들의 모듈을 경로에 등록 및 파일을 만들어줍니다. 이후 마지막으로 Project.swift파일을 만들어줄것입니다.

func registerModuleDependency() {
    registerModulePaths()
    makeProjectDirectory()
    registerXCConfig()
    registerMicroTarget(target: .sources)
    var targetString = "["
    if hasInterface {
        registerMicroTarget(target: .interface)
        makeScaffold(target: .interface)
        targetString += ".\(MicroTargetType.interface), "
    }
    if hasTesting {
        registerMicroTarget(target: .testing)
        makeScaffold(target: .testing)
        targetString += ".\(MicroTargetType.testing), "
    }
    if hasUnitTests {
        makeScaffold(target: .unitTest)
        targetString += ".\(MicroTargetType.unitTest), "
    }
    if hasUITests {
        makeScaffold(target: .uiTest)
        targetString += ".\(MicroTargetType.uiTest), "
    }
    if hasDemo {
        makeScaffold(target: .demo)
        targetString += ".\(MicroTargetType.demo), "
    }
    if targetString.hasSuffix(", ") {
        targetString.removeLast(2)
    }
    targetString += "]"
    makeProjectSwift(targetString: targetString)
    makeProjectScaffold(targetString: targetString)
}

디자인 패턴을 쓰고 싶었지만,, 단일 파일이라 미묘하게 부담스러워서 하드코딩을 저질러버렸다.
전체 코드는 여기에서 볼 수 있습니다!
+ 모듈의 Target파일을 생성할 때 tuist scaffold를 사용했는데, 이에 관한건 나중에 작성해보겠습니다..!

그리고 이 파일을 실행하는 것은 프로젝트 Root에 Makefile을 만들어서 명령어를 만들어놓겠습니다.

...


module:
    swift Scripts/GenerateModule.swift

...

으로 make module 을 치면 모듈을 만들 수 있게 해줍니다.

우선 여기까지 마치고, 더 자세한 내용은 https://github.com/baekteun/Tuist_Modular_Template 에서 볼 수 있습니다.

+ 해당 Repository의 코드는 현재 포스트와 일부 달라졌습니다
+ https://baegteun.tistory.com/15 에서 조금 더 개선한 버전을 볼 수 있습니다

References By

https://minsone.github.io
SyncSwift 2022 - Modular Architecture 시작하기
Let'Swift 2022 - Modular Architecture /w Tuist
https://docs.tuist.io/building-at-scale/microfeatures/

Tuist 사용법 - 7. Configuration + XCConfig

baegteun — Tue, 27 Dec 2022 14:54:09 +0900

이 글은 Tuist 버전 3.14.0 기준으로 작성되었습니다.

Configuration?

개발, 스테이지, 릴리즈 등의 배포환경을 분리할 때 Build Configuration을 활용합니다.

XCConfig?

Xcode 프로젝트 빌드의 설정을 구성하기 위한 파일입니다.

Configuration 설정법

Settings 를 만들 때 base, configurations, defaultSettings 에서

configurations에 값을 넣어줘서 설정할 수 있습니다.

configuration은 debug, release중 하나로 만들 수 있고 configuration별 이름을 정해줄 수 있습니다.

configuration을 만들 때 settings와 xcconfig(경로)를 지정해줄 수 있습니다.

활용

Configuration

configuration을 설정할 때 이름을 정해줄 수 있는데, ProjectDeployTarget 이라는 enum을 만들고 배포환경별로 case를 만들어줍니다.

public enum ProjectDeployTarget: String {
    case dev = "DEV"
    case stage = "STAGE"
    case prod = "PROD"
}

configuration을 설정할때 name은 ConfigurationName 타입입니다. 그렇기에 ConfigurationName에 extension으로 각 배포환경을 선언해놓습니다.

public extension ConfigurationName {
    static var dev: ConfigurationName { configuration(ProjectDeployTarget.dev.rawValue) }
    static var stage: ConfigurationName { configuration(ProjectDeployTarget.stage.rawValue) }
    static var prod: ConfigurationName { configuration(ProjectDeployTarget.prod.rawValue) }
}

이렇게 해놓으면 configuration을 설정할 때 아래처럼 사용할 수 있습니다.

XCConfig

configuration마다 다른 빌드 설정을 주기위해 XCConfig를 사용해보겠습니다.

저는 프로젝트의 루트 디렉토리에 XCConfig/ 디렉토리를 만들고, 이 안에 (모듈이름)/(configuration).xcconfig 파일들을 넣어주겠습니다.

그리고 XCConfig/ 바로 아래에 Shared.xcconfig 파일을 만들어주겠습니다. 이 파일 안에는

OTHER_SWIFT_FLAGS[config=DEV][sdk=*] = $(inherited) -DDEV
OTHER_SWIFT_FLAGS[config=STAGE][sdk=*] = $(inherited) -DSTAGE
OTHER_SWIFT_FLAGS[config=PROD][sdk=*] = $(inherited) -DPROD

로 내용을 넣어주겠습니다.

그리고 만들어질 모든 .xcconfig 에는

#include "../Shared.xcconfig"

으로 Shared를 include 하도록 하겠습니다.

만드는 이유는 각 환경에 맞게 OTHER_SWIFT_FLAGS 값을 추가하여

#if STAGE

같이 MACRO로 분기할 수 있도록 하기 위해서입니다.

xcconfig 파일들을 만들고 나서는 configuration을 설정할 때 xcconfig: 에 xcconfig 파일의 경로를 넘겨줘서 xcconfig 설정을 할 수 있습니다.

Additional

Configuration 작업을 한 이후에 Dependencies.swift에 디펜던시를 추가하고 generate를 하게 되면
Warning: The project 'Lottie' has missing or mismatching configurations. It has [Debug (debug), Release (release)], other projects have [DEV (debug), STATE (debug), PROD (release)]
라는 메시지가 출력될겁니다. 이는 외부에서 불러온 라이브러리의 Configuration은 저희가 구성한 Configuration과 달리 Debug와 Release로 구성되어있기 때문입니다. 이때는 Dependencies.swift에

import ProjectDescription
import ProjectDescriptionHelpers

let dependencies = Dependencies(
    swiftPackageManager: SwiftPackageManagerDependencies(
        [
            .remote(url: "https://github.com/airbnb/lottie-ios.git", requirement: .upToNextMajor(from: "3.5.0")),
            .remote(url: "https://github.com/uber/needle.git", requirement: .upToNextMajor(from: "0.19.0")),
            .remote(url: "https://github.com/Moya/Moya.git", requirement: .upToNextMajor(from: "15.0.3")),
            .remote(url: "https://github.com/Quick/Nimble.git", requirement: .upToNextMajor(from: "10.0.0")),
            .remote(url: "https://github.com/Quick/Quick.git", requirement: .upToNextMajor(from: "5.0.0"))
        ],
        baseSettings: .settings(
            configurations: [
                .debug(name: .dev),
                .debug(name: .stage),
                .release(name: .prod)
            ]
        )
    )
)

이렇게 baseSettings에 configuration을 설정해주면 됩니다.

References By

https://minsone.github.io/mac/ios/ios-project-generate-with-tuist-2
https://github.com/mephrine/TuistRxTemplate

[iOS - Swift] Swift의 메모리 구조

baegteun — Sun, 4 Dec 2022 14:55:18 +0900

프로그램이 실행되면 OS가 메모리 공간을 할당해주는데 Code, Data, Heap, Stack 4개로 나뉜다.

Code

우리가 작성한 소스코드가 저장되는 영역이다.

소스코드를 기계어 형태 (0, 1) 로 변경하여 저장한다.
컴파일 타임에 결정되고, 중간에 코드가 변경되면 안되니 Read-Only로 저장된다.

Data

이름 그대로 데이터를 저장하는 영역이다.

전역 변수, static 변수가 저장된다.
```
enum Constant {
  static let apiKey = ""
}
```

var name = "baegteun"
var number = 18


- 프로그램의 시작과 동시에 할당되고, 프로그램이 **종료되어야 해제**된다.
- 실행 도중 값이 변경될 수도 있으니 **Read-Write**로 저장된다.


# Heap
데이터 크기가 확실하지 않은 **가변적인 데이터 타입**들이 저장되는 영역이다.

- 4개의 영역중 유일하게 **런타임**에 결정된다.
- Heap영역에는 임의의 주소값에 해당 메모리를 할당한다.
  - 임의의 값에 해당하기 때문에 주소를 찾아가는 것에 대한 오버헤드가 크다.
- 메모리 할당, 해제가 하나의 명령어로 처리되지 않기 때문에 관리가 어렵다.
- 메모리가 올라갔는지 아닌지 계속 추적하는 **Reference Counting**이 필요하다.
  - **ARC**에 의해 Reference Counting이 관리된다.
- **스레드들이 공유**하는 영역이기 때문에 **thread-safety**하지 않다.
  - 이를 관리하기 위해서는 Lock같은 자원이 필요하고 이것이 오버헤드로 이어진다.

class의 인스턴스, closure, 가변적인 String, Array같은 타입들이 Heap영역에 저장된다.


# Stack
함수의 호출과 관련된 **지역 변수, 매개변수**들이 저장되는 영역이다.

- Stack은 선형의 단순한 구조이면 시간 복잡도가 O(1)이다. 즉, 할당과 해제가 **빠르고 효율적**이다.
  - CPU에 의해 관리되고 최적화 돼서 속도가 매우 빠르다.
- 함수가 종료되면 저장된 메모리도 해제된다.
- **컴파일 타임**에 결정되기 때문에 무한히 할당할 수 없다.
- 컴파일 단계에서 언제 생성되고 해제되는지 알 수 있는 struct와 같은 값들이 저장된다.
  - 단, struct가 protocol을 채택하는 경우에는 **Heap영**역에 저장된다.
- 스레드 별로 독립적인 Stack 영역을 가지고 있기 때문에 **thread-safety** 하다.


## Heap과 Stack의 관계
Heap과 Stack은 같은 메모리 공간을 사용한다.

Heap 영역은 메모리의 낮은 주소 -> 높은 주소의 방향으로 할당된다.

Stack 영역은 메모리의 높은 주소 -> 낮은 주소의 방향으로 할당된다.


# 정리
메모리구조
- Code : 소스코드(기계어), ReadOnly
- Data : 전역변수, 정적변수
- Heap : 동적 할당/해제, 유일하게 런타임에서 결정, ARC, Thread-Safety X
- Stack : 매개변수, 지역변수, Thread-Safety O

[iOS - Swift] rethrows

baegteun — Mon, 7 Nov 2022 17:43:52 +0900

rethrows

파라미터로 전달받는 함수(Closure)가 Error를 던질 때 사용
argument 내부에서 에러가 발생하면, 해당 argument에서 받은 Error를 다시 던질 수 있도록 명시

enum SomeError: Error {
    case someError
}

func someFunc(callback: () throws -> Void) {

}

func someThrowableFunc() throws {
    throw SomeError.someError
}

위와 같이 함수 정의할 시 callback()을 사용하려 하면

enum SomeError: Error {
    case someError
}

func someFunc(callback: () throws -> Void) {
    do {
        try callback()
    } catch {
        print(error)
    }
}

func someThrowableFunc() throws {
    throw SomeError.someError
}

someFunc(callback: someThrowableFunc)

someFunc 내부 에서 Error를 처리해야 한다.
하지만 someFunc가 rethrows를 이용하면

enum SomeError: Error {
    case someError
}

func someFunc(callback: () throws -> Void) rethrows {
    try callback()
}

func someThrowableFunc() throws {
    throw SomeError.someError
}

do {
    try someFunc(callback: someThrowableFunc)
} catch {
    print(error)
}

someFunc를 사용하는 곳에서 Error를 처리할 수 있다.

throws로 하면 안되나?

enum SomeError: Error {
    case someError
}

func someFunc(callback: () throws -> Void) throws {
    try callback()
}

func someThrowableFunc() throws {
    throw SomeError.someError
}

do {
    try someFunc(callback: someThrowableFunc)
} catch {
    print(error)
}

someFunc를 throws로 처리해도 someFunc를 사용하는 곳에서 Error를 처리할 수 있다.

그렇다면 throws와 rethrows의 차이는 무엇인가?

import Foundation

enum SomeError: Error {
    case someError
}

func someFunc(callback: () throws -> Void) rethrows {
    try callback()
}

func someThrowableFunc() throws {
    throw SomeError.someError
}

func someNonThrowableFunc() {}

someFunc(callback: someNonThrowableFunc)

rethrows를 가진 함수에 throws가 아닌 함수를 전달하면 Error처리를 하지 않는다.
하지만 throws를 가진 함수에 throws가 아닌 함수를 전달하면 Error처리를 해야한다.

이는 throws를 가진 함수는 내부에서 스스로 throw를 할 수 있고, rethrows를 가진 함수는 내부에서 스스로 throw를 할 수 없는 특성이 있기 때문인거같다.

그 외

부모 클래스의 throws는 자식클래스에서 rethrows로 override할 수 있다.
반대로 부모 클래스의 rethrows는 자식클래스에서 throws로 override할 수 없다.

프로토콜 함수에 throws가 있다면 rethrows로 구현할 수 있다.
반대로 프로토콜 함수에 rethrows가 있다면 throws로 구현할 수 없다.

Tuist 사용법 - 6. 버전 고정

baegteun — Mon, 19 Sep 2022 12:44:00 +0900

Tuist를 사용하면서 다른 사람과 협업할 때, 각자 설치해놓은 버전이 다를 수 있습니다. 또한 Tuist의 업데이트 주기가 짧은 편이기에 더욱 이런 사태가 발생할 가능성이 크죠.

이때 해당 프로젝트에서 Tuist의 버전을 고정해서 사용하는 방법이 있습니다.

프로젝트의 root에서 .tuist-version 파일을 만들고 그 안에 고정해놓을 Tuist 버전을 작성해놓으면 됩니다. (ex. 3.10.0)

References By

https://docs.tuist.io/guides/version-management/#local