Apple 플랫폼 매트릭스: 어떤 타겟이 어떤 앱을 받을 자격이 있는가

Apple은 개발자가 단일 Swift 코드베이스로 타겟할 수 있는 여섯 개의 소비자 컴퓨팅 플랫폼을 출시합니다: iPhone, iPad, Mac, Watch, Vision, TV. SwiftUI와 iOS 26 툴체인은 이들 중 어느 것이든 추가하는 것을 Xcode에서 체크박스 작업으로 만들어줍니다. 그 체크박스가 함정입니다. 추가되는 모든 타겟은 기능이 아니라 의무입니다. 각각이 디자인, 테스트, 접근성, 런타임 모델, 그리고 지속적인 유지보수의 표면적을 확장합니다. 앱에 알맞은 타겟의 수는 프레임워크가 허용하는 것보다 적습니다.

클러스터의 앱들은 서로 다른 조합으로 출시됩니다. Return은 여섯 개 플랫폼(iPhone, iPad, Mac, Watch, Vision, TV)에 출시됩니다. Get Bananas는 네 개(iPhone, iPad, Mac, Watch)에 출시됩니다. Reps와 Water는 사전 출시 단계로 여러 개의 컴파일된 타겟을 가지고 있지만 출시 전에 좁힐 예정입니다. Ace Citizenship과 Tappy Color는 각각 iPhone에만 출시됩니다. 같은 개발자, 같은 툴체인, 여섯 개의 다른 플랫폼 결정. 결정에는 규칙이 따르고, 그 규칙들은 공유된 지도를 가질 자격이 있습니다.

이 글은 그 규칙들을 명명합니다. 각 플랫폼은 “컴파일된다”가 아니라 그 플랫폼이 진정으로 더해주는 구체적인 사용자 가치를 통해 포함될 자격을 얻습니다. 출시에서 살아남는 매트릭스는 각 타겟이 스스로를 정당화하거나 잘려 나간 후에 남은 것입니다.

TL;DR

• 여섯 개 플랫폼, 여섯 개의 다른 의무: iPhone(기본값), iPad(사이즈 클래스 적응), Mac(윈도우/메뉴/키보드 관용구), Watch(런타임 계약), Vision(공간 멘탈 모델), TV(포커스 엔진).
• 추가되는 모든 타겟은 테스트 표면, 디자인 작업, 접근성, 그리고 지속적인 출시 조율을 더합니다. Xcode의 “플랫폼 추가” 체크박스는 그 비용을 숨깁니다.
• 올바른 테스트는 기술적 테스트가 아니라 사용자 가치 테스트입니다. 사용자가 그 플랫폼에서 이 앱을 실행함으로써 진정으로 혜택을 받는가? 답이 “거기서도 작동해요”라면, 잘라내십시오.
• 대부분의 앱은 한 개에서 세 개의 플랫폼에 출시해야 합니다. 네 개에서 여섯 개는 흔하지 않으며, 모든 플랫폼이 다른 플랫폼이 제공할 수 없는 사용자 가치를 진정으로 더할 때만 자리를 얻습니다.

iPhone은 기본값입니다

모든 Apple 앱은 iPhone에서 시작하거나, 시작하지 않습니다. iPhone은 가장 큰 설치 기반, 가장 정교한 접근성 표면, App Store를 통한 가장 강력한 배포 경로, 그리고 정전(canonical) SwiftUI 디자인 언어를 가지고 있습니다. 제가 출시한 모든 클러스터 앱은 iPhone에서 실행됩니다. iPhone-우선이 아닌 디자인으로 출시된 것은 하나도 없습니다.

iPhone에 대한 사용자 가치 테스트: 사용자가 이 앱을 폰에서 열까요? 거의 모든 소비자 카테고리에서 답은 예입니다. 헬스 및 피트니스 앱은 폰에서 살아갑니다. 생산성 도구는 폰에서 살아갑니다. 게임은 폰에서 살아갑니다. 커뮤니케이션 도구는 폰에서 살아갑니다. 기본값이 iPhone인 이유는 폰이 사용자가 있는 곳이기 때문입니다.

