스위프트 패키지를 코코아팟에 배포하기

스위프트 패키지를 코코아팟(CocoaPods) 의존성 관리도구(Dependency Manager) 에 배포하는 과정

1. 배경 및 목적

Xcode 에서 개발한 Framework 를 코코아팟에 배포하고 XCFramework 를 추출해서 스위프트 패키지 매니저에도 배포는 수차례 해보았지만 스위프트 패키지 매니저에 배포하던 스위프트 패키지를 코코아팟에 배포하는 것은 경험이 없었다.

CocoaPods의 매니페스트(Manifest) 설정을 담당하는 Podspec 를 가볍게 수정하는 것으로 스위프트 패키지를 코코아팟에 배포할 수 있다.

이 문서에서는 SevenSegmentUI 라는 스위프트 패키지에 .podspec 파일을 생성하고 코코아팟 트렁크(Trunk) 에 푸시하여 배포하는 과정을 다뤄보겠습니다.

2. 코코아팟 배포 과정

2.1. Podspec 생성 및 수정

중요

pod 커맨드라인 도구 설치가 사전에 필요합니다.

pod spec create SevenSegmentUI # 패키지 이름

spec create 는 .podspec 파일을 생성하는 명령어 입니다.¹

명령어 실행 후 package-seven-segments 폴더의 구성은 다음과 같게 됩니다.

package-seven-segments
|--- Package.swift
|--- SevenSegmentUI.podspec
|--- Sources
     |--- SevenSegmentUI

.podspec 을 열고 아래와 같이 팟의 스펙 정보를 작성했습니다.

Pod::Spec.new do |spec|
  spec.name         = "SevenSegmentUI"
  spec.version      = "0.0.1"
  spec.summary      = "한 줄 설명"

  spec.description  = <<-DESC
    라이브러리에 대한 자세한 소개 문구가 들어갑니다.
                   DESC

  spec.license      = { :type => "MIT", :file => "LICENSE" }

  spec.author             = { "Jaesung Lee" => "이메일주소" }

  spec.ios.deployment_target = "16.0"
  spec.swift_version = "5.9"

  spec.source       = {
    :git => "https://github.com/jaesung-0o0/package-seven-segments.git",
    :tag => "#{spec.version}"
  }

  spec.source_files  = "Sources/SevenSegmentUI/**/*"

end

스펙에 들어가야 하는 정보는 다음과 같습니다. 여기서 가장 중요한 것은 spec.source_files 입니다. Sources 하위 폴더 중 팟으로 제공하고자 하는 소스의 폴더를 명시해줘야 합니다.

.podspec 수정이 완료되면 다음과 같이 작성된 내용이 유효한 지 검증합니다.

pod spec lint SevenSegmentUI.podspec

2.2. 코코아팟에 배포

수정된 .podspec 커밋하고 원격 저장소에 푸시합니다.

git add *
git commit -m "[버전] 1.0.0"
git push origin main

커밋에 버전을 명시한 태그를 추가합니다. 아까 .podspec 에서 source_files 의 :tag 에 태그 내용을 버전으로 사용한다고 명시했기 때문에, trunk 에 배포 전 반드시 원격저장소에 태그가 먼저 추가되어 있어야 합니다.

git tag "1.0.0"

태그까지 추가 되었다면 트렁크에 푸시합니다.

pod trunk push

NOTE

git.author 에 기재한 작성자 정보가 트렁크에 등록되어있지 않다면 트렁크에 푸시할 수 없습니다. 푸시 전 다음 명령어를 실행하여 이메일과 이름을 트렁크에 등록해주도록 합니다.

pod trunk register 이메일주소 이름 # 띄어쓰기는 밑줄로 대체. 예: Jaesung_Lee

이 명령어를 실행하면 등록을 하려는 이메일 주소로 인증메일이 발송 됩니다. 인증 메일에 있는 링크를 누르면 등록이 완료됩니다.

푸시가 성공적으로 완료되면 다음과 같이 메세지가 나타납니다.

--------------------------------------------------------------------------------
 🎉  Congrats

 🚀  SevenSegmentUI (0.0.1) successfully published
 📅  November 3rd, 04:37
 🌎  https://cocoapods.org/pods/SevenSegmentUI
 👍  Tell your friends!
--------------------------------------------------------------------------------

3. 결론

.podspec 의 source_files 에 Sources/소스폴더이름/**/* 를 기재하여 스위프트 패키지를 코코아팟에 배포할 수 있습니다.

4. 참고 문헌

1: https://guides.cocoapods.org/making/specs-and-specs-repo

