빨강
초록
주황
파랑
갈색
모든 어플리케이션은 콘텐츠를 나타내기 위해 적어도 한개의 window와 한개의 view를 가진다.
뷰는 UIView 클래스의 인스턴스이다. (drawing(Core Graphics, OpenGL EL, UIKit), event(Gesture Recognizer를 통한 터치같은 이벤트), subview관리에 쓰인다.)
뷰는 유저 인터페이스를 구축하기 위해 사용하는 레고 블록이라고 생각하면 된다.
윈도우는 UIWindow 클래스의 인스턴스이다. 눈에 보이는 콘텐츠를 포함하지 않는다. 어플리케이션은 장치의 메인 스크린의 유저 인터페이스를 보여주는 적어도 하나의 window를 가지며 한번 생성되면 절대 바뀌지 않는다. 다른 장치에 연결되면 두번째 window를 보여주기도 한다.
시각적으로 하고 싶은 것은 view objects—instances of the UIView class에서 가능하다. class UIView : UIResponder. view objects는 스크린 위의 사각형 공간을 정의하고 공간에서 drawing과 터치 이벤트를 다룬다. 다른 뷰들의 부모가 될 수도 있고 뷰들의 위치를 조정하고 사이즈를 바꾸는 공간이기도 하다. UIView class는 대부분 뷰들의 관계를 관리하지만 디폴트 행동을 커스터마이즈할 수도 있다.
Core Animation 층과 함께 뷰의 컨텐츠를 렌더링하고 움직이게 할 수 있다. UIKit의 모든 뷰는 CALayer class의 인스턴스에 의해 뒷받침된다. 뷰와 뷰관련된 애니메이션을 다룬다. UIView 인터페이스에서 대부분의 기능을 작동시킬 수 있지만 렌더링이나 애니메이션에 대해 더 많은 조작을 하고 싶으면 이 계층을 사용한다.

Core Animation layers를 포함한 ViewTransitions의 샘플 어플리케이션이다.
1. window(view)
2. generic UIView(container view)
3. image view
4. toolbar
5. bar button(뷰는 아니지만 내부적으로 뷰를 관리한다)
모든 뷰는 뷰의 레이어 속성을 통해 접근할 수 있다.(바버튼은 뷰가 아니기 때문이다.) 레이어 객체의 뒤에는 객체를 렌더링하는 Core Animation과 스크린의 실제 비트를 관리하는 하드웨어 버퍼가 있다.
코어 애니메이션은 성능에 중요하다. 실제로 뷰 객체를 그리는 코드는 최대한 적게 사용되고 생성된 객체가 코어 애니메이션의 의해 캐시되고 최대한 많이 재사용된다. 뷰를 업데이트할 때 불필요한 뷰를 그리는 사이클 비용을 줄일 수 있다. 재사용하는 것이 새로 만드는 것보다 훨씬 경제적이다.
요약: UIView 클래스에서 대부분의 뷰를 관리한다. 그 뒤에는 Core Animation이 있는데 렌더링과 애니메이션이 많이 필요한 경우 중요하게 작용한다. CALayer는 뷰를 새로 만들기보다는 재사용하게 해서 성능을 향상시킨다.
뷰는 갖고 있는 콘텐츠를 보여줄 뿐만 아니라 다른 뷰의 컨테이너로서도 작용한다. 자식 뷰는 subview라고 부르고 부모 뷰는 superview라고 부른다.
시각적으로 subview는 superview에 영향을 끼친다. subview가 opaque(불투명한)하면 superview가 완전히 모호해진다. 만약 투명하다면 두 뷰가 섞인다.
부모 뷰의 사이즈를 바뀌는 것은 자식 뷰에 영향을 끼친다.
뷰의 계층은 이벤트에도 영향을 끼친다. 뷰 내부에서 터치가 발생하면 뷰로 보내진다. 뷰에서 이벤트가 처리되지 않으면 그 뷰의 슈퍼뷰로 이벤트를 계속 던지고 responder chain까지 계속된다. 특정 뷰는 이벤트를 view controller와 같은 responder object와 개입한다. 마지막까지 이벤트가 처리되지 않으면 application object로 이벤트를 보낸 후 이벤트는 버려진다.

