원본 문서:
Human Interface Guidelines App Architecture

NOTE
본 글은 Apple developer의 공식문서인 Human Interface Guidelines App Architecture원본을 번역 및 개인적인 의견을 추가하여 정리한다.

---

Accessing User Data and Resources

사용자의 개인 정보는 가장 중요하다. 사용자가 앱을 신뢰할 수 있도록 하려면 개인 정보와 관련된 데이터와 resources의 사용 방법을 투명하게 공개해야 한다. 예를 들어 다음과 같은 데이터에는 접근 권한을 요청해야 한다.

• 위치, 건강, 금융, 연락처, 그리고 다른 개인 식별 정보를 포함한 개인 데이터.

• 이메일, 메시지, 달력 데이터, 연락처, 게임 플레이 정보, 애플 뮤직 활동 데이터, HomeKit 데이터, 음성, 비디오, 그리고 사진과 같은 사용자 생성 콘텐츠

• 블루투스 주변장치, home automation 기능, 와이파이 연결, 로컬 네트워크와 같은 보호된 resource

• 카메라와 마이크와 같은 장치 기능

Important
iOS14.5, iPadOS 14.5부터 사용자를 추적하거나 기기의 광고 identifier에 접근하려면 AppTrackingTransparency framework를 사용하여 사용자의 권한을 요청해야 한다. 더 자세한 사항은 User Privacy and Data Use.

새로운 앱이나 업데이트된 앱을 제출할 때, 앱의 개인 정보 정책과 수집한 개인 정보 관련 데이터를 제공하면 App store가 제품 페이지에 관련 정보를 표시한다. (App store Connect에서 관련한 정보를 언제든지 관리할 수 있다.) 사용자는 제품 페이지의 개인 정보 관련 사항들을 확인하여 앱을 다운로드 할지 결정한다. 더 자세한 사항은 다음에 자세히 설명한다. App privacy details on the App Store

App Store의 제품 페이지에는 사용자가 다운로드하기 전에 앱의 개인 정보 정책을 이해하는 데 도움을 준다. 다음 사진에서 확인할 수 있다.

Requesting Access Permission

사용자 데이터나 보호된 resources를 사용하기 전에, 사용자의 permission(동의)를 얻어야 한다. 시스템은 사용자 개인 정보 또는 보호된 resources의 액세스 요청을 볼 수있는 표준 alert을 제공한다. 앱이 왜 개인 정보를 필요로 하는지에 대한 설명과 alert 요청에 대한 설명을 제공해야 한다. 사용자는 설정 > 개인 정보 보호에서 선택한 사항들을 변경할 수 있다.

• Request permission only when your app cleary needs access to the data or resource: 앱에서 데이터나 리소스의 접근이 명백하게 필요로 할 때 엑세스 권한 요청을 해야 한다. 개인 정보나 기기의 기능(마이크, 카메라)에 대한 엑세스 권한 요청에 대해 사용자가 의심스러워하는 것은 자연스럽다. 특히 반드시 필요한 경우가 아니라면 더욱 그럴 것이다. 사용자가 엑세스 권한 요청이 필요한 기능을 사용할 때까지 기다리고, 해당 기능을 사용할 때 권한을 요청하는 것이 합리적이다. 위치 요청의 경우 location button을 사용하여 사용자의 위치를 공유할 수 있다.

• Request permission at launch only when the data or resource is necessary for your app to function: 앱이 작동하는데 데이터 또는 리소스가 필요한 경우에만 실행 시 권한을 요청한다. 앱이 이런 정보를 요청하는 이유가 명백하다면 사용자가 앱의 처음 실행 시간으로 인해 불편함을 느끼지 않을 것이다. 사용자가 앱을 실행하자마자 app trackig을 수행하고 싶다면, tracking 데이터를 모으기 전에 시스템 제공 alert를 표시해야 한다.

• Write copy that clearly describe how your app uses the data or resource you are requesting: 앱에서 요청하는 데이터나 리소스를 어떻게 사용하는지 정확하게 기술한 문서를 작성한다. 표준 alert는 앱 이름 뒤에 또는 거부 버튼이나 승인 버튼 앞에 puporse string 또는 usage description이라 불리는 문서를 보여준다.

이 문서는 간단하고 구체적이며 간결하고 이해하기 쉬운 완전한 문장으로 작성 해야한다. 이를 위해 수동태 사용을 자제하고 문장 끝에 마침표를 포함하는 문장 스타일의 capitalization을 사용한다.

