[AHIG] App Architecture - Accessing User Data (1/2)

이 글은 Apple Human Interface Guidelines를 참고하여 작성하였습니다.

작성자 : 홍수정

 

제 블로그에도 포스팅 하였습니다 :)

https://velog.io/@my_youth99/HIG-Accessing-User-Data-12

 

Accessing User Data and Resources

✨사용자 개인 정보는 가장 중요✨

사용자들이 당신의 앱을 신뢰하기위해선 당신이 필요로 하는 사생활 관련 데이터 및 자원과 그것들을 어떻게 사용하는 지를 투명하게 공개하는 것이 중요하다. (ex. 액세스 권한 요청)

• 위치, 건강, 재무, 연락처 및 기타 개인 식별 정보를 포함한 개인 데이터
• 이메일, 메시지, 캘린더 데이터, 연락처, 게임 플레이 정보, Apple Music 활동, HomeKit 데이터, 오디오, 비디오 및 사진 콘텐츠와 같은 사용자 생성 콘텐츠
• Bluetooth 주변 장치, 홈 자동화 기능, Wi-Fi 연결 및 로컬 네트워크와 같은 보호된 리소스
• 카메라 및 마이크와 같은 장치 기능
  

!Important!

iOS 14.5 및 iPad부터 OS 14.5에 시작해서, 앱 추적 투명성 프레임워크를 사용하여 사용자들을 추적하거나 사용자 장치의 광고 식별자에 접근하기를 원한다면 사용자의 허가를 요청해야 한다.
자세한 내용은 사용자 개인 정보 및 데이터 사용을 참조

 

 

새로운 앱이나 업데이트된 앱을 제출할 때 개인 정보 보호 관행과 수집한 개인 정보 관련 데이터에 대한 세부 정보를 제공해야 앱 스토어가 제품 페이지에 정보를 표시할 수 있다.
(App Store Connect에서 언제든지 이 정보를 관리할 수 있다.)

 

사람들은 앱을 다운받기 전에 제품 페이지의 개인 정보 정보를 읽은 후, download 결정의 여부를 정한다. 자세한 내용은 앱 스토어의 앱 개인 정보 세부 정보를 참조.

앱의 앱 스토어 product page는 사람들이 앱을 다운로드하기 전에 앱의 개인 정보 보호 관행을 이해하는 데 도움이 된다.

Requesting Access Permission

사용자 데이터 또는 보호된 리소스를 사용하려면 먼저 사용자의 사용 권한을 얻어야 한다.

시스템은 개인 정보 또는 보호된 리소스에 대한 액세스 요청을 볼 수 있는 일반적인 alert를 제공한다.

앱에 항목이 필요한 이유에 대한 설명을 입력하면 시스템이 이 설명을 alert에 표시한다. 또한 사용자들은 설정>개인 정보 에서 설명을 보고 자신의 선택에 따라 업데이트할 수 있다.

1) Request permission only when your app clearly needs access to the data or resource.

앱에 데이터 또는 리소스에 대한 액세스 권한이 분명히 필요한 경우에만 사용 권한을 요청한다.

개인 정보 요청이나 장치 기능에 대한 액세스에 대해 사용자들이 경계하는 것은 당연하며, 특히 그러한 필요성에 대한 명백한 요구가 없는 경우에는 더욱 그렇다.

이상적으로는 사람들이 실제로 액세스가 필요한 앱 기능을 사용할 때까지 사용 권한을 요청할 때까지 기다린다. 위치 요청의 경우에는 location button을 사용하여 즉시 사용자의 위치를 공유할 수 있게 해준다. 자세한 내용은 Using the Location Button을 참조.

2) Request permission at launch only when the data or resource is necessary for your app to function.

실행 시 앱이 작동하는 데에 데이터 또는 리소스가 필요한 경우에만 사용 권한을 요청한다.

앱에 정보가 필요한 이유가 분명할 때 사용자들은 요청되는 실행시간에 덜 시달린다. (이유가 타당하면 사용자들이 사용권한 요청때문에 걸리는 시간을 잘 기다릴 수 있다는 뜻 같다.)

사용자들이 앱을 실행하는 즉시 앱 추적을 수행하려면 추적 데이터를 수집하기 전에 시스템에서 제공하는 alert를 표시해야 한다. (자세한 내용은 Clearifying Tracking Requests 참조).

3) Write copy that clearly describes how your app uses the data or resource you’re requesting.

앱에서 요청하는 데이터나 리소스를 사용하는 방법을 명확하게 설명하는 복사본을 작성한다.

standard alert은 사용자의 앱 이름 뒤와 사용자가 권한을 승인하거나 거부할 때 사용하는 button 앞에 사용자의 복사본(purpose string 또는 usage description이라고도 함)을 표시한다.

간단하고 구체적이며 이해하기 쉬운 짧고 완전한 문장을 목표로로 해야한다. capitalization를 사용하고, 수동적인 음성을 피하고, 끝에 마침표를 포함한다. (developer 가이드는 Requesting Access to Protected Resources와 App Tracking Transparency 참조)

*capitalization이 뭔지 찾아봤더니 대략 이런 내용이다

대략 purpose string의 예시를 들고 있다. 어떻게 해야 올바른 purpose string인지 보여주고 있음.

 

👇standard system alert의 몇 가지 예

 

 

Displaying a Custom Screen Before a Permission Alert

이상적으로, 사용자들은 context에 따라 당신이 자신들의 허락을 요청하는 이유를 이미 알고 있다. 추가 세부 정보를 제공해야 하는 경우, system alert이 발생하기 전에 사용자 지정 화면을 표시할 수 있다.
다음 지침은 보호된 데이터 및 리소스에(카메라, 마이크, 위치, 연락처, 일정관리 및 추적) 액세스할 수 있는 권한을 요청하는 system alert전에 보여지는 사용자 지정 화면에 적용된다.

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

하나의 button만 포함하여 system alert이 열리는지 확인한다.

사용자 지정 화면에 경고를 열지 않는 button이 존재할 때 사용자들은 조작되었다고 느낄 수 있다. 이는 사용자들이 직접 선택을 하지 못하게 하기 때문이다.

또 다른 유형의 조작은 "Allow"와 같은 용어를 사용하여 사용자 지정 화면의 button에 제목을 붙이는 것이다.

화면의 button이 alert의 allow button과 의미 및 시각적 무게가 비슷해 보일 경우, 사람들은 의미 없이 경고 허용 단추를 선택할 수 있습니다. "Continue" 또는 "Next"과 같은 용어를 사용하여 사용자 지정 화면의 단일 button에 제목을 붙여 시스템 경고를 여는 작업임을 명확히 합니다.

=> button을 비슷하게 만들어서 사용자가 아무생각없이 허용을 누르게끔 만들지 말라는 말 같다. 구분을 주라는 말.

2) Don’t add additional actions to your custom screen.

사용자 지정 화면에 추가적인 action을 덧붙이지 마라.
예를 들어 닫기 또는 취소 옵션을 제공하는 등 system alert을 보지 않고 화면을 나갈 수 있는 방법을 제공하지 마라.