[펌] iOS 8의 적응형(Adaptive) UI

---

 출처: http://www.shako.net/blog/ios8-adaptive-ui-explained/

---

하나의 정해진 화면 크기만 고려해서 개발하던 시대는 종말을 고했다. 3.5", 4", 4.7", 5.5", 7.9", 9.7" 크기의 디스플레이, 가로모드
, 세로모드, 레티나 디스플레이 등... 고려해야 할 사항들이 늘어남에 따라 설계해야 할 화면의 조합은 기하급수적으로 증가하였다.
애플은 iOS 8에서 내놓은 적응형(adaptive) UI의 등장 배경과 기본적인 개념을 정리하였다.

---

아이폰 화면크기의 변천사

2007년. UX 보다는 기능에 치중한 PDA와 피쳐폰이 난무하던 시절이였고, 당시 멀티터치 기반 인터페이스의 무한한 잠재력을 내다 본
애플은 새로운 형태의 스마트폰을 구상하고 있었다. 모바일이라는 극히 제약적인 환경에서 수 많은 프로토타입을 거친 결과 3.5" 크기의 디스플레이가 최종적으로 결정되었다. 출시가 이루어진 후 이듬해인 2008년에 앱스토어가 서비스에 들어갔고 서드파티 개발자들은
320 x 480 (@1x)에 최적화된 앱들을 개발하기 시작했다. 당시에는 가로모드(landscape)도 없었으니 하나의 해상도의 하나의 방향만
고려하면 되는, 그야말로 행복한 세상이였다.

2010년에 아이패드가 등장했다. 1024 x 768 (@1x) 픽셀의 화면과 크기를 가졌고, 새롭게 가로모드가 도입되었다.
동시에 "Split View"라는 화면분할 방식을 추가했다. 아이폰에서는 두 화면에 걸쳐 보여지던 내용을 한 화면에서 볼 수 있게 된 것이다.
메일 앱의 경우를 예로 들면, 왼쪽에는 메일 목록을 보여주고 오른쪽에는 메일 세부내용을 동시에 보여줘서 화면 전체를 전환하지 않아도
메일 항목간에 번갈아가며 볼 수 있게 되었다.

아이폰 4는 레티나 디스플레이(Retina Display)라고 불리우는 고해상도 화면을 탑재하였다.
가로, 세로로 픽셀의 갯수가 각각 두배가 되어서 640 x 960 픽셀의 해상도였다. 기존 앱들과의 호환성을 위해 포인트(point)라는 개념을
도입하였는데, 이는 화면에 표시되는 크기에 대한 논리적인 단위이다. 이전 기기에서는 1 포인트 = 1 픽셀로, 레티나 기기에서는
1 포인트 = 2 픽셀로 정의를 해서 포인트 단위로 화면에 출력을 할 경우 두 기기에서 동일하게 보여지게 된다.
예전에는 1개만 필요했던 이미지 파일들도 이 때 부터 저해상도, 고해상도 버전으로 2개씩 제작을 해야 했다.

2012년도에는 레티나 아이패드가 출시되었다. 1024 x 768 (@2x) 포인트를 유지했지만 마찬가지로 가로, 세로 픽셀이 각각 두 배가
되어 2048 x 1536 픽셀이 되었다. 이 때 까지만 해도 다양한 화면 크기와 해상도를 지원하는 일은 그럭저럭 견딜만 했다.
두 가지의 크기(아이폰, 아이패드)와 두 가지의 방향(가로모드, 세로모드), 그리고 두 가지의 해상도(비-레티나, 레티나)를 고려해야 했고,
이를 조합하면 모두 8가지 경우의 수가 나왔다.

2012년 가을에 아이폰 5가 출시되었다. 2007년만 해도 광활하다고 여겨졌던 3.5"의 디스플레이는 경쟁 제품들에 비해 초라한 크기가
되어버렸다. 이에 대한 고심의 결과인지 320 x 568 (@2x) 포인트, 640 x 1136 픽셀이라는 다소 의아한 해상도를 가지고 출시되었다.
그로 인해 추가로 늘어난 320 x 88 (@2x) 포인트 공간에 대한 고민이 시작되기 시작했다.

어떤 앱들은 이 공간을 목록보기에서 항목을 더 보여주는 것으로 사용했고, 이미지를 표시할 때 더 표시하는 것으로 사용하기도 했다.
하지만 커스텀 UI는 새로 만들어져야 했다. 개발자들이 아무런 처리를 하지 않으면 이 공간은 상/하단의 검은 여백이 표시되었다.
이제 개발자들은 세 가지의 포인트 크기와, 두 가지의 화면 방향, 두 가지의 해상도를 지원해야만 했다.

다행히도 아이폰 3GS가 단종되면서 320 x 480 (@1x) 포인트 화면을 지원할 필요가 사라졌다.
하지만 아이패드 2와 1세대 아이패드 미니는 여전히 비-레티나 화면이였기 때문에
1024 x 768 (@1x)는 여전히 고려해야 할 대상이였다.