다음은 purpose string의 예시이다.

다음은 표준 시스템 alert의 몇 가지 예시이다.

---

Displaying a Custom Screen Before a Permission Alert

현실적으로, 사용자는 앱이 권한을 요청하는 이유를 이미 인지하고 있다. 만약 권한 요청에 관한 추가적인 정보를 표시해야 한다면 system alert 전에 custom(사용자 정의) screen을 보여줄 수 있다. 다음 가이드라인은 카메라, 마이크, 위치, 연락처, 캘린더, tracking을 포함하여 보호된 데이터 그리고 리소스를 접근하는 system alert전에 나타나는 custom screen에 적용된다.

Include only one button and make it clear that it opens the system alert

Custom screen에 alert를 열지 못하는 버튼을 생성하면 사용자는 결정을 선택할 수 없으므로 사용자는 오해를 할 수 있다. 다른 유형의 오해는 "Allow"라는 제목의 버튼을 custom screen에 사용하는 것이다. 만약 화면의 버튼의 제목이 alert를 여는 버튼과 의미적, 시각적으로 유사하다면 사용자는 제목의 의미가 무엇인지 인지하지 못한 채 alert의 버튼을 선택할 것이다. 이를 방지하기 위해서 Custom scree에 "Continue"또는 "Next"라는 1개의 버튼을 생성하여 사용자에게 system alert를 여는 동작이라고 명확하게 알리도록 설계한다.

Don't add additional actions to your custom screen

예를 들어 close(닫기) 또는 cancel(취소)와 같은 옵션을 제공하여 system alert를 보지 않고 화면을 떠나는 방안을 제공하는 것을 피한다.

---

Clarifying Tracking Request

App tracking(앱 추척)이란 민감한 문제다. 그러나 어떤 경우에서는, tracking의 장점을 명확하게 기술하는 custom screen을 보여주는 것이 유용할 수 있다.

Never precede the system-provide alert with a custom screen that could confuse or mislead people

사용자는 때떄로 system alert를 읽는 것 없이 빠르게 건너뛰기 위해 탭을 누른다. 이러한 행동을 이용하여 결정에 영향을 미치는 custom messaging screen은 App Store의 검토에서 rejection(거부) 될 것이다. 여기 rejection이 된 몇 가지 custom-screen이 있다.

1. Incentive
   

권한 허가의 대가로 인센티브를 제공할 수 없다. 권한 허가에 대한 보상을 사용자에게 제한할 수 없으며, 사용자가 track을 허용하기 전까지 기능이나 콘텐츠를 유지하거나 앱을 사용하지 못하게 할 수 없다.

2. Imitation request
   

system alert와 유사한 custom screen을 만들지 마라. 사용자는 alert 이전 화면에서 아무것도 허용하고 싶지 않을 수 있기 때문에 특히 "Allow"나 이와 유사한 용어의 이름을 가진 버튼을 생성하여 사용자를 혼란스럽게 만드는 것을 피한다.

3. Alert image
   

표준 alert의 이미지를 보여주지 말고 수정하지 마라.

4. Alert annotation
   

System alert의 "Allow" 버튼에 사용자의 관심을 끄는 어떠한 시각적인 신호도 생성하지 마라.

---

Using the Location Button

iOS15 이상부터 Core Location은 버튼을 제공하여 사용자의 위치를 액세스할 수 있는 권한을 앱에 부여한다. 앱의 location 버튼의 외형은 앱의 UI마다 다를 수 있지만 즉시 알아볼 수 있게 설계 해야 한다.

location 버튼은 기기의 위치를 요청할 수 있는 임시 권한을 앱에 부여한다. 만약 권한 승인의 항목이 없는 경우 location button을 tapping(탭) 하면 standard alert에서 "한번 허용"한 효과와 동일하다. 하지만 이전에 사용자가 While using the App(앱을 사용하는 동안)이라는 항목을 선택했다면 location 버튼을 탭 하는 것은 앱의 상태에 아무런 변화도 일으키지 않는다. apple developer 가이드에서, 다음 2개의 버튼을 볼 수 있다. LocationButton (SwiftUI) CLLocationButton(Swift).

