maxcode

Link Binary with Libraries (Crash - Library not loaded)

jaelee — Thu, 20 Nov 2025 23:30:35 +0900

안녕하세요! 오늘은 LInk Binary with LIbraries와 관련된 트러블 슈팅에 대해서 작성해보려고 해요.

문제 상황

iOS 최소지원 버전이 16이지만 17부터 사용가능한 SwiftData를 이용하여 디버깅 도구를 개발했어요.

근데, iOS 16 기기에서 앱이 실행되지 않았어요.

빌드는 성공했으나 앱을 키려고 한 순간 아래와 같은 크래시가 났습니다.

dyld[5910]: Library not loaded: /System/Library/Frameworks/SwiftData.framework/SwiftData

발생 원인

Xcode 앱 Target의 Build Phases에 가보면 Target Dependencies와 Link Binary with Libraries를 확인할 수 있어요.

Target Dependencies

현재 Target에 필요한 다른 Target들이 있다면 이곳에 추가해주어야 합니다. 현재 Target을 빌드되기 전에 반드시 빌드되어야 하는 다른 타깃을 정의하는 곳이예요. 예를 들어, 다른 프레임워크를 Target으로 추가해두고 현재 Target이 해당 프레임워크를 사용하고 있다면 Target Dependencies에 추가해주어야 해요.

Target Depedencies에 추가된 Target들은 항상 앱 Target을 빌드하기 전에 먼저 빌드되기 때문에 항상 최신 상태를 유지할 수 있어요.

Link Binary with Libraries

현재 Target에서 사용되는 외부 라이브러리나 프레임워크들을 연결해주는 단계입니다. 이곳에 들어갈 수 있는 라이브러리는 아래와 같아요.

외부 라이브러리: SnapKit, Alamofire 등
Apple 기본 프레임워크: Collection, SwiftData, CoreLocation 등
직접 만든 프레임워크: Custom SPM

Xcode를 빌드할 때, 현재 Target에서 필요한 코드 심볼들은 Link Binary with Libraries에 정의된 라이브러리들을 사용해야한다고 정의해놓는 곳입니다.

컴파일러가 생성한 오브젝트 파일들을 하나의 실행파일로 결합하고 외부 심볼들을 참조하는 등의 역할을 담당하는 링커가 코드에서 사용된 심볼들이 링크된 라이브러리의 코드나 리소스를 사용해야한다는 것을 확인하고 연결을 설정하는 작업을 해줍니다. 그래야 앱이 실행될 때 어느 위치에서 코드를 찾아보아야하는 지 알 수 있어요.

Status

런타임에 해당 프레임워크가 없을 때 앱이 어떻게 동작해야할 지에 대한 Flag 값입니다.

Required: 프레임워크가 없다면 앱을 실행하지 않는다. launch 단계에서 바로 크래시가 납니다.
Optional: 프레임워크가 없더라도 앱을 실행한다. (weak linking) 대신 #available과 같은 전처리문을 통해서 코드 처리가 필요해요.

지금 16.0 OS인 기기에서 앱을 실행하면 SwiftData 프레임워크가 없는데 디폴트 설정이 Required이기 때문에 launch단계에서 앱이 죽고 있었어요.

해결방법

SwiftData.framework를 추가하고 Status를 Optional로 변경합니다.

참고

https://stackoverflow.com/questions/78803238/app-with-min-deployment-ios16-crashes-because-of-swiftdata

App with min. deployment iOS16 crashes because of SwiftData

I have an app on the AppStore that targets iOS 16 and later. I would like to introduce support for SwiftData for devices running iOS 17 and later, while maintaining support for iOS 16. Example code:

stackoverflow.com

https://www.mikegopsill.com/posts/target-dependencies-link-binary/

Target Dependencies vs Link Binary with Libraries

When developing iOS applications with Xcode, it’s essential to understand the difference between “Target Dependencies” and “Link Binary with Libraries.” These two options found in the Build Phases settings of a target play vital roles in defining

www.mikegopsill.com

@dynamicMemberLookup

jaelee — Wed, 19 Nov 2025 11:30:03 +0900

dynamicMemberLookup 말그대로 런타임에 멤버를 바라볼 수 있다는 뜻이예요.

@dynamicMemberLookup을 선언하면,

컴파일 타임에 정의하지 않은 프로퍼티라도 subscript(dynamicMember:) 메서드를 통해 런타임에 처리할 수 있도록 도와줘요.
"dot"을 통해 해당 타입의 프로퍼티에 접근할 수 있어요.

@dynamicMemberLookup을 선언하면 subscript(dynamicMember:) 메서드는 필수적으로 구현해주어야 합니다!

@dynamicMemberLookup
struct User {
    var name: String
    var like: String

    subscript(dynamicMember key: String) -> String {
        switch key {
        case "hobby":
            return like
        default:
            return "none"
        }
    }
}

let member = User(name: "Jaelee", like: "보드")

// 사용 방법 1: dot (dynamicMemberLookup 덕분에 가능)
member.hobby

// 사용 방법 2: subscript
member[dynamicMember: "hobby"]

SwiftUI에서 때 놓치기 쉬운 포인트 정리

jaelee — Tue, 18 Nov 2025 00:27:47 +0900

요새 SwiftUI로 화면을 빠르게 만드는데 재미가 들렸어요. 그치만 아무 생각없이 스유로 만들다보면 놓치기 쉬운 포인트들이 있어요. 이 포인트들을 놓치면 성능이 우려돼요. 체감상 느낄 수 없어도 스유에서 중요한 포인트들이라 한번 정리해봅니다.

StateObject 와 ObservedObject 차이 이해하기

StateObject

뷰가 객체의 소유일 경우에 선언합니다. 이 객체의 생명주기를 담당하는 뷰인 경우 사용합니다.

뷰가 생성될 때 객체를 힙 할당하고 id/token을 부여합니다. 뷰가 리렌더링될 때 해당 id/token을 기반으로 기존 인스턴스를 재사용합니다.

SwiftUI는 StateObject 객체를 별도 힙에 객체를 저장하고 identity를 유지하여 단 한번만 생성됩니다.

ObservedObject

뷰가 객체의 소유가 아니고 관찰만 할 경우에 선언합니다. 하나의 객체를 여러 뷰에서 공유하고 싶을 때 사용합니다.

ObservedObject로 선언하게 되면 뷰가 렌더링 될 때마다 힙할당을 하게 됩니다.

@Observable 매크로가 나온 이후 위 선언들은 모두 의미가 없어졌어요.
@Observable로 선언된 인스턴스는 SwiftUI가 자동으로 변화를 감지하고 @State로 선언하면 생명주기를 관리해줘요.

View body diffing 알고리즘 이해하기

SwiftUI 렌더링 기본 매커니즘

SwiftUI는 상태가 변경될 때마다 뷰트리를 새로 생성하여 이전 뷰트리와 비교하여 뷰를 리렌더링합니다.

1. @State, @StateObject 등 상태 변경

2. 영향 받는 뷰의 body가 호출되며 뷰트리 구성

3. 이전 뷰트리와 diffing 알고리즘 실행

4. 변경된 부분 UI 업데이트

SwiftUI에서 성능이 좋다는 것은 위 과정이 막힘없이 이루어진다는 것을 의미해요.
만약 하나의 과정에서 막힌다면 뷰 렌더링이 늦어지고 버벅이게 될 거예요.
View를 최대한 가볍게 만드는 것이 좋습니다!
만약 무거운 View가 있다면, placeholderView를 만들어두는 것이 좋아요.

diffing 알고리즘

View가 들고 있는 property들을 비교합니다.

property가

Equatable 하다면,

== 로직을 통해 비교

Value Type이라면,

Value 타입 내부를 전부 비교

Reference Type이라면,

동일한 인스턴스인지 비교

Closure라면,

무조건 다른 뷰임

뷰가 들고 있는 프로퍼티가 변하면 그 뷰는 diffing 알고리즘을 실행하고 이는 뷰 업데이트 로직을 탑니다.

struct Test1View: View {
    @State var count: Int = 0

    var body: some View {
        VStack(spacing: 10) {
            TextView(count: count)

            Button1View(count: $count)
            Button2View(count: $count)
        }
        .padding()
    }
}

struct TextView: View {
    let count: Int
    var body: some View {
        Text("색깔")
            .background(count % 2 == 0 ? Color.red : Color.green)
    }
}

struct Button1View: View {
    @Binding var count: Int
    var body: some View {
        Button {
            count += 2
        } label: {
            Text("짝수")
        }
    }
}

위 예제 코드에서 Button1을 계속 클릭하면, TextView는 계속 업데이트돼요.

이를 개선하려면 아래처럼 isRed 프로퍼티로 변경하면 이 프로퍼티가 변경될 때만 뷰가 업데이트 됩니다.

struct TextView: View {
    let isRed: Bool
    var body: some View {
        Text("색깔")
            .background(isRed ? Color.red : Color.green)
    }
}

아래는 Button1을 6번 눌렀을 때 인스트루먼트예요. isRed는 계속 true이기 때문에 TextView는 생성될 때 1번 body가 호출되었습니다. Button2도 count 프로퍼티를 들고 있기 때문에 뷰가 업데이트된 것을 볼 수 있어요.

UIViewRepresentable 조심하기

UIView를 SwiftUI에서 쓰기 위해선 아래와 같이 위 프로토콜을 채택해주어야 합니다.

struct AttributedText: UIViewRepresentable {
    private let string: String
    private let color: UIColor

    init(string: String, color: UIColor) {
        self.string = string
        self.color = color
    }

    func makeUIView(context: Context) -> UILabel {
        let label = UILabel()
        label.text = string
        label.textColor = color
        return label
    }

    func updateUIView(_ uiView: UILabel, context: Context) {
        uiView.textColor = color
    }
}

하지만, 위 프로토콜을 채택한 스유뷰는 업데이트가 어느 시점에 되는지 명확히 알기 어려워요.

