Swift 패키지 - 향후 종속성 관리

하도급 관리는 이미 수십 년 동안 존재해 왔다.APT에서 Maven에 이르기까지 초콜릿까지 모든 것이 다 있다.애플 분야에서 일하는 사람들에 대해서 말하자면, 우리는 코코푸드와 Homebrew에 대해 더 잘 알고 있을 것이다.그러나 Swift를 도입한 후 애플팀은 우리에게 새로운 패키지 관리자인 Swift 패키지 관리자를 주었다.
이 문서에서는 다음을 설명합니다.

iOS 및 기타 Swift 개발자가 사용할 수 있는 기능

SPM(Swift 패키지 관리자)의 이전 모델

과 비교 우위
우선 어떤 패키지 관리자를 사용해야 하는지 알아보자.

모듈화 및 재사용 - 패키지 관리의 장점

패키지 관리의 관건적인 구성 요소 중 하나는 코드를 공유하거나 파일을 실행할 수 있는 능력이다. 공개든 내부 개발진이든.
이렇게 하는 일부분은 코드를 다른 부분으로 분해하는 것이다.이것이 바로 가방 매니저가 모듈화를 장려하는 곳이다.구성 요소는 분리되어 적당한 테스트를 하고 다른 사람이 사용할 수 있다는 얘기다.
일단 이 부분의 기능을 분리하면 각종 설비와 운영체제에서 지원할 수 있다.애플의 생태계에서는 아이폰뿐만 아니라 리눅스 서버부터 애플워치까지 모든 제품을 지원한다는 의미일 수 있다.
패키지 관리의 또 다른 좋은 특징은 특정한 버전을 잠글 수 있다는 것이다.일반적으로 버전 표시나 지점 이름과 관련된 semver 호환 버전 번호를 지정할 수 있습니다.애플 생태계에서 개발자의 다양한 패키지 관리자에 들어가자.

전에 일어난 일...그리고 근처에 있어요.

Swift Package Manager는 Swift 개발자에게 새로운 제품이며 iOS와 macOS 개발자는 말할 것도 없다.개발자가 하기 전에 했던 일을 이야기해 봅시다.
스웨프트가 나타난 이래로 가타키는 줄곧 존재해 왔다.가타키는 2진 프레임워크를 구축하고 프로젝트에서 이를 공유하는 데 뛰어나다.가타키 이전에는 Objective-C 초기부터 코코넛 꼬투리가 있었다.
한 가지 단점은 Cocoapods는 루비에 구축되어 있기 때문에 정확한 버전의 루비를 설치해야 하고 Carthage는 Swift에 구축되어 있다는 것이다.Cocoapods의 또 다른 단점은 Xcode 프로젝트와 작업 영역을 수정해야 한다는 것입니다.가타키는 사용자가 처음 집적할 때 수동으로 구축된 프레임워크를 추가함으로써 이 문제를 해결했다.가타키가 코코넛 꼬투리와 다른 선택에 관심이 있다면 this piece the Carthage README.
마지막으로 둘 다 프로젝트에 적용되지 않으면 git submodules가 있습니다.Git 서브 모듈은 가장 처리하기 어렵지만 아마도 가장 통용될 것이다.그것들은 하위 디렉터리에 사용할 수 있는git repo만 있으면 연결할 수 있습니다.의존 항목을 편집할 계획이라면git 서브 모듈이 필요할 수도 있습니다.
만약 패키지 관리자를 사용하려고 한다면, 하나를 선택하고 꾸준히 사용하는 것이 가장 좋다.그러나 가장 좋은 선택은 Swift Package Manager로 마이그레이션하는 것입니다.

왜 Swift 패키지 매니저입니까?

Swift Package Manager는 많은 이점을 제공합니다.SPM(Swift 패키지 관리자)은 다기능 버전 제어 처리 기능 외에도 스위프트에서 네이티브 지원을 받았다.CocoaPods 등의 도구에는 Ruby와 기타 Gem 의존 항목이 필요하지만 SPM은 필요하지 않습니다.SPM은 MacOS 또는 Linux 시스템에 Swift 또는 Xcode를 설치하기만 하면 됩니다.
SPM도 오픈소스이며 애플의 지원도 받았다.이것은 어떤 것들이 어떻게 일을 하는지, 그리고 지역 사회에 개방되고, 애플의 최상의 이익에 부합하도록 지지할 수 있다는 것을 의미한다.
실제로 이것은 현재 의존 관계가 SPM을 지원하는지 여부에 따라 달라집니다.현재 SPM이 2진 패키지(즉 XC 프레임워크) 등 기능에 대한 지원을 확장하면서 SPM의 CoCoapod과 Carthage 패키지의 목록도 계속 증가하고 있다.
SPM은 Xcode 프로젝트에서 이점을 제공할 뿐만 아니라 코드를 모듈화하고 공유하는 방식에서도 이점을 제공합니다.

Swift Package Manager를 사용해야 하는 이유

