뷰 컨트롤러
1. 개요
1. 개요
뷰 컨트롤러는 iOS 애플리케이션의 사용자 인터페이스를 관리하고 구성하는 핵심 객체이다. UIKit 프레임워크에서 제공되며, 상위 클래스는 UIResponder이다. 주된 역할은 하나의 화면 또는 화면의 일부를 담당하는 뷰 계층 구조를 관리하고, 사용자의 상호작용을 처리하며, 애플리케이션의 데이터와 화면에 보여지는 뷰 사이의 중개자 역할을 수행하는 것이다.
모든 뷰 컨트롤러는 뷰의 생명주기에 따라 호출되는 특정 메서드들을 가지고 있다. 대표적으로 viewDidLoad, viewWillAppear, viewDidAppear, viewWillDisappear, viewDidDisappear 등이 있으며, 개발자는 이러한 메서드를 오버라이드하여 뷰가 화면에 나타나기 전후의 초기화나 정리 작업을 수행할 수 있다. 이를 통해 메모리 관리와 화면 전환을 효율적으로 처리한다.
뷰 컨트롤러는 단일 화면을 관리하는 UIViewController를 기본으로 하며, 특정 목적에 맞춰 다양한 종류로 확장되어 있다. 예를 들어, 목록 형태의 데이터를 표시하기 위한 UITableViewController, 그리드 레이아웃을 위한 UICollectionViewController, 그리고 여러 화면 간의 계층적 네비게이션을 담당하는 UINavigationController나 탭 기반 인터페이스를 구성하는 UITabBarController 등이 있다.
2. 역할과 기능
2. 역할과 기능
뷰 컨트롤러는 iOS 애플리케이션의 사용자 인터페이스를 관리하고 구성하는 핵심 객체이다. UIResponder 클래스를 상속받으며, UIKit 프레임워크의 근간을 이룬다. 기본적으로 하나의 화면 또는 화면의 일부 영역을 담당하며, 해당 영역에 표시되는 모든 뷰의 계층 구조를 생성하고 관리하는 역할을 수행한다. 이는 애플리케이션의 화면이 복잡한 뷰들로 구성되어 있을 때, 이를 체계적으로 제어할 수 있는 틀을 제공한다.
주요 기능은 화면의 뷰 계층 구조를 관리하는 것이다. 뷰 컨트롤러는 자신이 관리하는 루트 뷰를 중심으로 서브뷰들을 추가하거나 제거하며, 레이아웃이 변경될 때 뷰들의 크기와 위치를 조정한다. 또한 사용자가 버튼을 탭하거나 제스처를 입력하는 등의 사용자 상호작용을 직접 처리하거나, 적절한 대상에게 전달하는 매개체 역할도 한다.
뷰 컨트롤러는 데이터와 뷰 사이의 중개자 역할을 수행한다. 모델-뷰-컨트롤러 아키텍처에서 컨트롤러 계층에 해당하며, 애플리케이션의 비즈니스 로직이나 데이터 모델로부터 정보를 받아, 이를 뷰에 표시할 수 있는 형태로 가공하여 전달한다. 반대로 사용자의 입력을 받아 데이터 모델을 업데이트하는 작업도 조정한다.
이러한 역할을 효과적으로 수행하기 위해 뷰 컨트롤러는 정해진 생명주기를 가진다. 시스템은 화면에 표시되거나 사라지는 시점 등 중요한 상태 변화 시점에 viewDidLoad, viewWillAppear, viewDidAppear, viewWillDisappear, viewDidDisappear와 같은 특정 메서드를 호출한다. 개발자는 이 메서드들을 오버라이드하여 뷰의 초기 설정, 데이터 로딩, 화면 전환 시 정리 작업 등을 적절한 타이밍에 실행할 수 있다.
3. 뷰 컨트롤러의 종류
3. 뷰 컨트롤러의 종류
3.1. UIViewController
3.1. UIViewController
UIViewController는 iOS 애플리케이션에서 하나의 화면을 구성하고 관리하는 핵심 객체이다. UIKit 프레임워크에 속하며, UIResponder 클래스를 상속받는다. 각 UIViewController는 애플리케이션의 사용자 인터페이스를 담당하는 하나의 단위로, 화면에 표시되는 뷰 계층 구조를 관리하고 사용자의 입력을 처리하는 역할을 한다.
주요 역할은 화면의 뷰 계층 구조를 관리하고, 사용자와의 상호작용을 처리하며, 모델 데이터와 뷰를 연결하는 중개자 역할을 수행하는 것이다. 이를 통해 애플리케이션의 로직과 사용자 인터페이스를 효과적으로 분리할 수 있다. UIViewController는 다양한 생명주기 메서드를 제공하여, 뷰가 화면에 나타나기 전과 후, 사라지기 전과 후와 같은 시점에 개발자가 필요한 코드를 실행할 수 있도록 한다.
이 클래스는 가장 기본적인 뷰 컨트롤러 형태로, 테이블 뷰나 컬렉션 뷰를 주로 사용하는 화면을 위해 특화된 UITableViewController나 UICollectionViewController와 같은 서브클래스들의 기반이 된다. 또한, UINavigationController나 UITabBarController와 같은 컨테이너 뷰 컨트롤러와 결합하여 복잡한 네비게이션 구조를 구성하는 데에도 사용된다.
개발자는 UIViewController의 서브클래스를 생성하여 자신의 화면 로직을 구현한다. viewDidLoad, viewWillAppear, viewDidAppear, viewWillDisappear, viewDidDisappear 등의 생명주기 메서드를 오버라이드하여 뷰의 초기 설정, 데이터 로딩, 애니메이션 시작 및 정리 등의 작업을 적절한 시점에 수행하게 된다.
3.2. UITableViewController
3.2. UITableViewController
UITableViewController는 iOS 애플리케이션에서 테이블 형태의 데이터를 표시하고 관리하기 위해 특화된 뷰 컨트롤러이다. 이 클래스는 UIViewController를 상속받으며, 기본적으로 하나의 UITableView를 뷰로 가지고 있다. 테이블 뷰의 데이터 소스(UITableViewDataSource)와 델리게이트(UITableViewDelegate) 역할을 자동으로 설정하여, 개발자가 별도의 프로토콜 채택 선언 없이도 테이블 관련 메서드를 구현할 수 있도록 설계되었다.
주요 용도는 리스트 형태의 데이터를 효율적으로 표시하는 것이다. 연락처 목록, 설정 메뉴, 타임라인, 상품 목록과 같은 정형화된 정보를 사용자에게 제공하는 데 적합하다. UITableViewController를 사용하면 테이블 뷰가 컨트롤러의 뷰 영역 전체를 채우도록 자동으로 구성되며, 스크롤 및 셀 선택과 같은 기본적인 상호작용 처리를 간편하게 구현할 수 있다.
이 컨트롤러는 정적(Static Cells)과 동적(Prototype Cells) 두 가지 방식의 테이블 뷰 레이아웃을 인터페이스 빌더(Interface Builder)에서 지원한다. 또한, 테이블 뷰의 새로고침을 위한 UIRefreshControl을 내장하고 있어, 사용자가 테이블을 아래로 당겨 데이터를 갱신하는 풀-투-리프레시(Pull-to-Refresh) 기능을 쉽게 추가할 수 있다.
그러나 UITableViewController의 뷰가 오직 테이블 뷰로만 구성된다는 점은 제한적일 수 있다. 더 복잡한 사용자 인터페이스, 예를 들어 테이블 뷰 외에 다른 뷰 요소를 화면에 함께 배치해야 하는 경우에는 일반 UIViewController에 UITableView를 서브뷰로 추가하고 관련 프로토콜을 직접 구현하는 방식이 더 유연한 선택이 될 수 있다.
3.3. UICollectionViewController
3.3. UICollectionViewController
UICollectionViewController는 iOS 애플리케이션에서 컬렉션 뷰를 관리하는 데 특화된 뷰 컨트롤러이다. 이 클래스는 UIViewController를 상속받으며, 컬렉션 뷰와 그 데이터 소스 및 델리게이트를 기본적으로 설정하여 제공한다. 개발자는 이 클래스를 사용하여 격자 형태, 리스트 형태, 커스텀 레이아웃 등 다양한 방식으로 데이터를 시각적으로 표시하는 인터페이스를 쉽게 구현할 수 있다.
주요 역할은 컬렉션 뷰의 레이아웃을 정의하고, 표시할 데이터를 관리하며, 사용자의 상호작용(예: 항목 선택, 스크롤)에 응답하는 것이다. 이를 위해 UICollectionViewDataSource 프로토콜과 UICollectionViewDelegate 프로토콜의 메서드를 구현하여 데이터를 제공하고 이벤트를 처리한다. UICollectionViewFlowLayout 또는 커스텀 UICollectionViewLayout을 사용하여 셀의 배치, 크기, 간격 등을 세밀하게 제어할 수 있다.
일반적인 구현 방식은 UICollectionViewController를 서브클래싱하거나, 다른 뷰 컨트롤러 내에 컬렉션 뷰를 추가하는 것이다. 전자의 경우, 컨트롤러 자체의 뷰가 컬렉션 뷰가 되며, 데이터 소스와 델리게이트 메서드를 해당 서브클래스 내에서 구현한다. 이는 사진 앨범, 상품 목록, 갤러리 등 정렬된 데이터 집합을 표시하는 화면을 구성할 때 널리 사용된다.
UICollectionViewController는 UIKit 프레임워크의 핵심 구성 요소로, 뷰 컨트롤러의 생명주기(예: viewDidLoad, viewWillAppear)를 따르며 메모리 관리를 돕는다. 복잡한 레이아웃과 재사용 가능한 셀을 효율적으로 관리할 수 있어, 현대적인 iOS 애플리케이션의 사용자 인터페이스를 구축하는 데 필수적이다.
3.4. UINavigationController
3.4. UINavigationController
UINavigationController는 iOS 애플리케이션에서 계층적인 콘텐츠 구조를 탐색하는 데 사용되는 특수한 유형의 뷰 컨트롤러이다. 이 컨트롤러는 스택 자료구조를 기반으로 하여 여러 UIViewController 인스턴스를 관리하며, 사용자는 일반적으로 화면 상단의 네비게이션 바에 제공되는 뒤로 가기 버튼을 통해 이전 화면으로 돌아갈 수 있다. 이를 통해 앱 내에서 깊이 있는 정보 계층을 직관적으로 탐색할 수 있는 환경을 제공한다.
UINavigationController는 기본적으로 루트 뷰 컨트롤러로 지정된 첫 번째 화면을 스택의 맨 아래에 놓는다. 새로운 화면으로 이동할 때는 pushViewController(_:animated:) 메서드를 호출하여 새로운 뷰 컨트롤러를 스택의 맨 위로 추가한다. 반대로, 뒤로 가기 동작이 발생하면 popViewController(animated:) 메서드가 호출되어 현재 최상위의 뷰 컨트롤러를 스택에서 제거하고 그 아래에 있던 화면을 사용자에게 보여준다.
이 컨트롤러는 네비게이션 스택을 관리하는 동시에 사용자 인터페이스의 일부를 자동으로 구성한다. 대표적으로 화면 상단에 표시되는 네비게이션 바를 관리하며, 현재 스택의 최상위 뷰 컨트롤러의 제목을 표시하거나 오른쪽에 바 버튼 아이템을 추가할 수 있게 한다. 또한, 툴바를 함께 관리하는 기능도 제공하여 필요에 따라 화면 하단에 도구 모음을 표시할 수 있다.
UINavigationController는 UITabBarController와 함께 사용되어 앱의 주요 네비게이션 패턴을 형성하는 경우가 많다. 예를 들어, 탭 바에서 하나의 탭을 선택하면 그 내부에서 다시 UINavigationController가 관리하는 여러 화면으로 드릴다운하는 구조를 흔히 볼 수 있다. 이는 정보 구조를 체계적으로 보여주는 데 매우 효과적인 방식이다.
3.5. UITabBarController
3.5. UITabBarController
UITabBarController는 여러 개의 뷰 컨트롤러를 탭 형태로 구성하고 전환할 수 있게 해주는 컨테이너 뷰 컨트롤러이다. 주로 애플리케이션의 주요 기능 영역을 구분하여 각각 독립된 뷰 컨트롤러로 구현하고, 화면 하단의 탭 바를 통해 사용자가 쉽게 이동할 수 있도록 하는 데 사용된다. 예를 들어, 음악 앱에서는 '보관함', '둘러보기', '라디오'와 같은 섹션이 각각 UITabBarController에 의해 관리된다.
이 컨트롤러는 viewControllers 프로퍼티를 통해 관리할 자식 뷰 컨트롤러들의 배열을 설정한다. 각 자식 뷰 컨트롤러는 탭 바 아이템을 가지며, 이 아이템의 제목과 이미지를 설정하여 탭 바에 표시된다. UITabBarController는 사용자가 탭을 선택할 때마다 해당하는 자식 뷰 컨트롤러의 뷰를 화면에 표시하고, 이전에 보이던 뷰는 제거하는 방식으로 화면 전환을 관리한다.
UINavigationController가 계층적인 네비게이션을 제공하는 반면, UITabBarController는 평행한 구조의 여러 화면을 제공할 때 적합하다. 두 컨트롤러는 함께 사용될 수도 있는데, 예를 들어 탭 바의 각 탭이 하나의 UINavigationController를 루트로 가질 수 있다. 이를 통해 해당 탭 내에서 다시 계층적인 화면 이동이 가능해진다.
UITabBarController는 뷰 컨트롤러의 생명주기 이벤트를 자식 컨트롤러들에게 적절히 전달하며, 선택된 탭에 따른 화면 회전 설정이나 상태 표시줄 스타일 관리도 담당한다. 개발자는 UITabBarControllerDelegate 프로토콜을 활용하여 탭 선택 전후의 작업을 처리할 수 있다.
4. 생명주기
4. 생명주기
뷰 컨트롤러의 생명주기는 애플리케이션 실행 중에 뷰 컨트롤러가 생성되고, 화면에 나타났다가 사라지고, 최종적으로 메모리에서 해제되기까지의 일련의 상태 변화 과정을 의미한다. 애플의 iOS 프레임워크인 UIKit은 이 과정의 각 주요 단계에 호출되는 특정 메서드들을 제공하여, 개발자가 각 시점에 맞는 코드를 작성할 수 있도록 한다.
주요 생명주기 메서드로는 뷰 컨트롤러의 뷰 계층 구조가 메모리에 로드된 직후 호출되는 viewDidLoad, 뷰가 화면에 표시되기 직전과 직후에 호출되는 viewWillAppear와 viewDidAppear, 그리고 뷰가 화면에서 사라지기 직전과 직후에 호출되는 viewWillDisappear와 viewDidDisappear가 있다. viewDidLoad는 주로 초기 사용자 인터페이스 설정이나 데이터 초기화에 사용되며, 한 번만 호출되는 특징이 있다. 반면, 나타남과 사라짐 관련 메서드는 뷰 컨트롤러가 화면에 들어오고 나갈 때마다 반복적으로 호출된다.
이러한 생명주기 관리의 핵심 목적은 효율적인 자원 관리와 반응성 있는 사용자 경험을 보장하는 데 있다. 예를 들어, viewWillAppear에서는 화면이 나타나기 전에 최신 데이터를 갱신하는 작업을 수행할 수 있으며, viewDidDisappear에서는 애니메이션을 중지하거나 네트워크 요청을 정리하는 등의 정리 작업을 수행할 수 있다. 생명주기를 올바르게 이해하고 활용하는 것은 메모리 누수를 방지하고 애플리케이션의 성능을 최적화하는 데 필수적이다.
5. 뷰 계층 구조 관리
5. 뷰 계층 구조 관리
뷰 컨트롤러의 핵심 역할 중 하나는 뷰 계층 구조를 관리하는 것이다. iOS 애플리케이션의 사용자 인터페이스는 UIView 객체들이 부모-자식 관계를 이루며 구성된 트리 구조로 표현되며, 뷰 컨트롤러는 이 계층 구조의 루트인 메인 뷰를 관리한다. 뷰 컨트롤러는 view라는 프로퍼티를 통해 이 메인 뷰에 접근하며, viewDidLoad 메서드가 호출된 이후부터는 이 뷰 계층 구조가 메모리에 로드되어 안전하게 조작될 수 있다.
개발자는 주로 viewDidLoad 메서드 내에서 프로그램적으로 서브뷰를 생성하고 메인 뷰에 추가하거나, 인터페이스 빌더를 통해 미리 구성한 뷰 계층 구조를 로드한다. 뷰를 추가할 때는 addSubview(_:) 메서드를 사용하며, 필요에 따라 오토 레이아웃 제약 조건을 설정하여 다양한 화면 크기와 방향에 대응하는 반응형 레이아웃을 구성한다. 뷰 컨트롤러는 뷰의 배치, 표시, 숨김 처리뿐만 아니라 사용자의 터치와 같은 이벤트 처리도 담당한다.
뷰 계층 구조의 관리는 메모리 관리와도 밀접하게 연관되어 있다. 뷰 컨트롤러가 화면에서 사라지거나 메모리 부족 경고를 받으면, 필요 없는 뷰를 정리하여 메모리를 확보한다. 특히 복잡한 뷰 계층 구조를 가진 화면에서는 효율적인 관리가 애플리케이션 성능에 직접적인 영향을 미친다. 따라서 뷰 컨트롤러는 뷰의 생명주기에 맞춰 적절하게 자원을 할당하고 해제하는 역할을 수행한다.
6. 데이터와 뷰의 연결
6. 데이터와 뷰의 연결
뷰 컨트롤러의 핵심 역할 중 하나는 애플리케이션의 데이터와 사용자에게 보이는 뷰를 연결하는 중개자 역할을 수행하는 것이다. 뷰 컨트롤러는 모델-뷰-컨트롤러 패턴에서 컨트롤러에 해당하며, 모델 계층의 데이터를 가져와 뷰 계층에 적절히 표시하도록 지시한다. 또한 사용자가 뷰를 통해 입력한 데이터를 받아 모델을 업데이트하는 작업도 처리한다.
이 연결을 구현하는 일반적인 방식은 아웃렛과 액션을 사용하는 것이다. 아웃렛은 뷰 컨트롤러의 프로퍼티로, 인터페이스 빌더에서 구성한 스토리보드나 XIB 파일의 특정 뷰 객체를 코드에 연결한다. 이를 통해 뷰 컨트롤러는 해당 뷰의 텍스트, 이미지, 색상 등을 프로그래밍 방식으로 제어할 수 있다. 액션은 뷰에서 발생하는 사용자 이벤트, 예를 들어 버튼 터치나 값 변경을 특정 메서드와 연결하여 그 이벤트를 처리하는 코드를 실행하도록 한다.
데이터를 뷰에 표시하는 작업은 주로 viewDidLoad나 viewWillAppear와 같은 생명주기 메서드 내에서 이루어진다. 예를 들어, 네트워크 요청을 통해 받아온 데이터 배열을 테이블 뷰에 표시하려면, 뷰 컨트롤러가 테이블 뷰의 데이터 소스 프로토콜을 구현하여 각 셀에 데이터를 채워넣는다. 컬렉션 뷰나 사용자 정의 뷰를 사용할 때도 유사한 패턴으로 데이터를 바인딩한다.
이러한 연결 구조는 애플리케이션의 로직과 표현 계층을 분리하여 코드의 유지보수성과 재사용성을 높이는 데 기여한다. 뷰 컨트롤러는 데이터의 변화를 관찰하고, 뷰를 업데이트하며, 사용자의 의도를 해석하여 비즈니스 로직을 호출하는 매개체로서 동작한다.
7. 화면 전환과 네비게이션
7. 화면 전환과 네비게이션
뷰 컨트롤러는 단일 화면의 내용을 관리하는 기본 단위이지만, 사용자 경험은 여러 화면 간의 전환과 흐름으로 구성된다. 따라서 뷰 컨트롤러 간의 화면 전환과 네비게이션을 관리하는 것은 애플리케이션 개발의 핵심 과제 중 하나이다. iOS의 UIKit 프레임워크는 이를 위해 다양한 네비게이션 컨트롤러와 전환 방식을 제공한다.
가장 기본적인 화면 전환 방식은 한 뷰 컨트롤러가 다른 뷰 컨트롤러를 모달(Modal) 형태로 표시하는 것이다. 이는 주로 현재 작업에 집중해야 하는 임시적인 화면(예: 설정 창, 알림)을 보여줄 때 사용된다. 또한, 계층적인 정보 구조를 탐색하기 위해 UINavigationController가 널리 사용된다. 이 컨트롤러는 뷰 컨트롤러 스택을 관리하며, 새로운 화면을 스택에 푸시(Push)하여 표시하고, 뒤로 가기 동작 시 최상위 화면을 팝(Pop)하여 제거한다. 이는 설정 메뉴나 메일 앱의 메일 목록에서 세부 내용으로 이동하는 구조에 적합하다.
다른 주요 네비게이션 패턴으로는 UITabBarController를 이용한 탭 기반 인터페이스가 있다. 이는 애플리케이션의 여러 주요 기능 영역(예: 탐색, 검색, 설정)을 독립된 뷰 컨트롤러로 구성하고 하단 탭을 통해 빠르게 전환할 수 있게 한다. 아이폰의 전화 앱이나 음악 앱이 대표적인 예시이다. 또한, iPad와 같은 대형 화면 기기에서는 UISplitViewController를 사용하여 마스터-디테일 뷰를 동시에 표출하는 등 화면 공간을 효율적으로 활용할 수 있다.
이러한 화면 전환은 코드를 통해 프로그래밍 방식으로 수행되거나, 스토리보드에서 세그(Segue)를 정의하여 시각적으로 구성할 수 있다. 모든 전환 과정에서 뷰 컨트롤러의 생명주기 메서드가 순차적으로 호출되므로, 개발자는 viewWillAppear나 viewDidDisappear와 같은 메서드를 오버라이드하여 데이터를 새로 고치거나 리소스를 정리하는 로직을 적절히 배치해야 한다. 올바른 네비게이션 설계는 사용자에게 직관적이고 일관된 경험을 제공하는 데 필수적이다.
8. 메모리 관리
8. 메모리 관리
뷰 컨트롤러는 애플리케이션의 메모리 사용을 효율적으로 관리하는 중요한 책임을 가진다. iOS는 제한된 메모리 자원을 가진 모바일 환경에서 동작하기 때문에, 불필요한 메모리 점유는 애플리케이션의 성능 저하나 강제 종료로 이어질 수 있다. 따라서 뷰 컨트롤러는 자신의 생명주기와 시스템의 메모리 경고에 맞춰 적절히 자원을 할당하고 해제해야 한다.
시스템이 메모리 부족 상태에 빠지면, 운영체제는 모든 애플리케이션의 뷰 컨트롤러에게 didReceiveMemoryWarning 메서드를 호출하여 경고를 보낸다. 이 메서드 내부에서는 뷰 컨트롤러가 현재 화면에 표시되지 않는 대용량 데이터, 캐시된 이미지 객체, 또는 재생성 가능한 임시 객체들을 해제하는 코드를 작성해야 한다. 이는 주 뷰 자체를 해제하는 것이 아니라, 뷰 컨트롤러가 관리하는 보조 데이터를 정리하는 작업이다.
뷰 컨트롤러의 뷰 계층 구조는 필요에 따라 시스템에 의해 로드되고 해제될 수 있다. 뷰 컨트롤러가 화면에서 사라지고 다른 뷰 컨트롤러로 전환될 때, 시스템은 메모리 상황에 따라 이전 뷰 컨트롤러의 뷰를 메모리에서 언로드할 수 있다. 이때 viewDidUnload 메서드가 호출되었으나, 최신 iOS 버전에서는 이 메서드가 deprecated 되었다. 대신 메모리 경고는 didReceiveMemoryWarning에서 처리하며, 뷰 자체의 해제는 시스템이 자동으로 관리한다.
효율적인 메모리 관리를 위해 개발자는 강한 순환 참조를 주의해야 한다. 뷰 컨트롤러가 델리게이트나 클로저를 통해 자신을 강하게 참조하는 객체를 만들 경우, 뷰 컨트롤러가 화면에서 사라져도 메모리에서 해제되지 않는 메모리 누수가 발생할 수 있다. 이를 방지하기 위해 델리게이트 프로퍼티는 weak로 선언하고, 클로저 내부에서 self를 캡처할 때는 [weak self]를 사용하는 등의 주의가 필요하다.
9. 여담
9. 여담
뷰 컨트롤러는 iOS 애플리케이션 개발의 핵심 구성 요소로서, MVC 패턴에서 컨트롤러 역할을 담당한다. 이 패턴은 애플리케이션의 데이터(모델), 사용자에게 보이는 화면(뷰), 그리고 양자를 중재하는 로직(컨트롤러)을 분리하여 코드의 유지보수성과 재사용성을 높이는 데 기여한다. 뷰 컨트롤러는 이러한 구조 하에서 뷰의 생명주기를 관리하고 사용자의 입력에 반응하며, 모델의 데이터를 뷰에 적절히 표시하도록 조정하는 중추적인 임무를 수행한다.
초기 iOS SDK에서는 화면당 하나의 뷰 컨트롤러가 전체 화면을 관리하는 것이 일반적이었다. 그러나 아이패드의 등장으로 더 넓은 화면을 효율적으로 활용해야 할 필요성이 생기면서, 컨테이너 뷰 컨트롤러의 중요성이 부각되었다. UISplitViewController와 같은 컨테이너 뷰 컨트롤러는 여러 자식 뷰 컨트롤러의 내용을 동시에 조율하여 하나의 복합적인 사용자 인터페이스를 구성할 수 있게 해주었다. 이 개념은 이후 iOS 버전에서 더욱 발전하여, 모듈화되고 재사용 가능한 UI 컴포넌트를 설계하는 데 필수적인 요소가 되었다.
SwiftUI의 등장은 뷰 컨트롤러의 전통적인 역할에 변화를 가져왔다. SwiftUI의 선언형 문법과 상태 기반 데이터 흐름은 뷰 컨트롤러가 수동으로 관리하던 많은 업무를 프레임워크 자체가 대신하게 한다. SwiftUI에서는 View 프로토콜을 준수하는 구조체가 UI를 정의하고, @State나 @ObservedObject 같은 프로퍼티 래퍼를 통해 데이터를 관리하며, 뷰 계층 구조도 자동으로 구성된다. 이로 인해 명시적인 뷰 컨트롤러 클래스의 필요성이 크게 줄어들었지만, 기존 UIKit 기반 프로젝트의 유지보수나 특정 복잡한 상호작용을 처리할 때는 여전히 뷰 컨트롤러가 중요한 도구로 남아 있다.
따라서 현대적인 애플 플랫폼 개발은 뷰 컨트롤러의 세밀한 생명주기 관리와 강력한 제어 능력을 활용하는 UIKit 방식과, 빠른 프로토타이핑과 직관적인 코드 작성을 가능하게 하는 SwiftUI 방식을 상황에 맞게 선택하거나 혼용하는 형태로 발전하고 있다. 두 패러다임을 이해하는 것은 포괄적인 iOS 및 iPadOS 앱 개발 능력을 갖추는 데 필수적이다.
