App Intents는 여러분의 앱으로 연결되는 Apple의 새로운 API입니다

2026년 2월 8일 아침, 저는 부엌 싱크대 아래에 손을 넣은 채로 Apple Watch에서 Siri에게 물 8 oz를 기록해 달라고 요청했습니다. 물이 기록되었습니다. 워치 대화창에는 32 oz 남았다고 표시되었습니다. 화면은 단 한 번도 건드리지 않았습니다.¹

그보다 11주 전, 저는 제 수분 섭취 추적 iOS 앱인 Water에 Swift 파일 하나를 추가했습니다. LogWaterIntent.swift, 즉 AppIntent 80줄과 세 가지 Siri 문구 변형을 선언하는 AppShortcutsProvider였습니다. 그 파일은 이제 제가 보유한 API 표면 중 가장 뜨거운 곳입니다.²

다음은 제가 한참 만에야 체득한 부분입니다. App Intents는 Siri 기능이 아닙니다. 그것은 서드파티 앱이 Apple Intelligence와 맺는 계약입니다. Apple Intelligence는 Apple이 iOS 18에서 출시하기 시작해 iOS 26까지 계속 구축해 온 시스템 AI 표면입니다.³ 만약 여러분이 iOS 앱을 배포하면서도 여전히 App Intents를 “있으면 좋은” 음성 기능 정도로 취급하고 있다면, 여러분은 Apple이 무엇을 만들어 왔는지 잘못 읽고 있는 것입니다. App Intents는 Apple의 AI가 사용자를 대신해 여러분의 앱처럼 행동할 수 있게 해 주는 API입니다. 그 밖의 모든 것(Siri, Spotlight, Shortcuts, Apple Intelligence 요약, 그리고 Watch와 Vision Pro 표면)은 이 계약에서 파생된 것입니다. iOS 26에서 출시된 온디바이스 LLM인 Foundation Models는 인앱 도구 호출을 위한 별도의 Tool 프로토콜을 노출합니다. 이것은 App Intents를 거치는 것이 아니라 App Intents와 나란히 동작합니다.

TL;DR

• App Intents는 여러분의 앱이 무엇을 할 수 있는지를 타입이 지정된 구조화된 방식으로 선언하며, Apple의 AI가 이를 직접 호출할 수 있습니다. 이것은 서드파티 앱을 위한 Apple의 도구 사용(tool-use) API입니다.
• 실제 프로덕션 예시 하나: Water의 LogWaterIntent입니다. 80줄로 완전한 SwiftData 쓰기, HealthKit 동기화, 로케일 인식 단위 변환, 구조화된 Siri 대화 응답을 처리합니다.
• iOS 26은 Apple의 온디바이스 LLM인 Foundation Models를 추가했습니다. Foundation Models는 인앱 도구 사용을 위한 자체 Tool 프로토콜을 노출하며, App Intents는 여러 앱에 걸쳐 Siri / Spotlight / Apple Intelligence가 호출하는 정식 표면으로 남아 있습니다. 같은 방향, 두 개의 병렬 계약입니다.
• 2026년에 App Intents가 없는 앱은 Apple Intelligence에게 보이지 않습니다. AI 패브릭은 여러분이 선언한 인텐트를 통해 라우팅되거나, 여러분의 앱을 우회해 경쟁사로 라우팅됩니다.
• Apple은 이를 3년 동안 우리에게 알려 왔습니다. 그 명명(App Intents, App Shortcuts, Apple Intelligence)은 의도된 것입니다. 그 계약은 매 WWDC마다 스택 위로 한 단계씩 올라갑니다.

App Intents 프레임워크 참고 이미지는 Apple Developer 문서에서 가져왔습니다.⁵

App Intent란 실제로 무엇인가

2026년 2월 8일 커밋 e398c58로 배포된 LogWaterIntent의 전체 소스입니다:²

import AppIntents
import SwiftData

struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    static var description: IntentDescription = "Log a glass of water to your daily intake"

    @Parameter(title: "Amount", default: 8)
    var amount: Int

    static var parameterSummary: some ParameterSummary {
        Summary("Log \(\.$amount) oz of water")
    }

    func perform() async throws -> some IntentResult & ProvidesDialog {
        let container = try ModelContainer(for: WaterEntry.self, DailyLog.self, UserSettings.self)
        let context = ModelContext(container)

        let settingsDescriptor = FetchDescriptor<UserSettings>(
            predicate: #Predicate { $0.id == "user-settings" }
        )
        let settings = try context.fetch(settingsDescriptor).first ?? UserSettings()

        let amountMl: Double
        if settings.unitSystem == .imperial {
            amountMl = Double(amount) * 29.5735
        } else {
            amountMl = Double(amount)
        }

        let todayKey = DailyLog.todayKey()
        let logDescriptor = FetchDescriptor<DailyLog>(
            predicate: #Predicate { $0.dateKey == todayKey }
        )
        let log: DailyLog
        if let existing = try context.fetch(logDescriptor).first {
            log = existing
        } else {
            log = DailyLog(date: .now, goalAmount: settings.dailyGoal)
            context.insert(log)
        }

        let entry = WaterEntry(amount: amountMl)
        log.entries.append(entry)
        try context.save()

        if settings.healthKitEnabled {
            try? await HealthKitService.shared.logWater(amount: amountMl, date: entry.timestamp)
        }

        let unit = settings.unitSystem == .imperial ? "oz" : "mL"
        let totalDisplay = settings.formatAmount(log.totalAmount)
        return .result(dialog: "Logged \(amount) \(unit). Today's total: \(totalDisplay)")
    }
}

struct WaterShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: LogWaterIntent(),
            phrases: [
                "Log water in \(.applicationName)",
                "Add water in \(.applicationName)",
                "Drink water in \(.applicationName)",
            ],
            shortTitle: "Log Water",
            systemImageName: "drop.fill"
        )
    }
}

(Water의 현재 프로덕션 버전은 목표 도달 / 남은 양 조건문으로 대화를 한층 더 다듬었습니다. 위의 2월 8일 배포 코드가 제가 부엌 싱크대에서 테스트한 코드입니다.)

여기서 짚어 둘 만한 세 가지가 있습니다. 대부분의 “App Intents 튜토리얼”이 이것을 대충 넘기기 때문입니다.

@Parameter가 곧 스키마입니다. Apple의 AI는 기본값이 8인 amount: Int를 봅니다. Siri가 “물 12 oz를 기록해”를 파싱하면 LogWaterIntent(amount: 12)를 생성하고 perform()을 호출합니다. 제 쪽에서는 문자열 파싱이 전혀 없습니다. 타입 시스템이 곧 스키마입니다.⁵

parameterSummary는 매개변수의 자연어 표현입니다. Apple은 이를 사용해 Shortcuts UI, 대화, 그리고 점점 더 Apple Intelligence의 확인 패널에서 동작을 렌더링합니다. 이 요약은 사용자에게 소리 내어 읽혀집니다. 이를 잘못 작성하면 사용자는 어색한 문장을 듣게 되고, 제대로 작성하면 그 표면이 네이티브하게 느껴집니다.⁶

perform()은 IntentResult & ProvidesDialog를 반환합니다. 이것이 구조화된 반환값입니다. AI 표면은 단순한 성공/실패뿐 아니라 사용자가 듣게 될 대화 문자열까지 돌려받습니다. Apple은 점점 더 ProvidesDialog, ProvidesView, 또는 ReturnsValue를 기대하고 있으며, 그래야 결과가 Siri, Spotlight, Watch, 그리고 (iOS 26에서는) Apple Intelligence의 응답 체인으로 조합될 수 있습니다.⁷

맨 아래의 AppShortcutsProvider 블록이 Siri 문구를 등록하는 부분입니다. \(.applicationName) 토큰은 Siri가 “Water”를 자동으로 삽입하는 자리입니다. 같은 인텐트에 대해 세 가지 문구 변형을 두면, 여러분이 문구 사전을 따로 관리하지 않아도 Apple의 자연어 파서가 사용자 표현을 더 폭넓게 매칭할 여지를 갖게 됩니다. systemImageName은 실제 SF Symbols 이름입니다. Spotlight, Shortcuts, Apple Intelligence가 동작의 아이콘을 렌더링하는 방식이 바로 이것입니다.