예외는 개발 도구(Xcode, Terminal)와 화면 공간이 필요한 크리에이티브 도구(Final Cut, Logic)입니다. 이들은 Mac에서 시작하고, 명확한 핸드오프가 있을 때만 iPhone 컴패니언을 얻습니다(운동 중 Watch 심박수를 폰이 차트로 보여주는 경우, Camera Continuity). 소비자 소프트웨어에서 iPhone 우선은 논쟁의 대상이 아닙니다.

iPad는 픽셀이 더 많은 iPhone이 아닙니다

Catalyst는 사이즈 클래스 브레이크포인트로 UIKit iPhone 앱을 iPad에 출시할 수 있게 만들었습니다. SwiftUI는 @Environment(\.horizontalSizeClass)와 NavigationSplitView를 통해 같은 일을 더 쉽게 만들었습니다. “iPad에 출시”의 기술적 비용은 낮습니다. 제품 비용은 앱이 실제로 iPad의 더 큰 캔버스를 받을 자격이 있는지에 대한 질문입니다.

세 가지 iPad-예 신호:

앱이 사용자가 더 많은 화면을 원하는 콘텐츠를 읽거나 만듭니다. 읽기 앱(Books, 뉴스, 만화, 긴 문서). 그리기/페인팅 앱(Procreate). Apple Pencil을 사용한 노트 작성(Notability, GoodNotes). Get Bananas가 iPad 자리를 얻는 이유는 섹션이 있는 쇼핑 목록이 좁은 화면보다 넓은 캔버스에서 더 유용하기 때문입니다. iPad 디자인은 같은 섹션 목록을 더 큰 영역에 적응시킵니다.

앱이 iPhone 또는 Mac과 핸드오프 가치를 가지고 있습니다. Apple Notes, Reminders, Mail은 모두 사용자가 연속성을 기대하기 때문에 iPad 자리를 얻습니다. iPad의 Return 명상 기록도 같은 이유로 자리를 얻습니다. 사용자는 iPhone에서 시작하고 타이머가 실행되는 동안 iPad를 흘끗 봅니다.

앱이 iPad 네이티브 입력 어포던스를 가지고 있습니다. 스케치/필기를 위한 Apple Pencil. 더 큰 표면에서의 멀티 핑거 제스처. 타일 기반 레이아웃에서 혜택을 얻는 Stage Manager 워크플로. 어포던스가 iPhone에 존재하지 않는다면 iPad 타겟은 자리를 얻습니다.

iPad-아니오 신호:

규모에서 추가 가치가 없는 단일 컬럼 콘텐츠. 명상 타이머의 주요 뷰는 카운트와 버튼 하나입니다. iPad는 둘 다 더 크게 만들 뿐, 그것은 기능이 아닙니다. 빠른 로깅 수분 추적기도 마찬가지입니다. 더 넓은 화면이 5초간의 로깅 세션 동안 사용자가 하는 일을 바꾸지는 않습니다.

iPhone 전용 하드웨어에 의존하는 앱(Lock Screen, Dynamic Island, 특정 iPhone 전용 구성에서의 ProMotion, 특정 카메라 형식). 이러한 디자인 가정은 잘 번역되지 않습니다. 디자인을 다시 만들거나 타겟을 건너뛰십시오.

사용자가 이미 Mac에 더 나은 목적지를 가지고 있는 앱. 키보드 지원이 없는 iPad의 코드 에디터는 Mac 앱의 불구가 된 버전입니다. 디자인이 iPad의 특정 입력 모델에서 자리를 얻지 않는 한 타겟을 건너뛰십시오.

Mac은 윈도우, 메뉴 바, 그리고 키보드 관용구입니다

