24 · 프로세스 경계와 App Extension

P0 03장이 "iOS 앱은 프로세스로 어떻게 표현되고 샌드박스로 어떻게 격리되는가"를 다뤘다. 이 챕터는 그 격리를 실제로 마주치는 자리를 다룬다 — App Extension이다. 같은 번들 안에 들어 있고 같은 개발자가 만들었는데도 메모리를 공유할 수 없고, 파일 컨테이너가 다르고, 쓸 수 있는 API가 다르고, 자원 예산이 훨씬 빡빡하다. 여기서 겪는 문제들은 전부 "프로세스 경계란 무엇인가"의 구체적 귀결이다.

Q1. App Extension은 왜 앱이 아닌가?

CS 원리

P0 03장에서 본 프로세스 격리가 그대로 적용된다. 두 프로세스는 서로 다른 가상 주소 공간을 갖고(P0 01장), 서로 다른 샌드박스 컨테이너를 가지며, 커널이 그 경계를 강제한다. 같은 팀이 만들었다는 사실은 커널에게 아무 의미가 없다.

그래서 프로세스 간에 무언가를 전달하려면 명시적 IPC 메커니즘이 필요하다. iOS 익스텐션 모델이 제공하는 통로는 정확히 두 개뿐이다.

• host ↔ extension — 시스템이 개설한 요청/응답 채널. NSExtensionContext와 NSItemProvider가 그 위에 얹힌다(Q4).
• extension ↔ containing app — App Group 공유 컨테이너가 유일한 정식 통로다(Q3). 파일시스템을 경유하는 간접 통신이다.

여기서 중요한 예외가 하나 있다 — (레거시) Today 위젯만 NSExtensionContext.open(_:completionHandler:)로 컨테이닝 앱을 직접 열 수 있다. 나머지 익스텐션은 이 경로가 없다. WidgetKit 위젯은 이 API가 아니라 widgetURL·Link 딥링크로 앱을 연다.

생애주기도 앱과 근본적으로 다르다. 앱은 사용자가 종료할 때까지 살지만, 익스텐션은 요청/응답 트랜잭션이다.

1. host가 요청을 발행한다.
2. 시스템이 익스텐션을 인스턴스화하고 통신 채널을 연다.
3. 익스텐션이 host의 컨텍스트 안에 뷰를 띄우고 작업한다.
4. 사용자가 완료하거나 취소한다.
5. 작업 직후 시스템이 익스텐션을 종료한다.

5번이 특히 중요하다. completeRequest…를 호출한 직후부터 시스템은 언제든 익스텐션을 종료할 수 있다. "완료 처리하고 나서 정리 작업을 하자"는 발상이 통하지 않는다.

iOS에서는

이 구조가 만드는 실무 결과를 정리하면 이렇다.

배포·심사 쪽 제약도 있다.

• 익스텐션만 단독 제출할 수 없다 — 컨테이닝 앱이 반드시 필요하다.
• 컨테이닝 앱이 익스텐션만 담고 있으면 리뷰에서 탈락한다 — 앱 자체가 의미 있는 기능을 해야 한다.
• 앱 간 이전 불가 — 익스텐션을 다른 앱으로 옮길 수 없다.
• 타깃 디바이스 패밀리는 반드시 universal(iPhone/iPad) — 컨테이닝 앱이 iPad 전용이어도 그렇다.

그리고 디버깅 방법이 다르다. 익스텐션 scheme의 Run 단계에서 host app을 executable로 지정하고 그 host UI를 통해 익스텐션을 띄워야 디버거가 붙는다. 컨테이닝 앱 scheme으로 실행하면 익스텐션에 디버거가 붙지 않는다 — "브레이크포인트가 안 걸린다"의 대부분이 이것이다.

실험 · 도구

익스텐션이 정말 별도 프로세스인지는 직접 확인할 수 있다.

import Foundation
import os

// 익스텐션과 컨테이닝 앱 양쪽에 같은 코드를 넣고 로그를 비교한다
func dumpProcessIdentity(_ where_: String) {
    let info = ProcessInfo.processInfo
    Logger(subsystem: "com.example.shop", category: "process").notice("""
        [\(where_, privacy: .public)] \
        pid=\(info.processIdentifier, privacy: .public) \
        name=\(info.processName, privacy: .public) \
        bundle=\(Bundle.main.bundleIdentifier ?? "?", privacy: .public) \
        path=\(Bundle.main.bundlePath, privacy: .public)
        """)

    // 전역 변수는 프로세스마다 별개다 — 이것이 "싱글턴이 안 통하는" 이유
    Counter.shared.increment()
    Logger(subsystem: "com.example.shop", category: "process")
        .notice("[\(where_, privacy: .public)] 싱글턴 카운터 = \(Counter.shared.value, privacy: .public)")
}

final class Counter {
    static let shared = Counter()
    private(set) var value = 0
    func increment() { value += 1 }
}

# 두 프로세스를 동시에 관찰한다
log stream --predicate 'subsystem == "com.example.shop" AND category == "process"' \
           --style compact

# 결과 예시:
# [containing app] pid=1234 name=Shop bundle=com.example.shop path=/…/Shop.app
# [share extension] pid=5678 name=ShareExt bundle=com.example.shop.share
#                              path=/…/Shop.app/PlugIns/ShareExt.appex
#   → pid가 다르다. bundle identifier도 다르다. 번들 경로는 중첩돼 있다.
#   → 싱글턴 카운터는 양쪽 다 1이다. 서로의 값을 절대 못 본다.

# 실행 중인 익스텐션 프로세스 확인 (기기 연결 상태)
log stream --predicate 'process ENDSWITH "Ext"' --style compact

생애주기의 짧음도 확인해볼 만하다.

// completeRequest 이후 코드가 실행되지 않을 수 있음을 확인한다
extension ShareViewController {
    override func didSelectPost() {
        saveToSharedContainer()          // ✅ 완료 전에 끝낸다

        extensionContext?.completeRequest(returningItems: nil) { expired in
            // ⚠️ 이 블록이 불린 뒤 시스템은 언제든 프로세스를 죽일 수 있다
            Logger(subsystem: "com.example.shop", category: "process")
                .notice("완료 콜백 expired=\(expired, privacy: .public)")
        }

        // ❌ 여기에 중요한 작업을 두면 실행되지 않을 수 있다
        uploadAnalytics()                // 실행 보장 없음
    }
}

프로젝트 적용

익스텐션을 추가할 때 설계 원칙 넷.

• 상태는 전부 공유 컨테이너에서 읽는다. 메모리에 캐시된 세션·설정·사용자 정보는 익스텐션에 없다. 시작할 때마다 디스크에서 읽는다고 가정한다.
• 완료 전에 모든 영속화를 끝낸다. completeRequest 이후는 실행 보장이 없다. 관측 이벤트 전송도 마찬가지라, 익스텐션의 크래시·성능 데이터는 다음에 앱이나 익스텐션이 실행될 때 올라간다(19장 Q2와 같은 구조).
• 공유 코드는 embedded framework로. 소스 파일을 두 타깃에 중복 추가하면 유지보수가 갈라진다. 다만 그 프레임워크는 app-extension-safe여야 한다(Q6).
• 익스텐션을 별도 릴리스 단위로 취급한다. 21장 Q2에서 본 대로 dSYM도 따로이고, 크래시도 따로 집계된다. 대시보드에서 process=extension 축을 두면 "본 앱은 멀쩡한데 익스텐션만 죽는" 상황이 보인다.

