Fabula 앱 소개에 앞서 SwiftUI의 장단점에 대해서 간략하게 정리해보고 우리는 이 시점에서 SwiftUI를 도입하는 것이 좋을지 함께 고민해 보겠습니다.
Swift는 2014년 6월 2일 애플 세계 개발자 회의(WWDC)에서 처음 소개되었습니다. 그로부터 8년이 지난 지금, Apple은 또다시 개발 방법론에 변화를 예고하고 있습니다. 우리가 UIkit을 사용한 지 벌써 14년이 흘렀습니다. 그 긴 시간 동안 개발자들은 수많은 아키텍처와 개발 방법론을 제시했습니다. 물론 그 고민의 근간은 UIKit/AppKit을 통한 이벤트 중심의 명령형 프로그래밍, 그리고 효율화였습니다.
WWDC19에서는 Apple는 모든 플랫폼에서 하나의 코드로 앱을 만들 수 있는 완전히 새로운 SwiftUI 프레임워크를 발표했습니다. 기존 개발 방법론에서 큰 변화가 불가피하지만 Objective-C에서 Swift로 전환할 때와 같이 애플 개발자라면 언젠가 이 변화를 받아들여야 할 것입니다.
- WWDC19에서 Apple 생태계의 모든 플랫폼에서 앱을 만들 수 있는 완전히 새로운 UI프레임워크 SwiftUI를 발표
- UIKit의 명령형 방식과 달리 SwiftUI는 선언적 방식으로 UI를 설계
- Apple은 지속적으로 SwiftUI에 개선 사항을 반영중
SwiftUI의 장점
1. 선언적 구문
1
2
3
4
5
Text(Date(), style: .date)
.font(.title)
.bold()
.foregroundColor(.orange)
.italic()
- SwiftUI는 이벤트 중심의 프로그래밍(명령형 방식)이 아닌 선언적 구문을 사용하여 개별 기능을 명시하는 방법으로 처리함
- 예를 들어, Text로 구성된 화면에서 각 Text의 서체 및 색상등의 정보를 명시
- 이벤트 중심의 명령형 방식보다 코드가 간결하고 가독성이 향상되어 시간이 절약되고 유지 관리가 용이
2. 대폭 개선된 설계 / 개발 워크플로우
- 기존 방식은 시뮬레이터/디바이스를 통해 앱을 빌드해야 확인 가능한 개발 방식
- SwiftUI는 코드와 함께 실시간 미리보기를 제공하여 이 문제를 크게 개선
- 실시간으로 변경 사항을 확인 가능하여 개발 시간을 획기적으로 단축
3. 우수한 레이아웃 시스템
SwiftUI 레이아웃 프로세스의 3 단계
- 부모가 자식의 크기를 제안합니다.
- 부모의 제안을 받아 자식은 스스로 크기를 선택합니다.
- 자식이 선택한 크기를 기반으로 부모는 좌표 공간에 자식을 배치합니다.
- SwiftUI는 레이아웃 시스템이 개념적으로 단순하고 명확 함
- UIKit 처럼 앵커 및 제약 시스템에 의존하지 않고 전통적인 Grid System을 기반으로 함
- SwiftUI의 모든 Layout UI는 코드에서 직접 정의
- 코드는 더 간결하고 이해하기 쉬우며 오류 발생률이 낮아 유지 관리가 용이
4. 기본적으로 상태(State) 기반 UI 적용
- SwiftUI의 또 다른 핵심 기능으로 상태(State) 관리 메커니즘
- 모든 뷰는 여러 내장 메커니즘을 통해 상태 객체에 바인딩
- 주어진 상태 객체의 속성이 변경되면 변경을 반영해야하는 모든 뷰를 즉시 렌더링
- UIKit/AppKit의 명령형 접근 방식(이벤트 중심의 프로그래밍)보다 코드가 줄고 가독성이 좋음
- 기본적으로 뷰를 상태에 바인딩함으로써 상태를 전달하는 코드가 필요하지 않아 버그가 감소
- 단, 명령형 방식과 다른 개발 사고 방식이 필요
5. 양방향 브리징
- Objective-C -> Swift 전환과 마찬가지로 기존 프로젝트를 SwiftUI로 완전히 대체하기는 어려움
- SwiftUI 뷰에서 UIKit 코드를 사용할 수 있으며 그 반대의 경우도 사용할 수 있도록 브리징 래퍼 지원
- 브리징 래퍼를 이용하면 UIkit/AppKit을 유지하면서 SwiftUI를 학습할 수 있음
- Swift와 SwiftUI는 상호 배타적이지 않음
SwiftUI의 단점
1. 다소 가파른 학습 곡선
- 처음 SwiftUI로 개발할 때는 각 단계별로 학습이 필요하므로 개발 과정에서 추가 공수가 발생할 수 있음
- Objective-C -> Swift 전환과 마찬가지로 프로젝트 개발 기간이 다소 늘어날 수 있음
- 그러나 학습 후에는 SwiftUI를 통해 대부분의 작업을 더 빠르게 수행 할 수 있음
2. 아직 지원하지 않는 라이브러리/컴포넌트
- 광범위한 프레임워크를 한 번에 교체하는 것은 불가능
- Apple은 가장 일반적인 사용 사례를 먼저 시스템 컴포넌트로 지원
- UIKit/Appkit을 래핑해야할 경우 다소 공수가 들어갈 수 있음
- 이전에 작동했던 라이브러리/컴포넌트를 브리징 래퍼로 연결하는 작업 공수가 발생
- 경우에 따라서 UIKit에서 제공하는 특정 기능을 지원하지 않을 수 있음
3. SwiftUI는 여전히 진화중
- Apple이 SwiftUI를 발표한지 불과 만 2년이 지남
- 과거 Swift의 변화처럼 프레임워크의 상대적 미성숙을 감안해야 함
- 개선 과정에서 기능적으로 변경되거나 제거 될 수 있음
- 이러한 문제는 시간이 지날수록 줄겠지만 현 시점에서는 변경에 따른 리스크를 감수해야 함
4. 최소 버전은 iOS 13 / macOS 10.15
- SwiftUI를 채택하기에 가장 고민이 되는 것 중에 하나는 iOS 13 / macOS 10.15 이상에서만 사용할 수 있다는 것
- 앱에 따라서 iOS 12 이하 버전을 지원하고 일부는 더 과거 버전을 최소 버전으로 유지하고 있음
- iOS는 Android에 비해 OS 업데이트 속도가 빠르지만 이 문제는 일부 앱에서 여전히 타협점이 될 수 있음
그럼 우리는 SwiftUI를 프로젝트에 도입해도 될까?
- iOS12 이하 버전 사용자가 많을 경우에는 제약이 따름
- 커스텀 UI를 구현하기 어렵거나 불가능할 수 있음, 프레임워크가 더 성숙할 때까지 커스텀 디자인을 지양할 필요
- 새로운 앱을 개발 예정이라면 앞으로 Apple의 비전은 매우 명확하므로 SwiftUI를 도입하는 것이 바람직 함
- 새로운 프로젝트에 UIKit/AppKit만을 사용한다면 누군가가 지불해야하는 기술 부채가 됨
- Apple 생태계의 모든 플랫폼에서 동일한 코드로 개발 가능
- SwiftUI 프레임워크를 마스터하면 높은 품질의 안정적인 UI를 설계할 수 있고 다양한 화면 사이즈를 빠르고 쉽게 대응할 수 있음
마무리
현 시점에서 최선의 방법은 기존 프로젝트는 화면 단위로 SwiftUI를 채택하고, 신규 프로젝트는 전체를 SwiftUI로 진행하는 것입니다. 현재 iOS 14 이상 점유율이 90%를 넘기 때문에 신규 프로젝트는 SwiftUI로 진행해도 큰 무리는 없을 것 같습니다.