Mac Catalyst 또는 “Designed for iPad”를 통해 Mac에 출시된 SwiftUI 앱은 진정한 Mac 앱을 생산하지 않은 채 macOS에서 실행됩니다. 진정한 Mac 앱은 윈도우 크기 조정 시맨틱, 메뉴 바(SwiftUI의 Commands(content:)), 키보드 단축키, macOS 파일 피커, Finder와의 드래그 앤 드롭, 그리고 Mac 네이티브 공유를 존중합니다. 이 중 어느 것이라도 건너뛰면 Mac 사용자가 알아채고 판단하는 윈도우 안의 iPad 앱 경험을 만들어냅니다.

Mac-예 신호:

사용자가 앱에서 시간을 보내며 그것이 진정한 데스크톱 윈도우인 것에서 혜택을 얻습니다. Mac의 Get Bananas가 자리를 얻는 이유는 책상에서 긴 쇼핑 목록을 편집하는 사용자가 키보드 탐색이 있는 진정한 윈도우에서 혜택을 얻기 때문입니다. Mac의 Return이 자리를 얻는 이유는 작업 머신에서 명상 타이머를 실행하고 싶어하는 사용자가 진정한 메뉴바 앱이나 특정 모서리에 고정된 윈도우에서 혜택을 얻기 때문입니다.

멀티 윈도우 또는 멀티 도큐먼트 워크플로. 분할 패널이 있는 코드 에디터. 참조 이미지를 나란히 두는 사진 편집기. 스프레드시트. 이들 중 어느 것도 iPad나 iPhone에서 적절한 형태로 살아남지 못합니다. Mac이 올바른 플랫폼입니다.

키보드 주도 상호작용. 키보드를 무시하는 Mac의 SwiftUI 앱은 이름뿐인 Mac 앱입니다. 새로 만들기는 Cmd+N, 닫기는 Cmd+W, 포커스 이동은 Tab, 선택은 화살표 키. 비용은 앱별로 발생합니다. 모든 Mac 타겟에는 충분히 고려된 키보드 표면이 필요합니다.

Mac-아니오 신호:

앱이 윈도우에서 혜택을 받지 않는 작은 단일 작업 도구입니다. 사용자가 하루에 한 번 5분 동안 실행하는 아침 타이머는 Mac 타겟이 필요하지 않습니다. 사용자는 Mac 옆의 iPhone에서 그것을 실행할 수 있습니다.

iPhone 모양의 UI가 근본적으로 번역되지 않는 앱. 카메라 앱. Apple Watch 컴패니언 앱. 입력 모델이 터치 우선이고 키보드/마우스 등가물이 폰을 터치하는 것보다 나쁜 앱.

팀이 지속적인 Mac 전용 유지보수에 전념할 수 없습니다. Mac 출시는 iPhone 출시와 다르게 검토됩니다. macOS 업데이트 주기, Gatekeeper용 서명, 공증, 특히 Mac을 위한 App Store 심사, 이 각각은 팀이 예산을 잡아야 하는 출시 주기 작업을 추가합니다. 팀이 예산을 잡지 않는다면 타겟을 건너뛰십시오.

Apple Watch는 런타임 계약입니다

Watch는 “여기에 출시하라”가 능동적으로 오해를 일으키는 지시인 플랫폼입니다. watchOS 런타임은 백그라운드 작업이 아니라 계약입니다에서 자세히 다룬 Watch의 런타임 모델은 iOS의 것과 근본적으로 다릅니다. 손목이 떨어지면 시스템이 앱을 일시 중단하고, 특정 세션 유형(mindfulness, workout-processing, alarm 등)만 일시 중단 후에 실행될 수 있습니다. 런타임 스토리가 없는 Watch 타겟은 두 번째 사용에서 깨집니다.

Watch-예 신호:

앱이 watchOS 런타임 모델이 인식하는 세션 모양을 가지고 있습니다. 명상 타이머(mindfulness 세션). 피트니스 앱(workout-processing). 알람 시계(alarm). 내비게이션(navigation 세션 유형). Return이 Watch에 출시되는 이유는 명상이 mindfulness에 깔끔하게 매핑되기 때문입니다. Watch 앱은 런타임 계약이 그것을 허용하기 때문에 손목이 떨어져도 타이머를 계속 실행합니다.

사용자가 진정으로 손목을 입력 표면으로 원합니다. 운동 중 심박수 뷰어. 사용자가 폰을 꺼내지 않고 시작하는 타이머. 한 눈에 정보를 표시하는 컴플리케이션. Get Bananas는 iPhone 정전 매장과 짝을 이룬 빠른 목록 확인 표면으로 Watch에 출시됩니다. Reps와 같은 운동 앱은 같은 이유로 Watch 타겟을 얻습니다. 손목에서 세트를 기록하는 것이 주머니에서 폰을 꺼내는 것보다 빠르기 때문입니다.

컴패니언 앱 가치가 실제입니다. 일부 Watch 앱은 주로 iPhone 주도 데이터의 디스플레이로 존재합니다(예: iPhone이 타이머를 실행하고 Watch가 남은 카운트를 보여주는 레시피 타이머). 이들은 크로스 디바이스 동기화가 정직하게 구축되어 있고(Single Source of Truth: SwiftData + MCP + iCloud에서 다룸) Watch 뷰가 미러링을 넘어 실제 작업을 수행할 때만 자리를 얻습니다.

Watch-아니오 신호:

앱이 주장할 수 있는 세션 유형이 없습니다. Watch의 읽기 앱은 이름뿐인 Watch 앱입니다. 사용자는 손목에서 책을 읽을 수 없고, 런타임 모델이 세션을 확장하지 않습니다. 건너뛰십시오.

팀이 watchOS 전용 디버깅에 전념할 수 없습니다. Watch 디버깅은 독특하게 고통스럽습니다. 시뮬레이터 동작은 손목이 떨어지는 조건에서 실제 Apple Watch에서만 드러나는 방식으로 실제 디바이스 동작과 다릅니다. 팀이 하드웨어와 그것을 테스트할 의지를 가지고 있지 않다면, Watch 타겟은 깨진 채로 출시됩니다.

데이터 모델이 1MB의 크로스 디바이스 동기화 봉투에 맞지 않습니다. iPhone에서 Watch로의 크로스 디바이스 동기화는 보통 NSUbiquitousKeyValueStore를 통과합니다(멀티 플랫폼 출시 글에서 다룸). 저장소는 총 1MB + 값당 1MB + 1024개의 키를 가집니다. 앱의 세션 상태가 그 봉투에 맞지 않는다면, Watch 타겟은 다른 동기화 아키텍처가 필요하며, 이는 실제 엔지니어링 투자입니다.

Vision은 공간 멘탈 모델입니다

Vision Pro는 앱이 3D 공간에 떠 있는 평평한 패널로 출시되도록 유혹합니다. 그 패널은 SwiftUI 윈도우이고, visionOS의 SwiftUI는 그것을 출시하는 것을 원클릭 작업으로 만듭니다. 그 패널은 더 나쁜 iPad입니다. 플랫폼의 진정한 가치는 콘텐츠가 패널이 아닌 방 안에 사는 RealityKit과 공간 멘탈 모델에서 다룬 공간 멘탈 모델에서 옵니다.

Vision-예 신호:

앱에 방 안에 있는 것에서 혜택을 얻는 3D 콘텐츠가 있습니다. 사용자가 걸어 다닐 수 있는 가상 조각상. 실제 벽에 놓이는 줄자. 사용자 신체의 거울 이미지에 폼 큐를 투사하는 운동 코치. visionOS에 나타나는 대부분의 클러스터 앱은 네이티브 visionOS 타겟이 아니라 “Designed for iPad” 호환성을 통해 그렇게 합니다. 그 호환성은 사용자에게는 괜찮지만 앱을 Vision 네이티브 경험으로 만들지는 않습니다. RealityKit의 공간 멘탈 모델 글은 플랫폼을 받을 자격이 있다는 것이 그 위에서 실행되는 것 이상을 의미한다고 주장합니다.