2: ** 는 모든 하위폴더를 의미, * 모든 파일을 의미

결론

동일한 .sheet 로직이 서로 뷰 계층에 중복으로 있는 지 확인해 볼것!

struct ParentView: View {
    @State private var isSheetPresented = false

    var body: some View {
        VStack {
            ChildView()
                .sheet(isPresented: $isSheetPresented) {
                    SheetView()
                }
        }
        .sheet(isPresented: $isSheetPresented) {
            SheetView()
        }
    }
}

설명

부모 뷰와 자식뷰에 .sheet 를 동일한 데이터로 트리거 하는 로직이 있다면 해당 데이터가 동시에 두개 이상의 sheet 컨텐츠를 트리거할 수 있다. 꼭 부모-자식이 아니더라도 서로 다른 뷰 계층 구조면 해당되는 상황이다. 실제 그 상황이 발생하면 콘솔에 다음과 같이 로그가 뜨는 것을 확인할 수 있다.

Currently, only presenting a single sheet is supported. The next sheet will be presented when the currently presented sheet gets dismissed.

글쓴이 본인이 이 에러를 마주했을 때 코드는 아래와 같이 동일한 .sheet 코드가 부모 뷰와 자식뷰에 있었다.

// 부모뷰: NoticesContentView
var body: some View {
    NoticeList(store: self.store) // 자식뷰
        .sheet( // 👈 자식 뷰에 동일 코드 있음
            store: self.store.scope(
                state: \.$changeDepartment,
                action: \.changeDepartment
            )
        ) { store in
            NavigationStack {
                DepartmentSelector(store: store)
            }
        }
}

// 자식뷰: NoticeList
var body: some View {
    Section {
        // ...
    }
    .sheet( // 👈 자식 뷰에 동일 코드
        store: self.store.scope(
            state: \.$changeDepartment,
            action: \.changeDepartment
        )
    ) { store in
        NavigationStack {
            DepartmentSelector(store: store)
        }
    }
}

이 코드 하나만으로 onAppear 로직이 올바르게 동작하지 않아 Canvas Preview 가 실행되자 마자 에러가 나는 등 원인을 쉽게 찾을 수 없는 골치 아픈 에러들을 야기했다.

결론

리스트아이템 뷰에 적용하기

// Row.swift
struct Row: View {
    var body: some View {
        { ... }
            .buttonStyle(.plain)
    }
}

또는

// List.swift

List {
    ForEach(...) {
        Row()
            .buttonStyle(.plain)
    }
}

분석

List {
    ForEach(...) {
        Row()
            .buttonStyle(.plain) // 👈 2
    }
}
.listStyle(.plain)
.buttonStyle(.plain) // 👈 1

1번 경우

ForEach 에 적용하는 경우 de-select가 다소 늦게 동작하는 현상이 있었습니다. 예를 들어 swipe action을 하는 경우 selected 상태가 유지 되다가 터치를 떼는 순간 deselect 됩니다.

2번 경우

기대했던 동작으로 잘 되는 것을 확인할 수 있습니다. Row 뷰에 바로 적용하는 방법을 추천합니다.

결론

.aspectRatio(_:contentMode:) -> frame(maxWidth: .infinity) 호출해주면 된다.

설명

아래 사진처럼 정사각형 형태로 뷰를 최대 사이즈로 키우고 싶다면

.aspectRatio(_:contentMode:) -> frame(maxWidth: .infinity) 호출해주면 된다.

Color(.tertiarySystemGroupedBackground)
    .aspectRatio(1, contentMode: .fill)
    .frame(maxWidth: .infinity)

결론

애플의 WWDC19, 21 세션들을 보면, SwiftUI는 컴파일 시 커스텀 뷰들을 하나의 뷰 계층구조에 flatten 시키기 때문에 퍼포먼스 차이는 없습니다.

참고

• Building Custom View with SwiftUI, Apple Developer, https://developer.apple.com/videos/play/wwdc2019/237
• Demystify SwiftUI, Apple Developer, https://developer.apple.com/videos/play/wwdc2021/10022
• Demystify SwiftUI performance, Apple Developer, https://developer.apple.com/videos/play/wwdc2023/10160
• SwiftUI Tips and Tricks, Hacking with Swift, https://www.hackingwithswift.com/quick-start/swiftui/swiftui-tips-and-tricks

Apple Developer Documentations 의 Declaring a custom view 문서를 정독하며 정리한 내용입니다.

개요

참고 https://developer.apple.com/documentation/swiftui/declaring-a-custom-view