Apple Intelligence는 사용자 요청을 App Intents를 통해 라우팅하여 온디바이스 AI 기능을 제공합니다. 출처: apple.com/apple-intelligence.

왜 이것이 SwiftUI 이후 가장 중요한 iOS API인가

iOS API는 두 가지 형태로 나뉩니다. 어떤 것은 앱이 자신을 어떻게 그리는지에 관한 것입니다(UIKit, SwiftUI, Metal). 어떤 것은 앱이 시스템과 어떻게 통합되는지에 관한 것입니다(URL 스킴, Universal Links, widgets). App Intents는 세 번째 형태입니다. 이것은 Apple의 AI가 여러분의 앱을 어떻게 사용하는지에 관한 것입니다. 그 widget과 Control Center 표면 자체가 App Intents 표면이며, 같은 인텐트가 여러 곳에서 렌더링되는 것입니다. 이에 대해서는 The iOS 26 Widget Surface에서 추적합니다.

그 전개 과정을 짚어 볼 가치가 있습니다.

• iOS 10 (2016)은 SiriKit Intents(INIntent)를 도입했습니다. 서드파티 앱이 음성으로 호출될 수 있게 된 최초의 사례였습니다. 그 표면은 좁았습니다. 엄격한 스키마를 갖춘 고정된 도메인 목록(메시징, 결제, 차량 호출)이었습니다.⁸
• iOS 12 (2018)은 Siri Shortcuts로 그 표면을 넓혔습니다. 어떤 앱이든 NSUserActivity나 INIntent를 기부하고 Siri가 그것을 제안해 주기를 기대할 수 있었습니다.
• iOS 13 (2019)은 인앱 인텐트 처리를 추가하여, 앱이 시스템 Siri UI로 백그라운드 전환하지 않고도 단축어 호출에 응답할 수 있게 했습니다.
• iOS 16 (2022)은 App Intents 프레임워크를 도입했습니다. 타입이 지정되고 선언적이며, @Parameter와 AppShortcutsProvider를 갖췄습니다. 이전의 INIntent는 신규 개발에서 사실상 대체되었습니다.⁹
• iOS 18 (2024)은 Apple Intelligence를 도입했고, 가능한 모든 곳에서 Siri 요청을 App Intents를 통해 라우팅하기 시작했습니다. Apple Intelligence의 “개인 맥락(personal context)” 기능은 App Entities(App Intents의 데이터 버전)에서 정보를 읽습니다.¹⁰ iOS 27은 이를 한층 더 밀어붙여 App Schemas를 도입했습니다. App Schemas는 어떤 학습용 문구도 없이, Siri가 이미 이해하는 용어로 여러분의 엔티티를 추론하고 그에 따라 동작할 수 있게 합니다. 이에 대해서는 여기에서 다룹니다.
• iOS 26 (2025)은 Apple의 온디바이스 LLM인 Foundation Models 프레임워크를 도입했습니다. Foundation Models는 인앱 도구 호출을 위한 별도의 Tool 프로토콜을 노출합니다. App Intents는 Apple Intelligence를 위한 정식 크로스앱 표면으로 남아 있고, Tool은 직접적인 LLM 호출을 위한 인앱 표면입니다. 두 계약은 나란히 동작합니다.⁴

이 계약은 매 릴리스마다 스택 위로 확장되어 왔습니다. 원래 App Intent의 소비자는 Shortcuts를 탭하는 사람이었습니다. 그다음은 Siri 음성이었습니다. 그다음은 Spotlight였습니다. 그다음은 Apple Intelligence 요약이었습니다. 이제는 Apple Intelligence의 LLM 기반 시스템 표면이 사용자 요청을 처리하기 위해 이를 사용합니다. 여러분이 2026년에 배포하는 App Intent 표면이 바로 Apple Intelligence가 iOS 27, 28, 29에서 호출하게 될 표면입니다.