핸드 트래킹이 올바른 입력 모델입니다. 핀치-투-그랩, 양손 스케일링, 공중에서 그리기. visionOS는 다른 어떤 플랫폼도 가지고 있지 않은 입력 어포던스를 제공합니다. visionOS 자리를 얻는 앱들은 그것에 의지합니다.

앱이 공간 전용 표면을 처리합니다(Lock Screen 등가물, 몰입형 공간, 장식물). Vision에서 iPhone UI를 그저 띄우는 생산성 앱은 사용자가 디바이스를 사용하는 첫날부터 보이는 노이즈입니다. 사용자가 계속 돌아오게 하는 앱은 공간 표면을 활용하는 앱입니다.

Vision-아니오 신호:

앱이 근본적으로 패널 모양이고 깊이에서 전혀 혜택을 얻지 못합니다. 노트 작성 앱, 채팅 앱, 설정 유틸리티. visionOS는 그들을 실행할 것이고, 사용자는 iPad 대신 visionOS에서 그들을 사용할 이유가 없습니다. 건너뛰십시오.

개발 팀에 visionOS 전용 테스트가 없습니다. visionOS는 가장 작은 설치 기반과 가장 취약한 패턴을 가진 플랫폼입니다. 실제 디바이스 없이 Vision 타겟을 테스트하는 것은 watchOS의 경우보다 더 독특하게 어렵습니다.

프라이버시 및 존재감 우려가 지배적입니다. 건강 정보 공개 앱. 민감한 직장 도구. visionOS 디바이스는 iPhone과 다른 방식으로 가구 구성원 간에 공유됩니다. 사적인 정보를 표면화하는 앱은 iPhone에서와 다른 자세가 필요합니다.

Apple TV는 포커스 엔진입니다

TV 앱은 Siri Remote의 포커스 엔진에 의해 구동됩니다. 사용자는 리모컨으로 포커스 하이라이트를 이동하고, 선택을 위해 누르며, 결코 터치 상호작용을 보지 않습니다. tvOS의 SwiftUI는 .focusable(...) 모디파이어, @FocusState 프로퍼티 래퍼, 그리고 상태 바인딩을 위한 .focused(...)를 통해 이를 지원하지만, 모든 TV 앱은 처음부터 포커스 디자인이 필요합니다. iPhone의 탭 앤 스크롤 모델은 번역되지 않습니다.

TV-예 신호:

앱이 TV 시청 거리에서의 콘텐츠 소비를 위한 것입니다. 스트리밍 비디오(Apple TV+, Netflix). 사진 슬라이드쇼. 사용자가 리모컨으로 제어하는 가족 게임 앱. 사용자는 소파에 있고, 화면은 멀고, 입력은 희소하며, TV가 올바른 플랫폼입니다.

앱에 iPhone에는 없는 “기대어 보는(lean back)” 사용 사례가 있습니다. 사용자가 따라하는 운동 비디오. 사용자가 스토브 옆에서 참조하는 요리 앱. 사용자가 잘 때 듣는 잠자리 이야기. 이들 중 어느 것도 커피 테이블에 세워둔 폰으로는 잘 제공되지 않습니다.

상호작용 모델이 희소하고 포커스 주도적인 내비게이션에 맞습니다. 사용자가 한 번에 하나씩 고르는 항목 목록. 옵션 그리드. 선형 재생 흐름. 그보다 복잡한 어떤 것이라도, 멀티 터치 제스처, 세밀한 텍스트 입력, 드래그 앤 드롭은 tvOS에서 작동하지 않으며 타겟이 잘못되었음을 의미합니다.