struct MyView: View {
    // 뷰 모습을 묘사
    var body: some View {
        VStack {
            Text("안녕")
        } // 이처럼 여러개의 자식 뷰를 갖는 경우 `@ViewBuilder` 속성이 있는 클로져를 사용하면 된다.(1)
    }
}

커스텀 레이아웃

https://developer.apple.com/documentation/swiftui/composing_custom_layouts_with_swiftui

리더보드는 투표수와 득표율을 보여줌 -> Grid 를 사용한다.

• GridRow ∈ ForEach ∈ Grid

• GridRow 는 Column cell 생성

• Grid 의 정렬은 모든 셀에 적용

  • 셀에서 gridColumnAlignment(_:) 을 사용해서 정렬을 오버라이드 할 수 있음

    Grid(alignment: .leading) {
    ForEach(model.pets) { pet in
        GridRow {
            Text(...)
    
            ProgressView(...)
    
            Text(...)
              .gridColumnAlignment(.trailing)
        }
    
        Divider()
    }
    }

투표 버튼

각 버튼이 같은 너비를 가지려면 Layout 프로토콜을 준수하는 커스텀 레이아웃을 만들어야함. -> MyEqualWidthHStack

1. sizeThatFits(proposal:subviews:cache:): 컨테이너 사이즈와 주어진 하위뷰들 정보를 알려줌. 이 메소드는 하위뷰들간의 수평 공백과 각 방향별 가장 큰 사이즈를 결합하여 컨테이너 전체 사이즈를 찾음.

   func sizeThatFits(
    proposal: ProposedViewSize,
    subviews: Subviews,
    cache: inout Void
   ) -> CGSize {
    guard !subviews.isEmpty else { return .zero }
   
    let maxSize = maxSize(subviews: subviews) // 가장 큰 사이즈
    let spacing = spacing(subviews: subviews) // 수평 공백
    let totalSpacing = spacing.reduce(0) { $0 + $1 }
   
    return CGSize(
        width: maxSize.width * CGFloat(subviews.count) + totalSpacing, // 가장 큰 사이즈 기준으로 하위뷰를 잡고 모든 공백을 더함 -> 너비가 초과하진 않은가...? 
        height: maxSize.height
    )
   }

2. placeSubviews(in:proposal:subviews:cache:): 하위뷰들이 레이아웃 내 어디에서 떠야하는지 알려주는 용도 이 메소드는 각 하위뷰에 대한 사이즈를 제안하고 이 사이즈를 뷰의 바뀐 지점을 사용해서 버튼을 기본 공백값과 함께 수평으로 나열합니다.

   func placeSubviews(
    in bounds: CGRect,
    proposal: ProposedViewSize,
    subviews: Subviews,
    cache: inout Void
   ) {
    guard !subviews.isEmpty else { return }
   
    let maxSize = maxSize(subviews: subviews)
    let spacing = spacing(subviews: subviews)
   
    let placementProposal = ProposedViewSize(width: maxSize.width, height: maxSize.height)
    var nextX = bounds.minX + maxSize.width / 2
   
    for index in subviews.indices {
        subviews[index].place(
            at: CGPoint(x: nextX, y: bounds.midY),
            anchor: .center,
            proposal: placementProposal
        )
        nextX += maxSize.width + spacing[index]
    }
   }

3. ViewThatFits 투표 버튼의 크기는 텍스트의 너비에 따라 정해집니다. ViewThatFits 는 사용가능한 공간에 맞게 수평으로 정렬할지, 수직으로 정렬할지 SwiftUI에 의해 정하도록 합니다.

   ViewThatFits {
    MyEqualWidthHStack {
        Buttons()
    }
    MyEqualWidthVStack {
        Buttons()
    }
   }

4. 캐싱 Layout 프로토콜은 양방향 캐싱 파라미터를 가짐. 이 캐시는 특정 레이아웃 인스턴스의 모든 메소드 간 공유되는 옵셔널 저장소에 접근을 제공합니다.

   // storage 를 위한 타입 정의
   struct CacheData {
    let maxSize: CGSize
    let spacing: [CGFloat]
    let totalSpacing: CGFloat
   }

   그런 다음, makeCache(subviews:) 옵셔널 프로토콜 메소드를 사용해서 하위뷰들을 계산하고 위에서 정의한 타입의 값으로 리턴.

   func makeCache(subviews: Subviews) -> CacheData {
    let maxSize = maxSize(subviews: subviews)
    let spacing = spacing(subviews: subviews)
    let totalSpacing = spacing.reduce(0) { $0 + $1 }
   
    return CacheData(
        maxSize: maxSize,
        spacing: spacing,
        totalSpacing: totalSpacing
    )
   }

   만약 하위뷰들에 변화가 생기면, SwiftUI 는 updateCache(_:subviews:) 메소드를 호출합니다. 이 메소드의 기본 구현부는 makeCache(subviews:) 를 호출하도록 되어있고, 이는 데이터를 재계산 하게 됩니다. 그런다음 sizeThatFits(proposal:subviews:cache:) 와 placeSubviews(in:proposal:subviews:cache:) 메소드에서 cache 파라미터를 사용해서 데이터를 가져옵니다.

   // placeSubviews(in:proposal:subviews:cache:)
   let maxSize = cache.maxSize
   let spacing = cache.spacing

