https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/launching/
Launching
launch 경험은 사람들이 앱에 대해 느끼는 방식에서 중요한 영향력을 미칩니다. 사람들이 사용하는 혹은 마지막에 앱을 열었던 후로 얼마나 지났는지와 상관없이 launch 경험은 빠르고 원활해야 합니다.
아래 가이드라인은 즐거운 launch 경험을 디자인하는 것을 도와줄 수 있습니다. 개발자 가이드의 경우 Responding to the Launch of Your App을 보시기 바랍니다.
Responding to the Launch of Your App
https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app
https://velog.io/@panther222128/Responding-to-the-Lauch-of-Your-App
launch 스크린을 제공할 수 있습니다. 시스템은 앱이 시작하는 순간에 launch 스크린을 표시하고, 빠르게 launch 스크린을 앱의 첫 번째 스크린으로 대체합니다. launch 스크린의 기능은 초기 컨텐트 로드를 수행하는 동안 사람들에게 앱이 빠르고 반응적이라는 인상을 주는 것입니다. launch 스크린으로부터 원활한 전환을 보장하려면 첫 번째 앱 스크린과 비슷한 단순한 스크린을 디자인하는 것이 좋고, launch 스크린 자체에 주의를 기울이지 않도록 해야 합니다. 가이드는 Launch Screen을 보시기 바랍니다.
Launch Screen
https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/launch-screen
https://velog.io/@panther222128/Visual-Design
적합한 orientation에서 launch해야 합니다. 앱이 portrait과 landscape 모드를 모두 지원하는 경우 기기의 현재 orientation을 사해 launch해야 합니다. 앱이 하나의 orientation에서만 동작하는 경우 해당하는 orientation에서 launch되어야 하며, 필요한 경우 사람들이 기기를 회전하도록 해야 합니다. 다른 이유가 없는 한 landscape 모드에 있는 앱은 방향을 바르게 지정해야 하며, 이는 기기가 왼쪽 혹은 오른쪽으로 회전되었는지와 상관이 없습니다. 가이드는 Adaptivity and Layout을 보시기 바랍니다.
Adaptivity and Layout
https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/
https://velog.io/@panther222128/Visual-Design
설정 정보를 먼저 요청하지 않아야 합니다. 사람들은 단지 앱이 작동하길 기대합니다. 다수의 사용자를 위한 앱을 디자인해야 하며, 자신의 필요를 충족시키기 위한 사람들은 원하는 다른 설정으로 조정할 수 있도록 해줘야 합니다. 가능한 기기 설정 및 기본값으로부터 설정 정보를 가져오거나 iCloud와 같은 싱크 서비스를 통해서 설정 정보를 가져와야 합니다. 설정 정보를 요청해야만 하는 경우 사람들이 앱을 처음 열 때 프롬프트를 통해 제공하는 것이 좋으며, 앱의 설정에서 이후에 수정할 수 있도록 해줘야 합니다.
인앱 라이센스 승인 및 조항 표시를 피해야 합니다. 앱스토어가 승인 및 조항을 표시함으로써 사람들이 앱을 다운로드하기 전에 읽을 수 있도록 해줘야 합니다. 앱 내에서 이러한 항목을 포함해야 하는 경우 사용자 경험을 해치지 않는 균형잡힌 방식으로 통합해야 합니다.
앱이 재시작될 때 이전 상태를 복원해야 합니다. 사람들이 앱의 이전 위치에 도달하기 위해 단계를 다시 밟지 않도록 해야 합니다. 앱의 상태를 보존하고 복원함으로써 사람들이 빠져나간 곳에서부터 계속할 수 있도록 해야 합니다.
다시 부팅하는 것을 권장하지 않아야 합니다. 재시작은 시간이 걸리고, 앱이 사용하기에 신뢰할 수 없으며 어려운 것처럼 보이도록 합니다. 시스템이 부팅되지 않는 한 동작하기에 어려운 메모리 혹은 다른 이슈를 갖는 경우 이와 같은 이슈를 알려줄 필요가 있습니다.
지나치게 빠르게 혹은 자주 앱의 평가를 요청하지 않아야 합니다. 첫 launch 이후 바로 평가를 요청하는 것(혹은 사람들이 앱 사용 중에 너무 자주 요청하는 것)은 좋지 않은 경험을 제공할 것이며, 받을 수 있는 유용한 피드백의 양을 감소시킬 것입니다. 정성들인 피드백을 장려하려면 사람들에게 평가를 요청하기 전에 앱에 대한 의견을 생각할 수 있는 시간을 줄 수 있어야 합니다. 평가에 대한 프롬프트를 선택 해제할 수 있는 방법을 제공해야 하며, 앱 평가를 강요하지 않아야 합니다.
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/onboarding/
Onboarding
온보딩은 새 사용자를 반기도록 해주고 재방문 사용자를 다시 연결할 수 있습니다. 빠르고 흥미롭고 교육적인 선택적 온보딩 경험은 사람들이 방해받지 않고 앱을 최대한 활용할 수 있도록 도와줍니다.
사람들이 즐기는 것을 돕는 온보딩을 제공해야 하며, 단순히 설정을 위한 것이 아니어야 합니다. 사람들은 앱에 대한 더 많은 것을 알 수 있는 기회에 고마움을 느끼지만, 단지 작동하길 기대하는 것도 맞습니다. 온보딩 경험에서 설정 혹은 라이센스 세부사항을 포함하는 것을 피해야 합니다. 가이드는 Launching을 보시기 바랍니다.
Launching은 이 글의 윗 부분에 있습니다.
액션을 빠르게 가져와야 합니다. 시스템이 launch 스크린을 초기 앱 스크린으로 교체한 후 사람들이 앱의 이용에 즉시 진입하고 앱을 즐길 수 있도록 해줘야 합니다. 튜토리얼 혹은 인트로 시퀀스가 필요한 경우 사람들이 건너뛰기 위한 방법을 제공하는 것이 좋으며, 재방문 사용자에게 자동으로 보여주지 않도록 해야 합니다.
도움 요청을 예측할 수 있어야 합니다. 사람들이 앱 사용에 막히는 순간을 파악할 수 있어야 합니다. 예를 들어 게임은 일시정지되었을 때 혹은 캐릭터가 발전하지 않을 때 유용한 팁을 보여줄 수 있습니다. 사람들이 처음으로 무언가를 놓친 경우에 튜토리얼을 다시 시작할 수 있도록 해줘야 합니다.
튜토리얼의 본질을 고수해야 합니다. 시작하는 사람들에게 가이드를 제공하는 것은 괜찮지만 교육은 좋은 앱 디자인의 대체가 되지 않습니다. 무엇보다 앱을 직관적으로 만들어야 합니다. 너무 많은 가이드가 필요한 경우 앱의 디자인으로 다시 돌아오시기 바랍니다.
배움을 즐겁고 유익하게 만들어야 합니다. 행동으로 배우는 것이 설명의 리스트를 읽는 것보다 더 재미있고 효과적입니다. 애니메이션과 상호작용을 사용해서 맥락에 맞게 점진적으로 알려줘야 합니다. 상호작용으로 나타나는 정적 스크린샷 표시는 지양해야 합니다.
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/loading/
Loading
컨텐트가 로딩될 때 비어있는 혹은 정적 스크린은 앱이 얼어붙은 것처럼 보이게 할 것이며, 결국 혼란을 초래하고 사람들이 앱 사용을 피하게 될 것입니다.
로딩중이라는 것을 명확하게 해야 합니다. 최소한 어떤 일이 발생하고 있다는 것을 알려주기 위해 활동 스피너를 보여줘야 합니다. 더 나은 경우는 사람들이 얼마나 기다려야 하는지 파악할 수 있도록 명시적인 진행상황을 표시하는 것입니다.
가능한 빠르게 컨텐트를 보여줘야 합니다. 사람들이 기대하고 있는 스크린을 보기 전에 컨텐트 로드를 기다리지 않도록 해야 합니다. 스크린을 즉시 보여주고 플레이스홀더 텍스트, 그래픽 혹은 애니메이션을 사용해서 어느 곳의 컨텐트가 아직 사용할 수 없는지 식별할 수 있도록 해야 합니다. 이 플레이스홀더 요소를 컨텐트 로드로 대체해야 합니다. 가능한 애니메이션이 재생중인 동안 혹은 사용자가 레벨 혹은 메뉴를 탐색하고 있는 동안 백그라운드에서 다가올 컨텐트를 사전에 로드해야 합니다.
로딩 타임을 가리기 위해 사람들을 교육하거나 즐길 수 있도록 해야 합니다. 게임플레이에 대한 힌트를 보여주거나 비디오를 보여주는 것 혹은 플레이스홀더 그래픽을 즐길 수 있도록 하는 것을 고려하시기 바랍니다.
위 이미지는 영상입니다. 영상을 확인하시려면 링크에서 확인하시기 바랍니다.
로딩 스크린을 커스터마이징하시기 바랍니다. 표준 진행상황 인디케이터도 괜찮지만 맥락과 벗어난 느낌을 줄 수도 있습니다. 더 몰입감 있는 경험을 위해 커스텀 애니메이션, 앱 혹은 게임의 스타일과 일치하는 요소 디자인을 고려하시기 바랍니다.
추가적인 가이드는 Progress Indicators를 보시기 바랍니다.
Progress Indicators
https://developer.apple.com/design/human-interface-guidelines/ios/controls/progress-indicators/
https://velog.io/@panther222128/Controls
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/modality/
Modality
모달은 사용자가 이전에 보고 있었던 것으로부터 분리되어 있으며, 빠져나오려면 명시적인 액션을 요구하는 임시 모드에서 컨텐트를 제공하는 디자인 테크닉입니다. 컨텐트를 모달로 제공하는 것은 아래와 같은 효과가 있습니다.
- 사람들이 작업을 스스로 내포하고 있는 혹은 면밀하게 관련이 있는 옵션의 집합에 초점을 맞출 수 있도록 해줍니다.
- 사람들이 중요한 정보를 받을 수 있도록 해주고, 필요한 경우 조취를 취할 수 있도록 해줍니다.
원문에서 이 위치에 보이는 이미지가 존재합니다. 링크를 통해서 보시기 바랍니다.
iOS는 앱의 특정 상황에서 사용할 수 있는 알림, 활동 뷰(혹은 공유 시트), 액션 시트를 제공합니다. 앱에서 커스텀 모달 컨텐트를 제공하기 위해 iOS 13 및 이후 버전은 아래 프리젠테이션 스타일을 지원합니다.
Sheet
시트 프리젠테이션 스타일은 기존 컨텐트를 부분적으로 덮는 카드처럼 나타나며, 덮지 않은 영역과의 상호작용을 방지하기 위해 해당 영역을 어둡게 합니다. 부모 뷰의 상단 edge 혹은 이전 카드는 사람들이 카드를 열었을 때 이전에 일시정지한 작업을 기억할 수 있도록 현재 카드 뒤로 숨겨집니다. 사람들은 카드를 아래와 같은 방법으로 해제할 수 있습니다.
- 스크린의 상단으로부터 아래로 스와이프합니다.
- 카드 컨텐트가 상단으로 스크롤될 때 스크린 모든 어느 곳에서든 아래로 스와이프합니다.
- 버튼을 탭합니다.
복잡한 작업을 하지 않는 비몰입형 모달 컨텐트에 시트를 사용하시기 바랍니다.
Fullscreen
전체스크린 프리젠테이션 스타일은 전체 스크린을 덮습니다. 이전 뷰는 시각적 분산을 최소화하면서 완전히 덮어집니다. 사람들은 전체 스크린 모달 뷰를 버튼 탭을 통해 해제할 수 있습니다.
비디오, 사진, 카메라 뷰와 같은 몰입형 컨텐트에 전체 스크린 모달을 사용하시기 바랍니다. 혹은 문서에 표시하는 것이나 사진 편집과 같은 복잡한 작업은 전체스크린으로 사용하시기 바랍니다.
NOTE
스플릿 뷰 창, 팝오버, 기타 전체스크린이 아닌 뷰 내에서 모달 컨텐트를 표시하기 위해 현재 컨텍스트 모달 뷰 스타일을 사용하는 경우 compact 환경에서 모달 컨텐트를 나타낼 때 시트를 사용하도록 전환해야 합니다.
합리적인 경우에 모달을 사용하시기 바랍니다. 선택을 결정하거나 현재 작업과 다른 작업 수행으로 사람들의 관심을 끄는 것이 중요한 경우에 모달 경험을 생성하시기 바랍니다. 모달 경험은 사람들이 현재 컨텍스트의 밖으로 나오도록 하고 해제를 위한 액션을 요구하기 때문에 명확한 이익을 제공할 수 있을 때에만 사용해야 합니다.
필수적인(그리고 이상적으로는 행동 수행이 가능한) 정보를 전달하기 위한 알림을 예약하시기 바랍니다. 보통 알림은 무엇인가 잘못되었기 때문에 나타납니다. 알림은 경험을 인터럽트하고 해제를 위한 탭을 요구하기 때문에 사람들이 이와 같은 알림을 정당하다고 느낄 수 있도록 하는 것이 중요합니다. 가이드는 Alerts를 보시기 바랍니다.
Alerts
https://developer.apple.com/design/human-interface-guidelines/ios/views/alerts/
https://velog.io/@panther222128/Views
모달 작업을 단순하고 간결하며 좁은 초점으로 유지해야 합니다. 앱 내에서 앱 생성을 피해야 합니다. 모달 작업이 너무 복잡하면 사람들은 모달 컨텍스트에 진입할 때 일시정지했었던 작업의 시야를 잃어버립니다. 사람들이 단계를 잃어버리거나 어떻게 이전 단계를 재추적할지 잊을 수 있기 때문에 뷰의 계층구조에 관여하는 모달 작업 생성은 특히 주의해야 합니다. 모달 작업이 하위뷰를 포함해야 한다면, 계층구조를 통해 단일 경로를 제공하고 완료에 명확한 경로를 제공해야 합니다. 작업 완료와 다른 어떤 것에 대한 Done 버튼 사용을 피하시기 바랍니다.
모달 뷰를 해제하는 버튼을 항상 포함시켜야 합니다. 예를 들어 Done 혹은 Cancel을 사용할 것입니다. 버튼을 포함시키는 것은 모달 뷰가 보조 기술에 접근 가능하다는 것을 보장하고 해제 제스쳐에 대한 대안을 제공합니다.
필요한 경우 모달 뷰를 닫기 전에 사람들의 확인을 구하는 것을 통해 데이터 손실을 피할 수 있도록 해야 합니다. 사람들이 해제 제스쳐 혹은 뷰를 닫기 위한 버튼을 사용하는 것과 상관 없이 액션이 사용자가 생성한 컨텐트 손실을 초래할 수 있는 경우 상황을 설명하는 액션 시트를 제공하고 해결을 위한 방법을 제공하시기 바랍니다.
팝오버의 상단에 나타나는 카드를 표시하지 않아야 합니다. 팝오버 내에 카드를 표시할 수 있을지라도 팝오버의 상단에는 아무것도 나타나지 않아야 합니다(알림을 제외하고). 사람들이 팝오버에서 액션을 수행한 후 카드를 제공할 필요가 있는 드문 경우에 카드 표시 전에 팝오버를 닫으시기 바랍니다.
모달 작업을 식별할 수 있는 제목을 표시하시기 바랍니다. 사람들이 모달 작업에 진입할 때 사람들은 이전 컨텍스트로부터 전환하기 때문에 새로운 컨텍스트를 명확하게 하는 것이 좋은 아이디어입니다. 뷰의 다른 부분에서 더 완전하게 작업을 설명할 수 있는 혹은 가이드를 제공하기 위한 텍스트를 제공할 수도 있습니다.
앱과 함께 모달 뷰의 모양을 조정해야 합니다. 예를 들어 모달 뷰가 네비게이션 바를 포함하는 경우 앱에 있는 네비게이션 바와 같은 모양으로 사용해야 합니다.
앱에서 합리적인 모달 전환 스타일을 선택해야 합니다. 앱과 조화를 이룰 수 있고 임시 컨텍스트 이동의 인식을 보완하는 전환 스타일을 사용해야 합니다. 기본값 전환은 스크린의 하단으로부터 상단으로 모달 뷰를 수직 슬라이드하며, 해제될 때 아래로 돌아갑니다. 앱 전반에서 이관적인 모달 전환 스타일을 사용하시기 바랍니다.
개발자 가이드는 UIViewController와 UIPresentationController를 보시기 바랍니다.
UIViewController
https://developer.apple.com/documentation/uikit/uiviewcontroller
https://velog.io/@panther222128/ViewController
UIPresentationController
https://developer.apple.com/documentation/uikit/uipresentationcontroller
https://velog.io/@panther222128/UIPresentationController
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/navigation/
Navigation
사람들은 앱이 자신의 기대를 충족시키지 못할 때까지 앱의 네비게이션을 인식하지 못하는 경향이 있습니다. 해야 하는 것은 네비게이션 자체가 이목을 끌지 않도록 하면서 앱의 구조 및 목적을 지원하는 방식으로 네비게이션을 구현하는 것입니다. 네비게이션은 자연스럽고 친근한 느낌이어야 하며, 인터페이스를 압도하거나 컨텐트에 대한 집중을 가져오지 않아야 합니다. iOS에서는 세 가지 주요 네비게이션 스타일이 존재합니다.
Hierarchical Navigation
최종 목적지에 도달하기까지 스크린 당 하나의 선택을 만들어야 합니다. 다른 목적지로 갈 수 있도록 하려면 단계를 재추적하거나 시작에서부터 출발해야 하며, 다른 선택을 만들어야 합니다. 설정 및 메일은 이와 같은 네비게이션 스타일을 사용합니다.
Flat Navigation
여러 컨텐트 카테고리 사이를 전환합니다. 음악과 앱 스토어는 이 네비게이션 스타일을 사용합니다.
Content-Driven or Experience-Driven Navigation
컨텐트를 통해 자유롭게 이동하거나 컨텐트 자체가 네비게이션을 정의합니다. 게임, 도서, 기타 몰입형 앱은 일반적으로 이와 같은 네비게이션 스타일을 사용합니다.
몇 가지 앱은 여러 네비게이션 스타일을 조합합니다. 예를 들어 플랫 네비게이션을 사용하는 앱은 각 카테고리 내부에 계층구조 네비게이션을 구현할 것입니다.
항상 명확한 경로를 제공해야 합니다. 사람들은 앱 어느 곳에 있는지 항상 인식해야 하며, 다음 목적지에 어떻게 갈 수 있는지를 알아야 합니다. 네비게이션 스타일과 상관없이 컨텐트를 통한 경로가 논리적이고 예측 가능하며, 따라가기 쉬워야 하는 것은 필수적입니다. 일반적으로 사람들에게 각 스크린에 대한 하나의 경로를 제공해야 합니다. 사람들이 여러 컨텍스트에서 스크린을 볼 필요가 있다면 액션 시트, 알림, 팝오버, 모달 뷰 사용을 고려해보시기 바랍니다. 더 많은 정보는 Action Sheets, Alerts, Popovers, Modality를 보시기 바랍니다.
Action Sheets
https://developer.apple.com/design/human-interface-guidelines/ios/views/action-sheets/
https://velog.io/@panther222128/Views
Alerts
https://developer.apple.com/design/human-interface-guidelines/ios/views/alerts/
https://velog.io/@panther222128/Views
Popovers
https://developer.apple.com/design/human-interface-guidelines/ios/views/popovers/
https://velog.io/@panther222128/Views
Modality는 지금 글을 쓰고 있는 Navigation 바로 위에 있습니다.
컨텐트를 가져오는 데 빠르고 쉽게 만들 수 있도록 정보 구조를 디자인하시기 바랍니다. 최소한의 탭, 스와이프, 스크린 수를 요구하는 방식으로 정보 구조를 조직화하시기 바랍니다.
유동성 생성을 위해 터치 제스쳐를 사용하시기 바랍니다. 최소한의 마찰로 인터페이스를 이동할 수 있도록 해야 합니다. 예를 들어 이전 스크린 반환을 위해 스크린의 측면으로부터 스와이프할 수 있도록 만들 수 있습니다.
표준 네비게이션 컴포넌트를 사용하시기 바랍니다. 가능한 페이지 컨트롤, 탭바, 세그멘티드 컨트롤, 테이블 뷰, 컬렉션 뷰, 스플릿 뷰와 같은 표준 네비게이션 컨트롤을 사용하시기 바랍니다. 사용자는 이와 같은 컨트롤이 이미 친숙하며, 앱 탐색 방법을 직관적으로 알 것입니다.
데이터 계층구조 탐색을 위해 네비게이션 바를 사용하시기 바랍니다. 네비게이션 바의 제목은 계층구조에서 현재 위치를 보여줄 수 있으며, 뒤로가기 버튼은 이전 위치로 쉽게 돌아갈 수 있도록 합니다. 구체적인 가이드는 Navigation Bars를 보시기 바랍니다.
Navigation Bars
https://developer.apple.com/design/human-interface-guidelines/ios/bars/navigation-bars/
https://velog.io/@panther222128/Bars
컨텐트 혹은 기능의 다른 카테고리 제공을 위해 탭바를 사용하시기 바랍니다. 탭바는 사람들이 현재 위치와 관계없이 카테고리 사이를 빠르고 쉽게 전환할 수 있도록 해줍니다. 구체적인 가이드는 Tab Bars를 보시기 바랍니다.
Tab Bars
https://developer.apple.com/design/human-interface-guidelines/ios/bars/tab-bars/
https://velog.io/@panther222128/Bars
아이패드에서는 탭바 대신 스플릿 뷰를 사용하시기 바랍니다.. 스플릿 뷰는 탭바처럼 빠른 네비게이션을 제공하며, 큰 디스플레이 사용을 더 편하게 해줍니다. 가이드는 Split Views를 보시기 바랍니다.
Split Views
https://developer.apple.com/design/human-interface-guidelines/ios/views/split-views/
https://velog.io/@panther222128/Views
타입이 같은 컨텐트의 여러 페이지를 갖는 경우 페이지 컨트롤을 사용하시기 바랍니다. 페이지 컨트롤은 사용 가능한 페이지의 수를 명확하게 알려주며, 어떤 것이 현재 활성화된 상태인지 보여줍니다. 날씨 앱은 특정 위치의 날씨 페이지를 보여주기 위해 페이지 컨트롤을 사용합니다. 가이드는 Page Controls를 보시기 바랍니다.
Page Controls
https://developer.apple.com/design/human-interface-guidelines/ios/controls/page-controls/
https://velog.io/@panther222128/Controls
TIP
세그멘티드 컨트롤 및 툴바는 네비게이션을 활성화시키지 않습니다. 다른 카테고리에서 정보를 조직화하려면 세그멘티드 컨트롤을 사용하시기 바랍니다. 현재 컨텍스트와 상호작용하기 위한 컨트롤을 제공하려면 툴바를 사용하시기 바랍니다. 이러한 요소의 타입에 대한 추가적인 정보는 Segmented Controls와 Toolbars를 보시기 바랍니다.
Segmented Controls
https://developer.apple.com/design/human-interface-guidelines/ios/controls/segmented-controls/
https://velog.io/@panther222128/Controls
TooBars
https://developer.apple.com/design/human-interface-guidelines/ios/bars/toolbars/
https://velog.io/@panther222128/Bars
Accessing User Data
사용자 개인정보가 가장 중요합니다. 사람들이 앱을 신뢰할 수 있으려면 앱이 요구하는 개인정보 관련 데이터 및 리소스와 이 데이터 및 리소스를 어떻게 사용하는지에 대해 투명하게 하는 것이 중요합니다. 예를 들어 아래 사항에 접근 승인을 요청해야 합니다.
- 위치, 건강, 금융, 연락처, 기타 개인을 식별하는 정보를 포함한 개인의 데이터입니다.
- 이메일, 메시지, 달력 데이터, 연락처, 게임플레이 정보, 애플 뮤직 활동, 홈킷 데이터, 오디오, 비디오, 사진 컨텐트와 같은 사용자가 생성한 컨텐트입니다.
- 블루투스 주변 장치, 홈 자동화 기능, 와이파이 연결, 로컬 네트워크와 같은 보호된 자원입니다.
- 카메라, 마이크와 같은 기기 기능입니다.
IMPORTANT
iOS 14.5 및 iPadOS 14.5를 시작으로, 사용자의 데이터 추적 혹은 기기의 광고 아이덴티파이어에 접근하길 원한다면 사용자의 승인을 요청하기 위해AppTrackingTransparency프레임워크를 사용해야 합니다. 이에 대한 더 많은 정보는 User Privacy and Data Use를 보시기 바랍니다.
User Privacy and Data Use
https://developer.apple.com/app-store/user-privacy-and-data-use/
새로운 혹은 업데이트된 앱을 제출할 때 개인정보 관행 및 수집하는 개인정보 관련 데이터에 대한 세부사항을 제공해야 하며, 이로써 앱 스토어는 제품 페이지에서 해당 정보를 표시할 수 있습니다. (앱 스토어 커넥트에서 언제든지 이 정보를 관리할 수 있습니다.) 사람들은 앱 다운로드 전 정보를 기반으로 하는 의사결정을 내리기 위해 제품 페이지에서 개인정보 세부사항을 사용할 것입니다. 이에 대한 더 많은 정보는 App privacy details on the App Store를 보시기 바랍니다.
App privacy details on the App Store
https://developer.apple.com/app-store/app-privacy-details/
이 위치에 이미지가 하나 있습니다. 보시려면 링크에서 보시기 바랍니다.
Requesting Access Permission
사용자 데이터 혹은 보호된 자원을 사용할 수 있기 전에 그렇게 하려면 사람들의 승인을 얻어야 합니다.
요청 승인은 앱이 명확하게 데이터 혹은 리소스에 접근할 필요가 있을 때에만 하시기 바랍니다. 개인정보에 대한 요청 혹은 기기 기능에 대한 요청은 사람들이 의심할만 한 것이며, 특히 명확한 필요가 없어보이는 경우에 더욱 그렇습니다. 사람들이 실제로 접근을 요청하는 앱 기능을 사용할 때까지 요청 승인을 기다리는 것이 바람직합니다. 위치 요청의 경우 위치 버튼을 사용하면 사람들이 그들의 위치를 공유할 수 있는 방법을 제공할 수 있습니다. 가이드는 Using the Location Button을 보시기 바랍니다.
Using the Location Button은 이 글의 아래에 나옵니다.
데이터 혹은 리소스가 앱 작동에 필수적일 때에만 launch 시점에 승인을 요청하시기 바랍니다. 사람들은 앱이 왜 정보가 필요한지 명확할 때 launch 시점의 요청을 덜 귀찮아합니다. 앱 launch가 되자마자 사람들의 앱 추적을 수행하길 원한다면, 모든 추적 데이터 수집 전에 시스템 제공 알림을 표시해야 합니다.
시스템은 사람들이 개인정보 혹은 보호된 리소스 접근에 대한 요청을 볼 수 있도록 해주는 표준 알림을 제공합니다. 앱이 왜 아이템이 필요한지에 대한 설명을 제공할 수 있으며, 시스템은 알림에서 이 설명을 표시합니다. 또한, 사람들은 설정 > 개인정보에서 설명을 볼 수 있습니다(그리고 그들의 선택을 업데이트할 수 있습니다).
앱이 요청하고 있는 데이터 혹은 리소스를 어떻게 사용하는지 명확하게 설명하는 문구를 작성해야 합니다. 표준 알림은 앱 이름 뒤에 그리고 승인 혹은 거부를 위해 사용하는 버튼 앞에 문구(목적 스트링 혹은 사용 설명 스트링이라고 부르는)를 표시합니다. 간단하고 구체적이며 이해하시 쉬운 문구를 목표로 해야 합니다. 문장을 사용하고, 수동적인 표현은 피해야 하며, 끝에 마침표를 포함하시기 바랍니다. 개발자 가이드는 Requesting Access to Protected Resources 및 App Tracking Transparency를 보시기 바랍니다.
Requesting Access to Protected Resources
https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/requesting_access_to_protected_resources
https://velog.io/@panther222128/Requesting-Access-to-Protected-Resources
App Tracking Transparency
https://developer.apple.com/documentation/apptrackingtransparency
https://velog.io/@panther222128/App-Tracking-Transparency
| Example purpose string | Notes | |
|---|---|---|
 | 앱이 녹음을 통해 코를 고는 소리를 감지합니다. | 앱이 해당 데이터를 어떻게 그리고 왜 수집하는지 명확하게 설명하는 호라성화 문장입니다. |
 | 더 나은 경험을 위해 마이크 접근이 필요합니다. | 모호하고 정당성을 정의하지 못하는 수동적인 문장입니다. |