TV-아니오 신호:

앱이 텍스트 입력이 필요합니다. 리모컨을 통한 TV 텍스트 입력은 어떤 Apple 플랫폼에서도 가장 나쁜 입력 모델 중 하나입니다. 앱이 검색 박스 이상의 어떤 것이 필요하다면 TV를 건너뛰십시오.

앱의 가치가 사용자의 손이 다른 작업을 위해 자유로워야 한다는 것에 의존합니다. 피트니스 추적. 건강 모니터링. 실시간 협업. TV는 화면이지 웨어러블이 아닙니다.

유지보수 비용이 설치 기반에 비해 너무 높습니다. tvOS는 iOS에 비해 작은 설치 기반을 가지고 있습니다. 개발 비용은 실제입니다(포커스 디자인, 별도의 테스트, tvOS를 위한 App Store 심사). 대부분의 앱에서 수학이 자리를 정당화하지 않습니다. 명상 앱은 사용 사례가 실제로 보상하는 진정한 “소파에 앉아 있는 동안 낮은 밝기로 화면에 두기” 모드가 있을 때만 Apple TV 자리를 얻습니다. 그 모드 없이는, 타이머가 TV의 기대어 보는 패턴에 깔끔하게 매핑되는 앱조차 유지보수 청구서를 받을 자격이 없습니다.

실전에서의 매트릭스

각 클러스터 앱의 실제 매트릭스:

패턴: 각 행은 의도적인 추가만큼 의도적인 잘라냄입니다. Return이 여섯 개 플랫폼에 도달하는 이유는 각각이 특정 사용자 가치 테스트를 통해 정당화되기 때문입니다. iPhone 전용 앱은 다른 어떤 것도 그렇지 않기 때문에 거기에 머무릅니다. 같은 툴체인, 다른 제품, 다른 매트릭스.

매트릭스를 지속 가능하게 만드는 세 가지 아키텍처 결정

멀티 플랫폼 앱이 자체 무게에 무너지지 않도록 하는 세 가지 패턴:

공유 코어는 플랫폼 전용 표면을 위해 #if canImport(SwiftUI) && canImport(<platform>)을 타겟합니다. 코어 도메인 로직(데이터 모델, 비즈니스 규칙, 동기화)은 어디에서나 컴파일됩니다. 플랫폼 전용 UI는 컴파일 타임 조건문 뒤에 있습니다. SwiftUI의 @available(iOS 26.0, macOS 26.0, ...)는 대부분의 경우를 다룹니다. 진정으로 다른 표면(iPhone 등가물이 없는 Mac 메뉴 바, iPad 등가물이 없는 Watch 컴플리케이션)은 타겟별 그룹의 자체 파일을 받습니다.

크로스 디바이스 동기화는 도메인별로 선택된 하나의 기판을 통과합니다. 디바이스 간 작은 세션 수준 상태를 위한 NSUbiquitousKeyValueStore(Return은 크로스 디바이스 타이머 상태를 위해 이를 사용함). 크로스 프로세스 브리지를 위한 iCloud Drive JSON 파일(Get Bananas는 Single Source of Truth에서 다룬 MCP 서버와 함께 이를 사용함). 인 프로세스 상태를 위한 SwiftData. 도메인별로 기판을 혼합하는 것은 괜찮습니다. 같은 도메인에 두 개의 기판을 사용하는 것이 드리프트를 만드는 실패 모드입니다.

각 플랫폼은 앱별로 문서화된 명시적인 거부 패턴을 가지고 있습니다. “사용 사례에 기대어 보는 모드가 없는 한 TV에 출시하지 않을 것이다.” “앱이 패널이 아닌 RealityKit을 사용하지 않는 한 Vision에 출시하지 않을 것이다.” “세션 유형 없이는 Watch에 출시하지 않을 것이다.” 거부는 내가 쓰지 않는 것들의 정신으로 앱별로 포착되고 일관되게 적용되는 프로젝트 결정입니다.