Note 대부분의 간단한 레이아웃은 캐싱 사용에서 큰 효율을 얻진 못합니다. Instruments 를 사용해서 앱을 프로파일링 하면 캐싱하면 좋은 레이아웃이 뭔지 알아낼 수 있습니다.

참고

1. https://developer.apple.com/documentation/swiftui/declaring-a-custom-view#:~:text=Views%20that%20take%20multiple%20input%20child%20views%2C%20like%20the%20stack%20in%20the%20example%20above%2C%20typically%20do%20so%20using%20a%20closure%20marked%20with%20the%20ViewBuilder%20attribute.

call-as-function 알아보기

객체의 메서드를 호출하지 않고 객체 자체를 함수로 사용하는 방법.

1. 서론

Pointfree.co 의 ComposableArchitecure 라이브러리에서 제공하는 Send 타입이 CallAsFunction 을 구현하고 있어 다음과 같이 쓸 수 있다고 안내되어 있습니다.¹

return .run { send in
    send(.started)
    defer { send(.finished) }
    for await event in self.events {
        send(.event(event))
    }
}

이 때 send는 함수처럼 쓰고 있지만 타입을 보면 함수 타입이 아닌 Send 타입의 객체입니다. 객체를 함수처럼 쓸 수 있는 이유는 Send가 call-as-function 을 구현하고 있기 때문입니다.

이 문서에서 call-as-function이 무엇인지 다뤄보겠습니다.

2. 알아보기

2.1. 사용 방법

다음 내용은 Swift.org 의 내용을 번역하였습니다.²