꼬리 질문

Q2. Extension point 선택이 왜 API 집합까지 결정하는가?

CS 원리

이건 플러그인 아키텍처의 표준 설계다. 호스트 시스템이 확장 지점을 정의할 때 필요한 것은 셋이다.

• 계약(contract) — 플러그인이 구현해야 할 인터페이스.
• 정책(policy) — 언제 호출되고, 무엇이 허용되고, 어떤 자원을 쓸 수 있는가.
• 발견(discovery) — 시스템이 어떤 플러그인이 있는지 알아내는 방법.

extension point는 이 셋을 묶음으로 제공한다. 그래서 point를 고르는 것은 인터페이스만 고르는 게 아니라 정책 패키지 전체를 고르는 것이다.

왜 이렇게 묶었는지는 보안 모델로 설명된다. 만약 "모든 익스텐션은 같은 API를 쓸 수 있다"고 하면, 커스텀 키보드가 카메라를 쓰거나 위젯이 사용자 입력을 가로챌 수 있게 된다. 용도별로 권한을 좁히면 최소 권한 원칙이 구조적으로 강제된다.

발견 메커니즘도 point마다 다르다. Share 익스텐션은 공유 시트에 나타나야 하고, 그러려면 시스템이 "이 익스텐션이 이 데이터를 처리할 수 있는가"를 판정해야 한다 — 그게 NSExtensionActivationRule이고 Q5의 UTI 체계 위에서 동작한다. Today 위젯은 그런 판정이 필요 없고 대신 업데이트 주기 정책이 붙는다.

iOS에서는

주요 extension point 식별자를 정리하면 이렇다.

† Today 익스텐션은 iOS 14에서 WidgetKit으로 대체되어 deprecated다. 최신 iOS에는 Today 뷰 자체가 없으므로 새로 만들 위젯은 WidgetKit이고, 컨테이닝 앱을 여는 것도 NSExtensionContext.open이 아니라 widgetURL·Link 딥링크를 쓴다. 아래 Today 관련 서술은 레거시 익스텐션 모델을 설명하기 위한 것이다.

이 키는 NSExtension 딕셔너리의 직계 자식이어야 하고, Xcode 템플릿이 각각 올바른 값을 미리 설정해 준다. 그래서 템플릿을 고르는 것이 곧 point를 고르는 것이다.

point마다 기본 capability도 다르다. 예를 들어 iOS Document Provider 템플릿은 com.apple.security.application-groups 엔타이틀먼트를 기본 포함하고, macOS 익스텐션 템플릿은 App Sandbox와 com.apple.security.files.user-selected.read-only를 기본 포함한다.

Share와 Action의 구분이 실무에서 가장 자주 헷갈린다. 판단 기준은 데이터가 어디로 가는가다.

• Share — 콘텐츠가 밖으로 나간다. 우리 서비스에 게시, 우리 앱에 저장, 외부로 전송.
• Action — 콘텐츠를 그 자리에서 보거나 바꾼다. 번역해서 보여주기, 이미지에 워터마크 넣어 돌려주기.

Action이 결과를 host에 돌려줄 수 있다는 점이 결정적 차이다. Share는 보내고 끝이다.

그리고 Share 익스텐션에는 별도 제약이 있다 — 공유 UI는 폭을 늘릴 수 없고, iOS 13부터 컨테이닝 앱 표시명으로 노출되므로 앱당 하나만 두어야 한다. 여러 개를 만들면 공유 시트에 같은 이름이 여러 번 나타난다.

실험 · 도구

Info.plist 구조를 직접 확인하고 검증하는 것이 첫걸음이다.

# 익스텐션의 extension point 확인
plutil -p "YourApp.app/PlugIns/ShareExt.appex/Info.plist" \
  | grep -A6 NSExtension

# 출력 예시:
#   "NSExtension" => {
#     "NSExtensionPointIdentifier" => "com.apple.share-services"
#     "NSExtensionPrincipalClass" => "ShareViewController"
#     "NSExtensionAttributes" => { "NSExtensionActivationRule" => ... }
#   }