위의 패턴이 바로 제가 App Intents는 Siri 기능이 아니라고 말할 때 의미하는 바입니다. 그것은 Apple AI 패브릭 전체를 위한 구조화된 도구 사용 API입니다. SwiftUI가 가장 중요한 UI API였던 이유는, 그것이 visionOS, watchOS 10+, iOS 17+용 앱을 작성하는 유일한 방법이 되었기 때문입니다. App Intents는 AI 측면에서 같은 궤적을 따라가고 있습니다. Apple이 모든 베팅을 걸고 있는 표면인 것입니다.

Foundation Models 출시로 이제 무엇이 달라지는가

Foundation Models는 Apple Intelligence를 지원하는 모든 기기에 탑재되는 프레임워크입니다. 하드웨어 기준선은 Apple Intelligence 목록과 동일합니다: iPhone 15 Pro 및 15 Pro Max(A17 Pro), iPhone 16 라인업, iPhone 17 라인업, iPhone Air, iPhone 17e, M1 이상 iPad Pro, M1 이상 iPad Air, A17 Pro 탑재 iPad mini, M2 이상 Vision Pro, 그리고 M1 이상 Mac입니다. 눈에 띄게 빠진 것은: 기본형 iPhone 15 / 15 Plus입니다.⁴¹²

함의는 이렇습니다. 만약 Apple의 시스템 표면(Siri, Spotlight, Apple Intelligence)이 여러분의 앱을 조금이라도 호출한다면, 그것들은 App Intents와 App Entities를 통해 호출합니다. 시스템 AI 패브릭에는 서드파티 앱을 위한 setSystemPrompt(...) API가 없습니다. 인텐트 레지스트리가 있을 뿐입니다. Foundation Models는 자체 온디바이스 LLM 기능을 원하는 개발자를 위해 병렬적인 인앱 Tool 표면을 추가합니다. 크로스앱 계약(Apple Intelligence와 Siri가 여러분의 앱을 찾기 위해 사용하는 계약)은 App Intents를 통해 동작합니다.

앱 개발자에게 주는 세 가지 구체적인 결과는 다음과 같습니다.

관련 App Intent가 없는 앱은 해당 카테고리의 Siri 음성 명령에서 도달할 수 없습니다. Apple Intelligence는 “Hey Siri, 물 기록해”와 같은 문구를, 매칭되는 인텐트를 먼저 선언한 앱으로 라우팅합니다. 저는 2026년 2월에 Water의 인텐트를 배포했습니다. 프레임워크의 방향성에 대한 제 해석은 이렇습니다. 2027년에 인텐트를 배포하는 수분 섭취 앱들은, 라우팅 가중치가 이미 선발 주자 쪽으로 누적된 시장에 진입하게 될 것입니다. 같은 논리가 쇼핑 목록, 운동 기록, 캘린더 항목, 사진 검색에도 적용됩니다. 저는 인텐트 선언에서의 선점 우위가 복리로 쌓일 것이라 예상합니다. 다른 Apple 플랫폼 베팅 API들(HealthKit 카테고리, Spotlight 리치 결과, Live Activities 토큰)에서 그러했던 것처럼 말입니다.

Apple Intelligence 개인화는 인텐트뿐 아니라 App Entities에서 정보를 읽습니다. AppEntity는 “이 앱에는 이러한 형태의 데이터가 있다”고 선언합니다. 사용자가 “내가 읽기 목록에 마지막으로 추가한 책이 뭐였지”라고 물으면, Apple Intelligence는 설치된 모든 앱에서 Book에 매칭되는 모든 AppEntity를 검색합니다. 만약 여러분의 앱에 읽기 목록은 있는데 BookEntity가 선언되어 있지 않다면, 여러분의 데이터는 Apple의 AI 표면에게 보이지 않습니다. Apple Intelligence는 여러분의 데이터를 가져오거나 참조할 수 없습니다.¹¹

IntentResult & ProvidesDialog 반환 형태가 점점 더 중요해지고 있습니다. Apple Intelligence는 Siri, Spotlight, Watch에 걸쳐 인텐트 결과를 더 긴 응답으로 조합하고 있습니다. 구조화된 대화 없이 단지 성공만 반환하는 perform()은, 시스템이 일관된 답변으로 조합하기가 더 어렵습니다. ProvidesDialog와 ProvidesView는 선택적인 예의가 아닙니다. 그것은 여러분의 동작이 사용자의 AI 표면에서 인용(citation)이 되는 방식입니다.