| 마이크 접근을 켭니다. | 정당성을 제공하지 못하는 명령문입니다. |
표준 시스템 알림의 몇 가지 예시가 아래에 있습니다.
이 위치에 동적 이미지가 포함되어 있습니다. 보시려면 링크에서 보시기 바랍니다.
Using the Location Button
iOS 15 및 이후 버전에서 코어 로케이션은 어떠한 작업이 필요로 하는 순간에 사람들의 위치에 접근하기 위한 앱 임시 권한 승인을 할 수 잇는 버튼을 제공합니다. 위치 버튼의 모양이 앱의 UI와 일치하기 위해 다양할지라도 즉시 인식이 가능한 방식으로 위치 공유의 액션을 알려줄 수 있어야 합니다.
위치 버튼은 기기 위치를 요청하기 위한 앱 임시 권한을 승인합니다. 앱이 권한 상태를 갖지 못하면 위치 버튼 탭은 사용자가 표준 알림에서 한 번만 허용을 선택할 때와 동일한 효과를 갖습니다. 사람들이 이전에 앱 사용 중일 때만을 선택했던 경우 위치 버튼 탭은 앱 상태를 변경시키지 않습니다. 개발자 가이드는 LocationButton(SwiftUI) 및 CLLocationButton(Swift)를 보시기 바랍니다.
LocationButton
https://developer.apple.com/documentation/corelocationui/locationbutton
https://velog.io/@panther222128/LocationButton-8rd2pzwm
CLLocationButton
https://developer.apple.com/documentation/corelocationui/cllocationbutton
https://velog.io/@panther222128/CLLocationButton
사람들이 앱을 처음 열고 위치 버튼을 탭하면 시스템은 표준 알림을 표시합니다. 알림은 사람들이 버튼 사용이 사람들의 위치에 대한 앱 접근을 어떻게 제한하는지 이해하는 것을 돕습니다. 그리고 공유가 시작될 때 나타나는 위치 인디케이터를 사람들에게 상기시킵니다.
이 위치에 이미지가 하나 있습니다. 보시려면 링크에서 보시기 바랍니다.
사람들이 버튼 액션의 이해를 확인한 후 사람들은 그들의 위치 접근에 한 번 허용하는 것을 원할 때 위치 버튼을 탭합니다. 각각의 한 번 권한은 사람들이 앱 사용을 멈출 때 만료되지만, 사람들은 버튼 동작의 이해를 다시 확인할 필요는 없습니다.
사람들에게 특정 앱 기능에 대해 사람들의 위치를 공유하기 위한 간단한 방식을 제공할 수 있도록 위치 버튼 사용을 고려하시기 바랍니다. 예를 들어 앱은 사람들이 그들의 위치를 메시지 혹은 포스트에 첨부하거나 가게를 찾기 위해서, 혹은 건물, 공장, 위치에서 마주하는 동물을 식별하는 것을 도울 수 있습니다. 사람들이 앱에서 한 번만 승인을 자주 사용하고 있다는 것을 알고 있다면, 알림 상호작용 없이 사람들의 위치 공유를 편하게 할 수 있도록 위치 버튼 사용을 고려하시기 바랍니다.
UI와 조화를 이룰 수 있도록 위치 버튼 커스터마이징을 고려하시기 바랍니다. 구체적으로 아래 내용을 수행할 수 있습니다.
- "현재 위치" 혹은 "나의 현재 위치 공유하기"와 같은 기능에 최선으로 작동하는 시스템 제공 제목을 선택하시기 바랍니다.
- 채워진 혹은 아웃라인이 그려진 위치 글리프를 선택하시기 바랍니다.
- 배경 색상과 제목 및 글리프에 대한 색상을 선택하시기 바랍니다.
- 버튼의 코너 래디우스를 조정하시기 바랍니다.
사람들이 위치 버튼을 인식하고 신뢰할 수 있도록 다른 시각적 특성은 커스터마이징이 불가능합니다. 시스템은 대비가 낮은 색상 조합 혹은 높은 반투명도와 같은 문제에 대해 경고해서 위치 버튼을 읽기 쉽도록 만들어줍니다. 이와 같은 문제 수정과 더불어 텍스트가 버튼에 알맞게 들어가도록 하는 것에도 책임이 있습니다. 예를 들어 버튼 텍스트는 모든 접근성 텍스트 크기에서 잘 맞아야 하고, 다른 언어로 번역될 때에도 잘림 없이 잘 맞아야 합니다.
IMPORTANT
시스템이 커스터마이징된 위치 버튼에서 일관적인 문제를 식별하는 경우 사람들이 버튼을 탭할 떄 기기 위치에 대한 접근을 앱에 제공하지 않을 것입니다. 이와 같은 버튼이 앱의 다른 특정 액션을 수행할 수 있을지라도, 위치 버튼이 사람들의 기대처럼 작동하지 않는 경우 앱에 대한 신뢰가 떨어질 것입니다.
Using the Microphone in a ShazamKit App
ShazamKit은 ShazamKit 카탈로그 혹은 커스텀 오디오 카탈로그에 대해 오디오 샘플을 일치시켜서 오디오 인식을 가능하게 합니다. iOS 15 및 이후 버전에서 앱은 ShazamKit을 아래와 같은 기능을 가능하게 하기 위해 사용할 수 있습니다.
- 현재 재생중인 음악의 장르에 상응하는 그래픽 사용으로 앱 경험을 강화할 수 있습니다.
- 닫힌 캡션 혹은 오디오에 싱크하는 싸인 언어를 제공해서 청각 장애를 갖는 사람들이 미디어 컨텐트에 접근 가능하도록 합니다.
- 온라인 학습과 리테일처럼 컨텍스트에서 가상 컨텐트 사용으로 앱 내 경험을 동기화합니다.
인식을 위해 앱으로 오디오 샘플을 가져오고자 기기 마이크가 필요한 경우 마이크에 대한 접근 요청이 필요합니다. 다른 모든 타입의 승인 요청처럼 사람들이 왜 접근을 요청받는지 이해하도록 하는 것은 중요합니다. 가이드는 Requesting Access Permission을 보시기 바랍니다.
Requesting Access Permission은 이 글의 위에 있습니다.
이 위치에 이미지가 하나 있습니다. 보시려면 링크에서 보시기 바랍니다.
ShazamKit이 활성화된 기능을 위한 마이크 접근에 승인을 받은 후 아래 가이드를 따르시기 바랍니다.
가능한 빠르게 녹음을 중단해야 합니다. 사람들이 인식을 위한 오디오 녹음을 허용할 때 사람들은 마이크가 계속 켜져있길 기대하지 않습니다. 개인정보 보호를 돕기 위해 필요한 샘플을 가져오는 동안만 녹음하시기 바랍니다.
사람들이 앱에서 인식한 노래를 아이클라우드 보관함에 저장하도록 선택할 수 있게 해주시기 바랍니다. 앱이 아이클라우드에 인식된 노래를 저장할 수 있는 경우 사람들이 이 액션을 처음으로 승인할 수 있는 방법을 제공하시기 바랍니다. 음악 인식 컨트롤과 Shazam 앱은 모두가 인식된 노래의 소스로써 앱을 보여줄 수 있을지라도 사람들은 어떤 앱이 그들의 라이브러리에 컨텐트를 저장할 수 있을지 제어하는 것을 더 선호합니다.
개발자 가이드는 ShazamKit을 보시기 바랍니다.
ShazamKit
https://developer.apple.com/documentation/shazamkit
<>
Displaying Custom Messaging Before the Alert
사람들은 컨텍스트에 기반해 왜 승인을 요청하는지 이미 알고 있지만, 추가적인 세부사항 제공이 필수적인 경우 알림이 나타나기 전에 커스텀 메시지를 표시할 수 있습니다.
시스템 알림을 여는 것이 커스텀 지정 메시지 스크린에서 사람들이 액션을 수행할 수 있는 유일한 방법임을 명확하게 해야 합니다. 사람들은 사전 알림 메시지를 지연시키는 전략처럼 해석할 수 있기 때문에 빠르게 메시지를 해제하고 시스템 경고를 볼 수 있도록 하는 것이 중요합니다. 개인정보 관련 승인 요청에 선행하는 커스텀 스크린을 표시하는 경우 이 스크린은 시스템 알림을 표시해야 하는 하나의 액션만을 제공할 수 있습니다. 액션 제목에 "계속하기"와 같은 단어를 사용하시기 바랍니다. 사람들이 커스텀 스크린 내에서 권한을 부여하거나 다른 작업 을 수행하고 있다고 생각할 수 있는 "허용" 혹은 기타 용어를 사용하지 않아야 합니다.
이 위치에 이미지가 둘 있습니다. 보시려면 링크에서 보시기 바랍니다.
Clarifying Tracking Requests
앱 추적은 민감한 이슈입니다. 특정 경우에는 명확하게 추적의 이점을 설명하는 커스텀 메시지 표시가 합리적입니다.
혼란을 초래하거나 사람들을 착각하게 만들 수 있는 커스텀 메시지를 사용하는 시스템 제공 알림을 선행하도록 하지 않아야 합니다. 사람들은 알림을 읽지 않고 빠르게 알림을 해제할 때가 있습니다. 선택에 영향을 줄 수 있는, 이와 같은 동작을 수행하는 커스텀 메시지 스크린은 앱 스토어 리뷰에서 거절 사유가 될 수 있습니다.
거절 사유가 될 수 있는 금지된 커스텀 메시지 디자인이 몇 가지 존재합니다. 몇 가지 예시는 인센티브 제공, 요청과 유사하게 보이는 스크린 표시, 알림의 이미지 표시, 알림 뒤 화면에 주석을 다는 것(아래에 보이도록) 등이 있습니다. 가이드는 App Store Review Guidelines: 5.1.1 (iv)를 보시기 바랍니다.
App Store Review Guidelines: 5.1.1 (iv)
https://developer.apple.com/app-store/review/guidelines/#data-collection-and-storage
이 위치에 동적 이미지가 포함되어 있습니다. 보시려면 링크에서 보시기 바랍니다.
https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/settings/
Settings
몇 가지 앱은 선택을 설정할 수 있는 방법을 제공할 필요가 있을 것이지만, 대부분의 앱은 그렇게 하는 것을 피하거나 지연시킬 수 있습니다. 성공적인 앱은 대부분의 사람들에게서 즉시 작동하며, 경험을 조정할 몇 가지 편리한 방법을 제공하기도 합니다. 사람들이 가장 기대하는 기능으로 앱을 디자인할 때 설정에 대한 필요가 줄어듭니다.
이 위치에 이미지가 포함되어 있습니다. 보시려면 링크에서 보시기 바랍니다.
시스템으로부터 무엇을 할 수 있는지 추론하시기 바랍니다. 사용자, 기기, 환경에 대한 정보가 필요하다면, 사용자에게 요청하기보다 가능하면 시스템을 쿼리하시기 바랍니다. 예를 들어 로컬 옵션을 제공할 수 있도록 우편번호 입력을 요청하는 것 대신 현재 위치 사용 승인을 요청하는 것이 더 좋습니다. 사용자가 정보 접근을 거부하는 경우 수동 입력으로 대체해야 합니다.
앱 내에서 신중하게 설정 옵션의 우선순위를 정하시기 바랍니다. 앱의 메인 스크린은 필수적이거나 자주 변경되는 옵션을 놓기에 좋은 위치입니다. 두 번째 스크린은 때때로 변경되는 옵션에 적합합니다.
설정에서 자주 변경되지 않는 설정 옵션을 노출시키기 바랍니다. 설정 앱은 시스템 저반에서 설정 변경을 할 수 있는 중심 위치이지만, 사람들은 설정 앱에 닿으려면 사용중이던 앱을 빠져나와야 합니다. 앱 내에서 직접 설정을 조정하는 것이 더 편리합니다. 거의 변경을 요구하지 않는 설정을 제공해야만 하는 경우 Preferences and Settings Programming Guide에 있는 Implementing an iOS Settings Bundle을 보시기 바랍니다.
Implementing an iOS Settings Bundle
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/UserDefaults/Preferences/Preferences.html
이 위치에 이미지가 포함되어 있습니다. 보시려면 링크에서 보시기 바랍니다.
적합한 시기에 설정으로 가는 단축경로를 제공하시기 바랍니다. 앱이 사용자를 설정으로 연결하는 텍스트(“Go to Settings > MyApp > Privacy > Location Services”와 같은)를 포함하는 경우 해당 위치를 자동으로 열 수 있는 버튼을 제공하시기 바랍니다. 개발자 가이드는 UIApplication에 있는 openSettingsURLString을 보시기 바랍니다.
openSettingsURLString
https://developer.apple.com/documentation/uikit/uiapplication/1623042-opensettingsurlstring