# 앱 안 모든 익스텐션의 point를 한 번에 나열한다
for ext in YourApp.app/PlugIns/*.appex; do
  id=$(plutil -extract NSExtension.NSExtensionPointIdentifier raw "$ext/Info.plist" 2>/dev/null)
  echo "$(basename "$ext"): ${id:-없음}"
done

# CI 검증: point 식별자가 없거나 TRUEPREDICATE가 남아 있으면 실패시킨다
for ext in "$ARCHIVE"/Products/Applications/*.app/PlugIns/*.appex; do
  plist="$ext/Info.plist"
  point=$(plutil -extract NSExtension.NSExtensionPointIdentifier raw "$plist" 2>/dev/null)
  [ -n "$point" ] || { echo "❌ $(basename "$ext"): NSExtensionPointIdentifier 없음"; exit 1; }

  # Q5에서 다룰 리젝 사유 — 여기서 함께 잡는다
  if plutil -p "$plist" | grep -q TRUEPREDICATE; then
    echo "❌ $(basename "$ext"): TRUEPREDICATE 가 남아 있다 — 앱스토어 리젝 사유"
    exit 1
  fi
  echo "✅ $(basename "$ext"): $point"
done

Share와 Action의 동작 차이는 결과 반환으로 확인할 수 있다.

// Action 익스텐션 — 수정한 결과를 host에 돌려준다
final class WatermarkActionViewController: UIViewController {
    func finish(with image: UIImage) {
        let provider = NSItemProvider(item: image.pngData() as NSData?,
                                      typeIdentifier: UTType.png.identifier)
        let item = NSExtensionItem()
        item.attachments = [provider]

        // returningItems 로 host에 결과를 전달한다 — Share에는 없는 흐름
        extensionContext?.completeRequest(returningItems: [item], completionHandler: nil)
    }
}

// Share 익스텐션 — 보내고 끝. 돌려줄 것이 없다
final class ShareViewController: SLComposeServiceViewController {
    override func didSelectPost() {
        uploadToOurService()
        extensionContext?.completeRequest(returningItems: nil, completionHandler: nil)
    }
}

프로젝트 적용

extension point 선택에서 판단할 것 넷.

• 용도로 고른다. "우리 앱은 공유 기능이 있으니 Share"가 아니라 "이 익스텐션이 하는 일"로 고른다. 콘텐츠를 우리 서비스로 보내면 Share, 그 자리에서 변환해 돌려주면 Action.
• Share 익스텐션은 앱당 하나. iOS 13부터 컨테이닝 앱 이름으로 표시되므로 여러 개면 공유 시트에 중복된다.
• 필요한 API가 그 point에서 허용되는지 먼저 확인한다. 카메라가 필요한데 Share를 골랐다면 구현 도중에 막힌다 — 카메라·마이크는 iMessage 앱만 예외다(Q6).
• 템플릿을 쓰고 식별자를 바꾸지 않는다. Xcode 템플릿이 point별로 올바른 값과 기본 capability를 넣어준다. 식별자만 바꿔서 다른 point인 척하면 정책은 안 따라오고 동작이 깨진다.

꼬리 질문

Q3. 익스텐션과 컨테이닝 앱은 데이터를 어떻게 주고받는가?

CS 원리

App Group은 격리에 구멍을 뚫는 장치이고, 구멍을 뚫는 순간 격리가 막아주던 문제가 돌아온다. 그 문제가 동시성이다.

P0 02장에서 본 데이터 경쟁이 여기서 프로세스 간으로 확장된다. 그런데 프로세스 간 경쟁은 스레드 간 경쟁보다 다루기 어렵다.

• 공유 메모리가 없다. 뮤텍스나 액터 같은 프로세스 내 동기화 도구를 쓸 수 없다. 락도 파일시스템 기반이어야 한다.
• 상대가 언제 죽을지 모른다. 익스텐션은 시스템이 임의로 종료한다(Q1). 락을 쥔 채 죽으면 락이 영원히 안 풀릴 수 있다. 19장 Q4의 0xdead10cc가 정확히 이 상황을 시스템이 감지해 죽이는 것이다.
• 알림 메커니즘이 다르다. 같은 프로세스라면 KVO나 노티피케이션으로 변경을 알 수 있지만, 프로세스를 넘으면 이런 것들이 동작하지 않는다. Darwin notification 같은 별도 IPC가 필요하다.

그래서 공유 컨테이너 설계는 "어떻게 공유할까"가 아니라 "어떻게 안전하게 공유할까"가 본질이다.

iOS에서는

설정 순서는 이렇다 — Xcode/Developer 포털에서 컨테이닝 앱과 각 익스텐션에 App Groups를 켜고 → 포털에 그룹을 등록하고 → 쓸 그룹을 지정한다. 하나라도 빠지면 접근이 실패한다.

실제 접근 방법은 둘이다.

import Foundation

enum SharedStorage {
    static let groupID = "group.com.example.shop"

    /// (1) UserDefaults — 작은 설정값용
    /// ⚠️ .standard 와 완전히 별도의 저장소다. 자동 마이그레이션은 없다.
    static let defaults = UserDefaults(suiteName: groupID)!

    /// (2) 공유 컨테이너 디렉터리 — 파일용
    static var containerURL: URL {
        FileManager.default
            .containerURL(forSecurityApplicationGroupIdentifier: groupID)!
    }

    static var databaseURL: URL { containerURL.appendingPathComponent("shared.sqlite") }
    static var inboxURL: URL    { containerURL.appendingPathComponent("Inbox", isDirectory: true) }
}

UserDefaults(suiteName:)가 .standard와 완전히 별개라는 점이 실무에서 가장 자주 부딪히는 사실이다. 같은 키에 각각 다른 값을 넣으면 서로 다른 plist에 저장되어 절대 안 섞인다. 그래서 "App Group을 켰더니 기존 .standard 값이 익스텐션에 보인다"는 틀렸다 — 마이그레이션 코드를 직접 짜야 한다.

/// .standard → App Group 마이그레이션. 앱 시작 시 1회 실행한다.
enum DefaultsMigration {
    private static let doneKey = "migratedToAppGroup.v1"
    private static let keysToMove = ["lastSyncDate", "selectedTheme", "apiEnvironment"]

    static func runIfNeeded() {
        let shared = SharedStorage.defaults
        guard !shared.bool(forKey: doneKey) else { return }

        for key in keysToMove {
            guard let value = UserDefaults.standard.object(forKey: key) else { continue }
            shared.set(value, forKey: key)
            // 원본을 지울지는 정책 — 롤백 가능성을 원하면 남긴다
        }
        shared.set(true, forKey: doneKey)
    }
}

동시 접근 동기화는 문서가 지목한 셋 중에서 고른다.

마지막 행의 경고가 중요하다. NSFileCoordinator를 쓰면서 presenter를 제거하지 않으면 다른 프로세스의 파일 접근이 우리 응답을 기다리며 멈춘다 — 이미 죽은 익스텐션을 기다리는 셈이라 교착이 된다.

그리고 변경 통지가 별도 문제다. UserDefaults의 KVO는 프로세스를 넘지 않으므로, 값이 바뀐 것을 알리려면 Darwin notification을 쓴다.

import Foundation

/// 프로세스 간 변경 통지 — KVO나 NotificationCenter는 프로세스를 넘지 않는다
enum CrossProcessNotifier {
    private static let name = "com.example.shop.sharedDataChanged" as CFString

    static func post() {
        CFNotificationCenterPostNotification(
            CFNotificationCenterGetDarwinNotifyCenter(),
            CFNotificationName(name), nil, nil, true)
    }

    static func observe(_ handler: @escaping () -> Void) {
        // 콜백이 C 함수 포인터라 컨텍스트를 못 넘긴다 — 전역 저장이 필요하다
        Self.handler = handler
        CFNotificationCenterAddObserver(
            CFNotificationCenterGetDarwinNotifyCenter(),
            nil,
            { _, _, _, _, _ in Self.handler?() },
            name, nil, .deliverImmediately)
    }

    private static var handler: (() -> Void)?
}

위젯의 경우는 또 다르다 — 위젯은 공유 값을 실시간이 아니라 스냅샷 시점에만 읽으므로, 값을 바꾼 뒤 WidgetCenter.shared.reloadTimelines(ofKind:)를 직접 호출해야 갱신된다.

실험 · 도구

공유 저장소가 정말 분리돼 있는지 직접 확인해보자.

// 같은 키에 서로 다른 값을 넣고 양쪽을 읽어본다
UserDefaults.standard.set("standard-value", forKey: "probe")
SharedStorage.defaults.set("group-value", forKey: "probe")

print(UserDefaults.standard.string(forKey: "probe"))    // "standard-value"
print(SharedStorage.defaults.string(forKey: "probe"))   // "group-value"
// → 절대 안 섞인다. 다른 plist 파일이다.

// 실제 파일 위치를 확인한다
print("app 컨테이너:   ", FileManager.default.urls(for: .libraryDirectory, in: .userDomainMask)[0].path)
print("공유 컨테이너: ", SharedStorage.containerURL.path)
// → 완전히 다른 경로다.

동시 쓰기 경쟁도 재현할 수 있다.

// ⚠️ 동기화 없이 공유 파일에 쓰면 손상된다 — 재현 실험
func unsafeAppend(_ line: String) {
    let url = SharedStorage.containerURL.appendingPathComponent("log.txt")
    // 여러 프로세스가 동시에 이러면 내용이 섞이거나 잘린다
    if let h = try? FileHandle(forWritingTo: url) {
        h.seekToEndOfFile()
        h.write(Data(line.utf8))
        try? h.close()
    }
}

// ✅ POSIX 락으로 보호 — 단, 락 보유 중 종료되면 0xdead10cc 위험 (19장 Q4)
func safeAppend(_ line: String) {
    let url = SharedStorage.containerURL.appendingPathComponent("log.txt")
    guard let h = try? FileHandle(forWritingTo: url) else { return }
    defer { flock(h.fileDescriptor, LOCK_UN); try? h.close() }   // 반드시 해제

    guard flock(h.fileDescriptor, LOCK_EX) == 0 else { return }
    h.seekToEndOfFile()
    h.write(Data(line.utf8))
}

# 공유 컨테이너 내용을 기기에서 직접 확인 (Xcode)
#   Window › Devices and Simulators › (기기) › Installed Apps
#   › 앱 선택 › ⚙︎ › Download Container
#   ⚠️ 이 방법은 앱 컨테이너만 받는다. 공유 컨테이너는 별도로 확인해야 한다.

# 시뮬레이터에서는 경로로 직접 접근할 수 있다
xcrun simctl get_app_container booted com.example.shop groups
# → group.com.example.shop 의 실제 경로가 출력된다

프로젝트 적용

공유 컨테이너 설계 규칙 다섯.

• 접근을 한 곳으로 모은다. 공유 저장소를 읽고 쓰는 코드를 공유 프레임워크의 단일 타입에 두고, 그 타입만 동기화를 책임진다. 여기저기서 직접 파일을 열면 동기화가 무너진다.
• 단순한 값은 UserDefaults(suiteName:), 구조화된 데이터는 DB. 중간 크기의 JSON 파일을 직접 다루는 것이 가장 위험하다 — 동기화를 직접 해야 하는데 원자성 보장이 어렵다.
• 파일을 쓸 때는 원자적 쓰기를 쓴다(P0 10장). 임시 파일에 쓰고 교체하면 부분 기록 상태를 남기지 않는다.
• 락 보유 시간을 최소화한다. 익스텐션은 언제든 죽을 수 있고, 락을 쥔 채 서스펜드되면 0xdead10cc로 종료된다(19장 Q4). 읽고 바로 놓는다.
• 백그라운드 세션 식별자를 프로세스마다 다르게 한다. 백그라운드 세션은 한 번에 한 프로세스만 쓸 수 있다.

꼬리 질문

let container = NSPersistentContainer(name: "Model")
let url = SharedStorage.containerURL.appendingPathComponent("Model.sqlite")
container.persistentStoreDescriptions = [NSPersistentStoreDescription(url: url)]

let desc = NSPersistentStoreDescription(url: url)
desc.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)
desc.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey)

struct WriteAudit: Codable {
    let process: String     // "Shop" / "ShareExt" / "NotificationExt"
    let at: Date
    let version: String
}

Q4. NSItemProvider는 프로세스 경계를 어떻게 넘는가?

CS 원리

프로세스 간에 데이터를 넘기는 순진한 방법은 전부 복사해서 보내는 것이다. 그런데 이건 두 가지로 나쁘다.

• 낭비. 소비자가 안 쓸 포맷까지 만들어 보낸다. 이미지 하나를 PNG·JPEG·HEIC로 다 변환해 보냈는데 소비자가 PNG만 쓰면 나머지는 버려진다.
• 메모리 압박. 큰 파일을 통째로 메모리에 올려 전달하면, 익스텐션의 좁은 예산에서 즉시 죽는다(Q7).

NSItemProvider는 이를 능력 선언 + 지연 실행으로 푼다. 이건 흔한 패턴이다 — 값이 아니라 값을 만드는 방법을 전달하는 것. Swift의 lazy나 AsyncSequence와 같은 발상이고, 프로세스 경계에 적용한 것뿐이다.

구조를 정리하면 이렇다.

1. 제공자가 포맷별 로드 핸들러를 등록한다. 이 시점에는 아무것도 계산되지 않는다.
2. 프로바이더는 등록된 타입 식별자 목록만 노출한다. 소비자는 이 목록으로 협상한다.
3. 소비자가 특정 포맷을 요청하면 그 핸들러만 실행되어 데이터가 만들어진다.

여기서 타입 식별자로 협상한다는 점이 중요하다. 그 식별자 체계가 UTI이고, 준수 트리 덕분에 "정확히 이 타입"이 아니라 "이 타입에 준수하는 무엇이든"으로 물어볼 수 있다(Q5).

iOS에서는

익스텐션에서의 표준 흐름은 3단계다.

import UIKit
import UniformTypeIdentifiers

final class ShareViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        handleInputItems()
    }

    private func handleInputItems() {
        // (1) NSExtensionItem의 attachments를 훑는다
        guard let items = extensionContext?.inputItems as? [NSExtensionItem] else { return }

        for item in items {
            for provider in item.attachments ?? [] {
                // (2) 내가 아는 타입이 있는지 확인한다 — 준수 트리로 판정된다
                if provider.hasItemConformingToTypeIdentifier(UTType.image.identifier) {
                    loadImage(from: provider)
                } else if provider.hasItemConformingToTypeIdentifier(UTType.url.identifier) {
                    loadURL(from: provider)
                }
            }
        }
    }

    private func loadImage(from provider: NSItemProvider) {
        // (3) 로드한다 — 큰 파일은 Data가 아니라 파일 표현으로 받는다
        _ = provider.loadFileRepresentation(for: .image) { [weak self] url, _, error in
            // ⚠️ 이 블록은 내부 큐에서 호출된다. 문서가 명시적으로 경고하는 지점.
            guard let url, error == nil else { return }

            // 파일은 이 블록이 끝나면 사라질 수 있으므로 즉시 옮긴다
            let dest = SharedStorage.inboxURL.appendingPathComponent(url.lastPathComponent)
            try? FileManager.default.moveItem(at: url, to: dest)   // 복사가 아니라 이동

            DispatchQueue.main.async {
                // UI 갱신은 반드시 메인 큐로
                self?.showPreview(at: dest)
            }
        }
    }

    private func loadURL(from provider: NSItemProvider) { /* … */ }
    private func showPreview(at url: URL) { /* … */ }
}