내가 다르게 만들었을 것들

Water의 11주간 프로덕션 로그는 제가 더 일찍 했어야 할 세 가지를 말해 줍니다.

필요하다고 생각하는 것보다 더 많은 인텐트를 배포하세요. 저는 하나를 배포했습니다. 네 개를 배포했어야 했습니다: LogWaterIntent, CheckTodaysProgressIntent, AdjustGoalIntent, ShowHistoryIntent입니다. 각각은 사용자가 실제로 시도하는 Siri 문구에 대응합니다(“오늘 물 얼마나 마셨지”는 제 앱의 데이터가 아니라 Apple의 범용 AI로 라우팅되었습니다). 누락된 인텐트 하나하나가 Apple Intelligence가 저를 우회해 라우팅하는 쿼리입니다.

대화 문자열은 이메일 본문이 아닙니다. 저는 처음부터 ProvidesDialog를 가지고 있었지만, 초기 대화는 산문이었습니다. CarPlay나 AirPods로 그것을 듣는 사용자에게는 짧고 구체적이며 사실 중심의 구조가 필요합니다: “8 oz 기록됨. 32 oz 남음.” 특히 Watch 표면은 매우 공격적으로 잘라냅니다. 대화체 대화는 자신감 있는 사실 중심 대화보다 더 나쁜 사용자 경험입니다. 저는 4주 차에 제 것을 다시 작성했습니다.²

App Entities는 제가 생각했던 것보다 더 중요합니다. 저는 WaterEntry SwiftData 모델을 가지고 있습니다. 저는 WaterEntryEntity: AppEntity와 그 동반자인 WaterEntryQuery: EntityQuery도 선언했어야 합니다. 그래야 Apple Intelligence가 “어제 물 마신 시간을 보여줘”에 답할 수 있습니다. 최소한의 브리징은 다음과 같습니다:¹¹

struct WaterEntryEntity: AppEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Water Entry"
    static var defaultQuery = WaterEntryQuery()
    var id: UUID
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(amount) oz at \(timestamp.formatted())")
    }
    @Property(title: "Amount") var amount: Int
    @Property(title: "Timestamp") var timestamp: Date
}

struct WaterEntryQuery: EntityQuery {
    func entities(for identifiers: [UUID]) async throws -> [WaterEntryEntity] {
        // Fetch matching entries from SwiftData
    }
    func suggestedEntities() async throws -> [WaterEntryEntity] {
        // Recent entries Apple Intelligence can suggest
    }
}

작은 Swift 타입 두 개에 SwiftData 페치 연결 코드가 더해진 것입니다. 항목을 Spotlight에서 개별적으로 노출 가능하게(사용자가 “water”를 검색하면 올바른 항목에 도달하도록) 하려면, 엔티티를 IndexedEntity에 준수시키고 쓰기 시 인덱스 업데이트를 기부하세요. 그것이 단순한 AppEntity 노출을 넘어 Apple의 Spotlight 파이프라인이 기대하는 바입니다.

같은 형태가 제 다른 앱들에도 적용됩니다. 제 쇼핑 목록 앱인 Get Bananas는 이미 @Attribute(.unique) var id: UUID, name, amount, section, isChecked를 갖춘 SwiftData @Model ShoppingItem을 보유하고 있으며, iCloud Drive 동기화를 위한 lastModified 필드도 있습니다.¹³ 이를 ShoppingItemEntity: AppEntity로 래핑하고 몇 개의 인텐트(AddShoppingItem, CheckOffItem, ShowList)를 배포하면, Get Bananas가 이미 .mcpb MCP 서버를 통해 Claude Desktop에 노출하고 있는 것과 동일한 영속성 계층을 Apple Intelligence에도 노출하게 됩니다.¹⁴ 두 LLM 생태계, 두 개의 서로 다른 계약, 하나의 동일한 쇼핑 목록입니다. 이것이 바로 하나의 배포된 앱으로 본 병렬 계약 명제입니다: SwiftData 모델이 데이터이고, App Intents는 Apple의 계약이며, MCP는 Anthropic의 계약입니다. 두 표면 모두 동일한 단일 진실 공급원(source of truth) 위에서 동작합니다.