UIWindow and UIView 클래스는 좌표를 서로 변환할 수 있는 메서드를 갖고 있다.
중요: 몇몇의 iOS 기술들은 기본 좌표 시스템의 원래 포인트와 방향을 UIKit와 다르게 정의한다. 예를 들어, Core Graphics and OpenGL ES은 lower-left corner에 origin이 있고, y축의 포인트가 위쪽으로 올라가는 방향의 좌표 시스템을 사용한다.
frame: 슈퍼뷰의 좌표 시스템의 사이즈와 위치를 나타내는 프레임 사각형
bounds: 뷰의 로컬 좌표 시스템의 사이즈를 나타내는 바운드 사각형
center: 슈퍼뷰의 좌표 시스템에 있는 뷰의 센터 포인트
center 과 frame를 현재 뷰를 나타내기 위해 사용한다. 예를 들어, 뷰 계층 구조나 뷰의 위치와 사이즈를 런타임에 바꿀 때 사용한다. 만약 사이즈가 아니라 위치만 변경한다면 center는 사용하기 좋은 속성이다. center는 비율이나 회전하더라도 바뀌지 않는다.
You use the bounds 주로 drawing에 사용한다. 뷰의 로컬 좌표시스템을 나타내는데 사용된다. origin은 (0, 0)이고 프레임 사각형의 크기와 일치한다. bounds 사각형의 origin을 바꾸더라도 새로운 사각형 안에 그리는 것은 뷰의 보이는 콘텐츠가 된다.

슈퍼뷰로부터의 위치를 나타낸 왼쪽은 프레임이고, 로컬뷰(origin point(0, 0))로부터의 위치를 나타낸 오른쪽은 바운드이다.
프레임을 속성을 세팅했을 때, 바운드가 바뀌어도 프레임으로 새로 생성된 사이즈는 일치한다.
센터 속성을 세팅했을 때, 프레임의 오리진 값도 따라서 바뀐다.
바운드의 사이즈를 세팅했을 때, 프레임의 속성도 새로운 바운드에 맞춰 변한다.
| Divice | Screen dimensions(in points) |
|---|---|
| iPhone and iPod touch device with 4-inch Retina display | 320 x 568 |
| Other iPhone and iPod touch devices | 320 x 480 |
| iPad | 768 x 1024 |
One point does not necessarily correspond to one pixel on the screen.
포인트는 픽셀과 일치하지 않을 수도 있다.
OpenGL이나 ES과 같은 픽셀 기반의 이미지 작업을 할 때 device coordinate space는 알아서 계산해주니 UIKit에서 Core Graphics를 활용해 그릴 때 실제 기기의 해상도를 고려할 필요는 없다.
모든 iOS 어플리케이션은 적어도 하나의 UIWindow 클래스의 인스턴스를 가진다.
어플리케이션의 보이는 콘텐츠, 이벤트의 전달, 뷰 컨트롤러의 방향 전환에 중요한 역할을 한다.

주요 기능
nib(NeXT Interface Builder)은 번들파일로 바이너리 기반이다. SVN을 사용하면 문제가 발생해 xib(Xml Interface Builder)을 사용한다. xib은 플랫파일로 빌드하면 nib파일로 컴파일된다고 한다.
인터페이스 빌더를 통해 뷰 객체를 생성하면 만들면서 런타임화면을 볼 수 있고, 객체의 상태와 속성을 nib file로 저장할 수 있다.
nib file은 보통 뷰의 전체 계층을 포함하고 뷰 컨트롤러의 싱글 뷰를 포함한다.
뷰 컨트롤러와 함께 nib file을 사용려면 뷰 컨트롤러를 초기화해줘야 한다.
뷰 컨트롤러와 함께 사용하지 않으면 NSBundle나 UINib object를 사용해 뷰 객체를 재구성해야 한다.