로드 계열 메서드가 여럿인데, 메모리 관점에서 선택이 갈린다. (UTType을 받는 …(for:) 계열은 iOS 16+이고, 그 이전은 문자열 식별자를 받는 …(forTypeIdentifier:) 원형을 쓴다.)

익스텐션에서는 파일 표현을 기본으로 삼아야 한다. 사진·동영상은 수십~수백 MB가 될 수 있고, Data로 받으면 그 순간 메모리 한도를 넘는다(Q7).

조회 계열도 알아둘 만하다 — registeredTypeIdentifiers는 등록 순서대로 반환하므로 제공자가 선호하는 순서를 담고 있다. hasRepresentationConforming(toTypeIdentifier:fileOptions:)는 open-in-place 동작까지 고려해 판정한다.

반대 방향 — 익스텐션이 결과를 host에 돌려줄 때는 우리가 프로바이더를 만든다. 이때 여러 포맷을 등록해두면 소비자가 요청한 것만 계산되므로 효율적이다.

// 하나의 프로바이더가 여러 포맷을 지연 제공한다
let provider = NSItemProvider()

provider.registerDataRepresentation(for: .png, visibility: .all) { completion in
    // PNG를 요청받았을 때만 실행된다
    completion(self.renderedImage.pngData(), nil)
    return nil        // Progress를 반환할 수 있다
}
provider.registerDataRepresentation(for: .jpeg, visibility: .all) { completion in
    // JPEG를 요청받았을 때만 실행된다 — 둘 다 미리 만들지 않는다
    completion(self.renderedImage.jpegData(compressionQuality: 0.9), nil)
    return nil
}
provider.registerFileRepresentation(for: .movie, visibility: .all) { completion in
    completion(self.exportedMovieURL, true, nil)   // true = 제자리 열기 허용
    return nil
}

