[iOS HIG] Human Interface Guidelines - App Architecture (6) Accessing User Data and Resources 정리

https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/accessing-user-data/

Accessing User Data - App Architecture - iOS - Human Interface Guidelines - Apple Developer

유저 프라이버시는 매우 중요하다. 프라이버시와 고나련된 데이터와 자료, 그리고 그것을 어떻게 사용하는지에 대해 투명해야 사용자들이 앱을 믿을 수 있다. 이하와 같은 정보에 접근하기 위해서는 반드시 허락을 구해야 한다:

• 위치, 건강, 재정, 연락처 등의 개인 정보
• 이메일, 메시지, 캘린더 데이터, 연락처, 게임플레이 정보, 애플 뮤직 액티비티, 홈키트 데이터, 오디오, 비디오, 그리고 사진 등 유저가 만들어낸 컨텐츠들
• 블루투스 주변기기나 홈 자동화 기기, 와이파이 연결, 로컬 네트워크 등의 보호된 자원들
• 카메라나 마이크와 같은 디바이스 capability

iOS 14.5와 iPadOS 14.5에서부터는 사용자의 허락을 구하는 데 있어 반드시 AppTrackingTransparency framework를 사용해야 한다.

새 앱이나 업데이트된 앱을 제출할 때 반드시 프라이버시 활용과 수집한 프라이버시 관련 데이터에 관한 자세한 사항을 제공해야 한다. 앱스토어는 앱의 프로덕트 페이지에 해당 정보를 비치하고, 유저들은 앱을 다운로드 하기 전에 프라이버시 관련 사항을 프로덕트 페이지에서 확인한다.

 

1. Requesting Access Permission

유저 데이터나 보호된 자원에 접근하기 전에 반드시 사용자의 허가를 받아야 한다. 시스템은 사용자에게 그들의 정보나 보호된 자원에 접근할 권한을 요청하는 표준적인 알러트를 제공한다. 왜 앱에 해당 정보들이 필요한지 설명하면 시스템은 알러트에 그 설명을 띄운다. 사용자들은 Settings > Privacy에서도 설명을 보고 선택을 변경할 수 있다.

• 해당 데이터나 자원에 접근할 필요가 꼭 있을 때에만 접근 권한을 요청하라: 특별한 이유가 없다면 사용자들은 개인 정보나 디바이스 제어에 접근하는 요청을 의심스럽게 생각할 것이다. 이상적인 것은 사용자가 해당 접근이 필요한 기능을 직접 사용할 때까지 허가 요청을 기다리는 것이다.
• 앱이 작동을 위해 데이터나 자원이 필요한 경우에만 론치시에 허가를 요청하라: 앱이 왜 해당 정보를 필요로하는지가 명확하다면 사용자는 론치시에 접근 요청을 받아도 덜 꺼려할 것이다. 사용자가 론칭할 때 바로 앱 트래킹을 시작하고 싶으면, 트래킹 데이터를 수집하기 전 반드시 시스템에서 제공하는 알러트를 띄워야 한다.
• 요청하는 데이터나 자원을 앱이 어떻게 사용할 것인지 명확히 설명하는 문구를 작성하라: 표준 알러트는 앱 이름 뒤, 그리고 사용자가 허가하거나 거절하는 행위를 하기 위한 버튼 전에 문구를 띄워 보여준다. 직설적이고 구체적이며 이해하기 쉬운, 짧고 완전한 문장을 목표로 하라. 문장에 어울리는 대소문자 구별을 하고 수동체를 피하고, 마지막에는 온점으로 끝내라.

2. Displaying a Custom Screen Before a Permission Alert

사용자들이 맥락을 통해 왜 접근 허가가 요청되는지를 이미 알고 있는 게 가장 이상적이다. 추가적인 설명을 제공해야 한다면 시스템 알러트가 나타나기 전에 커스텀 화면을 띄워줄 수 있다.

• 버튼은 하나만 사용하고 그 버튼이 시스템 알러트를 연다는 것을 확실히 하라: 커스텀 화면이 알러트를 열지 않는 버튼까지 포함하고 있을 경우 사용자들은 조종당하고 있다는 느낌을 받을 수 있다. 또한 커스텀 화면의 버튼에 "Allow" 등의 제목을 붙이는 것도 좋지 않다. 커스텀 화면의 버튼이 의미적, 시각적으로 알러트 뷰의 버튼과 비슷하다면 사용자들은 알러트의 허용 버튼을 의도하지 않고 그냥 누르게 될 수도 있다. 버튼을 눌면 시스템 알러트를 연다는 것을 명확하게 하는 "Continue"나 "Next" 같은 단어를 선택하라.
• 커스텀 스크린에 더 추가적인 동작을 넣지 마라: 닫기나 취소 버튼 등, 시스템 알러트를 보지 않고 화면을 떠날 수 있는 방법을 주지 않아야 한다.