App Intent를 배포하지 말아야 할 때

거절도 설계의 일부입니다.

만약 여러분의 앱이 변경 가능한 사용자 상태 없이 순전히 소비 중심(사용자의 사진 읽기, 뉴스 표시, 오디오 재생)이라면, App Intents가 노출할 것이 아무것도 없을 수도 있습니다. Apple의 프레임워크는 OpenIntent(단지 특정 맥락으로 앱을 여는 것)를 지원하지만, 유일하게 유용한 동작이 “앱 열기”뿐이라면 그 인텐트는 부담일 뿐입니다. 그저 가지기 위해 하나 배포하지 마세요.

만약 동작이 추상화하기 어려운 UI 어포던스(복잡한 다단계 캔버스 도구, 3D 편집 앱)에 의존한다면, 인텐트에 필수인 parameterSummary는 아무도 실제로 말하지 않는 모호한 유사 자연어로 전락하게 됩니다. Siri 문구 “내 사진을 강도 7의 블러 도구로 편집해”는 기술적으로는 가능하지만 어떤 사람도 그렇게 말하지 않습니다. 그 인텐트의 표면은 아무 보상도 없는 세금입니다.

올바른 규칙은 이렇습니다. App Intent는 사용자가 그 동작을 자연스럽게 촉발할 만한 문장이 있을 때 제값을 합니다. “물 8 oz 기록해”가 바로 그런 문장입니다. “레이어 3에 시그마 2.4의 가우시안 블러를 적용해”는 그렇지 않습니다. 만약 여러분 앱의 동작들이 두 번째 패턴에 몰려 있다면, 인텐트는 여러분의 전환 지렛대가 아닙니다.

마무리하는 견해

3년 동안 Apple은 iOS의 시스템 AI 패브릭이 App Intents를 통한다는 신호를 보내 왔습니다. WWDC 2024는 Apple Intelligence 라우팅을 그 위에 추가했습니다. WWDC 2025는 Foundation Models를 별도의 인앱 도구 호출 표면으로 나란히 추가하면서, App Intents는 Siri / Spotlight / Apple Intelligence가 계속 사용하는 크로스앱 계약으로 남겨 두었습니다. 모든 신호는 같은 방향을 가리킵니다: 타입이 지정되고 선언적인 App Intent가 이제 서드파티 앱이 시스템과 맺는 계약입니다.

대부분의 iOS 앱은 여전히 App Intents를 Siri Shortcuts로 취급합니다. 즉, 시간이 있으면 배포할 기능 정도로 말입니다. 제 해석은 그 관점이 좋지 않게 나이 들 것이라는 점입니다. Apple Intelligence의 시스템 표면이 확장됨에 따라(이미 오늘날 Siri, Spotlight, Shortcuts, Apple Intelligence 요약을 통해서), 인텐트를 선언하지 않은 앱은 라우팅 그래프 바깥에 놓이게 될 가능성이 높습니다. Apple의 다른 플랫폼 베팅들을 지켜본 제 경험상, 선점 표면은 복리로 쌓입니다.

Water는 11주 동안 LogWaterIntent를 배포해 왔습니다. App Intent를 배포하는 코드의 양은 파일 하나에 들어갈 만큼 작습니다. 그것을 배포하지 않는 비용은 Apple Intelligence 릴리스가 거듭될수록 커집니다.

만약 여러분이 2026년에 iOS 앱을 배포하면서 App Intent를 단 하나도 선언하지 않았다면, 여러분의 로드맵에는 빠진 항목이 있는 것입니다. 추가하세요.

FAQ

iOS 개발에서 App Intent란 무엇인가요?

App Intent는 여러분 앱의 동작 중 하나를 Apple의 시스템 AI 표면에 노출하는, 타입이 지정되고 선언적인 Swift 구조체입니다. @Parameter를 통해 매개변수를, parameterSummary를 통해 자연어 요약을, 그리고 실제 작업을 수행하고 구조화된 결과를 반환하는 비동기 perform() 본문을 선언합니다. Apple의 Siri, Spotlight, Shortcuts, Apple Intelligence가 이를 호출할 수 있습니다. Foundation Models(Apple의 온디바이스 LLM)는 직접적인 인앱 도구 호출을 위해 별도의 Tool 프로토콜을 사용합니다.

