SwiftUI) SwiftUI란?

기존에 Swift를 사용하여 UI를 구축할 때는 플랫폼마다 다른 프레임워크를 사용해야 했다.
대표적인 예로 iOS, tvOS UI는 UIKit을, macOS는 AppKit을, watchOS는 WatchKit을 사용했다.
따라서 다양한 애플 플랫폼에서 개발을 하고 싶다면 수많은 프레임워크를 공부해야했다.
하지만 WWDC 19에서 처음 공개된 프레임워크인 SwiftUI는 모든 애플 플랫폼에서 사용자 인터페이스를 만들 수 있게 해주는 새로운 개발 패러다임이다.

SwiftUI vs. Storyboard

기존의 iOS 혹은 애플 플랫폼 개발자들은 대부분 스토리보드 개발 방식을 숙지하고 있을 것이다. 하지만, 스토리보드는 시간이 지남에 따라 급격하게 커지고, 협업 및 유지 보수 하기에도 매우 까다롭다.

스토리보드의 이러한 커다란 단점을 SwiftUI는 대부분 해결해준다. SwiftUI에서는 코드를 작성하는 동시에 디자인 인터페이스가 생성되고 디자인 요소들이 코드로 생성되기 때문에, 더 이상 읽기 어려운 스토리보드의 XML 방식을 사용하지 않아도 된다.

SwiftUI의 장점

1. 선언적 구문

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를 발표한지 불과 만 3년이 지남
• 과거 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를 설계할 수 있고 다양한 화면 사이즈를 빠르고 쉽게 대응할 수 있음