- Total
꿈꾸는리버리
HIG읽기 : Accessing User Data and Resources 본문
User Data and Resources 접근의 중요성
유저의 프라이버시는 가장 중요한 문제이다.
사람들이 당신의 app을 믿을 수 있게 하기 위해서 프라이버시 관련 data와 resource를 요구할 때 왜 쓰는지 분명하고 투명하게 알려줘야 한다.
애플은 사용자의 개인정보를 아주 중요하게 여긴다. 그래서 애플 "앱"에서도 개인정보에 접근을 하거나 사용을 해야 할 때 사용자에게 허락을 받고 사용해야 한다. 그리고 허락을 받기 위해서 해당 정보를 어떻게, 어디에, 무엇을 위해 사용하는지 보여주어야 한다. (이를 지키지 않을 시 해당 앱이 리젝될 수 있다.)
ex) 유저에게 access를 위한 permission 요청 예시
- 개인 정보 : 지역, 건강, 금융, 연락처, 기타 개인적인 식별 정보 등
- User-generated content : 이메일, 메시지, 캘린더정보, 사진, Apple Music에서의 활동기록 등
- 보호된 resources : 블루투스 기기, Wi-Fi 연결, 네트워크 등
- 장치 기능 : 카메라, 마이크 등
User Data and Resources 접근 설계법
1️⃣ app을 출시하거나 업데이트할 때, App store에 앱이 수집할 프라이버시 관련 데이터를 대해 자세하게 제공하라.
새로운 앱이나 업데이트된 앱을 제출할 때 개인 정보 보호 관행과 수집한 개인 정보 관련 데이터에 대한 세부 정보를 제공해야 앱 스토어가 제품 페이지에 정보를 표시해야 한다.(App Store Connect에서 언제든지 이 정보를 관리할 수 있다.)
App store에 등록함으로 유저가 앱을 다운 받기 전에 해당 앱을 다운 받을지 안 받을 지 결정을 할 수 있게 된다.
2️⃣ Access Permission 요청하기
- user data나 protected resources를 사용하기 위해서는 먼저 유저의 허락을 받아야 한다.
- 시스템은 사용자의 개인 정보 또는 보호된 리소스에 대한 액세스 요청을 볼 수 있는 표준 알림을 제공한다.
개발자가 앱에 항목이 필요한 이유에 대한 설명을 입력하면 시스템이 이 설명을 경고에 표시한다.
( 사용자는 설정 > 개인 정보에서 설명을 보고 선택한 내용을 직접 업데이트할 수도 있다. )
1) 명확하게 필요할 때만 Access permission을 요청하라.
일반적으로 유저는앱이 개인 정보를 요청하거나 장치에 접근하려고 하면 의심한다.
그렇기 때문에 앱을 시작하자마자 앱의 기능을 수행하는데에 필요한 모든 권한을 요청하기 보다는, 유저가 app을 쓰다가 access가 필요한 기능을 사용할 때 permission 요청을 하는 것이 좋다.
ex)
위치 요청의 경우 위치 단추를 사용하여 사용자에게 위치를 즉시 공유할 수 있는 방법을 제공할 수 있다. 자세한 내용은 위치 단추 사용을 참조하십시오.
2) app 구동에 access가 필수적이라면 launch에서 요청하라.
1번에서 말했던 것처럼 시작화면에서 모든 권한을 요청하는 것은 선호하는 방법은 아니지만, 만약 launch-time에서 접근이 필수적이고 app에서 유저들의 정보를 왜 필요로 하는지만 명확하게 알려준다면 launch-time에 access permission을 요청해도 된다.
(뒤의 "유저들의 정보를 왜 필요로 하는지만 명확하게 알려주는 방법"에 대한 내용인 4️⃣번 참고)
ex) 배달의 민족 앱을 처음 다운 받아서 access를 요청하는 부분들을 캡쳐해봤다. 앱을 다운 받고 음식 검색을 할 때 바로 인근의 음식점들의 데이터를 수집해와야해서 현재 위치 설정을 위한 modal 창이 떴다.
하지만 access 요청을 하는 flow가 좋다는 생각이 들었다. 특히 첫번째, 두번째 캡쳐 사진에서 접근권한 허용 modal(2번째 사진)이 뜬 후에 확인버튼을 누르면 allow 버튼이 있어야 할 거 같은데,, 또,, 뒤에서 알아보겠지만, 2번째 사진에서의 "확인"보다는 애플에서는 "다음", "계속"과 같은 멘트를 제한한다.
3) 유저 data를 어떻게 쓸건지 명확하게 describe하라.
< Alert 창 구조 >
app 이름과 요청하는 권한 서술
⬇️
어떻게 쓰는지에 대한 내용 (a purpose string / usage description string)
⬇️
permission 승인/거부 버튼
ex) "Medium" 앱 이름과 함께 noification 권한 요청 -> noification을 어떻게 사용할 건지에 대한 내용 -> permission 승인/거부 버튼
개발자는 어떤 권한을 요청하는지와, 해당 권한을 어떻게 사용할 건지를 작성하면 된다.
a purpose string / usage description string은 간략하고 명확한 문장으로 강압적이지 않으며, 직설적이고 구체적이며 이해하기 쉽게 작성해야 한다.
문장 형식의 대문자화를 사용하고, 수동적인 표현을 피하고 끝에 마침표를 찍어야 한다.
ex) apple store 심사시 빠꾸 당한 거랑 통과 당한거 예시
통과 : 앱이 데이터를 수집하는 방법과 이유를 명확하게 설명하는 활성 문장
빠꾸 : 애매하고 정의되지 않은 정당성을 제공하는 수동적인 문장, 명분이 서지 않는 명령형 문장
ex) a standard system alert 예시
아닛 세번째 예시 명령형 아님 ?
"Allow"라는 단어가 들어가서 요청으로 느낄 수 있는 custom screen 금지 했는데,,? 라는 질문을 했었는데
3️⃣ Permission alert 띄우기 전에 custom screen 보여주기
사람들이 context 속에서 permission 요청을 하는 이유를 미리 알고 permission alert을 마주하게 되면 좋겠지만, 그렇지 않을 때가 있다. 만약 추가적인 세부사항을 보여줘야 한다면 permission alert에 세부사항을 적기 보다는 permission alert가 뜨기 전에 custom screen을 보여줘라.
1) custom screen에서 permission alert을 띄우는 버튼은 1개여야 한다.
만약 permission alert이 뜨지 않는 action을 수행하는 button이 있다면 사용자는 날 낚나..? 하는 생각이 들 수 있다.
따라서 버튼은 하나로 두고 permission alert에서 허용과 불허용을 선택하기 전에 다른 화면으로 넘어가게 하지 마라.
2) custom screen에 "Allow" 버튼은 두면 안 된다. 대신 "Continue” 이나 “Next” 버튼을 두라.
custom screen에서 버튼을 누른다고 permission이 허용되는 것은 아니기 때문에 사용자의 혼란을 초래할 수 있다. 따라서 custom screen에서 permission alert으로 넘어가는 버튼으로 "Continue” 이나 “Next”이라고 해서 해당 작업이 시스템 경고를 여는 것임을 명확히 한다.
3) alert과 다른 디자인의 버튼
화면의 단추가 경고의 허용 단추와 의미 및 시각적 무게가 비슷하면 사용자는 의미 없이 경고의 허용 단추를 선택할 수 있다.
-> 정리를 하면, custom screen에는 permission alert에서 요구할 권한을 설명하는 screen일 뿐으로,
반드시 사용자가 custom screen에서 요청 권한 내용을 확인하고 한 flow로
permission alert으로 넘어가 해당 내용의 권한 허용 여부를 판단하게 해야 한다.
4️⃣ Tracking 요청 분명하게 말하기
app tracking은 민감한 주제이기 때문에 tracking의 필요한 이유와 함께 사용자가 tracking을 허용했을 때 어떤 이득이 발생하는지에 대한 내용을 custom screen에 작성하는 것이 좋을 때가 있다.
1) 절대 permission alert 내용에 혼란을 주는 내용을 custom screen에 두지 마라.
사람들은 custom screen의 내용을 진지하게 읽고 넘어가지 않기도 하기 때문에 이러한 점을 이용해서 permission alert의 권한 허용을 더 많이 하게끔 유도하는 앱은 app store review에서 걸러집니다 ^^
ex) app store review에서 reject이 되는 custom screen의 예시
- incentive를 제공해서 사용자가 허용하도록 유인하는 custom screen
- "Allow"라는 단어가 들어가서 요청으로 느낄 수 있는 custom screen
- permission alert의 이미지를 넣어둔 custom screen
- permission alert이 팝업으로 떴을 때 custom screen의 배경이 보이도록 해서 permission alert의 Allow를 유도하는 custom screen
5️⃣ Using the Location Button
위치 버튼은 앱에 기기 요청할 수 있는 임시 권한을 가진다.
만약 앱이 위치 승인 권한을 가지고 있지 않을 경우에 해당 버튼을 누르면 "Allow once"와 같은 효과를 가진다.
(만약 While Using the App이라면 기존 상태를 유지한다. )
유저가 처음 앱을 열고 위치 버튼을 탭했을 때 a standard alert가 보여짐으로 사용자는 버튼을 사용하는 동안만 자신의 위치에 접근할 수 있다는 것을 이해하게 된다. 그리고 사용자가 앱 사용을 중단하면 엑세스 권한 허용이 만료되고 재 접속시 해당 버튼을 탭하면 엡에 일회성으로 위치 엑세스 권한을 허용된다.
위치 버튼을 통해 특정 앱 기능에 대해 위치를 공유할 수 있는 간편한 방법을 제공하라
-> 예시를 못 찾았음 ㅠㅠ 네이버 지도 같은 거는 이거 아직 안쓰는 거 같던데 ㅠㅠ
ex) 카카오 지하철 앱 --> GPS를 끄고 킬 수 있는 버튼이 있음
ex)
For example, your app might help people attach their location to a message or post, find a store, or identify a building, plant, or animal they’ve encountered in their location. If you know that people often grant your appAllow Once permission, consider using the location button to help them benefit from sharing their location without having to interact with the alert.
앱은 사람들이 메시지나 게시물에 위치를 첨부하거나, 상점을 찾거나, 해당 위치에서 만난 건물, 식물 또는 동물을 식별하는 데 도움이 될 수 있습니다. 사람들이 앱에 한 번 허용 권한 을 자주 부여한다는 사실을 알고 있다면 위치 버튼을 사용하여 알림과 상호 작용할 필요 없이 위치를 공유할 수 있는 이점을 고려하십시오.
UI와 조화를 이루도록 위치 버튼을 사용자 정의하는 것을 고려하라.
- "현재 위치" 또는 "나의 현재 위치 공유"와 같이 기능에 가장 잘 맞는 시스템 제목을 선택
- 채워지거나 윤곽이 그려진 위치 글리프 선택 ( 글리프 : 문자를 형상화한 이미지 )
- 제목과 글리프의 배경색과 색상을 선택
- 버튼의 모서리 radius 조정
사람들이 위치 버튼을 인식하고 신뢰할 수 있도록 다른 시각적 attributes는 사용자 지정할 수 없습니다.
이러한 system은 대비가 낮은 색상 조합 또는 너무 많은 반투명도를 지양함으로 위치 버튼을 읽기 좋게 유지한다.
또한 텍스트가 button에 맞는지 확인해야 합니다. button 텍스트는 모든 접근성 텍스트 크기와 다른 언어로 번역될 때 잘리면 안된다.
IMPORTANT
system에서 위치 버튼과 같은 디자인을 사용해서 사람들이 탭할 때 앱에 기기 위치에 대한 액세스 권한이 부여되지 않을 때, 이 버튼은 다른 앱별 작업을 수행할 수 있지만 위치 버튼이 예상대로 작동하지 않으면 사람들이 앱에 대한 신뢰를 잃을 수 있습니다.
-> 너무 커스텀 입맛대로 하지마라 ..
6️⃣ Using the Microphone in a ShazamKit App
ShazamKit은 오디오 샘플을 ShazamKit 카탈로그 또는 사용자 지정 오디오 카탈로그와 일치시켜 오디오 인식을 가능하게 한다.
( iOS 15 이상에서 앱은 ShazamKit을 사용하여 다음과 같은 기능을 활성화할 수 있습니다. )
- 현재 재생 중인 음악 장르에 맞는 그래픽으로 앱 경험 향상
- 오디오와 동기화되는 자막 또는 수화를 제공하여 청각 장애가 있는 사람들이 미디어 콘텐츠에 액세스 가능
- 온라인 학습 및 소매와 같은 맥락에서 가상 콘텐츠와 앱과의 경험 동기화
앱이 인식할 오디오 샘플을 가져오기 위해 장치 마이크가 필요한 경우 액세스 권한을 요청해야 한다. 모든 유형의 권한 요청과 마찬가지로 사용자가 액세스 권한을 요청하는 이유를 이해하도록 돕는 것이 중요하다.
ShazamKit이 활성화된 기능에 대해 마이크에 액세스할 수 있는 권한을 받은 후 다음 지침을 따르라.
가능한 한 빨리 녹음을 중지하라.
사람들이 앱에서 인식을 위해 오디오를 녹음하도록 허용할 때 마이크가 켜져 있을 것이라고 생각하지 않는다. 개인 정보를 보호하기 위해 필요한 샘플을 얻는 데 걸리는 시간 동안만 기록하라.
사람들이 앱에서 인식한 노래를 iCloud 보관함에 저장하도록 선택합니다.
앱이 인식된 노래를 iCloud에 저장할 수 있는 경우 사람들에게 먼저 이 작업을 승인할 수 있는 방법을 제공하라. 음악 인식 컨트롤과 Shazam 앱 모두 앱을 인식된 노래의 소스로 표시하지만 사람들은 라이브러리에 콘텐츠를 저장할 수 있는 앱을 제어할 수 있다는 점이 장점이다.
NOTE
내용이 생각보다 길어서 오래 걸렸. 간혹 이런 사용자가 있다 ~하면서 설명한 그 사용자가 나라서 살짝 찔렸다.. ㅋㅋㅋ 애플이 사용자를 많이 고려해서 앱을 심사하는구나를 느낄 수 있는 챕터였던 거 같다. 애플 앱스토어에 앱이 등록되기 위해서는 많은 준비가 필요하겠구나라는 생각을 했고 얼른 앱을 올리고, 앱 스토어에서 내 앱을 다운 받을 수 있는 날이 오길 ! 아자아자, 오늘도 화이팅 ! 🤩 good luck River ! 🍀
출처
Accessing User Data - App Architecture - iOS - Human Interface Guidelines - Apple Developer
Accessing User Data and Resources User privacy is paramount. To help people trust your app, it’s crucial to be transparent about the privacy-related data and resources you require and how you use them. For example, you must request permission to access:
developer.apple.com
'오뚝이 개발자 > human interface' 카테고리의 다른 글
| HIG읽기 : iOS Design Theme (0) | 2022.05.18 |
|---|---|
| HIG읽기 : Setting (0) | 2022.04.09 |
| HIG읽기 : Navigation (0) | 2022.04.09 |
| HIG읽기 : Modality (0) | 2022.04.06 |
| HIG읽기 : Loading (0) | 2022.04.04 |