실험 · 도구

host가 실제로 무엇을 보내는지 확인하는 것이 개발의 출발점이다. host마다 제공하는 타입이 다르다.

/// 들어온 아이템의 실체를 전부 덤프한다 — 개발 초기에 필수
private func dumpInputItems() {
    guard let items = extensionContext?.inputItems as? [NSExtensionItem] else { return }
    let log = Logger(subsystem: "com.example.shop", category: "share")

    for (i, item) in items.enumerated() {
        log.notice("item[\(i, privacy: .public)] attachments=\(item.attachments?.count ?? 0, privacy: .public)")
        log.notice("  attributedTitle=\(item.attributedTitle?.string ?? "nil", privacy: .public)")

        for (j, p) in (item.attachments ?? []).enumerated() {
            // 등록 순서 = 제공자가 선호하는 순서
            log.notice("  provider[\(j, privacy: .public)] types=\(p.registeredTypeIdentifiers.joined(separator: ", "), privacy: .public)")
            log.notice("    suggestedName=\(p.suggestedName ?? "nil", privacy: .public)")
        }
    }
}

# 여러 host에서 공유를 시도하며 타입 목록을 비교한다
log stream --predicate 'subsystem == "com.example.shop" AND category == "share"' --style compact

# 관찰 포인트:
#   사진 앱 → public.jpeg, public.heic 등 이미지 타입
#   Safari  → public.url, public.plain-text, 그리고 웹 페이지 타입
#   파일 앱 → public.file-url 과 실제 파일 타입
#   → host마다 다르므로 "이미지겠지" 하고 하드코딩하면 특정 앱에서만 동작한다

메모리 차이도 직접 재볼 수 있다.

// Data 표현과 파일 표현의 메모리 차이를 비교한다
func compareLoadStrategies(_ provider: NSItemProvider) {
    let before = currentFootprintBytes() ?? 0        // 19장 Q5의 phys_footprint

    // (A) Data — 파일 크기만큼 메모리가 는다
    _ = provider.loadDataRepresentation(for: .movie) { data, _ in
        let after = currentFootprintBytes() ?? 0
        print("Data 로드: +\((after - before) / 1_048_576) MB, 크기 \(data?.count ?? 0)")
    }

    // (B) 파일 — 메모리는 거의 그대로다
    _ = provider.loadFileRepresentation(for: .movie) { url, _, _ in
        let after = currentFootprintBytes() ?? 0
        print("파일 로드: +\((after - before) / 1_048_576) MB, 경로 \(url?.lastPathComponent ?? "-")")
    }
}

프로젝트 적용

실무 규칙 다섯.

• 완료 블록에서 UI를 건드리지 않는다. 반드시 메인 큐로 넘긴다. 이건 문서가 명시적으로 경고하는 항목이고, 안 지키면 간헐적으로만 깨지는 버그가 된다.
• 큰 데이터는 파일 표현으로. 익스텐션에서 Data 로드는 메모리 사고의 1순위 원인이다.
• 임시 파일을 즉시 옮긴다. loadFileRepresentation이 주는 URL은 완료 블록이 끝나면 유효하지 않을 수 있다. 블록 안에서 공유 컨테이너로 이동시킨다.
• 타입을 넓게 물어보고 좁게 처리한다. public.jpeg가 아니라 public.image로 물어보면 준수 트리 덕분에 PNG·HEIC까지 잡힌다(Q5).
• 여러 host에서 테스트한다. 사진·Safari·파일·메모 앱에서 각각 공유해보면 타입 구성이 다르다는 것을 바로 알 수 있다.

꼬리 질문

let preferred: [UTType] = [.heic, .png, .jpeg, .image]   // 앞에서부터 시도
for type in preferred where provider.hasItemConformingToTypeIdentifier(type.identifier) {
    load(provider, as: type)
    break
}

Q5. UTI는 무엇이며 시스템은 파일 타입을 어떻게 판단하는가?

CS 원리

타입 식별 문제의 본질은 같은 것을 여러 이름으로 부르는 상황이다. 확장자·MIME 타입·매직 넘버가 각각 다른 체계이고 서로 1:1 대응도 아니다. 이걸 방치하면 모든 코드가 모든 별칭을 알아야 한다.

UTI는 정규 표현(canonical representation)을 도입해 이를 푼다. 별칭에서 정규형으로 가는 매핑을 시스템이 관리하고, 앱은 정규형만 다룬다.

두 번째 설계 결정이 준수 트리다. 단순 열거형이라면 "이미지면 다 받겠다"를 표현할 수 없어 모든 이미지 포맷을 나열해야 한다. 준수 관계를 도입하면 상위 타입으로 물어보는 것이 가능해진다.

public.jpeg ─┬─→ public.image ─┬─→ public.data ──→ public.item
             │                 └─→ public.content
public.png ──┘   (형제: public.tiff, public.heic)
public.audio ────→ public.data
public.text  ────→ public.data

• public.item — 최상위. 파일·폴더·심링크·POSIX 파이프까지 모든 파일시스템 객체.
• public.data — 바이트 시퀀스 일반.
• public.content — 파일시스템상 실체가 아니라 "사용자가 신경 쓰는 것"이라는 의미.

이 구조가 Swift/ObjC의 프로토콜 준수와 같은 모양이라는 점이 이해에 도움이 된다. public.image를 요구하는 것은 some Image를 요구하는 것과 같고, 다중 상속이 가능하다는 것은 여러 프로토콜을 동시에 채택하는 것과 같다.

확장자 기반 판정이라는 선택은 성능과 권한의 타협이다. 내용을 읽어 판별하는 것(매직 넘버 검사)이 정확하지만, 파일 목록을 표시할 때마다 수백 개 파일을 열어야 한다면 비용이 감당되지 않는다. 게다가 샌드박스 환경에서는 읽기 권한 자체가 없는 경우가 많다. 그래서 이름만 보고 판단한다.

이 선택의 귀결이 실무에서 자주 문제를 만든다 — 확장자가 틀리면 타입도 틀리고, 확장자가 없으면 시스템이 dyn 네임스페이스의 임시 식별자를 만들어낸다.

iOS에서는

UTI를 다루는 두 축이 있다 — 선언과 지원이다. Apple 문서가 명확히 구분한다.

• 선언(declare) — "이 타입이 존재한다."
• 지원(support) — "누가 선언했든 내가 열 수 있다."

선언은 다시 둘로 갈린다.

imported 타입을 static var로 선언해야 하는 이유가 중요하다 — 원 소유 앱이 설치되면 시스템이 더 권위 있는 선언으로 런타임에 갈아끼우는데, 상수로 잡아두면 그 갱신을 못 받는다.

import UniformTypeIdentifiers

extension UTType {
    /// exported — 우리가 정의한 타입. 우리가 권위자이므로 상수로 둬도 된다.
    static let shopReceipt = UTType(exportedAs: "com.example.shop.receipt")

    /// imported — 남의 타입. 반드시 계산 프로퍼티여야 런타임 갱신을 받는다.
    static var thirdPartyDoc: UTType {
        UTType(importedAs: "com.othervendor.document")
    }
}

예약 네임스페이스도 알아둬야 한다 — 직접 만들면 안 되는 것들이다.