struct Test2View: View {
    @State var selectedName: [String] = []
    private let items: [Item] = [
        .init(name: "A"),
        .init(name: "B"),
        .init(name: "C"),
        .init(name: "D"),
        .init(name: "E"),
        .init(name: "F")
    ]

    struct Item: Hashable {
        let id = UUID()
        let name: String
    }
    var body: some View {
        ScrollView {
            VStack {
                ForEach(items, id: \.id) { item in
                    Button {
                        // 선택한 아이템 추가/제거 로직 구현 
                    } label: {
                        TextView(
                            name: item.name,
                            isSelected: isSelected(item: item)
                        )
                    }
                }
            }
            .padding(.top, 16)
            .padding(.horizontal, 16)
        }
    }

    private func isSelected(item: Item) -> Bool {
        selectedName.contains(item.name)
    }
}

private struct TextView: View {
    let name: String
    let isSelected: Bool

    var body: some View {
        AttributedText(
            string: name,
            color: isSelected ? .blue : .red
        )
    }
}

위 Test2View를 Instrument로 돌리고 버튼을 2번 클릭해서 디버깅해보면 아래와 같이 AttributedText가 34번 업데이트 된 것을 볼 수 있어요. Time Profiler로 계속 디버깅해보면 UILabel 내부 attributedString을 변경하는 코드들이 계속 실행되는 것으로 보이는데 이 곳은 개발자들이 건들일 수가 없는 부분으로 보입니다.

그래서 최대한 UIViewRepresentable은 사용하지 않는 것이 좋아 보여요!

StoreKit 2 기반 인앱결제 / 구독 정리하기

jaelee — Fri, 14 Nov 2025 17:44:59 +0900

StoreKit 2를 이용해서 구독을 구현하기 위해 알아야하는 것들을 정리해보려고 합니다.

StoreKit을 사용하면 앱에서 제공하는 구독 서비스와 상품들을 간편하고 안전하게 구입할 수 있다고 해요.

원래 사용자가 결제를 하기 위해서 필요한 이것저것 인증들을 애플이 대신 해주기 떄문에 훨씬 쉽게 구현할 수 있어요.

https://developer.apple.com/kr/storekit/

StoreKit - Apple Developer

StoreKit을 사용하면 모든 Apple 플랫폼에서 사용자가 앱의 디지털 상품 또는 서비스를 구입할 수 있는 간편하고 안전한 방법을 제공할 수 있습니다.

developer.apple.com

사전 지식

인앱 결제로 구입할 수 있는 상품은 크게 2가지 타입으로 나눌 수 있어요.

앱 내 구입

생성: AppStoreConnect의 수익화 섹션의 인앱결제 메뉴에서 생성할 수 있어요.
종류:
nonConsumable: 영구 소유하는 상품 (ex. 광고 제거, 영구 프리미엄 업그레이드)
consumable: 구매 후 소비하면 다시 구매 가능한 상품 (ex. 게임 내 코인, 포인트)
환불
유저가 AppStore 또는 설정에서 환불 요청하고 Apple이 내부 기준에 따라 결제 금액을 환불해줘요.
만약 consuable상품으로 이미 사용한 상품인데 환불 요청을 했다면, 그에 따라 앱 설계가 필요해요.

생성: AppStoreConnect의 수익화 섹션의 구독 메뉴에서 생성할 수 있어요.
종류: autoRenewable(자동갱신) / nonRenewable(갱신 취소된 구독)
취소: 설정/앱스토어에서 유저가 직접 구독 해지

도메인 모델

Transaction

단일 스토어 구매 영수증 트랜잭션 ID에 대한 스냅샷입니다. 상품이 구독이라면 갱신될 때마다 발생해서 id는 새로 생성되지만, originalID는 처음 발생했던 트랜잭션의 ID를 가지고 있어서, 이미 처리했었던 영수증이라는 연속성을 알 수 있습니다.

아래는 주요 필드입니다.

- id(PK): 트랜잭션 ID
- originalID: 첫 구매가 일어난 트랜잭션 ID
- productID: 구매한 상품 ID 
- originalPurchaseDate: 첫 구매 날짜 
- purchaseDate: 구매 날짜 (트랜잭션 발생 날짜) 
- expirationDate: 만료 날짜
- revocationDate: 환불 날짜
- isUpgraded: 업그레이드 여부 (true라면 다른 트랜잭션이 활성화됩니다.)

VerficationResult

StoreKit에서 내려주는 트랜잭션 처리 결과입니다.

public enum VerificationResult<SignedType> {
    case unverified(SignedType, VerificationResult<SignedType>.VerificationError)
    case verified(SignedType)
}

내부적으로 Apple 서명 검증을 이미 수행하기 때문에 개발자는 .verfied 여부만 확인해도 기본적인 보안 검증은 끝나요.

만약, 더 높은 수준이 필요하면, VerficationResult안에 들어있는 jwsRepresentation을 이용해 직접 서명 검증(서버 측 검증)을 수행할 수 있다고 해요. (jwsRepresentation을 서버에 보내 Apple 서명 데이터를 직접 검증할 수 있어요)

Transaction.currentEntitlements

유저가 구매한 각 상품에 대한 최신 트랜잭션의 스트림입니다. consumable 상품과 환불된 상품에 대해서는 포함되지 않아요. 만약 consumable 상품에 대한 트랜잭션을 불러오려면 Transaction.all 또는 Transaction.unfinished를 활용해야 합니다.

주로유저가 구매한 상품들을 복구할 때 사용해요.

func refreshPurchasedProducts() async {
    for await verificationResult in Transaction.currentEntitlements {
        switch verificationResult {
        case .verified(let transaction):
            ...
        case .unverified(let unverifiedTransaction, let verificationError):
            ...
        }
    }
}

Transaction.updates

새로운 트랜잭션이 발생할 때 방출하는 스트림입니다. 앱이 사용중인 영수증을 실시간으로 관찰하고 있습니다.

설정이나 앱스토어, 다른 기기 등과 같이 앱 외부에서 구매 정보를 바꿀 때 들어올 때 활용할 수 있어요.

구매를 구현해보면, updates 스트림을 구현해달라고 보라색 경고가 뜨니 구현이 필수인 듯 해요.

func observeTransactionUpdates() {
    transactionUpdatesTask = Task(priority: .background) { [weak self] in
        logger.info("트랜잭션 업데이트 관찰 시작")
        for await update in Transaction.updates {
            guard let self else { return }
            guard let transaction = unwrapVerificationResult(update) else { continue }

            // 영수증 처리
        }
    }
}

Product.SubscriptionInfo.Status.updates

구독 상태가 변할 때 방출하는 스트림입니다. 현재 구독 상태 변화를 실시간으로 관찰하고 있습니다.

구독 만료/취소/결제실패 등과 같이 영수증 변화 없이도 구독 상태가 변화할 수 있기 때문에 구독 상태 변화 감지용으로 구현해주어야 해요.

func observeStatusUpdates() {
    statusUpdateTask = Task { [weak self] in
        logger.debug("상태 업데이트 관찰 시작")
        for await status in SubscriptionStatus.updates {
            guard let self,
                  let transaction = await unwrapVerificationResult(status.transaction),
                  let groupIDRawValue = transaction.subscriptionGroupID,
                  let subscriptionGroupID = SubscriptionGroupID(rawValue: groupIDRawValue)
            else {
                continue
            }
            // 구독 상태 변화 처리 
        }
    }
}

유저 플로우

앱에서 모든 인앱결제에 대한 처리하는 플로우입니다.

(서버에서 구독 상태를 관리해야 한다면 App Store Server API를 이용해야 해서 플로우가 달라져요.)

구매하기

func purchaseProduct(_ pid: String) async {
    do {
        guard let storeProduct = try await Product.products(for: [pid]).first else { return }
        let purchaseResult = try await storeProduct.purchase()

        switch purchaseResult {
        case let .success(transaction):
            // 영수증 처리 
        case .userCancelled:
            logger.info("구매 요청이 취소되었습니다.")
        case .pending:
            logger.info("구매 요청이 대기중입니다.")
        @unknown default:
            break
        }
    } catch {
        logger.info("구매 오류")
    }
}

success 콜백으로 영수증 처리를 할 수 있지만, 부모의 허락을 받아야하는 경우 바로 콜백으로 오지 않고 pending으로 떨어집니다.

그래서 updates도 꼭 구현이 필요합니다. (보라색 경고가 떠요)

func observeTransactionUpdates() {
    transactionUpdatesTask = Task(priority: .background) { [weak self] in
        logger.info("트랜잭션 업데이트 관찰 시작")
        for await update in Transaction.updates {
            guard let self else { return }
            guard let transaction = unwrapVerificationResult(update) else { continue }

            // 영수증 처리
        }
    }
}

복원하기

func restorePurchases() async throws {
    do {
        try await AppStore.sync()
        for await entitlement in Transaction.currentEntitlements {
            guard let transaction = unwrapVerificationResult(entitlement) else { continue }
            // 복원 성공 처리
            await processedTransaction.finish()
        }
    } catch {
        // 복원 실패 처리
    }
}

영수증을 AppStore에서 기기로 불러오면, 영수증에 변화가 있다면 Transaction.updates로 들어오는데 없다면 알 수 없습니다.

그래서 Transaction.currentEntitlements에서 가져와야 합니다.

구독 갱신 / 환불 / 취소

private func processSubscriptionTransaction(_ transaction: Transaction) async {
    let productType = transaction.productType

    guard productType == .autoRenewable || transaction.productType == .nonRenewable
    else {
        return nil
    }

    if let _ = transaction.revocationDate {
        // 상태 - 환불
    } else if let expirationDate = transaction.expirationDate, expirationDate < Date() {
        // 상태 - 만료
    } else if transaction.isUpgraded {
        // 상태 - Upgraded
        // 다른 활성화된 트랜잭션이 존재합니다.
    } else {
        // 상태 - 구독 / 갱신 / 변경
    }

    await transaction.finish()
}

구독 갱신인 경우, 영수증이 변하기 때문에 Transaction.updates 스트림으로 새로운 Transaction이 들어옵니다.

