Adopting Swift Packages in Xcode

https://developer.apple.com/videos/play/wwdc2019/408/

Adopting Swift Packages in Xcode - WWDC19 - Videos - Apple Developer

 

목차

 

1. Using an open source package

• Swift package manager를 이용해 패키지를 설치하는 과정을 설명해 주는 파트입니다.
• 관련 글들은 워낙 많기 때문에 생략하겠습니다..!

 

2. A closer look at packages

• 패키지는 Swift Package 매니패스트가 포함된 디렉토리이다.
• 매니페스트는 Package.swift라는 파일이며 해당 디렉토리를 Swift Package로 식별한다.
• 패키지는 Sources 디렉토리를 포함한다.
• Sources가 잘 동작하는지 확인하기 위한 Unit Tests도 포함한다.
• Sources 아래에는 패키지의 각각의 타겟에 대한 하위 디렉토리가 존재한다.
• 이것들은 개별적으로 패키지의 buildable components이다.
• 마찬가지로 Tests 디렉토리 아래에는 모든 test suite에 대한 별도의 하위 디렉토리가 존재한다.
• 타겟 디렉토리에서 각 타겟은 C 기반 언어 또는 Swift 중 하나의 구현을 가질 수 있다. 또한 Objective-C++ 파일도 포함할 수 있다.

Package.swift 구성

• Creating Swift Packages에도 나왔던 부분이라 생략하겠습니다!

• 우리의 프로젝트는 소스 파일로 구성되어 있고 의존하는 패키지도 소스파일로 구성되어 있다.
• 따라서 Xcode가 하는 일은 이 모든 소스파일들을 가져와서, 컴파일하는 것입니다. 특히, 패키지 코드들을 프로젝트의 앱 코드와 호환되는 방식으로 컴파일한다.
• 여기에는 아키텍쳐, 플랫폼 등이 포함된다.
• 필요한 경우 앱에 필요한 내용에 따라 여러번 다시 컴파일 된다.
• 그리고 link하고 앱에 결합시킨다.
• Package library들은 기본적으로 Static이다. 그래서 모든 코드가 서로 link되어 있다.

• 패키지가 다른 패키지에 의존하는 것 역시 가능하다. Package.swift파일에 디펜던시를 추가하면 된다.

 

3. Package resolution in more detail

• Project 파일에서 Package Dependencies에 가보면 내가 설치한 패키지들과 해당 패키지들의 버전 설정을 볼 수 있다.

• 만약 "Yams"라는 패키지를 설치했고 2.0.0 - Next Major로 설정했다면 2.0.0이상이지만 Major 버전이 3이상으로 넘어가지는 않도록 설치된다.
• 위의 그림에서 2.1.0과 3.0.0이 존재하지만 Xcode는 2.1.0을 선택해서 설치한 것을 볼 수 있다.

 

• 팀원이 다른 패키지들을 추가한 상황에서의 resolution에 대해 알아보자

• Yams를 제외하고 총 3개의 패키지를 팀원이 추가했다.

• Project editor 에 가보면 "DesignTheme" 패키지가 1.0.0 - Next Major로 설정된 모습을 볼 수 있다.

• 설정된 Version Rules에 따라 Xcode는 알맞은 버전을 선택하여 설치하였다.

하지만 여기서 의아한 점이 있을 수 있는데, 앞서 총 3개의 패키지를 더 추가했는데 "DesignTheme" 1개만 보인다는 점이다.

"DesignFont"와 "DesignColor" 패키지는 어디에 있을까?

 

그 이유는 Project Editor는 우리가 패키지를 추가한 프로젝트와 직접 의존하는 패키지(direct dependencies)들만 보여주기 때문이다.

 

• DesignTheme 패키지의 Package.swift에 가보면 dependencies로 앞서 찾던 2개의 패키지가 선언되어 있는 것을 확인할 수 있다.

• dependencies에 지정한 version rules에 맞게 버전이 선택된 것을 확인할 수 있다.

