[ Swift ] UIKit VS SwiftUI

iOS에서 화면(UI)을 만드는 방식은 크게 3가지로 정리된다.

1. UIKit + Storyboard/XIB(시각적으로 드래그해서 구성)

2. UIKit + Code(Programmatic UI)(UIKit을 코드로 구성)

3. SwiftUI(선언형 UI)

각 방식은 “정답”이 있는 게 아니라 팀 규모, 유지보수, 레거시, 지원 OS, UI 복잡도에 따라 선택 기준이 달라진다.

1) UIKit + Storyboard / XIB

개념

Xcode의 인터페이스 빌더에서 화면을 드래그 앤 드롭으로 구성하고, Auto Layout 제약을 잡은 뒤 IBOutlet/IBAction으로 코드와 연결하는 방식이다.

장점

• 프로토타이핑이 빠르다. 화면 구조를 시각적으로 바로 만들 수 있다.

• 진입 장벽이 낮다. UI를 “눈으로 보면서” 조정하기 쉬운 편이다.

• 레거시 프로젝트와 궁합이 좋다. 기존 앱에서 많이 쓰인다.

단점(실무에서 자주 부딪힘)

• Git 충돌이 잦다. storyboard/xib는 파일 구조상 머지가 까다롭다.

• 런타임 에러가 생기기 쉽다. outlet 연결 누락/타입 불일치가 실행 중 크래시로 이어질 수 있다.

• 규모가 커질수록 유지보수가 불편해진다. 화면이 많아질수록 파일이 무거워지고 복잡해진다.

• 재사용/컴포넌트화가 답답해질 수 있다.

추천 상황

• 작은 프로젝트, 단순한 화면이 많을 때

• 빠르게 데모/PoC를 만들어야 할 때

• 기존 코드베이스가 storyboard 중심이라 유지보수가 목적일 때

2) UIKit + Code (Programmatic UI)

개념

UIKit을 그대로 사용하되, UIView 생성부터 addSubview, Auto Layout 제약 설정까지 전부 코드로 작성하는 방식이다. (필요하면 SnapKit 같은 DSL을 쓰기도 한다.)

장점

• 버전관리/리뷰/머지에 강하다. 화면 변경이 코드 diff로 명확하게 보인다.

• 재사용/컴포넌트화에 유리하다. 공통 UI(버튼/카드/셀 등)를 모듈로 만들기 쉽다.

• 동적 UI에 강하다. 조건에 따라 뷰를 만들고 제거하는 로직이 자연스럽다.

• 타입 안정성이 상대적으로 좋다. 연결 실수(outlet)로 인한 런타임 문제가 줄어드는 편이다.

단점

• 초반 학습 비용이 있다. Auto Layout을 코드로 다루는 데 익숙해져야 한다.

• 처음엔 생산성이 떨어질 수 있다. 특히 레이아웃을 처음부터 코드로 짜는 게 부담일 수 있다.

• 팀 컨벤션이 없으면 코드 스타일이 난잡해질 수 있다.

추천 상황

• 협업 인원이 많고 코드리뷰/머지가 중요한 팀

• 공통 컴포넌트 재사용이 많은 서비스

• 화면이 상태/조건에 따라 많이 바뀌는 앱

• 장기 유지보수와 확장성이 중요한 프로젝트

3) SwiftUI

개념

SwiftUI는 “어떻게 그릴지(절차)”를 나열하기보다, “현재 상태라면 이렇게 보여야 한다”를 선언하는 방식이다. 상태가 바뀌면 화면이 자동으로 갱신되는 구조다.

장점

• 코드가 짧고 UI 구조가 읽기 쉬운 편이다.

• 상태 기반 UI가 자연스럽다. 로딩/에러/빈화면/성공 같은 상태 분기가 깔끔하다.

• 멀티플랫폼 확장에 유리하다. iOS 중심으로 시작해도 다른 Apple 플랫폼까지 확장할 때 이점이 있다.

• 점진 도입이 가능하다. 기존 UIKit 앱에서도 “새 화면만 SwiftUI”처럼 섞어 쓸 수 있다.

단점(현업 포인트)

• 세밀한 커스텀/특수 UI는 UIKit이 더 편한 경우가 있다.

• 디버깅/성능 튜닝 방식이 다르다. UIKit 경험만으로는 초반에 낯설 수 있다.

• 지원 OS 범위에 따라 제약이 생긴다. 최신 API를 쓰고 싶어도 최소 버전 때문에 못 쓰는 경우가 있다.

추천 상황

• 신규 앱/신규 화면을 빠르게 만들고 싶을 때

• 상태 변화가 많은 화면(리스트/설정/폼 등)이 많을 때

• 장기적으로 SwiftUI 중심으로 가져가려는 팀

• 기존 앱이라도 “새 기능부터” 점진적으로 전환하고 싶을 때

4) 요즘 추세

최근 흐름은 신규 개발에서 SwiftUI 비중이 계속 커지는 방향이다. 다만 대형 서비스에는 UIKit 레거시가 크고, 복잡한 커스텀 UI/세밀한 제어는 여전히 UIKit이 강해 혼용(점진 도입)이 현실적인 선택이 되는 경우가 많다. 즉 “SwiftUI가 대세”이긴 하지만 “UIKit이 끝났다”가 아니라, 상황에 맞게 섞어서 쓰는 시대에 가깝다.

🌟 요약

• 레거시 유지보수 / 정교한 커스텀 UI / 복잡한 제어 → UIKit(코드 기반이 보통 유리하다)

• 협업/머지/컴포넌트 재사용/확장성 → UIKit(Code) 강점이 크다

• 신규 개발 / 상태 기반 UI / 빠른 개발 / 멀티플랫폼 고려 → SwiftUI가 유리하다

• 현실적인 베스트 프랙티스 → 기존 UIKit + 새 화면 SwiftUI 같은 점진 전환이 많다