call-as-function 메서드 이름은 callAsFunction() 또는 callAsFunction( 로 시작하여 인자가 있는 형태를 사용합니다.

예를 들어, callAsFunction(_:_:) 과 callAsFunction(something:) 둘 다 call-as-function 메서드 이름으로 사용가능 합니다.

다음 함수 호출은 모두 동일합니다.

struct CallableStruct {
    var value: Int
    func callAsFunction(_ number: Int, scale: Int) {
        print(scale * (number + value))
    }
}

let callable = CallableStruct(value: 100)
callable(4, scale: 2)
callable.callAsFunction(4, scale: 2)
// 둘 다 208 를 출력합니다.

call-as-function 메서드는 다음 두 가지 사이에서 적절한 절충안을 만들어 균형을 유지시킵니다.

• 타입 시스템에 얼마나 많은 정보를 인코딩할 지
• 런타임 동안 얼마나 많은 동적 행동이 가능할 지

2.2. 왜 사용하는가?

객체를 함수처럼 호출할 수 있는 것은 상태를 가진 계산 프로그램, 파서 또는 컴퓨팅 객체를 표현하고자 할 때 유용함을 제공합니다. 이는 복잡한 수학 연산 및 머신 러닝에서 특히 흔하며 특정 객체가 일부 상태를 유지하고 하나의 메서드만을 구현하는 경우가 있습니다.

donnywals.com 에서 다음과 같은 예시를 통해 설명하고 있습니다. 실제 파이썬에서 자주 볼 수 있는 패턴 중 하나인 함수에 렌더링 객체를 전달하는 패턴을 Swift 언어로 보여주며 설명하고 있습니다.

protocol Route {
    associatedtype Output
}

func registerHandler<R: Route>(_ route: R, _ handler: (R) -> R.Output) {
    return renderer(route)
}

registerHandler 는 Route 프로토콜을 준수하는 객체를 전달받고, 이를 handler 에서 인수로 전달합니다. 이 함수를 다음과 같이 호출할 수 있습니다.

registerHandler(homeRoute) { route in
    /* 여기서 아웃풋을 생성하기 위해 수많은 작업을 수행해야 함 */

    return output
}

간단한 renderer의 경우 이 방식은 문제가 없지만, 파이썬 패턴을 현재 스위프트로 보여주고 있음을 고려하여, 파이썬의 맥락에서, 이러한 코드는 웹서버에서 실행됩니다. route는 사용자가 요청한 웹페이지의 URL(또는 경로)와 동등합니다. registerHandler의 클로저는 사용자에 의해 연결된 라우트가 요청될 때마다 호출됩니다. 처리해야할 작업이 많은 경우 간단한 클로저만으로 충분치 않을 수 있습니다. route를 처리하는데 사용되는 객체에는 데이터베이스 연결, 캐싱, 인증 등등 여러 기능이 있어야 합니다. 이 모든 것을 클로저에 포함시키는 것은 좋은 아이디어가 아닙니다. 클로저에 포함시키는 것 대신 route를 처리하는 하나의 객체를 사용하는 것이 좋습니다. 이 때 call-as-function을 사용하는 것이 매우 유용합니다.

struct HomeHandler {
    let database: Database
    let authenticator: Authenticator

    // ...

    func callAsFunction<R: Route>(_ route: R) -> R.Output {
        /* 여기서 아웃풋을 생성하기 위해 수많은 작업을 수행해야 함 */

        return output
    }
}

let homeHander = HomeHandler(
    database: database, 
    authenticator: authenticator
)

registerHandler(for: homeRoute, homeHandler)

이렇게 객체를 클로저를 받는 함수에 그대로 전달할 수 있습니다. homeHandler.callAsFunction 과 같이 메서드를 직접 넘길 수도 있으나 call-as-function 을 사용하기 때문에 어떤 메서드를 호출해야하는지 알 필요가 없어 사용도 쉽고, 읽기도 쉽습니다.

3. 결론

서론에서 보았던 Pointfree.co 의 ComposableArchitecture 의 예시코드를 다시 살펴 보겠습니다.

return .run { send in
    send(.started)
    defer { send(.finished) }
    for await event in self.events {
        send(.event(event))
    }
}

이때 클로져가 전달하는 실행인자가 함수가 아니라 Send 라는 객체입니다. 하지만 Send 가 callAsFunction 을 구현하고 있기 때문에 아래와 같이 함수처럼 사용할 수 있습니다.

send(.started)

따라서, call-as-function 은 객체의 메서드를 호출하지 않고 객체 자체를 함수로 사용하는 방법을 제공합니다.

4. 참조

4.1 용어 정리

4.2 참고 문헌

1: https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/send

2: CallsAsFunction, swift.org

xcodebuild docbuild 명령어로 문서 빌드 배포하기

xcodebuild 커맨드라인 도구(Command Line Tool)의 docbuild 명령어로 .doccarchive 파일 추출 및 정적 웹 호스팅을 위한 형태로 변형하는 과정.

1. 배경 및 목적

docc-plugin 의 경우 빌드 대상(build destination)이 macOS 으로 고정되어 있고 다른 대상으로 변경할 수 없습니다. 빌드 대상을 변경하고자 하는 경우 xcodebuild 커맨드라인 도구(Command Line Tool)의 docbuild 명령어를 사용해야합니다.

이 문서에서 xcodebuild 커맨드라인 도구를 사용해서 빌드 대상을 iOS 로 변경하여 DocC 프레임워크 기반 개발문서를 아카이브하고 더 나아가 정적 웹호스팅을 위한 형태로 변형하는 과정을 다뤄보겠습니다.

2. 진행 방법과 결과 데이터

2.1. 문서 아카이브 파일 생성 (.doccarchive)

xcodebuild docbuild -scheme BoxOffice \
  -derivedDataPath /tmp/docbuild \
  -destination 'generic/platform=iOS'

docbuild 는 문서 아카이브 (.doccarchive) 파일을 생성하는 명령어¹ 입니다. docbuild의 옵션은 다음과 같습니다.

Tip

-destination 옵션 설정 시 generic/platform=iOS 에서 generic 을 제외시키면 모든 iOS 시뮬레이터로 빌드하기 때문에 긴 빌드 시간이 > 소요되었습니다. 따라서 특정 시뮬레이터들을 돌려야 하는 경우가 아니면 generic 을 포함시키는 것이 좋습니다.

2.2. 정적 호스팅을 위한 형태로 변형 (/docs)

$(xcrun --find docc) process-archive \
  transform-for-static-hosting /tmp/docbuild/Build/Products/Debug-iphoneos/{타겟이름}.doccarchive \
  --hosting-base-path {레포지토리_이름} \
  --output-path {저장위치}

xcrun --find docc 는 docc 도구를 실행시키는 명령어 입니다. process-archive 는 아카이브를 처리하는 docc 명령어 입니다.

2.3. 빌드 결과물 처리

/docs 경로에 웹 호스팅이 가능한 파일들이 위치한 것을 알 수 있습니다. 과정2.1 과 과정2.2 의 명령어들을 .sh 스크립트 파일로 저장해두면 GitHub Actions 로 배포³할 때 용이합니다.

3. 결론

xcodebuild 커맨드라인 도구에도 docc 에 대한 명령어들이 있어 문서를 빌드하고, 아카이브 파일을 정적 웹호스팅을 위한 형태로 변형할 수 있습니다.

docc-plugin 에서는 macOS로 고정되어 있는 빌드 대상을 변경할 수 없는 반면 xcodebuild 는 빌드 대상을 바꿀 수 있기 때문에 macOS 가 아닌 다른 플랫폼(예: iOS)만 지원하는 스위프트 패키지의 경우 xcodebuild 커맨드라인 도구를 사용하여 문서를 빌드할 수 있습니다.

4. 참고문헌

1: https://developer.apple.com/documentation/xcode/distributing-documentation-to-external-developers, Apple, Inc.

2: https://apple.github.io/swift-docc-plugin/documentation/swiftdoccplugin, Apple, Inc.

3: https://github.com/jaesung-0o0/package-docc-example

라이브러리 에러와 임베드

정적 라이브러리와 동적 라이브러리에 대해 알아보고 라이브러리 에러 분석하고 해결하기

1. 배경 및 목적

사이드 프로젝트 앱 심사 중 다음과 같은 크래시 로그 파일을 전달 받았습니다.

crashlog-3BD80720-2A0C-4403-BB56-6EFC6063243F.txt

"termination" : {"code":1,"flags":518,"namespace":"DYLD","indicator":"Library missing","details":["(terminated at launch; ignore backtrace)"],"reasons":["Library not loaded: @rpath\/KuringSDK.framework\/KuringSDK"

앱 크래시의 원인은 "termination" 항목에서 확인할 수 있고, 보면 DYLD, Library missing, Library not loaded 이러한 용어들이 나옵니다. 용어를 몰라도 대충 KuringSDK 라는 프레임워크가 로딩 되지 않아서 크래시가 났구나 하고 알 수는 있습니다.

이 문서에서는 동적라이브러리, 정적 라이브러리에 대한 중요한 내용들을 다뤄보면서 위의 크래시 로그가 정확히 무슨 의미인지, 그리고 어떻게 해결하는 지를 알 수 있습니다.

2. 알아보기

2.1. 앱 패키지

앱 타겟을 빌드하면 결과물로 다음과 같은 패키지 폴더가 생성됩니다.

여기서 실행파일은 실제 앱 구동에 사용됩니다.

2.2. 동적 라이브러리 그리고 정적 라이브러리

라이브러리의 코드가 앱의 소스 코드에 합쳐지는 것을 "링크(Link)" 라고 합니다. 링크 되는 방식에 따라 라이브러리는 정적 라이브러리(Static Library) 그리고 동적 라이브러리(Dynamic Library) 로 구분됩니다.

정적 라이브러리는 앱 타겟 빌드 시, 스태틱 링커(Static Linker)에 의해 실행파일에 라이브러리의 코드가 앱의 소스코드와 합쳐지게 됩니다.

동적 라이브러리는 앱 타겟 빌드 시, 실행파일에 라이브러리의 코드에 대한 참조만 포함되고 앱 구동 중에 라이브러리 코드가 필요한 시점이 오면 다이나믹 링커(Dynamic Linker, 또는 다이나믹 로더 Dynamic Loader)가 이 참조를 가지고 라이브러리를 로딩하게 됩니다.

2.3. DYLD

DYLD 는 Dynamic Loader 를 의미합니다. 다이나믹 링커(Dynamic Linker) 라고도 합니다. 보통 라이브러리 관련해서 dy 로 시작하는 약어는 일반적으로 Dynamic (동적) 을 의미하고 좀 더 구체적으로는 다이나믹 라이브러리에 대한 것을 의미합니다. 예를 들어, dylib 는 Dynamic Library 를 의미합니다.

동적 라이브러리의 경우, 앱 타겟 빌드 결과물의 실행파일에는 라이브러리에 대한 참조 가 들어있어서, 앱을 실행하면 이 참조를 가지고 필요한 라이브러리의 코드를 로딩하게 됩니다. 이 로딩 과정을 진행하는 주체가 바로 DYLD 입니다.

2.4. 라이브러리와 임베드

임베드(Emded) 옵션은 라이브러리를 Frameworks 폴더에 포함시킬지 말지에 대한 여부를 나타내는 옵션입니다.

정적 라이브러리의 경우, 이미 필요한 라이브러리 코드를 앱 실행파일이 전부 갖고 있기 때문에 굳이 Frameworks 폴더에 라이브러리를 중복으로 들고 있을 필요가 없습니다. 따라서 임베드 옵션을 Do Not Embed 로 설정할 수 있습니다. 다만 번들의 경우 실행파일에 합쳐지는 것이 아니므로 정적 라이브러리가 번들과 같이 앱 구동 중 로딩이 필요한 요소를 갖고 있다면 Embed 로 설정해야 합니다.

동적 라이브러리의 경우, 앱 실행파일이 참조만 갖고 있기 때문에 이 참조를 가지고 다이나믹 로더가 라이브러리를 로딩할 수 있도록 Frameworks 폴더 안에 라이브러리가 있어야 합니다. 따라서 임베드 옵션을 Embed & Sign 혹은 Embed Without Signing 으로 설정해줘야 합니다.

3. 결론

서론에서 보았던 Library not loaded 에러는 문제가 되었던 라이브러리가 동적 라이브러리 였고 "Do Not Embed" 로 옵션이 설정되어 있었기 때문에 발생한 에러였습니다. 빌드 결과물의 실행파일에는 참조만 있고 앱 실행시 다이나믹 로더(DYLD) 가 이 참조를 가지고 라이브러리를 로드해야 하는데 임베드 옵션이 "Do Not Embed" 이었기 때문에, 로드할 라이브러리가 Frameworks 폴더에 없어서 크래시가 난 상황입니다. 그러므로 임베드 옵션을 "Embed~" 로 변경해주면 크래시 에러를 해결할 수 있습니다.

4. 참고문헌

Overview of Dynamic Libraries, developer.apple.com | Apple, Inc.

댓글로 깃헙 액션 돌리기

1. 배경 및 목적

참고: 결과물만 보고 싶은 경우 PR #42 링크를 확인하십시오

2년전에 (2021년) 사이드 프로젝트에서 깃헙 액션을 작업한 적이 있었습니다.

그때는 PR이 올라오면 base 브랜치가 develop 일 때 깃헙액션이 돌도록 했는데 문제는 커밋을 푸시할때마다 매번 테스트가 돌다보니 깃헙 액션 사용가능 시간을 불필요하게 많이 소모하는 문제가 있었습니다.

규모가 큰 앱도 아니었고 실제 깃헙 액션도 10-20분 정도 걸렸기 때문에, 매달 무료로 제공되는 2000분 (약 33시간)이면 마음껏 사용해도 되지 않나하고 생각할 수 있습니다. 하지만 운영체제 버전 마다 소모하는 사용시간의 크기가 다릅니다. 이 중 macOS 는 x10 만큼 소모합니다. 출처 링크

즉 테스트 한번에 100-200분을 소모하게 되고 최악의 경우 테스트 10번 돌리면 그 달의 사용가능한 깃헙액션 시간을 다 소진하게 됩니다. 실제로 전부 소진했다는 메일을 자주 받았었습다.

이번에 사이드 프로젝트 앱의 2.0 버전 작업을 하면서 깃헙 액션 작업도 새로 하게 되었고 매번 불필요하게 액션이 돌지 않고 필요할 때 돌릴 수 있도록 issue-comment 로 트리거 하는 방식을 생각했습니다.

커멘트로 깃헙 액션 작동시키는 스크립트 작성하는 방법은 cozzin 님이 작성한 블로그 포스트을 참고하였기 때문에 이 문서에서 스크립트 작성에 대한 부분은 가볍게 다루고 마주했던 문제를 자세하게 알아보도록 하겠습니다.

2. 진행 방법과 결과물

2.1. 스펙

구상한 스펙은 다음과 같습니다.

자동화 하려는 항목은 다음과 같았습니다.

• iOS 최신 버전에서 앱 타겟 빌드 성공 여부 (also 최소 지원버전)
• iOS 최신 버전에서 스위프트 패키지 기반 모듈들의 빌드 성공 여부 (also 최소 지원버전)
• iOS 최신 버전에서 앱 타겟 테스트 성공 여부 (also 최소 지원버전)

2.2. 액션 트리거 시점 설정

이슈에 댓글을 작성했거나, 댓글을 수정했을 때 깃헙 액션이 트리거 하려면 다음과 같이 작성합니다.

on:
  issue_comment:
    types: [created, edited]

2.3. 트리거 키워드

댓글에 특정 키워드가 포함되었을 때만 액션을 수행하도록 다음과 같이 작성합니다.

jobs:
  build:
    if: github.event.issue.pull_request &&
      contains(github.event.comment.body, '/깃헙') &&
      contains(github.event.comment.body, 'ios17 앱 빌드')

2.4. 빌드 응답 커멘트

댓글에 키워드가 포함되어있어서 액션을 시작하는 경우 다음과 같이 github-script 를 사용하여 액션을 실행한다고 댓글로 알려줄 수 있습니다.

# iOS17 빌드 응답 커멘트
- name: Add Build comment
  uses: actions/github-script@v5
  with:
    github-token: ${{secrets.GITHUB_TOKEN}}
    script: |
      github.rest.issues.createComment({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        body: 'iOS 17.0 iPhone 15 Pro 에서 앱타겟을 빌드합니다.'
      })

github-script 를 사용 시 github-token 을 넣어주면 이어서 작성한 script 를 수행할 수 있습니다. github-token 에는 ${{secrets.GITHUB_TOKEN}} 이라고 값을 넣어주면 됩니다. script 에는 github.reset.issues 의 createComment 명령어를 사용하여 body 에 댓글 내용을 작성해줄 수 있습니다.

2.5. 빌드 결과 커멘트

빌드에 성공했다면 2.4 와 동일한 방식으로 성공했다는 메세지를 댓글로 알려줄 수 있습니다.

빌드에 실패했거나, 액션 수행 중 실패가 발생한 경우 step 에 if 옵션에 failure() 를 넣어주면 실패한 경우에만 동작하는 step 을 만들 수 있습니다.

# 빌드 실패시 커멘트
- name: Notify failure
  uses: actions/github-script@v5
  with:
    ...
  if: failure()

2.6. 결과물

작업 결과물은 PR #42 에서 확인 가능합니다.

3. 마주했던 문제들

3.1. 액션이 트리거 되지 않는 현상

분명 스크립트는 잘 작성했는데 커멘트로 트리거가 되지 않는 현상이 있었고 원인은 다음과 같았습니다.

"Note: This event will only trigger a workflow run if the workflow file is on the default branch." 출처 | docs.github.com

issue-comment 트리거는 default branch 기반으로 돌아가기 때문에 아직 yaml 파일이 default branch 에 머지되지 않은 시점에서 issue-comment 트리거 시도를 해도 default branch 에는 트리거할 액션이 정의되어 있지 않아서 동작하지 않습니다.

이는 다음과 같은 방법으로 해결하였습니다.

테스트 할때는 PR 브랜치로 default branch를 (1)임시로 변경하고, 확인이 끝나면 팀원들에게 공유 후 default branch (2)복구

3.2. Xcode 버전 문제

스크립트에 테스트가 최신 Xcode 버전에서 돌아가도록 작성했는데, Xcode15 가 아닌, Xcode14.2 (심지어 14.3 도 아닌) 으로 돌아가는 문제가 있었습니다.

macos-latest 를 사용하는 경우 맥OS 에 Applications 폴더에는 Xcode_14.2.app 까지만 설치되어 있어서 발생한 문제였습니다.

이는 다음과 같은 방법으로 해결하였습니다.

Looks like you need to use macos-13, not macos-latest. link

build:
-  runs-on: macOS-latest
+  runs-on: macos-15
    steps:
      - name: Setup Xcode version
        uses: maxim-lobanov/setup-xcode@v1
        with:
          xcode-version: '15.0'

3.3. iOS 시뮬레이터 버전 문제

#Preview 매크로 빌드를 위해 Xcode15 환경이 필요했으며 iOS 17 외에도 iOS16 버전의 시뮬레이터에서도 앱타겟을 빌드하고 싶었습니다. 하지만 iOS 16 버전으로 앱타겟을 빌드 시도하면 다음과 같은 에러와 함께 액션일 실패하였습니다. "Tests must be run on a concrete device"

그래서 액션이 수행될 때 사용가능한 시뮬레이터 리스트(xcrun xctrace list devices)를 확인해보았고 iOS17 버전의 시뮬레이터만 목록에 있음을 확인하였습니다. 액션 수행 중 하위 버전의 시뮬레이터를 설치하는 방법이 있으나 소모시간 너무 길고, 특히 macOS 는 깃헙 액션 사용시간이 10배로 적용되기 때문에 최선의 방법은 아니라고 생각하여 아직 해결하지 못한 문제로 남아있습니다.

4. 참고

• docs.github.com/en/billing/managing-billing-for-github-actions
• 깃헙 액션 yml 파일 결과물
• medium.com/@hongseongho/github-action으로-comment-bot-만들기
• docs.github.com
• github.com/actions/runner-images/issues