구독 환불 또는 취소인 경우, 실시간으로 반영이 필요하지 않다면 앱을 실행할 때마다 영수증을 검사해서 위와 같은 로직으로 처리해줍니다. 실시간으로 반영이 필요하다면 Transaction.all / Transaciton.unfinished 스트림을 구독해서 별도 처리가 필요합니다.

상품 환불

private func processNonConsumableTransaction(_ transaction: Transaction) async {
    guard transaction.productType == .nonConsumable else {
        return
    }

    if transaction.revocationDate == nil, transaction.revocationReason == nil {
        ownedNonConsumables.insert(transaction.productID)
    } else {
        ownedNonConsumables.remove(transaction.productID)
    }

    await transaction.finish()
}

인 앱 결제 플로우가 StoreKit 1 보다 훨씬 간단해졌어요. StoreKit 내부에서 영수증 검증도 모두 처리되고 앱 외부에서 처리한 구독/환불/취소에 대한 변경사항들을 더 쉽게 처리가 가능해졌어요. 또 콜백으로 async/await을 활용할 수 있어 코드도 더 swift스럽게 작성할 수 있을 것 같네요!

참고

https://developer.apple.com/documentation/storekit/transaction/currententitlements

currentEntitlements | Apple Developer Documentation

A sequence of the latest transactions that entitle a customer to In-App Purchases and subscriptions.

developer.apple.com

https://developer.apple.com/documentation/storekit/verificationresult

VerificationResult | Apple Developer Documentation

A type that describes the result of a StoreKit verification.

developer.apple.com

https://developer.apple.com/documentation/storekit/transaction/updates

updates | Apple Developer Documentation

The asynchronous sequence that emits a transaction when the system creates or updates transactions that occur outside the app or on other devices.

developer.apple.com

가계부 앱 제작기

jaelee — Wed, 19 Feb 2025 23:20:55 +0900

프로젝트의 시작 (Project. Strict Money Checking)

호땡이와 함께 분당선 도곡역 테라로사 카페에서 만난 2024년 9월. 이 글을 작성하는 2025년 2월이 된 지금, 그날 어떤 이야기를 나누었는지는 가물가물하다. 하지만 확실한 건, 우리는 소비 습관에 대해 이야기하다가 자연스럽게 ‘가계부 앱을 만들어보자’는 얘기로 흘러갔다.

우리는 Swift 6의 Strict Concurrency에 대해 이야기하고 있었다. Strict Concurrency는 컴파일 타임에 데이터 레이스를 방지해 코드의 안정성을 보장하는 새로운 패러다임이다. 그렇다면, Strict Concurrency가 코드의 안정성을 보장하듯 우리의 소비 습관도 체계적으로 관리할 수 있지 않을까? ㅋㅋㅎ 그렇게 우리의 프로젝트가 시작되었다.

![[스크린샷 2025-02-14 오후 9.29.14.png | 300]]

개발밖에 모르는 우리는 GitHub을 파고 프로젝트 설정을 하자고 했던 기억이 난다. ㅋㅋ

자동 등록, 정말 편할까?

“요즘 누가 직접 가계부를 써? 토스나 뱅크샐러드에서 카드 내역이 자동 등록되는데!”
대부분의 핀테크 가계부 앱에서 자동 등록 기능을 제공한다. 하지만 우리는 오히려 ‘자동 등록이 불편하다’는 점에서 출발했다.

가계부를 쓰는 이유는 소비를 줄이기 위해서다. 그런데 카드 내역이 자동으로 입력되면 소비를 직접 인지하는 과정이 사라진다. 결국 “이번 달에 얼마나 썼지?” 하고 돌아보는 순간이 사라지고, 돈이 어디로 빠져나갔는지 흐릿해진다. 자동 등록이 오히려 소비 습관을 통제하는 데 방해가 되는 셈이다.

그렇다고 기존 가계부 앱이 편리한 것도 아니었다. 여러 소비 내역을 한 번에 등록할 수 없고, 같은 금액을 같은 장소에서 소비해도 매번 일일이 입력해야 했다. 게다가 기능이 너무 많아 오히려 복잡했다. “필요한 기능만 담아, 사용자가 직접 소비를 인지할 수 있는 가계부를 만들어보자.” 이런 고민 끝에 Strict Money Checking 프로젝트가 시작되었다.

개발 과정에서의 고민

차별화된 핵심 기능을 제공하려면 기본 기능이 탄탄해야 했다. 그러나 SwiftUI로 한정된 시간 내에 가계부의 필수 기능을 구현하는 것은 쉽지 않았다. (계산을 틀리는 가계부 앱은 만들 수 없으니까 .. )

기본 달력

가계부의 핵심 기능 중 하나인 달력은 주/월 전환과 좌우 무한 스와이프를 지원해야 했다. 주/월 전환은 비교적 단순했다. SwiftUI는 상태 기반 렌더링을 제공하므로, 표시할 데이터를 주 또는 월 단위로 변경하는 것만으로 자연스럽게 전환이 이루어졌다. 하지만 좌우 무한 스와이프 구현에서는 많은 시행착오를 겪었다.

초기 설계는 3개의 뷰를 배치하고 contentOffset을 조정하는 방식이었다. 예를 들어, 3월에서 2월로 스와이프하면 뷰의 위치를 초기화하고 데이터를 갱신해 자연스럽게 이어지는 것처럼 보이게 했다. 하지만 SwiftUI의 onScrollPhaseChange만으로는 스크롤 타이밍을 완벽하게 제어할 수 없어 빠른 스와이프 시 문제가 발생했다. 결국 UIPageViewController 기반 설계로 방향을 전환했다. UIViewControllerRepresentable을 활용해 SwiftUI에서 사용할 수 있도록 감싸고, 좌우 페이지를 동적으로 생성해 무한 스크롤을 구현했다. 최종적으로 안정적인 동작을 확보했지만, 첫 번째 접근법을 최적화하는 데 너무 많은 시간을 쏟은 점은 아쉬움으로 남았다.

[!warning] contentOffset 초기화 타이밍을 맞추기 위해 onScrollPhaseChange 뷰모디파이어에서 oldPhase == .decelerating && newPhase == .idle 시점을 활용했으나, 빠르게 스와이프할 경우 정상적으로 감지되지 않는 문제가 있었다.

로컬리제이션

한국뿐만 아니라 해외 가계부 시장도 궁금했다. 그래서 처음부터 영어와 일본어 로컬라이제이션을 함께 진행했다.

문자

Xcode 15부터는 String Catalog를 통해 로컬라이제이션을 쉽게 적용할 수 있다. 우리는 한국어를 key 값으로 사용하고, 번역은 ChatGPT를 활용했다. 문자열 로컬라이제이션 자체는 큰 고민 없이 진행했지만, 결국 수작업이 많았다. (노가다였음 )

날짜

날짜 형식은 언어에 따라 다르게 표시된다. 예: 2024년 12월 24일 (금) → December 24, 2024 (Fri)
처음에는 DateFormatter의 locale을 현재 국가에 맞추고, setLocalizedDateFormatFromTemplate을 활용하면 해결될 것이라 생각했다. 하지만 국가별로 세부적인 분기가 필요해 복잡해졌다. 이를 해결하기 위해 String Catalog에 “현재 날짜” key를 추가하고, 각 언어별 형식을 미리 설정한 후, dateFormat으로 적용했다.

년/월/일 설정

// String Catalog 설정 
// 한국: yyyy년 M월 d일 (E)
// 영어: MMM d, yyyy (E)
// 일본어: yyyy年 M月 d日 (E)

let formatter = DateFormatter()
formatter.locale = Locale(identifier: Locale.preferredLanguages.first!)
formatter.dateFormat = String(smcKey: "현재날짜", table: .recordSpending)
return formatter

요일 설정

let formatter = DateFormatter()
formatter.locale = Locale(identifier: Locale.preferredLanguages.first!)
formatter.setLocalizedDateFormatFromTemplate("E")
return formatter

금액 단위

금액 로컬라이제이션은 정책부터 확립해야 했다. 우리는 앱스토어 국가 기준으로 금액 단위를 결정하기로 했다.

한국 앱스토어에서 다운로드 → 기본 통화는 원(₩)
일본 앱스토어에서 다운로드 → 기본 통화는 엔(¥)
미국 앱스토어에서 다운로드 → 기본 통화는 달러($)
이후 언어 변경 시에도 금액 단위는 유지

이렇게 정한 이유는 환율 반영 문제 때문이다. 앱 내에서 실시간 환율을 적용하는 것은 가계부의 핵심 기능과 거리가 멀고, 추가적인 유지보수 부담도 발생하기 때문이다. 따라서 금액 단위는 사용자의 앱스토어 국가 기준으로 고정하고, 이를 로컬에 저장하도록 구현했다.

추가적으로, 달러($)는 소수점 두 자리까지 표기해야 한다는 점을 늦게 깨달았다. 이를 반영하기 위해 금액 단위를 Int에서 Double로 변경하고, 영어권 사용자를 위해 금액 입력 키보드에서 소수점 입력을 지원하도록 UI도 수정했다. (근데, 영어를 지원하는 다른 가계부 앱들은 왜 대부분 소수점 입력을 제공하지 않을까.. )

돌아보며

앱을 배포한 지 일주일이 지났고, 현재까지 약 30명이 다운로드했으며 일일 평균 9명이 사용 중이다. 별다른 마케팅 없이 이 정도의 유입이 있었다는 점에서, 실제 사용자들에게 가치 있는 앱을 만들었다는 점이 의미가 있다고 생각한다. 아직은 기본적인 기능만 제공하고 있지만, 앞으로 지속적인 개선을 통해 완성도를 높여갈 계획이다. 특히, AB 테스트를 돌려보며 다양한 시도를 해보고 싶다. 직접 원하는 방향으로 기능을 실험하고 최적화하는 과정도 하나의 재미있는 도전이 될 것 같다.

