맞춤형 Intent를 앱 Intent로 마이그레이션하기

안녕하세요 제 이름은 Ari입니다 맞춤형 Intent를 앱 Intent로 마이그레이션하는 방법을 알아보겠습니다 이 비디오에서는 새로운 앱 Intent 프레임워크를 도입해야 하는 이유 이전 버전과의 호환성을 포함하여 마이그레이션 작동 방식 및 실제로 앱 Intent로 변환하는 방법을 설명하겠습니다 먼저 앱 Intent를 도입해야 하는 이유와 이전 프레임워크와의 차이점을 알아보겠습니다 2016년에 선보인 SiriKit Intent 프레임워크에는 메시지, 운동, 전화 통화 등의 일반적인 사용 사례에 대한 완전한 사용자 경험을 제공하는 일련의 목적 기반 시스템 Intent가 포함되어 있습니다 다음으로 모든 사용 사례에 대한 고유한 Intent를 정의할 수 있는 맞춤형 Intent가 도입되어 앱의 기능을 Siri 단축어 및 제안에 구현할 수 있게 되었습니다 그리고 위젯 구성 및 예측을 위해 맞춤형 Intent를 사용하는 WidgetKit이 추가되었습니다 WWDC22에서 앱에서 시스템으로 Intent를 제공하는 새로운 Swift 기반 프레임워크인 앱 Intent가 공개되었습니다 앱 Intent는 사용자가 손쉽게 사용할 수 있는 강력한 최신 기술이므로 반드시 도입해야 할 프레임워크입니다 Swift에서 기본 실행되도록 설계된 최신 기술입니다 최신 언어 기능 덕분에 훨씬 적은 코드로 같은 기능을 지원할 수 있습니다 또한 Intent 정의 파일을 유지하고 코드 생성을 사용할 필요가 없게 되었습니다 스니펫을 간단한 SwiftUI 보기로 제공할 수 있습니다 더 자세한 사용 사례를 지원하는 엔터티와 쿼리로 기능이 강력합니다 확장 프로그램을 제공하지 않고 앱 프로세스에서 직접 앱 Intent를 실행할 수 있습니다 사용자가 Intent를 설정하고 실행할 때 사용자 경험을 맞춤화할 새로운 기회가 있습니다 또한 사용자가 쉽게 사용할 수 있습니다 Intent는 설정 없이 즉시 사용할 수 있는 앱 단축어로 쉽게 노출할 수 있습니다 또한 사용자가 새로운 방법으로 단축어를 발견할 수 있습니다 Spotlight 상단과 앱에 포함할 수 있는 Siri 팁에 표시되기 때문입니다 새 프레임워크의 모든 이점을 활용하려면 Siri 및 단축어용으로 빌드한 모든 맞춤형 Intent를 앱 Intent로 업그레이드해야 합니다 SiriKit Intent는 계속해서 그대로 지원됩니다 따라서 메시징 또는 미디어와 같은 영역의 Siri를 빌드하거나 WidgetKit에서 Intent를 사용하면 그대로 두어야 합니다 앱 Intent 프레임워크에 대해 자세히 알아보려면 WWDC22의 ‘앱 Intent 심층 분석’ 세션을 참고하세요 사용자가 Siri 및 Spotlight에서 앱의 기능을 정말 쉽게 사용할 수 있게 만드는 앱 단축어에 대해 자세히 알아보려면 ‘앱 Intent로 앱 단축어 구현’을 참고하세요 다음으로 마이그레이션에 대해 살펴보겠습니다 마이그레이션을 통해 Xcode에서 클릭 한 번으로 기존 Intent 정의를 앱 Intent로 변환할 수 있습니다 동일한 앱 바이너리로 iOS 15와 iOS 16 모두 지원할 수 있습니다 새 앱 Intent에서 계속 작동하도록 사용자의 기존 단축어를 활성화할 수 있습니다 Intent 정의를 앱 Intent로 변환하려면 Intent 정의 파일로 이동하여 Convert to App Intent 버튼을 누르기만 하면 됩니다 Xcode에서 이전 Intent 정의와 동일한 앱 Intent 코드가 생성됩니다 그러면 이전 콘텐츠 처리기 코드를 리팩터링하여 코드를 채울 수 있습니다 다음 섹션에서 이에 대해 자세히 알아보겠습니다 앱이 앱 Intent로 업그레이드될 때 사용자 경험이 원활하도록 이전 Intent에서 새 Intent로의 매핑은 시스템에서 자동으로 처리됩니다 매핑이 어떻게 작동하는지 살펴보겠습니다 CustomIntentMigrated AppIntent 프로토콜을 도입하기만 하면 이전 Intent와 새 Intent 간에 변환하는 방법을 파악할 충분한 정보가 시스템에 제공됩니다 이 프로토콜을 도입할 때 이전 맞춤형 Intent에 사용된 클래스 이름인 Intent 클래스 이름 속성이 제공됩니다 대부분의 경우 이를 개발자가 직접 제공할 필요는 없습니다 Convert to App Intent 버튼을 사용할 때 결과 코드에 이미 이 프로토콜이 도입됩니다 앱 Intent의 마이그레이션 기능으로 인해 앱 Intent로 업그레이드하기 위해 앱에서 iOS 16을 지원할 때까지 기다리지 않아도 됩니다 동일한 앱 바이너리로 최신 운영 체제와 이전 운영 체제를 모두 쉽게 지원할 수 있습니다 이렇게 하려면 레거시 Intent 처리기와 앱 Intent가 모두 앱에 포함되어야 합니다 코드 공유를 극대화하려면 공통 비즈니스 로직 세트에 두 세트의 Intent 처리기를 고려합니다 마이그레이션된 앱 Intent 프로토콜을 도입한다고 가정하면 앱에 두 세트가 모두 포함될 경우 단축어에서 중복된 Intent가 자동 제거됩니다 따라서 iOS 15 및 이전 버전에서는 단축어 앱에 레거시 Intent 구현만 표시되고 iOS 16 및 이후 버전에서는 앱 Intent 구현만 표시됩니다 최소 배포 대상을 iOS 16 및 이후 버전으로 전환하면 더 이상 필요하지 않은 마이그레이션한 Intent용 레거시 Intent 처리기와 정의를 안전하게 삭제할 수 있습니다 마이그레이션할 때 고려해야 할 한 가지는 사용자에게 단축어 앱에서 생성하거나 앱의 Siri에 추가 버튼을 사용하여 추가한 이전 Intent 기반의 기존 단축어가 있다는 것입니다 다행히 이러한 단축어는 마이그레이션된 앱 Intent 프로토콜을 도입하는 경우 새 앱 Intent와 호환됩니다 새 앱 Intent를 사용하기 위해 사용자 단축어를 덮어쓰지 않고 새 Intent와 이전 Intent에 모두 작동하는 공통 포맷을 자동 사용합니다 이렇게 되려면 레거시 Intent와 앱 Intent의 스키마가 호환되어야 합니다 호환되려면 맞춤형 Intent와 앱 Intent의 매개변수가 동일한 이름 및 동등한 유형을 가져야 합니다 스키마 호환성을 손상하지 않고 몇 가지를 변경할 수 있습니다 특히 매개변수를 추가 또는 제거하거나 기존 매개변수를 선택 사항이 아닌 항목으로 변경할 수 있습니다 Xcode에서 스키마 호환성을 확인하려면 매개변수 목록이 있는 이전 Intent 정의 파일을 확인합니다 각 매개변수에는 이름과 유형이 있습니다 속성 패널에는 Intent 클래스 이름 필드도 있습니다 앱 Intent 코드를 다룰 때는 시스템에서 새 Intent를 이전 Intent와 동등한 것으로 간주하도록 Intent 클래스 이름이 Intent 정의 파일에 있던 것과 일치하는지 확인해야 합니다 그리고 앱 Intent 코드의 매개변수 이름과 유형이 호환되는지 확인합니다 다시 말하자면 Xcode의 Convert to App Intents 버튼은 자동으로 스키마 호환성을 보장합니다 따라서 도구를 사용하고 변경하지 않으면 양호한 상태를 유지할 수 있습니다 다음으로 기존 Intent를 앱 Intent로 실제로 변환하는 방법에 대해 알아보겠습니다 Intent 마이그레이션은 두 단계로 진행됩니다 1단계는 Intent 정의 파일을 마이그레이션하는 것이고 2단계는 코드를 마이그레이션하는 것입니다 Intent 정의부터 시작하겠습니다 저는 수프를 좋아하기에 수프를 주문할 수 있는 SoupChef라는 예제 앱을 준비했습니다 이 앱에는 주문할 수프와 수량 추가할 토핑, 픽업 또는 배달 위치에 대한 매개변수로 주문을 처리하기 위한 Intent가 있습니다 이를 앱 Intent로 변환할 준비가 되었으므로 Xcode에서 Intent 정의 파일로 이동하고 변환 버튼을 누릅니다 다음으로 변환할 Intent를 선택합니다 이 경우는 한 개뿐입니다 그런 다음 새 Intent 코드를 저장할 위치와 Intent에 포함할 대상을 선택합니다 추가한 경우 앱이나 앱 Intent가 확장 프로그램의 대상이 될 수 있습니다 이 경우에는 앱과 Watch도 대상으로 선택하겠습니다 앱 Intent는 프레임워크 대상으로 추가할 수 없습니다 다음으로 Xcode에서 생성된 앱 Intent 코드가 표시됩니다 Intent 정의 파일에 포함된 모든 Intent, enum 및 맞춤형 유형을 나타내는 몇 개의 파일에서 분리됩니다 마이그레이션된 이전 Intent 정의의 몇 가지 특정 영역에 주목하세요 새 코드에는 앱 Intent 프로토콜을 따르는 orderSoup struct가 있습니다 이 struct는 iOS 16 및 이후 버전에서 사용 가능한 것으로 표시됩니다 iOS 16 이전 버전의 앱을 배포하는 경우 앱 Intent 프레임워크를 사용하는 모든 코드에 이 주석을 적용해야 합니다 Intent 정의 파일의 각 매개변수는 해당 메타데이터와 함께 앱 Intent 구조의 @Parameter 정의로 마이그레이션되었습니다 단축어 앱 매개변수 요약은 모두 이 parameterSummary 정의로 마이그레이션되었습니다 이전에 매개변수 관계로 표현되던 것은 이제 ParameterSummary의 Switch, Case 또는 When 문을 사용하여 나타낼 수 있습니다 Soup 및 Toppings 맞춤형 유형은 이제 나중에 작성해야 하는 TODO를 포함해 AppEntity입니다 OrderDetails는 이제 TransientAppEntity이며 나중에 조회하는 데 사용할 수 있는 고유 식별자가 없기 때문에 일시적인 것으로 간주됩니다 이제 OrderType 맞춤형 enum은 AppEnum입니다 사람이 읽을 수 있는 이름은 CaseDisplayRepresentations로 마이그레이션되었습니다 마지막으로 Intent 응답의 모든 대화는 IntentDialog의 확장 프로그램으로 마이그레이션되었습니다 이러한 대화는 perform 메서드에 사용할 수 있습니다 마이그레이터에서 필요 이상의 문자열이 생성될 수 있으므로 ‘Just to confirm, you wanted \ (soup)?’와 같이 이전 Intent 처리기에서 실제 사용되지 않는 문자열이 표시되면 자유롭게 제거하세요 Intent 정의를 마이그레이션했으므로 이제 Intent 처리 코드를 마이그레이션해 보겠습니다 자동 생성된 앱 Intent에는 perform() 메서드의 플레이스홀더를 작성해야 함을 알리는 TODO가 있습니다 이 방법을 살펴보겠습니다 이전 프레임워크에서는 Intent 정의 파일과 Intent 처리 코드 세트를 제공했습니다 새 프레임워크에서는 모든 요소가 코드로 표현됩니다 이전 Intent 정의의 매개변수는 이미 새 코드로 마이그레이션되었습니다 이전 코드의 resolve confirm, handle 메서드는 Intent가 실행될 때 호출되는 단일 perform 메서드로 결합되어야 합니다 그리고 맞춤형 유형 및 동적 옵션은 엔터티 및 쿼리로 리팩터링되어야 합니다 그럼 Intent 처리의 각 단계를 마이그레이션하는 방법을 resolve부터 살펴보겠습니다 resolve 단계에서는 Intent 처리기가 Intent의 각 매개변수를 확인하고 필요한 경우 사용자에게 값을 묻는 메시지를 표시합니다 resolve 메서드를 마이그레이션할 때 가능하면 앱 Intent의 새로운 자동 resolution 동작을 활용해야 합니다 그러지 않으면 resolution 로직을 perform() 메서드로 리팩터링해야 합니다 몇 가지 예를 살펴보겠습니다 이것은 soup 매개변수에 대한 이전 resolution 메서드로 이전 Intent 프레임워크의 일반적인 패턴을 따릅니다 soup 매개변수의 감싸기를 해제해 봅니다 nil이면 사용자에게 명확화를 사용하여 수프를 선택하도록 요청하는 resolution 결과를 반환합니다 설정된 경우 성공한 resolution 결과를 반환하고 이미 지정된 동일한 수프를 다시 전달합니다 자동 resolution 덕분에 이러한 종류의 상용구는 앱 Intent에 더 이상 필요하지 않습니다 이전에 이 방식으로 해결된 매개변수가 있는 경우 새 기능을 활용하는 방법을 알려 드리겠습니다 기본적으로 마이그레이션된 매개변수는 선택 사항이지만 유형을 non-optional로 변경하여 자동 resolution 동작을 얻을 수 있습니다 매개변수를 non-optional로 지정하면 비어 있는 경우 앱 Intent는 SoupAppEntity 쿼리에서 제안된 엔터티를 사용하여 자동으로 사용자에게 값을 요청합니다 그리고 매개변수 정의에 대화를 추가하면 resolution 시스템이 값을 입력하라는 메시지를 표시할 때 사용자에게 다음과 같은 특정 질문을 합니다 ‘Which soup do you want?’ 이렇게 하면 더 이상 이 매개변수에 대한 resolution 코드가 필요하지 않습니다 다른 모든 resolution 유형의 경우 해결 구현을 perform() 메서드의 맨 위로 이동하고 적절한 새 API를 사용하도록 API 사용을 변경하여 사용자에게 명확화를 요청해야 합니다 예를 들어 수량에 대한 이전 resolution 메서드에서 수량 감싸기를 해제하고 누락된 경우 needsValue를 던진 다음 수량이 실제로 사용 가능한 수프 수량보다 큰지 확인하여 크다면 오류를 반환한다고 가정하겠습니다 이 코드를 앱 Intent로 옮기면 첫 번째 부분이 더 이상 필요하지 않습니다 별도로 수량 매개변수를 non-optional로 만들 수 있기 때문입니다 두 번째 부분에서는 지원되지 않는 resolution 결과로 완료 처리기를 유발한 코드를 가져오고 재고가 충분하지 않음을 나타내는 오류를 발생시키는 코드로 대체하겠습니다 오류를 enum으로 정의하고 오류 및 현지화된 맞춤형 문자열 리소스 변환 가능 프로토콜을 따라야 합니다 이렇게 하면 이 경우에 해당될 때 사용자에게 들리거나 표시되는 대화를 제공할 수 있습니다 이 예제와 같이 동적으로 반환되는 코드와 needsValue 결과가 있는 경우 이를 needsValueError로 던지는 코드로 대체할 수 있습니다 needsValueError를 던지면 시스템에서 사용자에게 제공된 대화로 값을 입력하라는 메시지를 표시한 다음 perform 메서드를 처음부터 다시 실행합니다 또 다른 옵션은 requestValue 메서드를 사용하는 것입니다 requestValue를 사용하면 사용자에게 값을 묻는 메시지를 표시하고 다시 시작하지 않고도 perform 메서드를 계속 실행할 수 있습니다 requestValue 메서드 외에도 이전 API 사용을 대체하는 데 사용할 수 있는 requestDisambiguation 메서드와 requestConfirmation 메서드도 있습니다 다음으로 confirm에 대해 살펴보겠습니다 confirm은 시스템에서 사용자에게 진행을 원하는지 확인하도록 요청하기 위해 추가로 확인을 수행하고 정보를 제공할 기회입니다 확인을 수행하려면 confirm 메서드에 있던 모든 확인 로직을 perform 메서드로 이동해야 합니다 사용자에게 확인을 요청하는 새로운 간단한 request Confirmation() API가 있습니다 새 API는 단일 메서드 호출입니다 async/await를 사용하면 이 메서드는 perform 메서드를 계속하기 전에 사용자가 확인할 때까지 기다립니다 사용자가 취소하면 오류가 전송되고 perform 메서드 실행이 중지됩니다 requestConfirmation 메서드에는 확인 프롬프트에 영향을 미치는 여러 인수가 포함됩니다 예로는 Siri가 말하거나 표시하는 dialog 스니펫에 표시되는 SwiftUI view 확인 버튼에 사용되는 레이블 이 경우에는 order이고 대화를 화면에 프롬프트로 표시할지 제어하는 showPrompt 인수 등이 있습니다 dialog와 view에 서로 동일한 정보가 포함된 경우 false로 설정해야 합니다 따라서 Siri가 dialog를 말하지만 표시하지 않게 되는 것입니다 다음으로 handle을 살펴보겠습니다 핸들을 리팩터링하려면 handle 메서드에서 perform 메서드로 코드를 이동하기만 하면 됩니다 이제 resolve, confirm handle이 모두 단일 메서드에서 발생하므로 이전 handle 메서드에서 일부 확인 코드를 제거할 수 있어야 합니다 예를 들어 이전 코드를 handle에서 복사했다면 더 이상 선택 사항이 아닌 매개변수의 감싸기를 해제하는 코드로 끝날 텐데 이제 삭제할 수 있습니다 perform 메서드의 끝부분에서 Intent 결과를 반환해야 합니다 result에는 Siri가 말할 dialogue 또는 표시할 스니펫 view 등 다양한 필드가 포함될 수 있습니다 각 필드에 대화용 ProvidesDialog 및 SwiftUI 스니펫 보기용 ShowSnippetView와 같은 적절한 프로토콜을 사용하여 perform 메서드의 반환 유형 주석을 달아야 합니다 마지막으로 Dynamic Options 마이그레이션을 살펴보겠습니다 매개변수 유형에 따라 Query 또는 DynamicOptionsProvider를 입력해야 합니다 Xcode는 작성해야 할 위치에 TODO를 제공합니다 쿼리의 경우 identifier별로 검색 가능한 경우 string별로 사용자가 단축어에서 해당 매개변수를 탭할 때 표시되는 suggestedEntities 집합별로 엔터티를 반환하는 메서드를 구현해야 합니다 동적 옵션의 경우 results 메서드에서 모든 옵션을 반환하면 됩니다 이제 앱 Intent로의 마이그레이션이 완료되었습니다 실제로 완료하기 전에 몇 가지 더 살펴보는 것이 좋습니다 첫 번째는 앱 단축어를 도입하는 것입니다 이렇게 하면 Intent가 발견될 수 있고 사용자가 Siri에게 말하여 Intent를 사용할 수 있습니다 Siri 팁을 UI에 추가하여 사용자가 앱 기능을 사용하려면 Siri에게 어떻게 말해야 하는지 알려 주세요 이전의 Siri에 추가 버튼을 이렇게 대체해야 합니다 이전 버전의 앱으로 단축어를 만들고 새 버전의 앱에서 올바르게 작동하는지 테스트하여 고객이 업그레이드하는 경로를 테스트하세요 여러 로케일에서 작동하는 앱이라면 현지화를 고려하세요 앱 Intent를 현지화하려면 앱 Intent에 포함된 모든 문자열이 현지화된 문자열 리소스로 제공되어야 하며 해당하는 문자열과 함께 현지화할 수 있는 .strings 파일을 제공하여 현지화할 수 있습니다 복수형 문자열을 사용하는 경우 .strings dict 파일을 사용할 수도 있습니다 앱 단축어를 현지화할 때 AppShortcuts.strings라는 파일에 문자열을 추가하고 해당 문자열의 모든 변수를 ${ } 표기로 대체합니다 요약하자면 iOS 16의 새로운 기능과 새롭고 더 단순한 앱 Intent 개발 모델의 모든 이점을 활용하려면 맞춤형 Intent를 앱 Intent로 업그레이드하는 것이 좋습니다 사용자가 쉽게 발견하고 앱의 기능을 사용할 수 있도록 앱 단축어를 추가하세요 훌륭한 사용자 경험을 구성하는 방법에 대해 자세히 알아보려면 WWDC22의 ‘앱 단축어 디자인’ 세션을 참고하세요 감사합니다