2014년에 아이폰 6와 아이폰 6 플러스가 출시됨에 따라 사태는 점입가경에 이르게 된다.
아이폰 6는 375 x 667 (@2x) 포인트였고, 아이폰 6 플러스는 414 x 736 (@3x) 포인트였다.

특히 아이폰 6 플러스가 @3x라는 새로운 해상도를 도입한 것 외에도, 물리적인 픽셀 수가 1080 x 1920의 변태 해상도(!)였기 때문에
혼란은 가중되었다. 기존에는 포인트에 @ 배수를 곱하면 물리 픽셀과 일치하였지만 아이폰 6 플러스는 1242 x 2208 픽셀을 렌더링한 후에 다운샘플링(downsampling)하여 최종적으로 1080 x 1920 픽셀로 보여주게 된다.
이로 인해 디자이너로부터 사랑받았던 1픽셀 크기의 헤어라인(hair line)은 정상적으로 구현하기 어려워졌다.

2015년 1월 현재까지 출시된 기기들의 종류는 다음과 같다.

이 시점에서 개발자들은 다섯 가지의 포인트 크기와, 두 가지의 화면 방향, 세 가지의 해상도를 지원해야 했다.
이를 조합하면 무려 30가지 경우의 수가 나오고, 이 중에서 의미 없는 조합을 제외하더라도 14가지 경우의 수를
고려해야 하는 상황이 되었다.

다양한 화면 크기와 해상도를 출시한 애플은 뒷수습을 위해 2012년에 오토 레이아웃(Auto Layout)을 도입하였다.
이는 화면에 표시되는 항목들을 제약조건(constraints)에 따라 표시하는 방식이다.

예를 들면, '두 버튼 사이의 간격은 10 포인트'라는 조건을 지정해 주면 화면에 모든 조건들을 만족시키도록 표시하는 방식이다.
하지만 오토 레이아웃만으로는 복잡한 해상도 문제를 궁극적으로 해결할 수 없었고 화면 크기라는 변수와 조합이 필요했다.
이로 인해 도입되게 된 것이 사이즈 클래스라는 개념이다.

---

사이즈 클래스(Size classes)

애플은 iOS 8에서 사이즈 클래스를 도입했다. 가로와 세로의 화면의 크기를 의미적으로 구분하기 위한 것으로
, UIInterfaceOrientation와 UIUserInterfaceIdiom을 대체하게 될 것이다.
다음과 같이 네 가지가 정의되었다.

• 가로 레귤러 (Horizontal Regular)
• 가로 컴팩트 (Horizontal Compact)
• 세로 레귤러 (Vertical Regular)
• 세로 컴팩트 (Vertical Compact)

특별한 원칙에 따라 구분되었다기 보다는 그렇게 정의하기로 해서 정해진 느낌이 강하다. 아래에는 가로 사이즈 클래스의 경우를 보면
왼쪽과 같이 아이패드에서 뜨는 화면을 많이 차지하는 뷰는 '가로 레귤러'로 분류하고 있고, 오른쪽과 같이 아이폰에서 보여지는 경우
또는 아이패드에서 너비가 작게 표시되는 경우 '가로 컴팩트'로 분류하고 있다.

다음의 표는 전체화면 크기가 각 기기에서 어떻게 분류되는지를 보여준다.
특이하게도 아이폰 6 플러스의 경우에는 가로모드에서 다른 아이폰들과 달리 '가로 레귤러'로 표시된다.

애플이 제공하는 기본 UI중에서 사이즈 클래스의 변화에 따라 먼저 최적화된 것은 네비게이션 바(navigation bar)이다.
컴팩트/레귤러에서 컴팩트/컴팩트로 바뀌게 될 때 네비게이션 바의 높이가 작아지며 상태 바(status bar)는 사라지도록 하였다.
이는 화면에 컨텐츠를 최적화해서 보여주기 위함이다.
iOS 9, iOS 10 이후에는 좀 더 많은 UI 요소들이 이런 최적화를 보여주리라 기대가 된다.

사이즈 클래스에 따라 화면을 구성하는 것이 가능해짐에 따라 개발자들은 좀더 쉽게 화면 크기에 최적화된 앱들을 만들 수 있다.
예를 들어 세로모드에는 위, 아래로 배치되어 있던 버튼들을 가로모드에서는 왼쪽과 오른쪽으로 배치해서 보여줄 수 있다.
또한 아이패드에서만 가능했던 Split View를 아이폰에서도 사용할 수 있게 되었다. 실제로 아이폰 6+에서는 가로모드에서
아이패드 같은 화면을 보여주게 된다.

---

트레잇 컬렉션(Trait Collection)