• public — Apple 표준 타입.
• dyn — OS가 생성하는 호환 shim. 릴리스마다 값이 바뀌므로 하드코딩 금지.
• com.example — 예제·샘플 전용.
• com.apple — Apple 전용.

식별자는 대소문자 무시 ASCII의 역-DNS다. 그리고 확장자는 3글자에 얽매일 필요가 없다 — 문서는 오히려 충돌 회피를 위해 긴 확장자를 권장한다.

익스텐션에서 UTI가 쓰이는 자리는 셋이다.

1. NSExtensionActivationRule — 시스템이 "이 익스텐션을 공유 시트에 띄울까"를 판정할 때. UTI-CONFORMS-TO 연산자가 준수 트리를 타고 판정한다.
2. NSItemProvider — registeredTypeIdentifiers와 hasItemConformingToTypeIdentifier(Q4).
3. 문서 타입 선언 — 우리 앱이 어떤 파일을 열 수 있는지.

NSExtensionActivationRule은 미리 정의된 키 방식과 술어 방식 둘 다 지원한다. 미리 정의된 키가 훨씬 간단하다.

<key>NSExtensionAttributes</key>
<dict>
  <key>NSExtensionActivationRule</key>
  <dict>
    <key>NSExtensionActivationSupportsImageWithMaxCount</key><integer>10</integer>
    <key>NSExtensionActivationSupportsMovieWithMaxCount</key><integer>1</integer>
    <key>NSExtensionActivationSupportsWebURLWithMaxCount</key><integer>1</integer>
  </dict>
</dict>

주요 키는 이렇다 — SupportsText, SupportsWebURLWithMaxCount, SupportsWebPageWithMaxCount(JS 접근 시 필수이고 0이 아니어야 함), SupportsImageWithMaxCount, SupportsMovieWithMaxCount, SupportsFileWithMaxCount, SupportsAttachmentsWithMaxCount/MinCount. 값은 처리 가능한 최대 개수이고, 지원하지 않으면 0이거나 키를 뺀다.

실험 · 도구

준수 트리를 직접 탐색해보면 구조가 손에 잡힌다.

import UniformTypeIdentifiers

// 준수 관계 확인 — 상위 타입으로 물어보면 하위가 전부 잡힌다
print(UTType.jpeg.conforms(to: .image))     // true
print(UTType.jpeg.conforms(to: .data))      // true — 트리를 타고 올라간다
print(UTType.jpeg.conforms(to: .content))   // true — 다중 상속
print(UTType.png.conforms(to: .jpeg))       // false — 형제 관계

// 상위 타입 목록을 재귀로 펼쳐본다
func printTree(_ t: UTType, depth: Int = 0) {
    print(String(repeating: "  ", count: depth) + t.identifier)
    for parent in t.supertypes.filter({ $0 != t }) where depth < 3 {
        printTree(parent, depth: depth + 1)
    }
}
printTree(.heic)

// 확장자 ↔ UTI ↔ MIME 상호 변환
print(UTType(filenameExtension: "jpg")?.identifier)          // "public.jpeg"
print(UTType(filenameExtension: "jpeg")?.identifier)         // "public.jpeg" — 같은 값으로 정규화
print(UTType(mimeType: "image/jpeg")?.identifier)            // "public.jpeg"
print(UTType.jpeg.preferredFilenameExtension)                // "jpeg"
print(UTType.jpeg.preferredMIMEType)                         // "image/jpeg"

// 확장자가 없거나 알 수 없으면 dyn 네임스페이스가 나온다
print(UTType(filenameExtension: "zzzunknown")?.identifier)   // "dyn.ah62d4..." ← 하드코딩 금지

"시스템은 파일을 열어보지 않는다"는 것도 실험으로 확인된다.

// PNG 데이터를 .txt 확장자로 저장하면 시스템은 텍스트로 판단한다
let pngData = UIImage(named: "logo")!.pngData()!
let url = FileManager.default.temporaryDirectory.appendingPathComponent("logo.txt")
try pngData.write(to: url)

let values = try url.resourceValues(forKeys: [.contentTypeKey])
print(values.contentType?.identifier)   // "public.plain-text" ← 내용은 PNG인데도
//   → 시스템은 바이트를 읽지 않고 확장자만 봤다.
//   → 그래서 사용자가 준 파일의 확장자를 믿으면 안 되는 경우가 생긴다.

# 커맨드라인으로 UTI 확인
mdls -name kMDItemContentType -name kMDItemContentTypeTree ~/Desktop/photo.jpg

# 시스템에 등록된 타입 선언 확인 (macOS)
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister \
  -dump | grep -A5 "com.example.shop.receipt"

프로젝트 적용

UTI 관련 실무 규칙 다섯.

• 활성화 규칙은 넓게, 처리는 좁게. SupportsImageWithMaxCount로 이미지 전체를 받되, 실제 처리에서 지원 포맷을 확인하고 안 되면 친절한 안내를 보여준다. 규칙을 너무 좁히면 공유 시트에 아예 안 나타나 사용자가 우리 앱이 지원하는지조차 모른다.
• TRUEPREDICATE를 CI에서 차단한다(Q2의 스크립트). 리젝 사유이면서 발견이 늦다.
• imported 타입은 static var로. 상수로 두면 원 소유 앱 설치 시 갱신을 못 받는다.
• dyn 식별자를 하드코딩하지 않는다. 릴리스마다 값이 바뀐다.
• 우리 타입을 선언할 때 준수 관계를 신중히 정한다. 일반 파일이면 public.data에, OS가 파일처럼 다뤄야 할 디렉터리면 com.apple.package에 준수시킨다. public.json 같은 구현 세부 준수는 선택이고, 포맷이 바뀔 여지가 있거나 남이 의존하길 원치 않으면 빼는 편이 낫다.

꼬리 질문

/// 확장자를 믿지 않고 매직 넘버로 확인한다
func looksLikePNG(_ url: URL) -> Bool {
    guard let h = try? FileHandle(forReadingFrom: url) else { return false }
    defer { try? h.close() }
    let magic = Data([0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A])
    return (try? h.read(upToCount: 8)) == magic
}

Q6. App-extension-safe API를 어기면 언제 터지는가?

CS 원리

여기서 작동하는 원리는 정적 링크 시점의 전이적 의존이다. 익스텐션이 프레임워크 F를 링크하면, F가 참조하는 심볼이 전부 익스텐션의 의존성이 된다. 우리가 그 코드 경로를 실행하지 않아도, 바이너리에는 그 심볼 참조가 남아 있다.

Apple의 검사는 바이너리 수준에서 이뤄지므로 "호출 안 하니까 괜찮다"가 통하지 않는다. 실행 여부가 아니라 링크 여부가 기준이다.

왜 이렇게 엄격한지는 보안 모델의 일관성으로 설명된다. 익스텐션은 host app의 컨텍스트 안에서 실행되므로, 익스텐션이 할 수 있는 일은 host의 신뢰 경계에 영향을 준다. 커스텀 키보드가 카메라를 열 수 있다면 사용자가 어떤 앱에서 타이핑하든 위험해진다. 그래서 "실행 시점에 막는다"가 아니라 "애초에 링크할 수 없게 한다"는 접근을 택했다.

이건 P0 03장의 샌드박스 개념과 층이 다르다는 점도 짚을 만하다.