이번 프로젝트는 1.0 버전 배포까지 비교적 순조롭게 진행되었지만, 개인적으로 바쁜 시기가 있어 약 1~2주간 개발을 진행하지 못한 적이 있었다. 다행히도, 함께하는 동료들의 열정적인 모습에 다시 동기부여를 얻어 집중할 수 있었다. 이번 경험을 통해, 주변의 좋은 동료들이 얼마나 중요한지 다시 한번 깨달았다. 앞으로도 함께 성장하며 더 나은 서비스를 만들어가고 싶다! 잘 부탁해요

그리고 SwiftUI는 코드 단 몇 줄로 멋진 애니메이션과 UI를 구현할 수 있는 강력한 도구다. 잘 활용해서 아름답고 직관적인 앱을 만들어보자!!

@Published protocol에 정의하기

jaelee — Sat, 5 Nov 2022 00:59:57 +0900

문제 상황

Combine으로 작성한 코드를 테스트하는 중인데 @Published 프로퍼티 래퍼가 말썽입니다.

ViewModel에 @Published 프로퍼티 래퍼 타입을 정의하고 ViewController에서 이 타입을 바인딩하여 ViewModel에 변화가 일어나면 ViewController가 감지할 수 있게 하기 위해서 사용했습니다.

위 상황을 코드로 간략하게 정리해봤습니다.

아래 코드는 책 목록을 보여주는 화면의 로직을 담당하는 ViewModel과 이를 바인딩하고 있는 ViewController입니다. bookList에 변화가 일어난다면 bookList publisher는 BookListViewController에 UI를 업데이트하라고 전달합니다.

final class BookListViewModel: BaseViewModel {

    @Published var bookList: [Book]

    init(bookList: [Book] = []) {
        self.bookList = bookList
    }
}

final class BookListViewController: BaseViewController {
    var viewModel: BookListViewModel!

    var cancellables: Set<AnyCancellable> = []

    func bind() {
        viewModel.$bookList
            .receive(on: DispatchQueue.main)
            .sink { [weak self] bookList in
                // UI 
                self.activityIndicator.stopAnimating()
            }
            .store(in: &cancellables)
    }
}

여기서 더 나아가서, 프로토콜 프로그래밍의 다형성을 위해서 viewModel의 비즈니스 로직들을 프로토콜로 정의하려고 했습니다. ViewController가 해당 프로토콜을 채택한 어떠한 ViewModel을 받을 수 있게 하기 위해서 입니다. 그래야 테스트 코드를 작성할 때 목 데이터를 쉽게 작성할 수 있기 때문입니다.

protocol BookListBusinessLogic {
    @Published var bookList: [Book]
}

final class BookListViewModel: BaseViewModel, BookListBusinessLogic {

    @Published var bookList: [Book]

    init(bookList: [Book] = []) {
        self.bookList = bookList
    }
}

final class BookListViewController: BaseViewController {

    let viewModel: BookListBusinessLogic

    init(viewModel: BookListBusinessLogic = BookListViewModel()) {
        self.viewModel = viewModel
        super.init(nibName: nil, bundle: nil)
    }
}

하지만 @Published 프로퍼티 래퍼 타입을 프로토콜에 정의했더니 해당 기능은 지원하지 않는다고 합니다.

컴파일 에러 : 너 선언하면 안된다.

해결책

ViewController에서 ViewModel의 @Published 타입에 바인딩하기 위해 필요한 타입을 알아야 합니다.

viewModel.$bookList
    .receive(on: DispatchQueue.main)
    .sink { [weak self] bookList in
        guard let self = self else { return }
        // UI
        self.activityIndicator.stopAnimating()
    }
    .store(in: &cancellables)

위 코드에서 $bookList에 바인딩을 하고 있고 이 타입은 Publisher입니다. 다시 생각하면 ViewController가 실제로 필요한 것은 @Published 프로퍼티 래퍼 타입이 아니라 bookList의 Publisher 타입입니다. ([Book]의 Publisher)

프로토콜에는 Publisher 타입을 정의하고 실제 구현에서 bookList의 Publisher를 반환하는 코드를 작성합니다.

protocol BookListBusinessLogic {
    var bookListPublisher: Published<[Book]>.Publisher { get }
}

final class BookListViewModel: BaseViewModel, BookListBusinessLogic {

    @Published var bookList: [Book]

    var bookListPublisher: Published<[Book]>.Publisher { $bookList }

    init(bookList: [Book] = []) {
        self.bookList = bookList
    }
}

ViewController에선 ViewModel을 프로토콜 타입으로 정의하고 bookListPublisher에 바인딩시킵니다.

final class BookListViewController: BaseViewController {

    let viewModel: BookListBusinessLogic

    init(viewModel: BookListBusinessLogic = BookListViewModel()) {
        self.viewModel = viewModel
        super.init(nibName: nil, bundle: nil)
    }

    func bind() {
        viewModel.bookListPublisher
            .receive(on: DispatchQueue.main)
            .sink { [weak self] bookList in
                guard let self = self else { return }
                // UI
                self.activityIndicator.stopAnimating()
            }
            .store(in: &cancellables)
    }
}

이를 통해 ViewModel과 ViewController의 바인딩 상태는 유지한 채 다형성을 성공적으로 적용시킬 수 있습니다.

테스트 코드를 작성할 때 BookListBusinessLogic를 따르는 MockBookListViewModel를 만들어 BookListViewController에 주입할 수 있습니다.

하지만, 단점도 있습니다. @Published 프로퍼티 래퍼 타입은 양방향 바인딩을 위한 녀석입니다. SwiftUI와 다르게 UIKit은 UI 컴포넌트에 직접 바인딩이 어려운 명령형 프로그래밍으로 이루어져 있습니다. 즉, 유저가 버튼을 누르면 연결된 데이터를 직접 바꿔주어야 하고, 데이터가 바뀌면 직접 UI를 업데이트해야 합니다. 만약 ViewController가 @Published 녀석에 대해 모르도록 숨겨버린다면 양방향 바인딩의 장점은 사라지고 단방향 데이터 흐름을 가지게 됩니다.

Combine에서 테스트 코드를 작성하다 작성한 글입니다. 틀린 점이 있다면 지적 부탁드려요!

읽어주셔서 감사합니다.

ViewController 생명주기의 몰랐던 점

jaelee — Mon, 24 Oct 2022 21:12:21 +0900

ViewController 생명주기 호출 순서

iOS 개발을 한다면 ViewController 생명주기는 모두가 알고 있을 거예요.

viewDidLoad
-> viewWillAppear
-> viewDidAppear
-> viewWillDisappear
-> viewDidDisappear

다른 뷰컨트롤러로 넘어가는 상황에서 현재 뷰컨트롤러의 viewWillDisppear가 먼저 호출될까 전환되는 뷰컨트롤러의 viewWillAppear가 먼저 호출될까? 도 디버깅을 해본다면 바로 알 수 있습니다.

테스트를 위해서 뷰컨트롤러의 모든 생명주기에 print문을 찍어볼게요.

final class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()

        print("✨ FirstViewController viewDidLoad")
    }

    @IBAction func buttonDidTap(_ sender: Any) {
        
    }
    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

        print("✨ FirstViewController viewWillAppear")
    }

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)

        print("✨ FirstViewController viewDidAppear")
    }

    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)

        print("✨ FirstViewController viewWillDisappear")
    }

    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)

        print("✨ FirstViewController viewDidDisappear")
    }
}

final class SecondViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()

        title = "두번째"
        view.backgroundColor = .yellow
        print("  SecondViewController viewDidLoad  ")
    }

    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)

        print("  SecondViewController viewWillAppear  ")
    }

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)

        print("  SecondViewController viewDidAppear  ")
    }

    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)

        print("  SecondViewController viewWillDisappear  ")
    }

    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)

        print("  SecondViewController viewDidDisappear  ")
    }
}

그리고 FirstViewController에서 SecondViewController로 네비게이션 push를 해보겠습니다.

FirstViewController의 viewWillDisappear가 먼저 호출되고 다음 SecondViewController의 viewWillAppear가 호출되는 것을 볼 수 있어요. 이 호출 순서가 중요할까? 라고 생각할지 모르겠지만 두 화면에서 각각 애니메이션을 처리하고 있을 때 부드러운 애니메이션 효과를 주기 위해 필요합니다.

다음 뒤로가기 버튼을 눌러볼게요.

FirstViewController와 SecondViewController 각각을 생각해보면, 모두

viewDidLoad
-> viewWillAppear
-> viewDidAppear
-> viewWillDisappear
-> viewDidDisappear

위와 같은 호출순서를 따르고 있어요.

그런데, 이번에 만난 이슈에서는 이 호출 순서보다 한가지 재밌는 예외 케이스(?)를 발견했어요.

viewWillAppear 다음에 항상 viewWillDisappear 호출된다? ❎

viewWillAppear 메소드가 호출된 후에 viewWillDisappear 메소드가 항상 호출되지 않습니다.그리고, viewWillDisappear 메소드 다음에도 항상 viewDidDisappear 메소드가 호출되지 않습니다.

어떤 경우에 호출되지 않을까요?

네비게이션 push를 통한 화면전환에서 스와이프 제스처를 이용해서 뒤로 가려다 취소를 한 경우입니다.

그 상황을 녹화해봤어요. SecondViewController에서 뒤로가기 버튼을 눌러 뒤로가는 것이 아닌, 제스처를 통해서 뒤로가려고 했다가 중간에 취소한 케이스입니다.

뷰컨트롤러 생명주기 호출 순서는 아래와 같습니다.

먼저, FirstViewController를 보면, 호출 순서는 다음과 같습니다.

viewWillAppear
-> viewWillDisappear
-> viewDidDisappear

뷰컨트롤러가 보여질려고 했지만 취소되어 사라집니다. viewWillAppear가 호출된 이후에 viewDidAppear가 호출되지 않았습니다!

다음, SecondViewController를 보면 호출 순서는 아래와 같습니다.

viewWillDisapppear
-> viewWillAppear
-> viewDidAppear