App Intents는 이전의 INIntent와 어떻게 다른가요?

App Intents(iOS 16, 2022에서 도입)는 Apple의 주요 인텐트 프레임워크로서 INIntent를 대체했습니다. 새 프레임워크는 완전히 Swift 네이티브이고, @Parameter 같은 프로퍼티 래퍼를 사용하며, AppEntity를 통한 타입 안전 엔티티 쿼리를 지원하고, Siri, Spotlight, Shortcuts, Apple Intelligence가 호출하는 표면입니다. 이전의 INIntent는 여전히 지원되지만 새로운 기능 작업은 받지 못합니다.

App Intent를 배포하려면 iOS 26이 필요한가요?

아니요. App Intents는 iOS 16부터 사용할 수 있습니다. iOS 26은 Foundation Models 프레임워크를 나란히 추가하지만, App Intent 선언 그 자체는 iOS 16+에서 동작합니다. 위의 예제 코드는 SwiftData(iOS 17+)를 사용하므로, 배포 타깃은 여러분의 perform() 본문이 무엇을 import하느냐에 따라 달라집니다. 순수한 App Intents는 iOS 16까지 거슬러 동작하고, SwiftData 기반인 것은 iOS 17이 필요합니다.

App Intent와 App Entity의 차이는 무엇인가요?

App Intent는 동작(동사)입니다. App Entity는 여러분의 앱이 알고 있는 데이터(명사)입니다. LogWaterIntent는 인텐트입니다. WaterEntry가 쿼리 가능한 타입이 되는 것은 엔티티입니다. Apple Intelligence는 둘 다 사용합니다. 동작을 취하는 데에는 인텐트를, 응답에서 데이터를 가져오고 참조하는 데에는 엔티티를 사용합니다.

App Intents는 Foundation Models 도구 호출과 어떤 관계인가요?

Foundation Models는 직접적인 인앱 LLM 도구 호출을 위해 자체 Tool 프로토콜을 노출합니다. App Intents는 Apple Intelligence, Siri, Spotlight가 호출하는 정식 크로스앱 표면으로 남아 있습니다. 같은 방향(타입이 지정되고 선언적인 도구 사용), 두 개의 병렬 계약입니다. 시스템 AI 표면에서 도달 가능해지기를 원하는 앱은 App Intents를 배포하고, 자체 온디바이스 LLM을 커스텀 도구로 호출하고 싶은 앱은 Tool 준수를 배포합니다. 많은 앱이 둘 다 배포하게 될 것입니다.

App Intents는 기능이 아닙니다. 그것은 계약입니다. 인텐트를 먼저 배포한 앱이 그 표면을 차지하고, 나중에 배포하는 앱은 그 표면이 이미 다른 곳으로 라우팅된 것을 발견하게 됩니다. 11주 전에 저는 Water에 하나를 배포했습니다. 복리는 이미 시작되었습니다.

Apple Ecosystem 시리즈 더 보기

이 에세이는 진입점입니다. 나머지 네 편이 아키텍처 스택의 나머지를 다룹니다:

• Two Agent Ecosystems, One Shopping List: Get Bananas가 iCloud Drive의 JSON 파일 하나를 통해 동일한 데이터를 Apple Intelligence(App Intents)와 Claude Desktop(MCP)에 노출하는 방법.
• Liquid Glass in SwiftUI: Three Patterns From Shipping Return: iOS 26 비주얼 레이어를 위한 프로덕션 패턴.
• Five Apple Platforms, Three Shared Files: 멀티 플랫폼 배포 전략, 코드를 언제 공유하고 언제 타깃을 분기할 것인가.
• HealthKit + SwiftUI on iOS 26: 권한 흐름, 샘플 타입, 그리고 사용자를 여러분의 앱에서 잠가 버리는 함정의 데이터 소스 계층.

또는 전체 허브로 바로 이동하세요: Apple Ecosystem Series. AI 에이전트와 함께하는 iOS의 더 넓은 맥락은 iOS Agent Development guide를 참고하세요.

References