Swift Package Manager를 통해 응용 프로그램을 버스트하거나 라이브러리나 실행 파일을 게시할 수 있는 여러 가지 이유가 있습니다.우선 서버부터 디바이스에 이르기까지 전체 Swift로 애플리케이션을 구축하는 것이 더욱 쉬워졌습니다.

제비 한 묶음

예를 들어, Vapor, Lambda, Smoke, Hummingbird 등 지원 서버 애플리케이션을 Swift로 구축할 수 있습니다.이렇게 하면 클라이언트(iOS 응용 프로그램)와 서버 간에 코드를 공유할 수 있습니다.구체적으로 iOS와 서버에서 코딩 가능한 모델을 공유할 수 있다.서버가 있는 경우에도 Swift에서 아날로그 서버를 구축하여 테스트할 수 있습니다.

    // an example of sharing server-side and client-side code via SPM

    // HeartwitchKit/WorkoutData.swift
    public struct WorkoutData {
      public let heartRate: Double?

      public init(heartRate: Double? = nil) {
        self.heartRate = heartRate
      }

      public func updated(with new: WorkoutData) -> WorkoutData {
        let heartRate = new.heartRate ?? self.heartRate
        return WorkoutData(heartRate: heartRate)
      }
    }

    extension WorkoutData: Codable {}

    // HeartwitchKitServer/WorkoutData
    import Vapor
    extension WorkoutData: Content {}

Swift에서 애플리케이션의 양 끝을 구축하려면 SPM이 유일한 선택입니다.실제로 SPM은 장치에서 추상화할 수 있는 일부 코드에 대해 Xcode보다 테스트에 유리하다.

테스트 가능성

SPM을 통한 테스트도 간단합니다.특히 시뮬레이터에서 실행하기가 어렵고 느릴 때예를 들어 Xcode 12.5가 watchOS 테스트를 지원하기 전에는 watchOS 실행 단위 테스트가 거의 불가능했다.
하지만 대부분의 애플워치 앱 코드를 스위프트 패키지에 넣으면 워치OS가 필요 없는 코드를 쉽게 테스트할 수 있다.이것은 이 문제를 피할 수 있지만, 실제 장치나 시뮬레이터를 통과하지 않아도 더욱 쉽게 할 수 있다.
SwiftUI 또는 HealthKit 코드와 같이 코드는 시계에서만 사용할 수 있으며 사전 프로세서 명령 조합을 사용하여 가용성을 표시할 수 있습니다.

    // using canImport and os to disable applicable code

    #if canImport(HealthKit)
      import HealthKit

      extension HKHealthStore: HealthInterface {
        public func workout(withConfiguration configuration: WorkoutConfiguration) throws -> Workout {
          let hkConfig = HKWorkoutConfiguration()
          hkConfig.activityType = configuration.activityType.healthKitType
          #if os(watchOS)
            return try HealthKitLiveWorkout(fromHealthStore: self, withConfiguration: hkConfig)
          #else
            return try HealthKitWorkout(fromHealthStore: self, withConfiguration: hkConfig)
          #endif
        }
      }
    #endif

뿐만 아니라 서버 사이드 응용 프로그램을 개발할 때, 나는 매번watchOS 응용 프로그램을 실행해서 서버의 기능을 테스트하고 싶지 않을 수도 있다.그런 면에서 스위프트백을 재구성하는 것도 유용하다.대부분의 watchOS 코드를 포함하는 라이브러리를 가지고 있으면 애플워치 프로그램의 심장 박동률을 시뮬레이션할 수 있는 간단한 명령행 프로그램을 만들 수 있습니다.

명령줄 도구

SPM에서는 watchOS 응용 프로그램 Heartwitch의 기능을 심장 박동률 센서 기능을 복제하는 명령행 도구로 복사할 수 있습니다.따라서 내 Apple Watch나 에뮬레이터에서 Heartwitch 애플리케이션을 실행하지 않고도 서버 애플리케이션을 쉽게 테스트할 수 있습니다.

내가 가장 좋아하는 도구 중 하나는 the Swift Argument Parser by the Swift team이다.
Swift Argument Parser는 Swift UI(즉 속성 패키지)와 Codable의 위대한 사상을 바탕으로 구축되어 명령줄에 도입됩니다.하위 명령, 유용한 피드백, 옵션, 로고 등을 실행할 수 있습니다.내 예에서, 나는 그것을 사용하여 더욱 빠른 서버 사이드 개발을 실현했다.구체적으로 말하면 애플워치 응용 프로그램의 심장 박동률 모니터링 기능을 복제하고 서버에 시뮬레이션 심장 박동률을 제공하는 명령행 도구를 구축했다.

SPM의 힘

이 문서에서 다른 관리자에 비해 패키지 관리 및 SPM의 장점에 대해 설명합니다.SPM을 고려하여 Swift 패키지를 프로젝트에 통합하는 세부 사항을 학습합니다.Cocoapods나 Carthage를 사용하고 있다면, 응용 프로그램을 서버로 이전하는 것을 고려하십시오.다음 기사에서는 Swift 패키지를 처음부터 만들고 가장 중요한 부분인 패키지를 논의할 것입니다.swift - swift 패키지 목록 파일.