iOS 스터디를 위해 만든 강의 자료

UIKit 이란?(User Interface Kit)

• ‘명령형’ 프레임워크
• 명령형 프레임워크에서는 View를 직접 생성하고 제어
• UI를 더 섬세하게 조절할 수 있고 SwiftUI보다 더 많은 기능과 UI를 제공
• 커스터마이징이 많이 필요한 UI를 기획하고 있다면 UIKit이 좋음

그러면 SwiftUI와 차이점은?

• ‘선언형’ 프레임워크
• UI에 표시될 데이터만 정의하면, 데이터를 ‘어떻게’ 표시할지는 프레임워크가 결정
• 개발 과정이 단순, 복잡한 UI도 적은 양의 코드로 만들 수 있다는 장점을 가짐
• 간단한 앱을 빠르게 개발하고 싶다면 SwiftUI가 좋음

→ 필요에 따라 UIKit와 SwiftUI를 한 앱에서 같이 사용할 수 있음.

UIKit 앱의 일부를 SwiftUI로 구현하거나 두 프레임워크 간에 인터페이스를 혼합.

예를 들어, SwiftUI를 UIKit의 UIViewController에서 사용할 수 있고, UIView를 SwiftUI의 View 안에서 사용할 수 있음.

---

여러 iOS 개발 방법 차이

UIKit (Storyboard)

• 장점
  • 뷰를 위한 코드를 적게 작성 가능
  • 뷰를 직관적으로 이해하기 쉬움
  • 뷰작업 속도가 빠름
• 단점
  • 작업내용을 보기가 어려움 → 컨플릭트 났을때, xml 보고 수정하는게 빡셈
  • 재사용성이 낮음
  • 뷰의 동적 변화에 있어서 제약

UIKit (Code)

• 장점
  • 작업 내용을 보기가 쉬움
  • 재사용성 높음
  • 동적 변화에 제약이 덜함
• 단점
  • 뷰를 위한 코드가 많이 들어감
  • 뷰를 직관적으로 바로 이해하기 어려움
  • 뷰작업 속도가 느림 (재사용성 높아짐에 따라, 속도는 향상 가능)

SwiftUI

• 장점
  • 작업 내용을 보기가 쉬움
  • 재사용성 높음
  • 뷰를 위한 코드를 적게 작성 가능
  • 뷰를 직관적으로 이해하기 쉬움
  • 뷰작업 속도가 빠름
• 단점
  • 현재 대부분 프로젝트는 UIKit 기반이 많음
  • iOS 버젼 별로, 되는 UI가 있어서, 분기를 태워서 버젼별로 관리해주어야함

---

UIKit의 구조

• MVC 디자인 패턴(Model-View-Controller)을 중심으로 구성

View 계층 구조

• 화면에 보이는 모든 요소는 UIView의 서브클래스
• 뷰는 트리 구조로 구성 (root view → subview).

UIViewController
 └── UIView (root view)
      ├── UILabel
      ├── UIButton
      └── UIImageView

UIViewController

• 하나의 화면을 담당하는 클래스
• 뷰 컨트롤러는 뷰 계층을 로드하고, 이벤트를 처리하고, 화면 전환을 관리
• View와 관련된 모든 로직을 처리해주는 역할

→ 여기서 MVC 패턴에 한계점이 들어남

• ViewController가 Model, View, 네트워크, 비즈니스 로직까지 다 떠맡게 됨
• 즉, “모든 책임이 ViewController에 집중”되는 현상이 발생
• 코드의 양이 많아지고 유지보수가 어려움
• View와 Controller가 긴밀하게 연결돼 있어 재사용이 어려움

앱 진입구조

UIApplicationMain
 └── AppDelegate.swift
      └── SceneDelegate.swift
           └── UIWindow
                └── RootViewController

• AppDelegate: 앱 실행/종료, 푸시알림, 백그라운드 진입 등 앱 전반 이벤트 처리
• SceneDelegate: 하나의 윈도우/화면 단위를 관리 (iOS 13 이후 다중 창 도입)

---

AutoLayout

• 다양한 화면 크기나 방향에서도 UI를 일관되게 표시하기 위한 레이아웃 시스템

필요한 이유?

• iPhone, iPad 등 화면 크기가 다양한 기기 지원
• 가로/세로 회전 대응
• 다국어 지원 (문장 길이가 달라짐)
• 사용자 설정 (예: Dynamic Type) 대응

예시

Auto Layout은 뷰 간의 관계(Constraint, 제약조건) 을 기반으로 레이아웃을 계산

• “이 버튼은 상단에서 20pt 떨어져 있어야 한다”
• “이 뷰의 너비는 화면의 절반이다”
• “두 뷰는 항상 수평 정렬된다”

주의사항

• 제약조건이 충돌(conflict) 나면 경고 발생
• 제약조건이 불충분(insufficient) 하면 위치와 크기를 결정할 수 없음
• 항상 필요 최소한의 제약조건을 설정