SwiftUI in UIKit vs UIKit in SwiftUI

• SwiftUI : declare the user insterface and behavior for your app on every platform
• UIKit : construct and manage a graphical, event-driven user interface for your iOS or tvOS app

SwiftUI 프레임워크를 적용할 때 2가지 옵션이 있다.

• SwiftUI 프로젝트에 UIKit 통합하기 (UIKit 과의 data dependency 가 있는)
• UIKit 프로젝트에 SwiftUI 통합하기

UIKit 프로젝트에 SwiftUI를 통합하는 방법

1. SwiftUI 로 작성된 ContentView를 준비한다.
2. storyboard에 Hosting Controller 를 만들고 segue를 만든다.
3. segue를 view controller 에연동하고 hosting controller 의 rootView 를 SwiftUI view 의 instance (ContentView) 로 설정한다.

SwiftUI 프로젝트에 UIKit 을 통합하는 방법

1. ViewController.swift 와 StoryBoard를 SwiftUI 프로젝트에 추가한다.
2. storyboard identity inspector 에 storyboard ID 를 설정한다.
3. ViewController 의 표현을 위한 구조체를 만든다.
4. ContentView 에서 NavigationLink를 달아준다.
5. ViewController 는 UIViewControllerRepresentable 을 준수해야 되서 make, update 메서드를 구현해주고 Coordinator 구현을 통해 datasource 및 delegate를 연결한다.

---

현재 상황

• SDK 는 UIKit 으로 전부 되어있다.
• 사용 라이브러리도 UIKit 이다.
• 그런데 SwiftUI를 도입하고 싶다.
• SwiftUI 로 위젯, Watch app, mac app 등의 cross platform 을 지원하고 싶다.
• Combine + declaritive UI 의 장점을 사용해보고 싶다.
• iOS14 가 나온 상황에서 몇년 후엔 iOS13 을 min target 으로 잡을 수 있다.
• SwiftUI 로 짠 프로토타입 코드가 있다.

SwiftUI 의 장점

• SwiftUI framework 가 reactive 하게 view 를 관리해줘서 RxSwift와 같은 추가적인 opensource 없이 MVVM 아키텍쳐 도입이 쉽다.
• 네트워킹 쪽도 combine을 사용하여 SwiftUI 와 시너지를 낼 수 있다.
• 크로스 플랫폼 지원이 간단하다.
• 테마를 관리하기 편해진다.(dark, light)
• live preview를 통해 build 없이 UI 결과를 볼 수 있다.
• 같은 UI 와 기능을 작성하는데 필요한 LOC 가 작다.

SwiftUI 가 UIKit 에 비해 빠른이유

• layer 계층을 flatten 하기 때문에 drawing 을 덜하고 많은 operation이 Core animation을 거치지 않고 바로 Metal 로 이어지기 때문
• UIKit의 view 들은 UIView를 상속받는다. 그래서 사용하지 않는 많은 기능들 (배경색, layer) 등이 있다. SwiftUI는 구조체이고 view protocol 만 준수하면 되기 때문에 쓸때없는 값이 parent class 에서 상속되지 않는다.

SwfitUI 단점

• iOS 13이상부터 지원한다.
• 아직 참고할만한 많은 레퍼런스가 없다.
• preview 에서 view 계층을 볼 수 없다.
• API coverage 가 제한적이다.
• 내가 익숙하지가 않다.

*여전히 SwiftUI의 많은 부분은 UIKit 위에서 빌드된다. (UITableView) 근데 Apple 이 알아서 SwiftUI 로 수정한다.

---

UIKit 프로젝트에 SwiftUI 통합하기

+ 필요한 부분만 SwiftUI 로 만들어 Hosting View Controller 로 통합하면 된다.

+ 하다가 SwiftUI 로 안되겠으면 UIKit으로 구현하면 된다. (risk 감소)

+ @available API로 iOS13 이상에서만 SwiftUI 를 적용해서 target OS 를 낮출 수 있다.

- 하나의 뷰에 UIKit을 사용하는 컴포넌트가 하나 이상 존재할 확률이 크다.
==> 그렇게 되면 UIKit 에서 SwiftUI view 를 만들고 그 view 내에 UIKit 를 쓰는 control이나 library를 작성해야 한다. (3뎁스)

- 추후 리팩토링이 필요할 때 SwiftUI로 수정해야할 코드량이 많아진다.

SwiftUI 프로젝트에 UIKit 통합하기 (UIKit 과의 data dependency 가 있는)

+ 기본으로 SwiftUI 를 작성하다 필요한 부분에만 UIKit을 사용하면 된다.

+ 추후 리팩토링이 필요할 때 UIKit을 사용한 부분만 수정하면 되서 빠른 리팩토링이 가능하다.

+ @available API로 iOS13 이상에서만 SwiftUI 를 적용해서 target OS 를 낮출 수 있다.

- SwiftUI 로 구현하지 못하겠으면 UIKit으로 바꿔서 구현하는데 그럼 애초에 SwiftUI 프로젝트로 만든 의미가 없어진다.

- UIKit을 사용하는 라이브러리가 많아서 swiftUI 프로젝트인데 UIKit integration 만 계속 할 수도 있다.

정리

• target 을 13이하도 지원하고 싶다. --> 둘다 using @available API)
• 개발일정에 맞춰 Risk 를 줄이고 싶다. --> UIkit host SwiftUI
• UIKit을 사용하는 컴포넌트가 많다. --> SwiftUI host UIkit (3depth가 생김)
• UIKit을 사용하는 컴포넌트가 많다. --> UIKit hose SwiftUI (UIKit 전부 Integration 해야되면 애초에 UIKit으로 만들지)
• 미래에 빠르게 독립 SwiftUI 프로젝트로 개발하고싶다. --> SwiftUI host UIKit

어쨋든 SwiftUI 와 UIKit을 통합해서 앱을 만들어야 한다면 
UIKit으로 프로젝트를 만들었을 때 부분부분의 SwiftUI view 에서 또 UIKit integration 을 해야하는 공수가 크다.
그래서 SwiftUI 프로젝트 내부에 UIKit을 사용하는게 좋을 것으로 판단된다.