뷰컨트롤러가 사라지려고 했지만 취소되어 다시 보입니다.

이 관계를 보았을 때,

viewWillAppear 뒤에 항상 viewDidAppear가 호출되지 않는다.

viewWillDisappear 뒤에 항상 viewDidDisappear가 호출되지 않는다.

라고 할 수 있습니다.

또 더 유추해본다면 뷰컨트롤러의 생명주기는 서로에게 영향을 미칩니다. appear가 호출되면 뷰가 사라지기 위해 disappear가 무조건 호출되어야하고, disappear가 호출된다면 해당 뷰가 다시 appear되기 위해선 appear가 호출되어야 합니다.

즉,

will과 did의 상관없이 appear과 disappear의 관계는 항상 붙어다니는 관계

라고 생각할 수 있습니다.

will과 did의 관계도 생각해보면,

will 다음에 항상 did는 올 수도 있고 안 올수도 있지만,

did 전에는 항상 will이 와야합니다.

이말은 아래의 사실과 같다고 할 수 있어요.

viewDidAppear 전에는 항상 viewWillAppear가 호출되어야한다.

viewDidDisappear 전에는 항상 viewWillDisappear가 호출되어야한다.

조금 더 실험해볼게요.

modal present 화면 전환에서는?

위의 상황에서 SecondViewController를 ThirdViewController라고 생각하고만 바꿔서 화면전환은 모달로 다시 테스트해보겠습니다!

modal present하는 상황은 presentation이 fullscreen인 상황과 아닌 상황 2가지로 나눠서 볼게요.

두가지 상황을 나누는 이유는 fullscreen이 아닌 경우 FirstViewController의 disappear 생명주기 메소드가 호출되지 않기 때문이에요. 뷰컨트롤러가 완전히 사라지지 않고 뒤에 스냅샷으로 남아있기 때문에 다른 케이스입니다.

먼저, fullscreen부터 실험을 해볼게요. 이 케이스는 일반적인 케이스입니다! 그니까 원래 생각했던 방식대로 뷰컨트롤러 생명주기가 실행돼요.

FirstViewController와 ThirdViewController 모두 생각했던 일반적으로 실행됩니다.

viewDidLoad
-> viewWillAppear
-> viewDidAppear
-> viewWillDisappear
-> viewDidDisappear

그럼 fullscreen이 아닌 모달인 경우에는 어떻게 될까요?

네. 이번에도 모달을 닫으려는 제스처를 취소하는 경우 viewWillAppear 이후 viewDidAppear 함수가 호출되지 않고, viewWillDisappear 이후 viewDidDisappear 함수가 호출되지 않습니다! 아래 영상같은 경우입니다.

빨간 네모 박스를 친 부분을 보신다면

viewWillDisappear
-> viewWillAppear
-> viewDidAppear

위 호출 순서를 볼 수 있습니다.

이 사실을 알고 난 후, viewDidAppear에 애니메이션 효과를 시작하고, viewWillDisappear에서 사라지는 애니메이션 효과를 주어 더 부드럽게 효과를 개선할 수 있었습니다.

개선 전, 뒤로가기 제스쳐에서 행성이 남아있음.

개선 후, 뒤로가기 제스쳐에 애니메이션 효과 적용

영상으로는 이 부드러움이 안담기네요.. 나중에 출시하면 링크 달아두겠습니다!

UIAdaptivePresentationControllerDelegate

제스쳐를 이용한 뒤로가기를 어떻게 감지할 수 있는지에 대해서도 알면 좋을 것 같아 더 찾아봤습니다.

A set of methods that, in conjunction with a presentation controller, determine how to respond to trait changes in your app.

해당 프로토콜을 UIPresentationController 객체에 채택한다면, 제스처로 뒤로가는 상황을 알 수 있습니다!

이전 뷰컨트롤러와 다음 뷰컨트롤러 두 곳 모두에서 유저가 제스처로 인해 뒤로갔는지에 대한 여부를 알 수 있을 것 같아요.

이 프로토콜도 나중에 알아봐야되겠어요.

읽어주셔서 감사합니다!

[CoreAnimation] Layer에 CoreAnimation을 무한으로 체이닝할 수 있을까?

jaelee — Sun, 23 Oct 2022 21:49:58 +0900

안녕하세요!

오늘은 코어애니메이션을 체이닝할 수 있는지에 대해 알아보려고 합니다. 그냥 체이닝이 아니라 무한 체이닝입니다!

(살짝 스포하자면 실패했습니다.. 스레드문제인 거 같은데...) 일단 구현에 들어가보도록 할게요.

구현할 애니메이션은 아래 밤하늘이에요!

질문이 나오게 된 배경

위 질문이 왜 나오게 되었는 지 설명해볼게요.

먼저, 저는 밤하늘에 별이 반짝이는 애니메이션을 주고 싶었어요. 그래서 먼저 피그마로 별을 디자인했습니다!

왜 굳이 디자인을 해주었냐면, 별이 찍힐 좌표값을 알아야했기 때문입니다!

별을 구성하고 있는 모서리를 알아야 UIBezierPath로 경로를 그려줄 수 있어요.

이미지로 추출해서 layer의 contents로 넣어줘도 가능하지만 정밀한 컨트롤이 불가능할 것 같아서 직접 만들어주었어요.

위에 보이는 모서리를 이용해서 path를 한땀한땀 만들어줬어요. 생각해보면 애니메이션은 개발의 영역이 아닌 것 같기도 합니당.. 이렇게 말한 이유는 나중에도 생각할 수 있지만... 일단 넘어가서!

UIBezierPath의 Extension함수로 만들었습니다!

extension UIBezierPath {
    static var starPath: UIBezierPath {
        let path = UIBezierPath()
        path.move(to: .init(x: 10, y: 0))
        path.addLine(to: .init(x: 7.35, y: 6.36))
        path.addLine(to: .init(x: 0.49, y: 6.91))
        path.addLine(to: .init(x: 5.72, y: 11.39))
        path.addLine(to: .init(x: 4.12, y: 18.09))
        path.addLine(to: .init(x: 10, y: 14.5))
        path.addLine(to: .init(x: 15.88, y: 18.09))
        path.addLine(to: .init(x: 14.28, y: 11.39))
        path.addLine(to: .init(x: 19.51, y: 6.91))
        path.addLine(to: .init(x: 12.65, y: 6.36))
        path.close()
        return path
    }
}

왜 저렇게 작성해야하는 지에 관해서 궁금하시다면 아래 링크를 보고 오시면 도움이 될 것 같습니당

https://github.com/wody-d/woody-iOS-tip/blob/main/TIL_2022:10:19_uibezierpath.md

GitHub - wody-d/woody-iOS-tip: iOS에 대한 소소한 팁들과 개발하다 마주친 버그 해결기, 그리고 오늘

iOS에 대한 소소한 팁들과 개발하다 마주친 버그 해결기, 그리고 오늘 배운 것들을 모아둔 레포 - GitHub - wody-d/woody-iOS-tip: iOS에 대한 소소한 팁들과 개발하다 마주친 버그 해결기, 그리고

github.com

그럼 이제 별이 빛날 배경을 만들기 위해서 샘플코드를 작성했습니다!

final class ViewController: UIViewController {

    lazy var starBackgroundView = StarBackgroundView(frame: view.bounds)
    
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .black

        view.addSubview(starBackgroundView)
    }
}

final class StarBackgroundView: UIView {