사용자가 처음으로 앱을 열고 그리고 location 버튼을 탭 하면 시스템은 standard alert를 보여준다. Alert는 버튼을 사용하여 앱의 위치 액세스를 조작하는 방법을 이해하도록 돕고, 위치 공유가 시작될 때 location indicator(위치 표시기: 사용자의 현재 위치를 나타냄)를 상기시킨다.

사용자는 앱의 위치 권한 액세스를 한 번만 부여하려고 할 때 location button을 탭 하면 된다. 사용자가 앱의 동작을 멈추고 종료하면 위치 권한이 만료된다.

Consider using the location button to give people a lightweight way to share their location for specific app features: 앱의 특정 기능을 위해 위치를 공유하는 간편한 방법을 제공하려면 location 버튼을 사용해라. 예를 들어 사용자의 위치는 메시지나 post(게시글)에 위치를 포함하거나 매장을 찾거나, 사용자의 위치에서 마주친 건물, 동물, 식물을 확인하는 데 도움이 될 수 있다. 만약 사용자가 앱에 "Allow Once"권한을 자주 부여한다면 alert를 띄우는 것 없이 위치를 공유하는 방법도 있다.

Consider customizing the location button to harmonize with your UI: 앱의 UI와 location 버튼이 조화를 이루도록 버튼을 customizing 해라. Customizing은 다음과 같이 할 수 있다.

• Choose the system-provided title that works best with your features, such as "Current Location" or "Share My Current Location"

• Choose the filled or outlined location glyph

• Select a background color and color for the title and glyph

• Adjust the button's corner radius

사용자가 location 버튼을 인식하고 신뢰하기 위해서, 다른 시각적인 요소들은 customizable 할 수 없다. 또한 시스템은 명암 대비가 낮은 색상 조합 또는 너무 높은 투명도를 가진 문제들에 대해 경고하여 버튼을 시각적으로 잘 보이게 만든다. 이러한 문제들을 해결하는 것뿐만 아니라 텍스트가 버튼에 잘 맞는지 확인할 필요가 있다. 예를 들어 버튼의 텍스트는 접근성 텍스트 크기 및 다른 언어로 번역될 때 잘리는 현상이 없어야 한다.

Important
시스템이 location 버튼에서 일관된 문제를 인식한다면 사용자가 탭을 누를 때 기기의 위치에 대한 접근 권한을 부여하지 않을 것이다. 이는 사용자들이 앱에 대한 신뢰를 잃게 만드는 원인이 될 수 있으니 조심해야 한다.

---

Using the Microphone in a ShazamKit App

ShazamKit은 오디오 샘플을 ShazamKit 카탈로그와 custom 오디오 카탈로그를 사용하여 음성 인식을 한다. iOS 15 이상부터 앱은 ShazamKit을 사용하여 다음과 같은 기능을 한다.

• Enhancing app experiences with graphics that correspond with the genre of currently playing music: 현재 재생 중인 음악 장르에 맞는 그래픽으로 앱 만족도 향상

• Making media content accessible to people with hearing disabilities by providing closed captions or sign language that syncs with the audio: 오디오와 동기화되는 자막 또는 수화를 제공하여 청각 장애가 있는 사용자가 콘텐츠에 액세스하는 기능 제공

• Synchronizing in-app experiences with virtual content in contexts like online learning and retail

음성 샘플을 얻기 위해 기기의 마이크가 필요한 경우, 이것에 대한 권한을 요청해야 한다. 다른 유형의 권한 요청과 마찬가지로 마이크 권한 요청이 필요한 이유를 사용자에게 설명하는 것은 중요하다.

ShazamKit이 마이크 액세스 권한을 받은 후에 다음 지침을 따라라.

• Stop recording as soon as possible: 녹음을 최대한 빨리 종료해라. 사용자는 인식을 위해 음성 권한을 허용할 때 마이크가 항상 켜져 있는 것을 원치 않는다. 개인 정보를 보호하기 위해 녹음을 할 때만 음성 권한을 허용한다.

• Let people opt in to storing your app’s recognized songs to their iCloud library: 사용자가 앱에서 인식한 노래를 사용자의 iCloud에 저장하도록 한다. 만약 앱이 인식된 노래를 iCloud에 저장하는 경우 사용자에게 이 작업을 승인할 수 있는 방법을 먼저 제공한다. 음악 인식 제어와 Shazam app은 인식된 노래의 소스(제목?)만 보여주지만 사용자는 인식된 콘텐츠를 저장할 수 있는 것에 편리함을 느낄 것이다.

ShazamKit