플랫폼 추가가 잘못된 경우

쉬운 길이 잘못된 길인 세 가지 경우.

팀이 툴체인이 쉽게 만들기 때문에 타겟을 추가합니다. Xcode의 “타겟 복제” 마법사는 Mac 또는 visionOS 타겟 추가를 4클릭 작업으로 만듭니다. 그 4클릭에는 디자인 검토, 접근성 감사, App Store 스크린샷 생성, 지속적인 출시 조율, 또는 플랫폼별 테스트가 포함되지 않습니다. 그 작업과 함께 출시되지 않은 마법사에서 출시된 타겟은 첫날에 깨집니다.

팀이 타겟 수를 상태 신호로 취급합니다. “우리는 다섯 개의 Apple 플랫폼에 출시합니다”는 출시 트윗에서 인상적으로 들립니다. 출시 트윗은 사용자 디바이스에서 실행되지 않습니다. 앱이 실행됩니다. 둘 다 못 박는 두 플랫폼 앱이 늘어진 다섯 플랫폼 앱보다 더 나은 제품입니다.

팀이 지속적인 유지보수를 과소평가합니다. 각 Apple 플랫폼은 매년 주요 OS 업데이트를 출시합니다. 다섯 플랫폼 앱은 반응해야 할 다섯 세트의 출시 노트, 테스트해야 할 다섯 세트의 동작 변경, 최신으로 유지해야 할 다섯 세트의 App Store 메타데이터를 가지고 있습니다. 비용은 복합됩니다. 그들을 유지할 대역폭 없이 다섯 모두에 출시하는 팀은 그 플랫폼 중 세 개에서 천천히 부패하는 제품을 생산합니다.

이 패턴이 iOS 26+에 출시되는 앱에 의미하는 것

세 가지 시사점.

1. 플랫폼 포함은 엔지니어링 결정이기 이전에 제품 결정입니다. Xcode 체크박스는 엔지니어링 측면입니다. 사용자 가치 테스트는 제품 측면입니다. “사용자가 그 플랫폼에서 이 앱을 실행함으로써 진정으로 혜택을 받는가”에 대한 명확한 답이 없으면 타겟은 잘립니다.

2. 각 플랫폼은 특정 의무를 가져옵니다: 사이즈 클래스(iPad), 윈도우/메뉴/키보드(Mac), 런타임 계약(Watch), 공간 모델(Vision), 포커스 엔진(TV). 의무를 건너뛰면 iPad-앱-온-Mac, 폰-앱-온-Vision, iPhone-앱-온-Watch가 만들어지며, 이는 모두 플랫폼의 실제 사용자가 알아채는 보이는 실패입니다.

3. 대부분의 앱은 한 개에서 세 개의 플랫폼에 출시해야 합니다. 네 개에서 여섯 개는 흔하지 않으며, 각 플랫폼이 진정으로 사용자 가치를 더할 때만 얻어집니다. 클러스터의 앱은 한 개에서 여섯 개에 걸쳐 있습니다. 여섯 플랫폼 사례(Return)는 규칙을 증명하는 예외이며, 모든 추가 플랫폼은 자체 사용자 가치 테스트를 가진 별도의 제품 결정이었습니다.

전체 Apple 생태계 클러스터: Apple Intelligence 표면을 위한 타입화된 App Intents; 에이전트 표면을 위한 MCP 서버; 그들 사이의 라우팅 질문; 인 앱 온 디바이스 LLM 기능을 위한 Foundation Models; 런타임 대 툴링 LLM 구별; 세 가지 표면 통합; single source of truth 패턴; Xcode 통합을 위한 Two MCP Servers; Apple 개발용 훅; Live Activities; watchOS 런타임 계약; SwiftUI 내부; RealityKit의 공간 멘탈 모델; SwiftData 스키마 규율; Liquid Glass 패턴; 멀티 플랫폼 출시; 내가 쓰지 않는 것들. 허브는 Apple Ecosystem Series에 있습니다. 더 넓은 iOS-with-AI-agents 컨텍스트는 iOS Agent Development 가이드를 참조하십시오.