트레잇 컬렉션은 현재 스크린 정보를 담고 있다. 가로 및 세로의 사이즈 클래스(레귤러, 컴팩트), 인터페이스 이디엄(Interface Idium; 아이폰 또는 아이패드를 구분), 화면 비율(1.0 또는 2.0)들이 여기에 포함된다. 아래의 예는 레티나 아이폰 세로모드에서의 경우이다.
가로 사이즈 클래스는 컴팩트이고, 세로 사이즈 클래스는 레귤러이다. 아이폰/아이팟 터치인 경우이므로 userfaceIdiom은 Phone이고, displayScale은 2.0이다.

UIViewController에서 traitCollection을 통해 접근이 가능하며,
화면 방향이 바뀌게 되면 traitCollectionDidChange: 메소드가 호출되게 된다.

---

이미지 파일 관리

이미지 파일 관리에도 변화가 생겼다. Xcode 6에서 바뀐 이미지 어셋(Image Assets)을 통해서, 가로 및 세로 사이즈 클래스, 인터페이스 이디엄, 화면 비율 등의 정보를 트레잇 컬렉션을 통해 정보를 가져오고 꼭 필요한 이미지를 불러오게 된다.

예를 들면, 아이폰 가로모드에서 버튼 크기를 가로모드에서보다 좀 작게 하려면, 두 개의 이미지를 제작한 후 각각 상황에 지정하면
되는 방식이다. 다양한 이미지 파일을 만들어야 한다는 사실은 변함이 없지만만, 적어도 Xcode 안에서 파일들을 체계적으로 정돈하고
관리할 수 있는 길이 생긴 것이다.

위와 같이 이미지들을 지정해주면, 아이폰 가로모드의 경우 왼쪽과 같은 트레잇 컬렉션으로 인식하여 큰 이미지를 표시해주고
, 아이폰 세로모드의 경우 오른쪽과 같은 트레잇 컬렉션으로 인식하여 작은 이미지를 표시해준다.

---

Split View Controller

Xcode 6에서는 하나의 스토리보드를 가지고, 다양한 화면을 대응할 수 있게 되었다.
이를 위해서 뭔가 엘레강스한 디자인 패턴이 필요했는데 이를 위해서 애플이 가장 먼저 손을 댄 것이 Split View Controller이다.

위는 환경설정 앱의 예이다. 왼쪽에는 주로 목록을 보여주는 마스터(master) 뷰, 오른쪽에는 주로 세부사항을 보여주는 디테일(detail) 뷰로 구성이 되어 있다. 계층 구조의 데이터를 표현해주는 많은 종류의 앱이 이러한 형태로 표현하기 좋다.
또한 현재 화면의 가로 사이즈 클래스의 값에 따라 다음과 같이 자동으로 화면 전환이 이루어진다.

• 가로 레귤러일 경우 위 그림처럼 나란히(side-by-side) 표시된다.
• 가로 컴팩트일 경우 마스터 뷰가 표시되고, 디테일 뷰는 숨겨진다.

아이패드는 가로모드, 세로모드 모두 가로 레귤러의 사이즈 클래스를 가지고 있기 때문에 화면 전환에 따라 위의 전환이 일어나지 않는다.
아이폰 6 플러스를 제외한 아이폰도 두 경우 모두 가로 컴팩트이므로 마찬가지로 위의 전환이 이루어지지 않는다.

아이폰 6 플러스의 경우 가로모드에서 세로모드로 전환할 경우, 위에 해당하는 전환이 이루어진다.
메일 앱을 아이폰 6 플러스에서 가로모드에서 볼 경우 다음과 같이 배치된다.

---

꽤 장문의 포스팅이 되었지만 개발자로서 고민을 해야 할 부분은 이제부터 시작이다.
아이폰 5가 처음 나왔을 때 추가로 늘어난 화면 크기에 대한 고민이 이루어졌던 것 처럼,
아이폰 6와 아이폰 6 플러스가 제공해주는 더 큰화면 영역이 어떻게 사용되어야 할지에 대한 고민이 필요해졌다.
아이폰용 앱과 아이패드용 앱을 따로 만들던 시대로부터 벗어남에 따라 같은 내용을 각각의 기기에서 어떻게
일관적으로 보여줄가에 대한 고민도 필요하다.
애플이 내놓은 Split View Controller 같은 패턴들이 좀더 다양하게 개발되어야 할 것이다.

반응형 웹이 처음 나왔을 때와 마찬가지로 정리가 되려면 시간이 좀 더 필요해 보인다.
현재로서는 아래와 같은 자료들을 참고할 수 있다.

• Adaptive User Interfaces
• Adaptive UI in iOS 8: Explained
• Preparing for the new iPhone 6 and iPhone 6 Plus screen sizes
• iOS Development Tips for iPhone 6 and iOS 8
• View Controllers in iOS 8 - A quick review
• WWDC 2014, Building Adaptive Apps with UIKit