3. Clarifying Tracking Requests

앱 트래킹은 민감한 사안이다. 때로는 트래킹의 장점을 확실히 설명하는 커스텀 화면을 제공하는 게 좋을 때도 있다.

• 사용자를 헷갈리게 할 수 있는 커스텀 스크린을 시스템 알러트 이전에 사용하지 마라: 사용자들은 때때로 알러트를 해제하기 위해 제대로 읽지 않고 빠르게 탭한다. 그런 행동을 이용해서 이득을 취하는 것은 앱스토어 리뷰에서 거절당하는 것으로 이어질 것이다. 
• 금지된 커스텀 화면 디자인이 여러 개 있는데, 이는 거절 요소이기 때문에 피하라.

4. Using the Location Button

iOS 15 이후로 코어 로케이션은 태스크가 위치를 필요로하는 순간에 사용자들이 위치 권한을 허용할 수 있도록 하는 버튼을 제공한다.

위치 버튼은 앱이 디바이스 위치를 요청할 수 있는 일시적인 권한을 준다. 앱에 권한이 없다면 위치 버튼을 누르는 경우 표준 알러트에서 Allow Once를 누르는 것과 같은 효과를 준다. 만일 사용자가 이전에 While Using the App로 설정했다면, 위치 버튼을 누르는 것은 앱의 상태에 영향을 주지 않는다.

사용자가 처음 앱을 열고 로케이션 버튼을 탭하면 시스템은 표준 알러트를 띄운다. 알러트는 사용자들의 위치에 대한 앱의 접근을 버튼이 어떻게 제한하는지 설명한다. 또한, 공유가 시작되면 사용자들에게 위치 인디케이터를 띄워 상기시킨다.

사용자들이 버튼의 액션에 대해 이해하고 있음을 확인하면, 그들은 위치 버튼을 눌러 그들의 위치에 접근할 일시적인 권한을 허용한다. 일시 권한은 사용자가 앱을 그만 사용하면 만료되지만, 사용자들은 버튼의 행위에 대해 굳이 다시 이해하고 확인할 필요가 없다.

• 사용자들이 특별한 앱 기능을 위해 위치를 공유하는 가벼운 방법이 될 수 있도록 위치 버튼을 사용하라
• UI와 조화를 이루도록 위치 버튼을 커스터마이징해라: 색깔이나 코너 radius 등을 조절하는 등. 사용자들이 위치 버튼을 인식하고 믿을 수 있게 하기 위해서 다른 시각적 특성들은 커스텀하지 못한다. 또한 버튼을 읽기 힘들게 하는 색상 등에는 시스템이 경고를 준다. 텍스트와 버튼이 맞도록 할 필요도 있다(사이즈나 언어 등이 달라질 때)

중요한 점은 시스템이 커스텀 위치 버튼에서 지속적으로 문제를 파악하면 앱에 디바이스 위치 접근 권한을 넘겨주지 않는다는 것이다.

 

5. Using the Microphone in a ShazamKit App

iOS 15 이후부터 앱들은 ShazamKit을 이용하여 다양한 기능을 수행할 수 있다.

디바이스 마이크에 접근하기 위해서는 액세스 권한을 요청해야 한다. 다른 권한 요청과 마찬가지로, 사용자들에게 왜 접근이 필요한지 이해시키는 것이 중요하다.

• 최대한 빨리 녹음을 멈춰라: 사용자들은 인식을 위해 음성 녹음을 허락할 때 마이크가 계속 켜져있는 것을 기대하지 않는다. 프라이버시를 위해 필요한 샘플을 얻을 정도로만 녹음하도록 하라.
• 사용자의 iCloud 라이브러리에 앱이 인식한 노래를 저장하는 것에 대한 동의를 구하라: 만약 앱이 인식한 노래를 아이클라우드에 저장할 수 있다면, 우선 사용자들이 이 행위를 승인할 수 있는 길을 제시하라.