FAQ

Apple 플랫폼 타겟을 추가할지 어떻게 결정합니까?

툴체인이 그것을 허용하는지가 아니라, 사용자가 그 플랫폼에서 앱을 실행함으로써 진정으로 혜택을 받는지 물어보십시오. Xcode 체크박스는 기술적 측면입니다. 사용자 가치 테스트는 제품 측면입니다. 각 플랫폼은 특정 의무(사이즈 클래스, 윈도우/메뉴, 런타임 계약, 공간 모델, 포커스 엔진)와 특정 유지보수 비용을 가져옵니다. 답이 “거기서도 작동해요”라면, 올바른 결정은 보통 타겟을 건너뛰는 것입니다.

모든 여섯 개의 Apple 플랫폼에 출시해야 합니까?

보통 아닙니다. 대부분의 앱은 한 개에서 세 개의 플랫폼에서 혜택을 받습니다. 네 개에서 여섯 개는 흔하지 않으며, 각 플랫폼이 진정으로 사용자 가치를 더할 때만 얻어집니다(Return은 mindfulness 세션이 Watch에 맞고, 타이머가 책상 컴패니언으로서 iPad와 Mac에 맞고, visionOS가 몰입형 모드에 맞고, TV가 기대어 보는 소파 사용 사례에 맞기 때문에 여섯 개 모두에 도달합니다). 대부분의 앱에서 tvOS의 상호작용 모델과 visionOS의 공간 요구사항은 맞지 않으며, 올바른 결정은 그 타겟을 건너뛰는 것입니다.

iPad 타겟을 추가할 때 가장 흔한 실수는 무엇입니까?

iPad를 “픽셀이 더 많은 iPhone”으로 취급하는 것입니다. 사이즈 클래스 적응 없이 iPad에 떨어진 SwiftUI iPhone 앱은 iPad 사용자가 즉시 절반의 노력으로 판단하는 늘어진 단일 컬럼 UI를 생산합니다. 올바른 패턴은 @Environment(\.horizontalSizeClass)를 읽고, 더 큰 캔버스에 레이아웃을 적응시키며(NavigationSplitView를 통해 의미가 있는 곳에서 두 컬럼, 그렇지 않으면 편안한 간격이 있는 단일 목록), Apple Pencil과 멀티 핑거 어포던스를 iPad 전용 가치로 고려하는 것입니다.

왜 Apple Watch는 다른 플랫폼과 그렇게 다릅니까?

watchOS는 iOS의 백그라운드 실행 모델을 가지고 있지 않습니다. 손목이 떨어지면 시스템이 앱을 일시 중단하고, 특정 세션 유형(mindfulness, workout-processing, alarm 등)만 일시 중단 후에 실행될 수 있습니다. 깔끔한 세션 유형이 없는 앱은 두 번째 사용에서 깨지는 경험을 생산합니다. 클러스터의 watchOS 런타임 글은 계약을 자세히 다룹니다.

플랫폼 매트릭스 전반에 걸친 크로스 디바이스 동기화는 어떻게 작동합니까?

세 가지 기판: 작은 키-값 상태(설정, 마지막 선택된 탭, 크로스 디바이스 타이머 상태)를 위한 NSUbiquitousKeyValueStore, 크로스 프로세스 브리지(Get Bananas + MCP 서버 패턴)를 위한 iCloud Drive 파일, 인 프로세스 상태를 위한 SwiftData. 도메인당 하나의 기판을 선택하십시오. 같은 도메인에 두 개를 혼합하면 드리프트가 발생합니다. 클러스터의 single source of truth 글은 결정 매트릭스를 안내합니다.