• 샌드박스 — 런타임에 커널이 강제. 파일 접근, 네트워크 등.
• app-extension-safe — 빌드·심사 시점에 강제. API 표면 자체를 제한.

두 층이 함께 작동해서, 런타임 우회도 어렵고 빌드 우회도 어렵게 만든다.

iOS에서는

금지 목록을 구체적으로 정리하면 이렇다.

UIBackgroundModes 키가 익스텐션 Info.plist에 있으면 그 자체로 리젝이다. VoIP·백그라운드 오디오 같은 모드를 쓰려고 키를 넣으면 안 된다.

공유 코드 구성에서 부딪히는 지점이 embedded framework다. Apple이 정한 정식 코드 공유 수단인데, 그 프레임워크 전체가 app-extension-safe여야 익스텐션이 링크할 수 있다.

금지 API를 쓰는 프레임워크는 컨테이닝 앱에서만 안전하게 링크할 수 있고, 익스텐션과는 그 코드를 공유할 수 없다. Q1 꼬리질문에서 본 분리 전략(프레임워크 분할, 프로토콜 경계, 조건부 컴파일)이 여기서 필요해진다.

빌드 설정에서 놓치기 쉬운 함정도 있다.

• Copy Files 빌드 페이즈 목적지 — 반드시 "Frameworks". "SharedFramework"를 고르면 앱스토어가 제출을 리젝한다.
• 아키텍처 — embedded framework를 링크하는 컨테이닝 앱은 arm64(iOS)를 포함해야 한다. 미포함 시 리젝.

실험 · 도구

가장 중요한 것은 경고를 에러로 승격하는 것이다. 경고로 두면 반드시 새어 나간다 — 21장 Q6에서 본 "조용한 실패"와 같은 구조다.

# 1) 빌드 설정 확인 — 익스텐션 타깃과 공유 프레임워크 타깃 모두 켜야 한다
xcodebuild -showBuildSettings -target ShareExtension \
  | grep APPLICATION_EXTENSION_API_ONLY
#   APPLICATION_EXTENSION_API_ONLY = YES  ← 이래야 정상

# 공유 프레임워크도 확인 — 여기를 빼먹는 경우가 많다
xcodebuild -showBuildSettings -target SharedCore \
  | grep APPLICATION_EXTENSION_API_ONLY

# 2) CI 검증 — 하나라도 NO 면 실패시킨다
for t in ShareExtension NotificationExtension SharedCore; do
  v=$(xcodebuild -showBuildSettings -target "$t" 2>/dev/null \
      | awk -F' = ' '/APPLICATION_EXTENSION_API_ONLY/{print $2}' | tr -d ' ')
  [ "$v" = "YES" ] || { echo "❌ $t: APPLICATION_EXTENSION_API_ONLY=$v"; exit 1; }
done

# 3) 빌드 로그에서 관련 경고를 잡아낸다
xcodebuild build 2>&1 | grep -i "not safe for use in application extensions" \
  && { echo "❌ app-extension-safe 위반"; exit 1; }

바이너리 수준 검사도 가능하다. 링크된 심볼을 직접 들여다본다.

# 익스텐션 바이너리가 금지 심볼을 참조하는지 확인
EXT="YourApp.app/PlugIns/ShareExt.appex/ShareExt"

nm -u "$EXT" | grep -E 'UIApplication|sharedApplication' \
  && echo "⚠️ UIApplication 참조 발견 — 확인 필요"

# 링크된 라이브러리 목록 — 예상 밖의 프레임워크가 있는지 본다
otool -L "$EXT"
#   /System/Library/Frameworks/UIKit.framework/UIKit  ← 정상
#   @rpath/SharedCore.framework/SharedCore            ← 우리 프레임워크
#   @rpath/SomeAnalyticsSDK.framework/...             ← ⚠️ 이게 안전한가?

컴파일 타임에 잡아내는 방법도 있다. Swift에서는 가용성 검사로 일부가 걸린다.

// APPLICATION_EXTENSION_API_ONLY=YES 인 타깃에서는 컴파일 에러가 난다
func openSettings() {
    // ❌ 'shared' is unavailable in application extensions for iOS
    UIApplication.shared.open(URL(string: UIApplication.openSettingsURLString)!)
}

// ✅ 대안 — 익스텐션에서는 컨텍스트를 통하거나, 아예 다른 흐름을 설계한다
func requestOpenSettings() {
    // ⚠️ 레거시 Today 위젯만 이 경로를 쓸 수 있다. WidgetKit 위젯은 widgetURL/Link 딥링크.
    extensionContext?.open(URL(string: "shop://settings")!, completionHandler: nil)
}

// 공유 코드에서 앱 전용 기능이 필요하면 프로토콜로 경계를 만든다 (Q1 꼬리질문)
protocol AppCapabilities {
    func openExternalURL(_ url: URL)
}
// 구현은 앱 타깃에만 둔다 — 프레임워크는 프로토콜만 안다

프로젝트 적용

실무 규칙 다섯.

• 모든 관련 타깃에 설정을 켠다. 익스텐션뿐 아니라 익스텐션이 링크하는 모든 프레임워크에 켜야 한다. 이걸 빼먹는 것이 1순위 실수다.
• 경고를 빌드 실패로 만든다. CI에서 해당 경고 문자열을 잡아 실패시킨다. 사람이 로그를 읽어 발견하기를 기대하면 안 된다.
• SDK 도입 시 익스텐션 지원 여부를 확인한다. 21장 Q3(dSYM), 23장 Q2(privacy manifest)에 이어 세 번째 도입 기준이다. 익스텐션에서 쓸 SDK라면 app-extension-safe인지 문서로 확인한다.
• 공유 프레임워크는 처음부터 안전하게 설계한다. 나중에 분리하는 것보다 훨씬 싸다. UI 프레임워크 의존을 최소화하고 순수 로직 위주로 두면 자연스럽게 안전해진다 — P0 17장의 관심사 분리가 여기서도 이득을 준다.
• Copy Files 목적지를 "Frameworks"로. 한 번 잘못 고르면 심사에서야 발견된다.

꼬리 질문

FW="Carthage/Build/iOS/SomeSDK.framework/SomeSDK"

# 빌드 시 app-extension-safe로 컴파일됐는지 확인
otool -l "$FW" | grep -A3 LC_BUILD_VERSION

# 금지 심볼 참조 확인
nm -u "$FW" | grep -E 'UIApplication|sharedApplication|AVCaptureDevice'

Q7. 익스텐션의 자원 예산은 왜 앱보다 빡빡한가?

CS 원리

여기서 작동하는 것은 자원 공정성과 격리의 트레이드오프다. P0 01장에서 본 per-process 메모리 한도가 익스텐션에서 훨씬 낮게 설정되는 이유는 셋이다.

• 동시 실행 가능성. 익스텐션이 도는 동안 host app도 살아 있어야 한다. 두 프로세스가 각각 앱 수준 예산을 쓰면 시스템 메모리가 감당하지 못한다.
• 사용자 인식 귀속. 익스텐션이 죽으면 사용자는 host 앱이 이상하다고 느낀다. 그래서 시스템은 익스텐션을 먼저, 공격적으로 종료해 host를 보호한다.
• 수명이 짧다는 전제. 익스텐션은 몇 초짜리 작업이므로 큰 예산이 필요 없다는 설계 가정이 깔려 있다.