    override init(frame: CGRect) {
        super.init(frame: frame)
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

준비는 완료가 되었기에 별 레이어를 추가해볼게요.

final class StarBackgroundView: UIView {
    let starSize = CGSize(width: 10, height: 10)
    let starCount: Int = 100
    var starLayers = [CALayer]()
	
    override init(frame: CGRect) {
        super.init(frame: frame)

        for _ in 0..<starCount {
            let astar = CAShapeLayer()
            astar.frame = .init(origin: generateRandomPosition(), size: starSize)
            astar.path = UIBezierPath.starPath.cgPath
            astar.fillColor = UIColor.systemYellow.cgColor
            astar.shadowPath = UIBezierPath.starPath.cgPath
            astar.masksToBounds = false
            astar.shadowColor = UIColor.red.cgColor
            astar.shadowOpacity = 2
            astar.shadowOffset = .zero
            astar.shadowRadius = 4
            starLayers.append(astar)
        }
    }
    
	override func draw(_ rect: CGRect) {
	starLayers.forEach {
	    layer.addSublayer($0)
	}
    
    // ✅ 랜덤 위치 생성 함수
    func generateRandomPosition() -> CGPoint {
    	let height = frame.height
    	let width = frame.width
	
    	return CGPoint(
    	    x: CGFloat(arc4random()).truncatingRemainder(dividingBy: width),
    	    y: CGFloat(arc4random()).truncatingRemainder(dividingBy: height)
    	)
    }

}

별의 frame이 필요했기에 사이즈를 가로 세로가 10로 정했고, 별의 개수는 100개로 했습니다!

별 레이어의 속성들을 초기화를 해주었는데 여기서 중요한 점은 frame의 origin 속성입니다.! 랜덤한 값을 넣어줘야 매번 다른 위치에 별이 생성되니까요. path는 처음에 만들어준 별 경로를 할당했고 색깔, 그림자 등등을 정의했어요.

그리고 이제 만든 별 레이어를 배경 뷰가 초기화될 때 별 별의 개수만큼 추가해주었어요. 이때 for문을 이용해서 별을 추가해주었지만 처음에는 CAReplicatorLayer로 레이어를 복제하려고 했습니다. 하지만 CAReplicatorLayer는 원하는 위치에 랜덤배치가 되지 않았어요. instanceTransform 프로퍼티는 복제된 이전의 위치를 기반으로 다음 레이어가 복제되기 때문에, 원하는 구현이 아니었습니다.. 그래서 for문을 이용하기로 했어요.

빌드해보면 시뮬레이터에 이렇게 나온답니다.

여기까지가 준비였고, 이제 Core Animation을 주도록 할게요.

opacity, fillColor 2가지에 대한 애니메이션을 줬고 어떻게 줬는지에 대한 설명은 생략하도록 하겠습니다. 궁금하시다면, 다른 글을 읽고 오시면 좋을 것 같아요!

아래 코드를 draw 메소드에 추가해줍니다.

starLayers.forEach {
    let opacityAnimation = CABasicAnimation(keyPath: "opacity")
    let duration: CGFloat = 1
    opacityAnimation.fromValue = 0.2
    opacityAnimation.toValue = 0.8
    opacityAnimation.timeOffset = duration * drand48()
    opacityAnimation.duration = duration
    opacityAnimation.repeatCount = .infinity
    opacityAnimation.autoreverses = true
    opacityAnimation.delegate = self
    opacityAnimation.isRemovedOnCompletion = false

    $0.add(opacityAnimation, forKey: "opacity")

    let colorAnimation = CAKeyframeAnimation(keyPath: "fillColor")
    colorAnimation.duration = duration
    colorAnimation.values = [UIColor.clear.cgColor, UIColor.systemYellow.cgColor, UIColor.white.cgColor]
    colorAnimation.timeOffset = duration * drand48()
    colorAnimation.repeatCount = .infinity
    colorAnimation.autoreverses = true
    colorAnimation.delegate = self
    $0.add(colorAnimation, forKey: "color")
}

그럼 이제 별이 반짝이는 애니메이션을 볼 수 있어요.

그런데, 이제부터가 시작이에요.

지금 별들은 매번 같은 duration, 같은 timeOffset, 같은 speed를 가진 채 반짝이고 있습니다. 저는 duration, timeOffset과 speed를 매번 다르게 주고 싶었어요. 별은 매번 일정하게 반짝이는 것이 아니라 매번 랜덤하게 반짝이니까요. (어쩔때는 오랫동안 별의 빛을 유지하기도 하다가 또 어쩔때는 금방 깜박이고..)

Core Animation 효과를 무한으로 체이닝할 수 있을까?

가장 처음 든 생각은 현재 repeatCount 프로퍼티를 infinity로 줬는데 이것을 0으로 준 후, 애니메이션이 끝날 때마다 새로운 애니메이션을 추가하는 방법이었어요. 애니메이션이 끝나는 시점은 2가지 방법으로 알 수가 있었습니다.

먼저, delegate을 채택하고 func animationDidStop(_ anim: CAAnimation, finished flag: Bool) 메소드에서 알 수 있습니다. 따라서 해당 메소드에서 새로운 애니메이션을 추가하면 돼요. 그래서 아래와 같이 추가를 해줬습니다.

// opacity 애니메이션만 일단 적용 
// 전체코드 아님 주의! 

opacityAnimation.delegate = self
   
func animationDidStop(_ anim: CAAnimation, finished flag: Bool) {
	if let opacity = anim.value(forKey: "opacity") as? String, opacity == "opacityValue" {
		let opacityAnimation = CABasicAnimation(keyPath: "opacity")
		let duration: CGFloat = 1
		opacityAnimation.fromValue = 0.2
		opacityAnimation.toValue = 0.8
		opacityAnimation.timeOffset = duration * drand48()
		opacityAnimation.duration = duration
		opacityAnimation.repeatCount = 0
		opacityAnimation.autoreverses = true
		opacityAnimation.delegate = self
		opacityAnimation.setValue("opacityValue", forKey: "opacity")
		starLayers.forEach {
			$0.add(opacityAnimation, forKey: nil)
		}
	}
}

그런데, 한번 더 동작하고 더이상 동작하지 않았습니다.

음. 왜지?

애니메이션을 레이어에 추가하는 스레드가 먹통인가? "그럼 애니메이션만 추가하는 아토믹한 명령으로 만들어보자"라는 생각으로 CATransaction을 이용했어요.

CATransaction.begin()
starLayers.forEach {
    $0.add(opacityAnimation, forKey: nil)
}
CATransaction.commit()

이번엔 되긴 했어요. 근데 duration을 무시하고 빠른 속도로 깜박입니다..

음.. 이유에 대해서 생각해봤어요.

모르겠습니다. 고민은 정말 많이 했는데 그 원인을 찾기가 쉽지 않았습니다. 검색해도 나오지가 않더라구요. 이유가 있을까요...? iOS 커뮤니티와 오픈채팅방에도 여쭤봤지만 답이 없었습니다.. 클린 코드 책에서는 "말이 안되는 실패는 잠정적인 스레드 문제로 취급하라" 고 합니다. 스레드를 디버깅하는 방식은 더 공부해봐야할 것 같아 Main 쓰레드에서 코드를 작성해보았지만 그마저도 실행되지 않았습니다.

UIView의 애니메이션으로 구현하면 매번 프로퍼티값을 랜덤하게 설정해줄 수 있기 때문에 원하는 애니메이션을 만들 수는 있습니다. 하지만 별이 정말 많아지면, cpu에 부담을 많이 줄 수 있습니다. Core 애니메이션으로 구현하면 매번 프로퍼티값을 랜덤하게 설정할 수가 없어요. 트레이드오프가 있네요... (사실 제가 코어 애니메이션으로 못하고 있는 것 같습니다만.. 아신다면 댓글에 이유를 남겨주세요!..!)

물론! 코어 애니메이션으로 원하는 애니메이션의 개수가 딱 정해져있으면 체이닝이 가능합니다!

1. beginTime 프로퍼티와 CAAnimationGroup을 이용하는 방법이 있고,

2. CATransaction의 setCompletionBlock 프로퍼티를 이용하는 방법도 있습니다.

무한으로 체이닝하려고 하기 때문에 위와 같은 이슈가 발생하는 것입니다. 이 이슈로 오늘 6시간을 보냈습니다. 더 찾아보고 싶지만 이제 지금 하고 있는 프로젝트를 개발하러 가야겠습니다... 아쉽지만 다음에 찾아보도록 할게요. 오늘도 읽어주셔서 감사합니다.

[CoreAnimation] 물체를 path 따라 움직이기 (feat. 우주비행사 날리기)

jaelee — Sat, 22 Oct 2022 22:43:33 +0900

오늘은 이 우주비행사를 원하는 경로로 움직여보려고 합니다!

먼저 지난번에 알아본 CAKeyframeAnimation와 UIBezierPath의 개념에 대한 이해가 필요해요.

아래 두곳에 정리해두었는데 참고하시면 좋겠습니다!

https://github.com/wody-d/woody-iOS-tip/blob/main/TIL_2022:10:19_uibezierpath.md

GitHub - wody-d/woody-iOS-tip: iOS에 대한 소소한 팁들과 개발하다 마주친 버그 해결기, 그리고 오늘

github.com

https://github.com/wody-d/woody-iOS-tip/blob/main/TIL_2022:10:20_core_animation.md

GitHub - wody-d/woody-iOS-tip: iOS에 대한 소소한 팁들과 개발하다 마주친 버그 해결기, 그리고 오늘

github.com

경로 그리기

가장 먼저 view 하나를 준비합니다. 위 view위에 layer를 추가해줄려고 합니다.

final class ViewController: UIViewController { 

	lazy var animationView =  AnimationView(
	    frame: .init(
	        origin: .init(x: 50, y: 100),
	        size: .init(width: view.frame.width-100, height: 300)
	    )
	)
	
	override func viewDidLoad() {
	   super.viewDidLoad()
	   view.backgroundColor = .white
	   view.addSubview(animationView)
	}
}

final class AnimationView: UIView {

    override init(frame: CGRect) {
        super.init(frame: frame)
        self.backgroundColor = .black
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

이제 시작해볼게요.

물체를 원하는 경로로 날리기 위해서는 경로를 그려줘야 합니다.

경로는 UIBezierPath를 이용해서 간단한 곡선을 그려볼게요.

let path = UIBezierPath()
path.move(to: .init(x: 0, y: 0))
path.addQuadCurve(
    to: .init(x: bounds.width/2, y: bounds.height/2),
    controlPoint: .init(x: 0, y: bounds.height/2)
)
path.addQuadCurve(
    to: .init(x: bounds.width, y: bounds.height),
    controlPoint: .init(x: bounds.width, y: bounds.height/2)
)
path.move(to: .init(x: bounds.width, y: bounds.height))

경로를 만들어주었으면 이제 레이어를 추가해주어야해요.

override func draw(_ rect: CGRect) {
   let lineLayer = CAShapeLayer()
   lineLayer.frame = bounds
   lineLayer.path = path.cgPath
   lineLayer.strokeColor = UIColor.white.cgColor
   lineLayer.fillColor = UIColor.clear.cgColor
   self.layer.addSublayer(lineLayer)
}

의도한 대로 결과가 나온걸 볼 수 있어요!

Shake 버튼과 아래 슬라이더는 일단 무시해주세요. 여러가지 실험을 위한 재료들입니다.

애니메이션 입히기

그럼 이제 이 선에 애니메이션을 주겠습니다.

아무데서나 우주비행사 아이콘을 하나 준비하고

뷰에 추가합니다.

final class AnimationView: UIView {
    let imageView: UIImageView = UIImageView(image: .init(named: "astronaut"))

    override init(frame: CGRect) {
        super.init(frame: frame)
        self.backgroundColor = .black
        addSubview(imageView)
        imageView.frame = CGRect(
            origin: .init(x: -20, y: -20),
            size: .init(width: 40, height: 40)
        )
       
       // path 코드 생략...
    }

네,

저는 우주비행사가 왼쪽 상단 모서리에 오도록 배치했습니다.

이제 우주비행사한테 애니메이션을 주려면 애니메이션을 실행해줄 CAKeyframeAnimation 객체가 필요합니다,

또 움직일 경로가 필요한데 이미 위에서 path는 준비해두었네요!

이 때, CAKeyframeAnimation의 keypath는 우주비행사 이미지를 움직이는 것이므로 position이 됩니다.

position은 해당 객체의 위치를 나타냅니다.

position은 객체의 위치를 항상 나타내지는 않습니다. 위의 경우 우주비행사 이미지에 새로 추가한 레이어가 없고 anchorPoint 또한 (0.5, 0.5) 이기 때문에 우주비행사 이미지의 중앙을 나타냅니다. 자세한 내용은 아래 내용을 참고해주세요!
https://wodyios.tistory.com/71

override func draw(_ rect: CGRect) {
	let lineLayer = CAShapeLayer()
	lineLayer.frame = bounds
	lineLayer.path = path.cgPath
	lineLayer.strokeColor = UIColor.white.cgColor
	lineLayer.fillColor = UIColor.clear.cgColor
	self.layer.addSublayer(lineLayer)
	
	// 아래 코드 추가 
	let astronautAnimation = CAKeyframeAnimation(keyPath: "position")
	astronautAnimation.repeatCount = 0
	astronautAnimation.path = path.cgPath
	astronautAnimation.duration = 1
    
	imageView.layer.add(astronautAnimation, forKey: nil)
	imageView.layer.position = path.currentPoint
}

여기서 선도 함께 애니메이션을 줄 수 있습니다.

override func draw(_ rect: CGRect) {

    let lineLayer = CAShapeLayer()
    lineLayer.frame = bounds
    lineLayer.path = path.cgPath

    lineLayer.strokeColor = UIColor.white.cgColor
    lineLayer.fillColor = UIColor.clear.cgColor
    self.layer.addSublayer(lineLayer)

    let astronautAnimation = CAKeyframeAnimation(keyPath: "position")
    astronautAnimation.path = path.cgPath
    astronautAnimation.duration = 2
    let lineAnimation = CABasicAnimation(keyPath: "strokeEnd")
    lineAnimation.fromValue = 0
    lineAnimation.toValue = 1
    lineAnimation.duration = 2

    CATransaction.begin()
    lineLayer.add(lineAnimation, forKey: nil)
    imageView.layer.add(astronautAnimation, forKey: nil)
    imageView.layer.position = path.currentPoint
    CATransaction.commit()
}

위 코드에서 CATransaction을 사용한 이유는 2개의 애니메이션을 함께 실행하는 것을 보장하기 위해서입니다. CATransaction은 타입메소드로 되어 있기 때문에 CATransaction.begin()과 commit()과 같이 사용할 수 있어요.

원래 Core Animation을 레이어에 추가하면 스레드의 다음 런루프에 애니메이션이 실행이 돼요. 애니메이션이 실행될 때, 부분적으로 실행되다가 중단되지 않을 것을 보장하기 위해 transaction을 만드는데, 스레드의 런루프마다 자동으로 생성되는 transaction을 implicit transaction이라 해요. 반대로, CATransaction와 같이 명시적으로 transaction을 만들어줄 수가 있는데 이를 explicit transaction이라고 합니다! 저는 지금 explicit transaction을 만들었습니다!

transaction은 inner와 outer로 구분될 수도 있습니다. CATransaction안에 또다른 CATransaction을 만들어줄 수가 있기 때문에 2번의 begin()을 하면, 2번의 commit()이 필요합니다. 자세한 내용은 아래 문서를 확인해주세요!
https://developer.apple.com/documentation/quartzcore/catransaction

실행해보면 아래와 같은 애니메이션을 볼 수 있어요!

시간 조절하기 (timeOffset, speed)

위 애니메이션은 view가 로드되는 순간 실행돼요.

하지만 저는 직접 제 손으로 우주비행사를 원하는 경로로 움직이고 싶습니다!

슬라이더의 값을 통해 우주비행사의 위치를 저 경로에 맞춰서 이동시키도록 시도해봤어요.

먼저 슬라이더를 추가하고 슬라이더의 값이 변할 때마다 CoreAnimation을 주면 되겠다고 생각했습니다.

그런데,,, 애니메이션을 주면 처음부터 같은 애니메이션이 반복해서 실행되자나요?

그래서, 슬라이더의 값에 따라 원하는 위치에 있기 위해서는 timeOffset이라는 프로퍼티를 사용해야 했어요.

timeOffset 프로퍼티는 애니메이션이 실행될 때 몇 초 후 애니메이션이 그리고 있는 레이어에서부터 시작할 수 있도록 도와주는 프로퍼티입니다! (여기서 이해가 안될 수도 있는데 아래에서 더 자세하게 설명할게요)

그리고 CAMediaTiming 문서를 좀만 읽어가다 보면,

레이어에 speed 프로퍼티가 있고 이 프로퍼티는 애니메이션의 속도를 조절하는 것이라는 사실을 알 수 있었어요.

그래서 speed = 0으로 하고 timeoffset에 슬라이더의 값 * duration을 할당했습니다. duration을 곱해준 이유는 duration동안 애니메이션이 실행되기 때문입니다! 생각한 것을 코드로 구현했습니다.

// 슬라이더 추가 코드 생략

func changeValue(_ value: Float) {
	let pathAnimation = CAKeyframeAnimation(keyPath: "position")
	pathAnimation.path = path.cgPath
	let duration: CGFloat = 1
	pathAnimation.duration = duration
	pathAnimation.speed = 0
	pathAnimation.timeOffset = duration * Double(value)
	
	imageView.layer.add(pathAnimation, forKey: nil)
	imageView.layer.position = path.currentPoint
}

슬라이더의 값이 변경됨에 따라, 우주비행의 위치도 정해준 경로를 이동하는 것을 볼 수 있어요!

다른 방법? (beginTime, isRemovedOnCompletion, fillMode)

이 방법이 최선일까 더 찾아보다가 신기한 방법을 찾아냈어요.

speed = 0 을 하지 않아도, beginTime isRemovedOnCompletion, fillMode 3가지 프로퍼티만으로 작동하더라구요.

func changeValue(_ value: Float) {
    let pathAnimation = CAKeyframeAnimation(keyPath: "position")
    pathAnimation.path = path.cgPath
    let duration: CGFloat = 1
    pathAnimation.duration = duration
    pathAnimation.timeOffset = duration * Double(value)
    pathAnimation.beginTime = 1 // ✅
    pathAnimation.isRemovedOnCompletion = false // ✅
    pathAnimation.fillMode = .forwards // ✅
    
    imageView.layer.add(pathAnimation, forKey: nil)
    imageView.layer.position = path.currentPoint
}

근데 이 코드가 왜 되지? 싶었어요.

isRemovedOnCompletion 프로퍼티는

애니메이션이 끝났을 때 해당 애니메이션을 지울까말까 여부에 관한 프로퍼티예요.

fillMode 프로퍼티는

애니메이션이 끝났을 때, 다시 원래대로 돌아갈까 아니면 끝난 시점 레이어로 보여줄까에 관한 프로퍼티예요.

즉, 처음에 실행되는 애니메이션에서 우주비행사가 오른쪽아래로 이동했을 때 다시 왼쪽위모서리로 되돌릴까 아니면 그대로 남길까에 관한 프로퍼티인거죠. 이 프로퍼티는 isRemovedOnCompletion = false일 때에만 실행돼요. 애니메이션이 레이어에서 제거되면 애니메이션 에 관한 정보가 남아있지 않기 때문에 유효하지 않아요.

beginTime 프로퍼티는 애니메이션이 시작되는 시간을 의미해요.

프로퍼티들의 정의를 다 읽어보고 fillMode와 isRemovedOnCompletion프로퍼티는 납득이 갔어요.

"애니메이션을 남겨서 이동된 위치정보를 가지고 있게하기 위해 설정한 것이구나"

그런데, 도저히 beginTime은 이해가 가지 않았습니다..

beginTime = 0 으로 설정하면 애니메이션이 의도대로 동작하지 않고 0이 아닌 다른 값으로 설정하면 의도대로 동작하더라구요.

Customizing the Timing of an Animation 문서를 더 뒤져봤어요.

그리고 어느정도 유추해보았는데요.

먼저 알아야할 개념은 레이어마다 각자의 시간을 가지고 있다는 사실이에요. 레이어 각각의 시간차이는 유저가 느끼지 못할 정도로 작기 때문에 시간차를 준 애니메이션이 아니고선 시간차이에 관해서는 신경쓰지말라고 합니다.

두번째로는 부모와의 상대적인 시간 개념도 있어요. 즉, frame과 bound의 관계처럼 말이에요.

그래서 결국 부모와 local 시간 중에 무엇이 더 중요하냐면, 레이어 각각이 가지고 있는 local 시간이 중요합니다!

그래서 각 레이어의 현재 시간(local time)을 구하기 위해 부모의 시간을 자신의 시간(local time)으로 변환하는 과정이 필요해요.

여기까지 읽어보았을 때, beginTime을 0으로 설정하면 자동으로 부모의 시간을 자신의 시간으로 변환해서 애니메이션을 실행합니다. 하지만, 0이 아닌 0.1초, 1초, 5초 등의 시간으로 설정하면 beginTime은 레이어의 절대적인 시간을 설정하는 것이므로 부모 레이어의 시간과 비교해보았을 때, 너어무 비슷해서 실행하고 바로 멈추는 것 같아요. (사실 이게 오작동 아닐까요?)

애니메이션이 아래와 같이 동작하는게 정삭적일 텐데,

Normal : | A->B->C->D->E
beginTime : | A->B->C->D->E
timeOffset : | C->D->E->A->B

beginTime이 부모 레이어의 시간과 너무 맞지 않아,

Normal : | A->B->C->D->E
beginTime+timeOffset : | C

이렇게 끝나버린겨죠..

조금 더 찾아봐야겠지만 일단 이렇게 결론을 내려봤어요. 더 찾아보고 놀라운 내용이 있다면 글을 다시 작성하도록 하겠습니다!

아무튼 이걸 통해서 멋진 애니메이션을 구현할 수 있으면 좋곘네요. 읽어주셔서 감사합니다!

Ref

https://stackoverflow.com/questions/27643002/ios-swift-animation-controlled-by-gesture

iOS, Swift: animation controlled by gesture

I trying to find a way for connecting user interaction (pan gesture) with animation. I want to control animation progress by dragging view (or just by finger panning on the screen). I think I can ...

stackoverflow.com

https://developer.apple.com/documentation/quartzcore/camediatiming/1427654-begintime

Apple Developer Documentation

developer.apple.com

https://developer.apple.com/documentation/quartzcore/catransaction

Apple Developer Documentation

developer.apple.com

https://developer.apple.com/documentation/quartzcore/camediatiming

Apple Developer Documentation

developer.apple.com

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreAnimation_guide/AdvancedAnimationTricks/AdvancedAnimationTricks.html#//apple_ref/doc/uid/TP40004514-CH8-SW1

Advanced Animation Tricks

Advanced Animation Tricks There are many ways to configure your property-based or keyframe animations to do more for you. Apps that need to perform multiple animations together or sequentially can use more advanced behaviors to synchronize the timing of th

developer.apple.com

https://stackoverflow.com/questions/1166405/how-to-specify-an-begintime-for-an-animation-by-using-cftimeinterval

How to specify an beginTime for an animation by using CFTimeInterval?

For my understanding, beginTime can be used to say "hey, start at exactly 12:00 'o clock". But how would I tell this with an CFTimeInterval type? I thought that this one is nothing more than a kind...

stackoverflow.com

[CoreAnimation] AnchorPoint, position의 관계 (feat. SwiftUI에선 anchortPoint가 없다..?)

jaelee — Sat, 22 Oct 2022 01:00:35 +0900

뷰의 레이아웃을 위치시킬 때, 오토레이아웃을 사용하면 사실 frame, anchorPoint 등 레이아웃 관련 프로퍼티는 크게 신경 쓰지 않아도 됩니다. 그런데, 이번 프로젝트에서 frame을 이용해야 하는 조금 어려운 애니메이션을 구현해보는 구현 내용이 있었고 구현을 하다보니 이전에 공부하다 헷갈렸던 내용과 똑같은 곳에서 헷갈렸습니다.

그래서 이 글은 저와 비슷하게 헷갈리는 분들이 있을 수 있기 때문에 작성했습니다.

layer프로퍼티에 있는 position은 무엇을 나타내는 값일까요? 라는 질문이 나오기까지의 과정을 설명하겠습니다.

먼저, Core Animation Basics 문서를 읽다보면 중간에 아래 그림이 나옵니다.

"anchor point가 layer의 position에 얼마나 영향을 미치는지"에 대한 사진입니다. 그리고 위에 부가설명이 적혀있었습니다.

Figure 1-5 demonstrates how changing the anchor point from its default value to a different value affects the position property of a layer. Even though the layer has not moved within its parents’ bounds, moving the anchor point from the center of the layer to the layer’s bounds origin changes the value in the position property

위 말을 마지막 문장을 보시면, "앵커포인트를 (0.5, 0.5), 즉 중앙에서 다른 곳으로 옮기는 행위는 position 프로퍼티 값을 바꾼다" 라고 이해가 됩니다. 하지만 실제로 코드를 작성해보면 그렇지 않았습니다.

아래 코드에서 position 프로퍼티 값의 결과는 (0,0)으로 일정했습니다.

let layer = CAShapeLayer()
layer.path = UIBezierPath(
	rect: .init(origin: .init(x: view.center.x-100, y: view.center.y-100), 
    size: .init(width: 200, height: 200)
)).cgPath
layer.fillColor = UIColor.blue.cgColor

print(layer.position)
layer.anchorPoint = .init(x: 0, y: 0)
print(layer.position)

view.layer.addSublayer(layer)

먼저, position의 정의를 다시 알아봤습니다.

position은 레이어의 프로퍼티이고 자신의 부모 레이어의 좌표계내에서의 위치를 나타낸다고 합니다.

그리고 Discussion에서 새로운 레이어는 기본적으로 position이 (0.0, 0.0)으로 설정된다고 합니다.

아, 그럼 새로운 레이어를 추가했기 때문에 (0,0)으로 초기화되었고 새 레이어를 추가해서 예제를 만들면 안되겠다는 사실을 알았습니다.

그럼 이제 새로운 뷰를 추가하여 실험을 해보았습니다.

let view1 = UIView(frame: .init(
    origin: .init(x: view.center.x-100, y: view.center.y-100),
    size: .init(width: 200, height: 200)
))
view1.backgroundColor = .blue
view.addSubview(view1)

위와 같이 작성한 후, 레이어의 앵커포인트를 (0,0)으로 수정했습니다.

view1.layer.anchorPoint = .init(x: 0, y: 0)

그랬더니 웬걸, 뷰가 오른쪽 아래로 배치되었습니다.

position을 앵커포인트가 바뀌기 전과 바뀐 후와 비교해보니, (195.0, 422.0)로 일정했습니다. 해당 좌표는 핸드폰 중앙입니다.

여기서, position은 anchorPoint를 변하게해도 일정하다는 사실을 알 수 있습니다.

그럼 위 문서에서 사진은 무슨 의미일까요?

사진에선, anchorPoint가 (0.5, 0.5) -> (0,0)으로 바뀌었을 때, position은 (100.0, 100.0) -> (40.0, 60.0) 으로 좌표값이 변했습니다. 하지만 이것은 완전히 상대적 값입니다. "position은 이제 anchorPoint가 바뀌면서 중앙에서 왼쪽 위로 변했다"라고 사진에서는 보여 준것입니다. 그것을 이해가 쉽게 하기 위해 좌표를 통해 보여준 것입니다. 처음에 봤을 때, 아마 모든 사람들이 position 값이 변하는 줄 알았을 것이라고 생각합니다.. 이 생각이 맞는 지 실험을 해보았습니다.

위 상황처럼 뷰의 anchorPoint를 (0.0, 0.0)으로 수정한 상황에서, position을 (0,0)으로 수정해봤습니다. (혹시나, 레이어와 뷰가 따로 노는가 싶어서 레이어의 테두리에도 색깔을 주었습니다.)

let view1 = UIView(frame: .init(
    origin: .init(x: view.center.x-100, y: view.center.y-100),
    size: .init(width: 200, height: 200)
))
view1.backgroundColor = .blue
view.addSubview(view1)
view1.layer.anchorPoint = .init(x: 0, y: 0)
view1.layer.position = .init(x: 0, y: 0)
view1.layer.borderColor = UIColor.red.cgColor
view1.layer.borderWidth = 4

네모가 왼쪽위에 붙어있는 것을 알 수 있습니다. (왜 왼쪽 위에 붙지? 라고 생각하신다면 레이어트리를 생각하시면 이해하실 수 있습니다.)

다시 정리하면,

position은 anchorPoint를 명시적으로 나타내는 좌표라고 할 수 있습니다. 따라서 position을 변경하면 뷰는 움직입니다. 하지만 anchorPoint를 바꾼다고 뷰가 움직이지는 않습니다.

이 anchorPoint는 transform에서 의미를 가집니다. 해당 문서를 더 읽어보면 아래의 사진을 보실 수 있습니다.

anchor point가 transform 영향을 어떻게 미치는지에 대한 사진으로 회전축이라고 생각하시면 됩니다. 이 회전축은 뷰의 비율(0~1)로 생각하고 정의를 하고 비율이므로 실제 anchorPoint의 좌표는 position이 되는 것입니다.

SwiftUI?

그럼 아주 조금만 더 나아가서, SwiftUI에서도 position과 anchorPoint라는 개념이 있는 지 궁금해져서 조금 더 찾아봤습니다.

position이라는 뷰모디파이어는 찾을 수 있었습니다. 하지만, anchorPoint는 찾을 수 없었습니다.

Text("Position by passing a CGPoint()")
    .position(CGPoint(x: 175, y: 100))
    .border(Color.gray)

그럼 SwiftUI에서는 뷰의 anchorPoint를 바꾸기 위해서는 어떻게 할까요? 라는 질문이 자연스레 나올 수 있습니다.. 네.. 이게 정상입니다..

그래서 검색해봤고.. 스택오버플로우에서 하나의 예시를 찾을 수 있었습니다. 하나의 예시라고 한 이유는 SwiftUI에서는 관점을 바꿔서 생각해야했기 때문입니다. (그래서 다양한 방법으로 애니메이션을 줄 수 있기 때문입니다.)

https://stackoverflow.com/questions/57442995/anchor-point-in-swiftui

Anchor point in SwiftUI

I'm playing with SwiftUI animations. I wanted to make a square bigger modifying its frame with an animation this way: struct ContentView: View { let squareWidth = CGFloat(100) let squareHe...

stackoverflow.com

(UIKit언어로) anchorPoint가 (0.5, 0.5)일 때,

VStack {
    Color.green
        .frame(width: bigger ? self.squareWidth * 2 : self.squareWidth, height: self.squareHeight)
        .animation(.default, value: bigger)
    Button(action: {
            self.bigger.toggle()
    }) {
        Text("Click me!")
    }
}

(UIKit언어로) anchorPoint가 (0.0, 0.5) 일 때,

HStack {
    VStack {
        Color.green
            .frame(width: bigger ? self.squareWidth * 2 : self.squareWidth)
            .frame(height: self.squareHeight)
            .animation(.default, value: bigg
        Button("Click me!") { self.bigger.toggle() }
            .animation(.default, value: bigger)
  
    Space()
}

정말 트위터에서 최근에 본 사진이 생각납니다 ㅎㅎ

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreAnimation_guide/CoreAnimationBasics/CoreAnimationBasics.html#//apple_ref/doc/uid/TP40004514-CH2-SW3

Core Animation Basics

Core Animation Basics Core Animation provides a general purpose system for animating views and other visual elements of your app. Core Animation is not a replacement for your app’s views. Instead, it is a technology that integrates with views to provide

developer.apple.com

https://developer.apple.com/documentation/quartzcore/calayer/1410791-position

Apple Developer Documentation

developer.apple.com

https://developer.apple.com/documentation/swiftui/view/position(x:y:)

Apple Developer Documentation

developer.apple.com