• 전체적인 패키지 import 그래프는 위와 같다.
• 패키지 resolution이 동작하는 것과 매우 유사한 그래프이다. 그리고 이것은 의도적이다.

• 만약 Lunch 앱이 DesignTheme 을 거치지 않고 바로 DesignFont를 import하고 싶다면 어떻게 될까?

• DesignTheme은 DesignFont 및 Update에 대한 종속성을 잃고 Xcode는 DesignFont에 대한 참조를 잃게 된다.
• 따라서, DesignFont 라이브러리를 사용할 수 없게 된다.
• 해결방법은 무엇일까?

• Lunch 프로젝트와 DesignFont 패키지 사이에 직접적인 의존성을 만드는 것이다.
• 이렇게 하면 Lunch 프로젝트에서 DesignFont의 내용을 가져올 수 있다.
• 왜나하면 DesignTheme는 DesignFont에 대한 의존성을 잃게 되지만 Xcode내부의 해당 라이브러리에 대한 참조는 여전히 유지되기 때문이다.

 

4. Updating packages

• 패키지의 새로운 버전이 출시되어서 업데이트를 하고 싶다면 Xcode에서 File -> Packages -> Update to Latest Packages Versions를 누르면 된다!

영상의 예제에서는 DesignFont를 1.2.1로 업데이트 했다.

어떻게 패키지의 Version을 업데이트 할 수 있었는지 알아보자..!

 

• xcshareddata 디렉토리에 있는 Package.resolved는 workspace 내부의 모든 패키지에 대한 버전 정보를 기록한다.
• 업데이트 작업을 수행하면 이 파일이 업데이트되고, Xcode가 새로운 버전을 선택한다.
• 중요한 점은 이 작업이 Local 작업이라는 것이다. 버전 업데이트를 팀 전체에게 공유하려면  Package.resolved 파일의 변경을 commit하고 push해야한다. (팀원들도 수정된 Package.resolved 파일을 가져야 한다는 의미)
• Package.resolved 파일은 우리가 직접 편집할 필요가 없다. Xcode가 이 작업을 수행한다.

버전이 바뀌어서 Package.resolved도 자동으로 수정된 모습

 

5. Resolving package conflicts

앞선 예시의 Lunch앱에서 DesignFont 패키지의 version 2.0.0을 직접 사용해야 한다는 상황을 가정하자.

Lunch 앱에 직접 DesignFont 패키지를 2.0.0 버전으로 설정하여 추가하려고 하면 다음과 같은 에러가 발생한다.

원인

Lunch앱은 DesignTheme에 의존하고 있고 DesignTheme은 DesignFont에 의존하고 있다.

이때, DesignTheme에서 DesignFont의 Version을 1.0.0 up to next major로 설정했기 때문에 Lunch에서 새롭게 2.0.0으로 직접 추가하게 되면 두 요구사항에 충돌이 생기는 것이다.

한 workspace에는 하나의 버전의 패키지만 존재 가능하다.

 

해결 방법

DesighTheme 의 버전을 업데이트하여 해결 할 수 있다.

• 깃허브에서 DisgnTheme의 버전이 2.0.0일 때 DesignFont에 대한 버전 설정이 .upToNextMajor(from "2.0.0") 인 것을 확인할 수 있다.
• 따라서 Lunch 프로젝트에서 DesignTheme에 대한 version rule을 수정해서 2.0.0으로 설치하면 자동으로 DesignFont 또한 2.0.0 이상으로 설치되는 것이다.

DesignTheme의 버전을 2.0.0 이상으로 설정

DesignTheme이 2.0.0으로 업데이트 되면서 DesignFont도 2.0.0으로 올라온 모습

주의해야할 점: 사용하는 패키지들의 Major 버전을 업데이트 했을 경우 몇몇 api의 변경이 있을 수 있기 때문에 이에 대응해야 한다.

 

이제 Lunch 프로젝트에 직접 DesignFont 패키지를 추가해도 문제 없이 추가가 가능하고 `import DesignFont`를 해서 코드에서 사용도 가능해졌다!!