iOS 8의 적응형(Adaptive) UI

아이폰의 스크린 크기는 파편화 되지 않았다는 이야기는 이제 옛 말이 되었습니다. 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)도 없었으니 하나의 해상도의 하나의 방향만 고려하면 되는, 그야말로 행복한 세상이였습니다.

iPhone 3/3GS

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

iPad 1/2

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

iPhone 4/4s

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

iPad 3/4, iPad Air 1/2

2012년 가을에 아이폰 5가 출시되었습니다. 2007년만 해도 광활하다고 여겨졌던 3.5"의 디스플레이는 경쟁 제품들에 비해 초라한 크기가 되어버렸습니다. 이에 대한 고심의 결과인지 320 x 568 (@2x) 포인트, 640 x 1136 픽셀이라는 다소 의아한 해상도를 가지고 출시되었습니다. 그로 인해 추가로 늘어난 320 x 88 (@2x) 포인트 공간에 대한 고민이 시작되기 시작했습니다. 어떤 앱들은 이 공간을 목록보기에서 항목을 더 보여주는 것으로 사용했고, 이미지를 표시할 때 더 표시하는 것으로 사용하기도 했습니다. 하지만 커스텀 UI는 새로 만들어져야 했습니다. 개발자들이 아무런 처리를 하지 않으면 이 공간은 상/하단의 검은 여백이 표시되었습니다. 이제 개발자들은 세 가지의 포인트 크기와, 두 가지의 화면 방향, 두 가지의 해상도를 지원해야만 했습니다.

iPhone 5/5c/5s

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

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

iPhone 6

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

iPhone 6 Plus

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

All

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

Table

다양한 화면 크기와 해상도를 출시한 애플은 뒷수습을 위해 2012년에 오토 레이아웃(Auto Layout)을 도입하였습니다. 이는 화면에 표시되는 항목들을 제약조건(constraints)에 따라 표시하는 방식입니다. 예를 들면, ‘두 버튼 사이의 간격은 10 포인트’라는 조건을 지정해 주면 화면에 모든 조건들을 만족시키도록 표시하는 방식입니다. 하지만 오토 레이아웃만으로는 복잡한 해상도 문제를 궁극적으로 해결할 수 없었고 화면 크기라는 변수와 조합이 필요했습니다. 이로 인해 도입되게 된 것이 사이즈 클래스라는 개념입니다.


사이즈 클래스(Size classes)

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

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

아래에는 가로 사이즈 클래스의 경우를 보면 왼쪽과 같이 아이패드에서 뜨는 화면을 많이 차지하는 뷰는 ‘가로 레귤러’로 분류하고 있고, 오른쪽과 같이 아이폰에서 보여지는 경우 또는 아이패드에서 너비가 작게 표시되는 경우 ‘가로 컴팩트’로 분류하고 있습니다.

Size Classes Example

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

Size Classes

애플이 제공하는 기본 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입니다.

Trait Collection

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


이미지 파일 관리

이미지 파일 관리에도 변화가 생겼습니다. Xcode 6에서 바뀐 이미지 어셋(Image Assets)을 통해서, 가로 및 세로 사이즈 클래스, 인터페이스 이디엄, 화면 비율 등의 정보를 트레잇 컬렉션을 통해 정보를 가져오고 꼭 필요한 이미지를 불러오게 됩니다. 예를 들면, 아이폰 가로모드에서 버튼 크기를 가로모드에서보다 좀 작게 하려면, 두 개의 이미지를 제작한 후 각각 상황에 지정하면 되는 방식입니다. 다양한 이미지 파일을 만들어야 한다는 사실은 변함이 없지만, 적어도 Xcode 안에서 파일들을 체계적으로 정돈하고 관리할 수 있는 길이 생긴 것입니다.

Image Assets

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

Image Renderings


Split View Controller

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

Split View Controller

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

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

아이패드는 가로모드, 세로모드 모두 가로 레귤러의 사이즈 클래스를 가지고 있기 때문에 화면 전환에 따라 위의 전환이 일어나지 않습니다. 아이폰 6 플러스를 제외한 아이폰도 두 경우 모두 가로 컴팩트이므로 마찬가지로 위의 전환이 이루어지지 않습니다. 아이폰 6 플러스의 경우 가로모드에서 세로모드로 전환할 경우, 위에 해당하는 전환이 이루어집니다. 메일 앱을 아이폰 6 플러스에서 가로모드에서 볼 경우 다음과 같이 배치됩니다.

iPhone 6 Plus Mail app


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

현재로서는 아래와 같은 자료들을 참고할 수 있습니다.

comments powered by Disqus