여기에 런루프 소유권 문제가 더해진다. 익스텐션은 host의 UI 컨텍스트 안에 뷰를 띄우는데, 메인 런루프를 소유하지 않는다. 20장에서 본 "메인스레드를 막으면 앱이 멈춘다"가 여기서는 남의 앱을 멈추게 하는 문제가 된다. 그래서 익스텐션에서의 메인스레드 블로킹은 앱에서보다 죄질이 무겁다.

19장에서 본 종료 메커니즘도 그대로 적용된다 — 메모리 한도 초과는 EXC_RESOURCE (MEMORY) 경고 후 Jetsam 종료로, 시간 초과는 워치독 계열로 나타난다. 다만 임계값이 훨씬 낮다.

iOS에서는

제약을 항목별로 정리하면 이렇다.

실험 · 도구

익스텐션의 실제 여유 메모리는 런타임에 확인할 수 있다. 이것이 고정 수치에 의존하지 않는 유일한 방법이다.

import Foundation
import os

enum MemoryBudget {
    /// 지금 이 프로세스가 더 쓸 수 있는 메모리 (바이트)
    static var available: Int { os_proc_available_memory() }

    /// 현재 footprint — Jetsam이 판정에 쓰는 값 (19장 Q5)
    static var footprint: UInt64 {
        var info = task_vm_info_data_t()
        var count = mach_msg_type_number_t(
            MemoryLayout<task_vm_info_data_t>.size / MemoryLayout<natural_t>.size)
        let kr = withUnsafeMutablePointer(to: &info) {
            $0.withMemoryRebound(to: integer_t.self, capacity: Int(count)) {
                task_info(mach_task_self_, task_flavor_t(TASK_VM_INFO), $0, &count)
            }
        }
        return kr == KERN_SUCCESS ? info.phys_footprint : 0
    }

    /// 작업 전 여유를 확인하고 규모를 조절한다
    static func canAfford(_ bytes: Int, safetyMargin: Double = 0.5) -> Bool {
        Double(available) * safetyMargin > Double(bytes)
    }

    static func log(_ stage: String) {
        Logger(subsystem: "com.example.shop", category: "memory").notice("""
            [\(stage, privacy: .public)] \
            footprint=\(footprint / 1_048_576, privacy: .public)MB \
            available=\(available / 1_048_576, privacy: .public)MB
            """)
    }
}

// 익스텐션 시작 시 로그를 남기면 실제 예산이 보인다
MemoryBudget.log("extension start")
// [extension start] footprint=12MB available=108MB
//   → 이 기기·이 익스텐션의 실제 한도가 약 120MB임을 런타임에 알 수 있다.
//     하드코딩하지 말고 이 값으로 판단한다.

이미지 처리처럼 메모리를 많이 쓰는 작업은 여유에 맞춰 규모를 조절한다.

import ImageIO
import UniformTypeIdentifiers

/// 원본 디코딩 없이 다운샘플링 — 익스텐션의 필수 기법 (P0 08장 Q5)
func downsample(at url: URL, maxPixel: Int) -> CGImage? {
    let srcOptions = [kCGImageSourceShouldCache: false] as CFDictionary
    guard let src = CGImageSourceCreateWithURL(url as CFURL, srcOptions) else { return nil }

    let options = [
        kCGImageSourceCreateThumbnailFromImageAlways: true,
        kCGImageSourceShouldCacheImmediately: true,
        kCGImageSourceCreateThumbnailWithTransform: true,
        kCGImageSourceThumbnailMaxPixelSize: maxPixel,
    ] as CFDictionary

    // 원본 전체를 메모리에 올리지 않고 축소본만 만든다
    return CGImageSourceCreateThumbnailAtIndex(src, 0, options)
}

// 여유에 따라 목표 크기를 정한다
func safeMaxPixel() -> Int {
    let available = MemoryBudget.available
    switch available {
    case ..<(30 * 1_048_576):   return 512     // 여유가 적으면 작게
    case ..<(80 * 1_048_576):   return 1024
    default:                    return 2048
    }
}

# 익스텐션의 메모리 한도 초과를 실제로 관찰한다
# 1) 실기기에서 익스텐션을 실행하고 큰 이미지를 계속 로드
# 2) 종료된 뒤 기기의 분석 데이터에서 리포트를 확인한다
#    설정 › 개인정보 보호 및 보안 › 분석 및 향상 › 분석 데이터
#    → ShareExt-...-JetsamEvent 또는 EXC_RESOURCE 리포트

# 리포트에서 실제 한도를 확인한다 (19장 Q5)
grep -E "Exception (Type|Subtype|Message)" ShareExt-*.ips
#   Exception Type:    EXC_RESOURCE
#   Exception Subtype: MEMORY
#   Exception Message: Memory limit exceeded (Limit 120 MB)
#     ↑ 여기서 실제 값을 확인할 수 있다. 다만 이 값에 의존하지는 말 것.

# Instruments로 프로파일링 — 익스텐션 scheme에 host를 지정해야 붙는다 (Q1)

프로젝트 적용

익스텐션 성능 설계 원칙 여섯.

• 익스텐션을 얇게 만든다. 받아서 저장하고 끝낸다. 변환·업로드·인덱싱 같은 무거운 일은 공유 컨테이너에 표시만 남기고 앱이 처리한다(Q3).
• 파일은 메모리에 올리지 않는다. loadFileRepresentation + moveItem 조합이 기본이다(Q4).
• 이미지는 반드시 다운샘플링한다. 원본 디코딩은 익스텐션에서 가장 흔한 사망 원인이다.
• 메인스레드를 막지 않는다. 앱에서보다 더 엄격히 지킨다 — 남의 앱을 멈추게 하기 때문이다. 20장 Q5의 숨은 블로킹 목록이 그대로 적용되고, 특히 동기 네트워킹은 절대 금지다.
• 런타임 여유로 판단한다. 고정 수치를 하드코딩하지 말고 os_proc_available_memory()로 확인한다.
• 익스텐션을 별도 지표 축으로 감시한다. 18장 Q5의 태그에 process=extension을 넣으면 "본 앱은 멀쩡한데 익스텐션만 죽는" 상황이 보인다. 19장 Q5의 EXC_RESOURCE (MEMORY) 경고가 여기서 특히 유용한 조기 신호다.

꼬리 질문

// 익스텐션용 최소 계측 — 완료 전에 반드시 기록한다
final class ExtensionMetrics {
    private let start = ContinuousClock.now
    private var peakFootprint: UInt64 = 0

    func sample() { peakFootprint = max(peakFootprint, MemoryBudget.footprint) }

    /// completeRequest 호출 "전에" 부른다 — 이후는 실행 보장이 없다 (Q1)
    func finish(outcome: String) {
        let elapsed = ContinuousClock.now - start
        SharedStorage.appendPendingEvent([
            "kind": "extension.run",
            "process": Bundle.main.bundleIdentifier ?? "?",
            "duration_ms": elapsed.milliseconds,
            "peak_mb": peakFootprint / 1_048_576,
            "available_mb": MemoryBudget.available / 1_048_576,
            "outcome": outcome,
        ])
    }
}

출처 · 참고자료