UITableView, UICollectionView, UIStackView 등의 용도 차이
UITableView 는 단일 column 으로 표현되는 데이터를 표시할 때, UICollectionView 는 복수의 row, column 으로 표현되는 데이터를 표시할 때, UIStackView 는 여러 디자인 요소를 단일 row 또는 단일 column 으로 표현하고 싶을 때 사용합니다.
단일 column 으로 표현되는 데이터를 표시하지만 복잡한 UX/UI 를 구현해야 하는 경우 UICollectionView 를 사용하는 경우도 많습니다. UICollectionViewLayout 등을 이용하면 UITableView 보다 UICollectionView 를 사용하는 것이 더 많은 부분을 커스텀하여 사용할 수 있기 때문입니다.
디자인 요소들 (Collection of Views) 을 행 또는 열로 배치할 때 사용합니다. UITableView 나 UICollectionView 가 데이터 집합 을 나타낼 때 사용된다면, UIStackView 는 뷰 집합 을 정렬하는 인터페이스로 사용됩니다.
동일선상에서 비교하기는 힘들지만 UICollectionView 혹은 UITableView 와 비교하여 정적인 UI 를 만들 때 사용됩니다. 추가, 삭제, 재정렬과 같은 사용자 상호 작용이 필요한 뷰 집합 을 표현해야 하는 경우, UIStackView 대신 다른 레이아웃 요소를 활용하는 것이 낫습니다.
앱 구조에 영향을 주는 UI Component 시스템의 용도와 차이
HIG 에서는 Components 항목을 8 가지 하위 항목으로 나누어 설명하고 있습니다. 이 중 iOS 앱 구조에 크게 영향을 끼칠 수 있는 몇가지 컴포넌트들에 대해 살펴보겠습니다.
HIG 는 iOS 앱만을 대상으로 하는 가이드 문서는 아니기 때문에 macOS, iPadOS 등 다양한 OS 에서 사용할 수 있는 컴포넌트들에 대해 포괄적으로 설명합니다. 해당 스터디의 목적을 고려하여 이번 문단에서는 iOS 앱에 연관있는 컴포넌트들에 대해서만 설명합니다.
탭바는 일반적으로 글로벌 탐색 컴포넌트로써 사용됩니다. 앱의 콘텐츠를 몇개의 큰 섹션으로 분류하고 이들 사이를 탐색할 수 있는 기능을 제공합니다. 따라서 앱 계층 구조의 최상위에 위치하는 경우가 많습니다.
UITabBarController 는 Bar Item 을 사용하여 동일한 뷰에서 상호 베타적인 콘텐츠를 탐색할 수 있도록 합니다. 상호 베타적인 콘텐츠 란 계층 혹은 의존 관계가 없는 콘텐츠들을 말합니다. 물론 한 앱 내부의 콘텐츠들이기 때문에 완전히 베타적일 수는 없지만, 적어도 확실한 계층 및 의존 관계가 있는 콘텐츠가 UITabBarController 로 관리되어선 안됩니다.
iOS 의 기본 연락처 앱에서 UITabBarController 를 사용한 예시를 볼 수 있습니다. 연락처 앱의 하위 콘텐츠들이기 때문에 완전히 베타적이진 않지만 계층 및 의존 관계과 없는 즐겨찾기, 최근 통화, 연락처, 키패드, 음성 사서함 콘텐츠가 메인 화면에서 탭바를 이용해 탐색할 수 있도록 배치되어 있습니다.
탭바는 탐색용 으로만 사용해야 합니다. 탭바를 Action 을 위해서 사용하면 안됩니다. Action 을 위한 바가 필요한 경우 Toolbar 를 사용하는 것이 좋습니다.
일반적으로 iOS 에선 3 ~ 5 개의 탭을 사용하는게 좋습니다. 이보다 더 탭이 많아지는 경우 복잡성이 증가하고 사용자가 원하는 정보를 찾기 어려워집니다. 5 개 이상의 탭을 사용해야 하는 경우 UITabBarController 이외의 컴포넌틀를 사용하거나, 콘텐츠 구조를 개선하는 것이 좋습니다.
특정 탭을 사용할 수 없는 경우에도 Bar Item 이 사라지거나 터치가 불가능해지도록 처리하지 않아야 합니다. 탭을 사용할 수 없는 경우 탭을 사용할 수 없는 이유를 설명하거나 탭을 사용할 수 있도록 안내하는 콘텐츠를 배치하는 것이 좋습니다. 예를 들어 iOS 의 기본 음악 앱에서 지금 들을 수 있는 음악이 없더라고 지금 듣기 탭을 사용할 수 있습니다.
세그멘티드 컨트롤은 동일한 영역에서 상호 베타적인 콘텐츠를 탐색할 수 있도록 합니다. 또는 관련도가 높은 항목들을 선형으로 구조화하고 이들을 단일 혹은 복수개 선택하는 버튼으로써 동작합니다. 이 문서에서는 상호 베타적인 콘텐츠를 탐색하는 세그멘티드 컨트롤에 대해 설명합니다. (Tab views 의 동작을 구현하기 위해 iOS 에서 세그맨티드 컨트롤을 사용하는 경우에 대해 설명합니다)
대부분의 동작은 탭바와 동일하지만, 앱의 최상위가 아닌 특정 컴포넌트 내부에서 동작한다는 것이 차이점입니다. 아래 영상은 네이버페이 앱에서 세그멘티드 컨트롤과 유사한 커스텀 뷰를 사용하는 예시 영상입니다. (결제 탭 내부에서 상호 베타적인 멤버십, 현장결제, 교환권 콘텐츠를 탐색할 수 있도록 구현되어 있습니다)
네비게이션바는 앱 화면 상단에 표시되어 콘텐츠의 계층 구조를 표시하고 탐색하는데 사용됩니다. 네비게이션바에 간단한 제목이나 콘텐츠와 관련된 동작을 위한 버튼이 추가될 수 있습니다.
네비게이션바에 제목을 추가할 경우 제목은 현재 콘텐츠에 대한 유용한 정보를 제공해야 합니다. 앱 이름과 같은 제목은 유용한 정보를 나타내지 않으므로 부적잘합니다. 제목이 필요 없는 경우 이를 생략해도 무방합니다. 예를 들어 iOS 의 기본 메모 앱에서, 세부 메모 항목은 네비게이션바에 제목을 표시하지 않습니다.
보다 몰입감 있는 환경을 제공하기 위해 탐색 모음을 일시적으로 숨길 수 있습니다. 예를 들어 iOS 의 기본 Photos 앱에서, 전체 화면 사진을 볼 때 내비게이션바를 숨깁니다. 이후 사용자가 화면을 탭하거나 아래로 스와이프하여 내비게이션바를 복원할 수 있습니다.
HIG 가 개편되기 이전에는 크게 View, Control, Bar 항목으로 문서를 나누어 설명했습니다. Interface Essentials 이라는 제목으로 이들에 대해서 요약하여 설명해주었는데 해당 문서는 삭제된 상태입니다. 한글 번역 문서 를 통해 이전의 문서를 확인할 수 있습니다.
HIG 가 개편되며 View, Control, Bar 형태로 기본 골자를 나누고 하위로 정렬하기보다는 기능과 컴포넌트 위주로 나누어 설명하는 형태로 변경되었습니다. 개인적으로는 특정 OS 에 종속되어 기술적으로 가이딩하는 것 대신 어떤 OS 에서든 애플의 느낌을 모두 녹여낼 수 있도록 정리된 느낌을 받았습니다. 이전의 문서 역시 분명히 배울 점이 많지만 이제는 참고 정도에서 활용하고 개편된 HIG 를 활용하는 것이 나을 것 같다는 생각입니다.
Appstore Review Guideline
앱스토어는 사용자에게는 안전하게 앱을 이용할 수 있는 경험, 개발자에게는 뛰어난 앱을 개발할 수 있는 훌륭한 기회를 제공한다는 원칙 아래, 스토어에 등록 전 앱 심사(Review)를 진행하고 있습니다. 간단하게 리뷰 항목에 대해 알아보고, 리뷰 과정에서 앱 심사가 거절 당하는 몇몇 케이스에 대해 알아보겠습니다.
Appstore Review Guideline 의 기본 내용
애플에서는 앱스토어 리뷰를 위해 다섯가지 세션의 리뷰 가이드를 제공하고 있습니다. 아래에서 다섯가지 세션의 내용에 대해 간단히 요약하였습니다. 상세한 내용은 App Store 심사 지침 가이드라인을 통해 확인할 수 있습니다. 한국어 버전이 영어 원문보다 업데이트가 느리나, 큰 차이점은 없습니다.
안전성
앱에 불쾌하거나 모욕적인 콘텐츠가 없어야 하고, 기기에 손상을 주지 않아야 하며, 앱을 사용했을 때 신체적인 손상을 입을 가능성이 있어서는 안 됩니다.
성능
앱 심사 팀에 제출하는 앱은 필요한 모든 메타데이터가 있고 URL이 정상적으로 작동하는 최종 버전이어야 합니다. 베타버전 등의 앱은 앱 스토어 리뷰에서 거부될 수 있습니다. 또한 충돌이나 명백한 기술 문제가 드러나는 불완전한 앱 번들과 바이너리는 거부당합니다.
비즈니스
비즈니스 모델이 명확하지 않은 경우 메타데이터와 앱 심사 메모에 설명을 기재해야 합니다. 앱이 어떻게 작동하는지 파악할 수 없거나 앱 내 구입 기능을 바로 이해할 수 없는 경우 리뷰가 지연되거나 앱이 거부될 수 있습니다. 앱 가격은 개발자가 결정하지만, 앱과 앱 내 구입의 가격이 지나치게 높다고 판단되는 경우 배포를 허용하지 않습니다. 불합리하게 높은 가격으로 사용자를 속이려는 비싼 앱은 거부당합니다.
디자인
최소한의 디자인 기준을 충족하지 않는 앱은 리뷰에서 거부될 수 있습니다. 또한 앱을 승인받은 후에도 지속적인 업데이트를 통해 앱이 정상적으로 작동하도록 유지하여 기존 고객과 신규 고객에게 매력적인 사용 경험을 제공해야 합니다. 작동하지 않거나 수준 미달의 경험을 제공하는 앱은 언제든지 앱스토어에서 삭제될 수 있습니다.
법적 요구 사항
앱은 상용화될 지역의 모든 법적 요구 사항을 준수해야 합니다. 또한 불법 행위나 명백하게 위험한 행동을 요구하거나, 유도하고, 조장하는 앱은 무조건 거부됩니다. 인신매매 및 아동 착취를 조장하는 것으로 판명된 앱과 같이 극단적인 경우가 발생하면 담당 기관에 보고됩니다.
Review 거절 사례
앱스토어 리뷰 가이드가 명확하게 지정되어 있지만, 매우 다양한 사례들과 결국 사람이 리뷰한다는 한계로 명확하게 동일한 가이드가 적용되지는 않습니다. 어떤 앱은 통과 되었지만 다른 앱은 거절(리젝)되는 일이 많습니다. 아래는 다양한 Review 거절(리젝) 사례입니다.
소셜 로그인 관련 리젝
소셜 로그인 기능을 포함하려면, Apple ID 로 로그인 기능을 필수로 포함해야 합니다. 카카오 로그인, 네이버 로그인 등 소셜 로그인 기능을 포함했는데 Apple ID 로그인 기능이 빠져있다면 리젝 대상에 해당합니다.
인앱 구매 관련 리젝
오프라인에서 사용할 수 있는 재화를 판매할때는 애플의 인앱결제 기능을 사용하지 않아도 괜찮지만, 앱 내부에서 사용되는 디지털 재화를 판매할때는 무조건 애플의 인앱결제 기능만 사용해야 합니다. 쿠팡은 인앱 결제를 사용하지 않지만, iOS 에서 발매되는 게임앱 등의 경우는 아이템을 애플 인앱결제로 구매해야하는 이유입니다. 앱 내부에서 사용되는 디지털 재화를 구매할 수 있는 다른 경로가 존재하는 경우 리젝 대상에 해당합니다.
회원 가입 기능이 있는 경우, 탈퇴 기능이 없다면 리젝
회원 가입 기능을 포함하는 앱에 탈퇴 기능이 없다면 리젝 대상에 해당됩니다. 회원 가입이 가능하다면 탈퇴할 수 있는 방법 역시 필수적으로 포함시켜야 합니다.
에셋, 기타 콘텐츠 파일명 관련 리젝
테스트 혹은 베타 라는 문구가 에셋이나 콘텐츠에서 발견되는 경우 리젝 대상에 해당됩니다. 물론 앱 성격에 따라 정식 버전의 앱에서 여러분의 성격을 테스트해보세요 등의 문구가 삽입될 수 있으나, 이런 경우를 제외하고는 테스트 혹은 베타라는 텍스트가 삽입되면 안됩니다.
사용자가 콘텐츠를 등록할 수 있고 그것이 다른 사용자에게 노출되는 경우, 신고 기능이 없다면 리젝
사용자가 콘텐츠를 등록할 수 있음에도 불구하고, 다른 사용자가 이를 차단하거나 신고할 수 있는 기능이 없다면 리젝 대상에 해당합니다. 예를 들어 SNS 앱의 경우 다른 사용자가 올린 피드가 노출되는 것을 막을 방법을 만들어두어야 합니다.
네이티브 기능이 아예 없거나 매우 빈약하면 리젝
웹앱의 경우 높은 확률로 리젝 대상에 해당합니다. 이는 앱으로써 기능하지 않는다고 판단하기 때문입니다. 웹페이지와 완벽하게 동일하게 작동하거나, 심사 담당자의 기준에서 앱이 가지는 추가적인 기능이 없다고 판단될 경우 리젝 대상에 해당합니다.
보고된 용도 이외의 기능이 포함되는 경우 리젝
일부 특수한 목적으로만 사용을 허가하는 라이브러리를 이용하는 경우, 보고된 특수 목적 이외의 용도로 앱이 사용될 가능성이 있으면 리젝 대상에 해당합니다. 예를 들어 아이폰의 조도 센서 등을 사용하는데 필요한 SenserKit 프레임워크의 경우 연구 목적을 위해서만 사용할 수 있습니다. 조도 센서를 이용하여 어두운 환경에 진입했을 때 화면 밝기를 낮추는 상업용 앱을 심사 요청할 경우 리젝 대상에 해당합니다.
이외에도 다양한 이유로 앱스토어 등록이 리젝 당할 수 있습니다. 온라인상에 리젝을 회피할 수 있는 여러가지 팁이 있으나, 모든 경우에 대응할 수 없거니와 리젝 자체는 큰일이 아니므로 사실상 심사 과정에서 발견되는 문제점은 명확하게 수정해주는 것이 정답이라고 볼 수 있습니다.
여담으로 언제든 리젝이 발생할 수 있다는 것을 염두에 두고 배포 일정을 산정하는 것도 시니어 개발자의 역량... 이라는 농담을 꽤 들었습니다.
Human Interface Guideline
UITableView, UICollectionView, UIStackView 등의 용도 차이
UITableView 는 단일
column으로 표현되는 데이터를 표시할 때, UICollectionView 는 복수의row,column으로 표현되는 데이터를 표시할 때, UIStackView 는 여러 디자인 요소를 단일row또는 단일column으로 표현하고 싶을 때 사용합니다.단일
column으로 표현되는 데이터를 표시하지만 복잡한 UX/UI 를 구현해야 하는 경우 UICollectionView 를 사용하는 경우도 많습니다.UICollectionViewLayout등을 이용하면 UITableView 보다 UICollectionView 를 사용하는 것이 더 많은 부분을 커스텀하여 사용할 수 있기 때문입니다.Lists and tables
UITableView 의 경우 데이터를 그룹이나 계층구조 형태로 보여줄 수 있습니다. 또한 선택, 추가, 삭제, 재정렬과 같은 사용자 상호 작용을 제공할 수 있습니다.
일반적으로 간단한 데이터 (텍스트 데이터 등) 를 나타날 때 많이 사용합니다. 데이터가 다양한 크기를 가지거나 많은 수의 이미지를 나타내야하는 등의 경우는 UITableView 대신 UICollectionView 를 활용하는 것이 낫습니다.
Collections
UICollectionView 의 경우 정렬된 데이터(콘텐츠) 집합을 관리하고, 데이터에 시각적인 요소를 입혀서 보여줄 수 있습니다. UITableView 에 비해 훨씬 더 다양하고 고도화된 시각적 효과를 만들어 낼 수 있습니다.
일반적으로 이미지를 포함한 비정형 데이터 집합을 나타낼 때 많이 사용합니다. 데이터가 텍스트 형태로 간단하게 나타낼 수 있는 경우, UICollectionView 대신 UITableView 를 활용하는 것이 낫습니다.
사용자에게 혼란을 주거나, 과도한 주의를 끌 수 있는 레이아웃은 사용하지 않는 것이 좋습니다. 일반적인 경우엔 UICollectionViewFlowLayout 을 사용하는 것으로 충분합니다.
StackView
디자인 요소들 (Collection of Views) 을 행 또는 열로 배치할 때 사용합니다. UITableView 나 UICollectionView 가 데이터 집합 을 나타낼 때 사용된다면, UIStackView 는 뷰 집합 을 정렬하는 인터페이스로 사용됩니다.
동일선상에서 비교하기는 힘들지만 UICollectionView 혹은 UITableView 와 비교하여 정적인 UI 를 만들 때 사용됩니다. 추가, 삭제, 재정렬과 같은 사용자 상호 작용이 필요한 뷰 집합 을 표현해야 하는 경우, UIStackView 대신 다른 레이아웃 요소를 활용하는 것이 낫습니다.
앱 구조에 영향을 주는 UI Component 시스템의 용도와 차이
HIG 에서는 Components 항목을 8 가지 하위 항목으로 나누어 설명하고 있습니다. 이 중 iOS 앱 구조에 크게 영향을 끼칠 수 있는 몇가지 컴포넌트들에 대해 살펴보겠습니다.
Tab bars
탭바는 일반적으로 글로벌 탐색 컴포넌트로써 사용됩니다. 앱의 콘텐츠를 몇개의 큰 섹션으로 분류하고 이들 사이를 탐색할 수 있는 기능을 제공합니다. 따라서 앱 계층 구조의 최상위에 위치하는 경우가 많습니다.
UITabBarController 는
Bar Item을 사용하여 동일한 뷰에서 상호 베타적인 콘텐츠를 탐색할 수 있도록 합니다.상호 베타적인 콘텐츠란 계층 혹은 의존 관계가 없는 콘텐츠들을 말합니다. 물론 한 앱 내부의 콘텐츠들이기 때문에 완전히 베타적일 수는 없지만, 적어도 확실한 계층 및 의존 관계가 있는 콘텐츠가 UITabBarController 로 관리되어선 안됩니다.iOS 의 기본
연락처앱에서 UITabBarController 를 사용한 예시를 볼 수 있습니다. 연락처 앱의 하위 콘텐츠들이기 때문에 완전히 베타적이진 않지만 계층 및 의존 관계과 없는즐겨찾기,최근 통화,연락처,키패드,음성 사서함콘텐츠가 메인 화면에서 탭바를 이용해 탐색할 수 있도록 배치되어 있습니다.탭바는 탐색용 으로만 사용해야 합니다. 탭바를
Action을 위해서 사용하면 안됩니다.Action을 위한 바가 필요한 경우Toolbar를 사용하는 것이 좋습니다.일반적으로 iOS 에선 3 ~ 5 개의 탭을 사용하는게 좋습니다. 이보다 더 탭이 많아지는 경우 복잡성이 증가하고 사용자가 원하는 정보를 찾기 어려워집니다. 5 개 이상의 탭을 사용해야 하는 경우 UITabBarController 이외의 컴포넌틀를 사용하거나, 콘텐츠 구조를 개선하는 것이 좋습니다.
특정 탭을 사용할 수 없는 경우에도
Bar Item이 사라지거나 터치가 불가능해지도록 처리하지 않아야 합니다. 탭을 사용할 수 없는 경우 탭을 사용할 수 없는 이유를 설명하거나 탭을 사용할 수 있도록 안내하는 콘텐츠를 배치하는 것이 좋습니다. 예를 들어 iOS 의 기본음악앱에서 지금 들을 수 있는 음악이 없더라고지금 듣기탭을 사용할 수 있습니다.Segmented controls
세그멘티드 컨트롤은 동일한 영역에서 상호 베타적인 콘텐츠를 탐색할 수 있도록 합니다. 또는 관련도가 높은 항목들을 선형으로 구조화하고 이들을 단일 혹은 복수개 선택하는 버튼으로써 동작합니다. 이 문서에서는 상호 베타적인 콘텐츠를 탐색하는 세그멘티드 컨트롤에 대해 설명합니다. (Tab views 의 동작을 구현하기 위해 iOS 에서 세그맨티드 컨트롤을 사용하는 경우에 대해 설명합니다)
대부분의 동작은 탭바와 동일하지만, 앱의 최상위가 아닌 특정 컴포넌트 내부에서 동작한다는 것이 차이점입니다. 아래 영상은 네이버페이 앱에서 세그멘티드 컨트롤과 유사한 커스텀 뷰를 사용하는 예시 영상입니다. (결제 탭 내부에서 상호 베타적인
멤버십,현장결제,교환권콘텐츠를 탐색할 수 있도록 구현되어 있습니다)Navigation bars
네비게이션바는 앱 화면 상단에 표시되어 콘텐츠의 계층 구조를 표시하고 탐색하는데 사용됩니다. 네비게이션바에 간단한 제목이나 콘텐츠와 관련된 동작을 위한 버튼이 추가될 수 있습니다.
네비게이션바에 제목을 추가할 경우 제목은 현재 콘텐츠에 대한 유용한 정보를 제공해야 합니다. 앱 이름과 같은 제목은 유용한 정보를 나타내지 않으므로 부적잘합니다. 제목이 필요 없는 경우 이를 생략해도 무방합니다. 예를 들어 iOS 의 기본
메모앱에서, 세부 메모 항목은 네비게이션바에 제목을 표시하지 않습니다.보다 몰입감 있는 환경을 제공하기 위해 탐색 모음을 일시적으로 숨길 수 있습니다. 예를 들어 iOS 의 기본
Photos앱에서, 전체 화면 사진을 볼 때 내비게이션바를 숨깁니다. 이후 사용자가 화면을 탭하거나 아래로 스와이프하여 내비게이션바를 복원할 수 있습니다.각 View, Control, Bar 의 사용 목적과 그에 대한 이해와 응용
해당 주제는 HIG 가 개편되기 이전에 정해진 주제인 듯 하여 간단하게만 살펴보겠습니다.
애플 디자인 팁 문서는 현재 링크가 망가진 상태입니다.
HIG 가 개편되기 이전에는 크게
View,Control,Bar항목으로 문서를 나누어 설명했습니다.Interface Essentials이라는 제목으로 이들에 대해서 요약하여 설명해주었는데 해당 문서는 삭제된 상태입니다. 한글 번역 문서 를 통해 이전의 문서를 확인할 수 있습니다.HIG 가 개편되며
View,Control,Bar형태로 기본 골자를 나누고 하위로 정렬하기보다는 기능과 컴포넌트 위주로 나누어 설명하는 형태로 변경되었습니다. 개인적으로는 특정 OS 에 종속되어 기술적으로 가이딩하는 것 대신 어떤 OS 에서든 애플의 느낌을 모두 녹여낼 수 있도록 정리된 느낌을 받았습니다. 이전의 문서 역시 분명히 배울 점이 많지만 이제는 참고 정도에서 활용하고 개편된 HIG 를 활용하는 것이 나을 것 같다는 생각입니다.Appstore Review Guideline
앱스토어는 사용자에게는 안전하게 앱을 이용할 수 있는 경험, 개발자에게는 뛰어난 앱을 개발할 수 있는 훌륭한 기회를 제공한다는 원칙 아래, 스토어에 등록 전 앱 심사(Review)를 진행하고 있습니다. 간단하게 리뷰 항목에 대해 알아보고, 리뷰 과정에서 앱 심사가 거절 당하는 몇몇 케이스에 대해 알아보겠습니다.
Appstore Review Guideline 의 기본 내용
애플에서는 앱스토어 리뷰를 위해 다섯가지 세션의 리뷰 가이드를 제공하고 있습니다. 아래에서 다섯가지 세션의 내용에 대해 간단히 요약하였습니다. 상세한 내용은 App Store 심사 지침 가이드라인을 통해 확인할 수 있습니다. 한국어 버전이 영어 원문보다 업데이트가 느리나, 큰 차이점은 없습니다.
안전성
앱에 불쾌하거나 모욕적인 콘텐츠가 없어야 하고, 기기에 손상을 주지 않아야 하며, 앱을 사용했을 때 신체적인 손상을 입을 가능성이 있어서는 안 됩니다.
성능
앱 심사 팀에 제출하는 앱은 필요한 모든 메타데이터가 있고 URL이 정상적으로 작동하는 최종 버전이어야 합니다. 베타버전 등의 앱은 앱 스토어 리뷰에서 거부될 수 있습니다. 또한 충돌이나 명백한 기술 문제가 드러나는 불완전한 앱 번들과 바이너리는 거부당합니다.
비즈니스
비즈니스 모델이 명확하지 않은 경우 메타데이터와 앱 심사 메모에 설명을 기재해야 합니다. 앱이 어떻게 작동하는지 파악할 수 없거나 앱 내 구입 기능을 바로 이해할 수 없는 경우 리뷰가 지연되거나 앱이 거부될 수 있습니다. 앱 가격은 개발자가 결정하지만, 앱과 앱 내 구입의 가격이 지나치게 높다고 판단되는 경우 배포를 허용하지 않습니다. 불합리하게 높은 가격으로 사용자를 속이려는 비싼 앱은 거부당합니다.
디자인
최소한의 디자인 기준을 충족하지 않는 앱은 리뷰에서 거부될 수 있습니다. 또한 앱을 승인받은 후에도 지속적인 업데이트를 통해 앱이 정상적으로 작동하도록 유지하여 기존 고객과 신규 고객에게 매력적인 사용 경험을 제공해야 합니다. 작동하지 않거나 수준 미달의 경험을 제공하는 앱은 언제든지 앱스토어에서 삭제될 수 있습니다.
법적 요구 사항
앱은 상용화될 지역의 모든 법적 요구 사항을 준수해야 합니다. 또한 불법 행위나 명백하게 위험한 행동을 요구하거나, 유도하고, 조장하는 앱은 무조건 거부됩니다. 인신매매 및 아동 착취를 조장하는 것으로 판명된 앱과 같이 극단적인 경우가 발생하면 담당 기관에 보고됩니다.
Review 거절 사례
앱스토어 리뷰 가이드가 명확하게 지정되어 있지만, 매우 다양한 사례들과 결국 사람이 리뷰한다는 한계로 명확하게 동일한 가이드가 적용되지는 않습니다. 어떤 앱은 통과 되었지만 다른 앱은 거절(리젝)되는 일이 많습니다. 아래는 다양한 Review 거절(리젝) 사례입니다.
소셜 로그인 관련 리젝
소셜 로그인 기능을 포함하려면, Apple ID 로 로그인 기능을 필수로 포함해야 합니다. 카카오 로그인, 네이버 로그인 등 소셜 로그인 기능을 포함했는데 Apple ID 로그인 기능이 빠져있다면 리젝 대상에 해당합니다.
인앱 구매 관련 리젝
오프라인에서 사용할 수 있는 재화를 판매할때는 애플의 인앱결제 기능을 사용하지 않아도 괜찮지만, 앱 내부에서 사용되는 디지털 재화를 판매할때는 무조건 애플의 인앱결제 기능만 사용해야 합니다. 쿠팡은 인앱 결제를 사용하지 않지만, iOS 에서 발매되는 게임앱 등의 경우는 아이템을 애플 인앱결제로 구매해야하는 이유입니다. 앱 내부에서 사용되는 디지털 재화를 구매할 수 있는 다른 경로가 존재하는 경우 리젝 대상에 해당합니다.
회원 가입 기능이 있는 경우, 탈퇴 기능이 없다면 리젝
회원 가입 기능을 포함하는 앱에 탈퇴 기능이 없다면 리젝 대상에 해당됩니다. 회원 가입이 가능하다면 탈퇴할 수 있는 방법 역시 필수적으로 포함시켜야 합니다.
에셋, 기타 콘텐츠 파일명 관련 리젝
테스트 혹은 베타 라는 문구가 에셋이나 콘텐츠에서 발견되는 경우 리젝 대상에 해당됩니다. 물론 앱 성격에 따라 정식 버전의 앱에서
여러분의 성격을 테스트해보세요등의 문구가 삽입될 수 있으나, 이런 경우를 제외하고는 테스트 혹은 베타라는 텍스트가 삽입되면 안됩니다.사용자가 콘텐츠를 등록할 수 있고 그것이 다른 사용자에게 노출되는 경우, 신고 기능이 없다면 리젝
사용자가 콘텐츠를 등록할 수 있음에도 불구하고, 다른 사용자가 이를 차단하거나 신고할 수 있는 기능이 없다면 리젝 대상에 해당합니다. 예를 들어 SNS 앱의 경우 다른 사용자가 올린 피드가 노출되는 것을 막을 방법을 만들어두어야 합니다.
네이티브 기능이 아예 없거나 매우 빈약하면 리젝
웹앱의 경우 높은 확률로 리젝 대상에 해당합니다. 이는 앱으로써 기능하지 않는다고 판단하기 때문입니다. 웹페이지와 완벽하게 동일하게 작동하거나, 심사 담당자의 기준에서 앱이 가지는 추가적인 기능이 없다고 판단될 경우 리젝 대상에 해당합니다.
보고된 용도 이외의 기능이 포함되는 경우 리젝
일부 특수한 목적으로만 사용을 허가하는 라이브러리를 이용하는 경우, 보고된 특수 목적 이외의 용도로 앱이 사용될 가능성이 있으면 리젝 대상에 해당합니다. 예를 들어 아이폰의 조도 센서 등을 사용하는데 필요한
SenserKit프레임워크의 경우 연구 목적을 위해서만 사용할 수 있습니다. 조도 센서를 이용하여 어두운 환경에 진입했을 때 화면 밝기를 낮추는 상업용 앱을 심사 요청할 경우 리젝 대상에 해당합니다.이외에도 다양한 이유로 앱스토어 등록이 리젝 당할 수 있습니다. 온라인상에 리젝을 회피할 수 있는 여러가지 팁이 있으나, 모든 경우에 대응할 수 없거니와 리젝 자체는 큰일이 아니므로 사실상 심사 과정에서 발견되는 문제점은 명확하게 수정해주는 것이 정답이라고 볼 수 있습니다.