[SwiftUI] View scene window이란? UIKit에서도 본 거 같은데?

자바로 코테를 준비하다가 Swift로 전향한지 이제 한달...?  처음으로 Swift로 도전하는 네이버 파이낸셜  연계형 인턴 코테보고 왔습니다. 완전 말렸어요 ㅠㅠ. 알고리즘 공부는 잠시 쉬고 다시 SwiftUI 달립니다.

 

UIKit과 SwiftUI를 완전 다른 기술이라고 취급하고 싶지 않고 

그동안 UIKit과 함께하면서 생긴 자잘한 노하우들을 활용할 생각이기에 두 개념의 매핑되는 것과 차이점 장단점들을 비교해가면서 포스팅할 생각입니다. 또한 이 방법이 UIKit에 대한 이해도를 스스로 테스트 해볼 수 있을 것이라 생각합니다.

 

사이드 프로젝트 Bidit 개발중 시뮬레이터를 돌려보다가 실수로 기기를 macOS로 설정하고 돌린 적이 있습니다. 
안 되겠지? 하고 기다려봤는데 모바일 형태가 아닌 작은 창 형태로 그대로 앱이 켜지더군요. 
엥? 그냥 macOS 앱이 이렇게 만들어지는건가? 그때 당시엔 이렇게 생각만 하고 지나쳤습니다.

원래 기존의 mac 앱은 AppKit으로 UI를 빌드했다고 합니다. 그런 앱들은 모바일에서 열리지 않습니다. 

맥북이 먼저일까요? 아이폰이 먼저일까요? 

맥북이 먼저 나왔다고 해요. 원래 아이폰 유저들은 알고 계셨겠지만 애플로 넘어온지 얼마 안 된 전 몰랐네요 ㅎㅎ.

갓 나온 아이폰 UI를 개발 할 수 있도록 해주는 프레임워크가 필요했을것 입니다. 따라서 자연스럽게 AppKit의 내용중 필요한 내용만 추려서 나온 것이 UIKit이라고 합니다.

근데 왜 AppKit을 그냥 쓰면 안 되나 생각이 들 수 있겠죠?
이건 조금 iOS개발과 상관은 없는 이야기가 될 것 같지만 해보자면

초기 아이폰은 arm칩이 채택되었다고 해요. 맥에 들어가는 칩에 비해 느렸기 때문에 macOS의 기능을 그대로 가져갈 수 없었던 거죠. 그 결과로 나온 게 UIKit입니다.

 

 

 

애플 실리콘 칩들이 나오면서 새롭게 생긴 기능들 중 하나가 macOs, 아이폰, 아이패드 구분 없이 앱을 작동할 수 있도록 앱스토어의 기능이 추가되었다는 것입니다. 그래서 처음에 언급한 macOs 시뮬레이터의 동작이 성공한 것이죠.

 

참고로 아이패드와 macOS로 내게 되면 앱스토어 심사 제출할 때 미리보기 이미지들도 기기별로 맞추어 따로 준비해주어야 합니다. 생각했던 것보다 쉽진않습니다. ㅋㅋㅋㅋ

 

하지만 지금처럼 다른 OS간 호환이 되지 않던 시절엔 아예 따로 만들어야했을까요?

Mac Catalyst는 UIKit으로 준비된 앱을 Mac 앱으로 확장이 가능하도록 도와주는 용도로 쓰이던 것입니다.

 

또 종종 로제타라는 단어를 볼 수 있는데 이는 사용자가 x86_64 아키텍쳐에서 돌아가는 앱들을 애플 실리콘 칩에서 돌아갈 수 있도록 해주는 것입니다.

 

 

Xcode 14 이전에, 하나의 앱에서 iOS와 macOS를 지원하기를 원한다면, 각각의 target이 필요했습니다.

이제는 하나로 통합이 가능하다는 걸 말하기위한 빌드업 같죠?
그렇지만 다른 코드베이스가 필요하거나, 다른 플랫폼 간에 설정을 거의 공유하지 않거나, 각 앱 target이 서로 다른 기본 기술에 의존하는 경우엔 각각의 target을 두는 것이 좋다고 합니다.

 

다중 플랫폼 앱 템플릿은 라이프사이클 및 인터페이스에 SwiftUi를 사용하며, 이를 통해 iPhone, iPad 및 Mac을 지원하도록 기본적으로 구성된 대상부터 시작합니다.

 

---

서론이 길었습니다. 

 

View

SwiftUI는 처음 경험하시게 되면 눈에 띄는 몇가지가 있습니다.

UIKit을 해보셨다면 View가 눈에 띄실 거 같습니다.

원래 봤던 거 아닌가?... UIView가 아닙니다 ㅎㅎ.

• UIView는 UIKit에서 제공되는 서브클래싱과 커스텀이 가능한 클래스입니다. 반면에 View는 SwiftUI로 커스텀 뷰를 만들 때 상속받아야 하는 프로토콜입니다. 
• UIView는 명령형(imperative) 프로그래밍 모델을 기반으로 하는 UIKit 프레임워크의 View의 일부 입니다. View는 선언형(declarative) 프로그래밍 모델을 기반으로한 프레임워크인 SwiftUI의 View의 일부입니다.
• UIView는 오토레이아웃을 정의하여 레이아웃과 하위 뷰의 위치를 정의합니다. 반면 View는 스택과 Alignment Guide를 기반으로한 레이아웃 시스템을 사용하여 정의합니다.

 

 

 

SwiftUI프로젝트를 열면 View의 모습을

프리뷰 Provider를 통해 바로 확인하실 수 있습니다.

 

이것도 UIViewController없이 독립적으로 볼 수 없는 UIVIew와 체감할 수 있는 차이죠. 

1. View는 Scene 컨텐츠를 생성합니다.

View는 프로토콜이므로 몇가지 지켜야할 것이 있습니다. 

2.  body 프로퍼티가 필요합니다. 

body는 View 프로토콜을 준수하는 인스턴스를 반환해야한다고 되어있습니다.

처음 SwiftUI파일을 만들면 기본 형태로 구현되어 있는 것을 보셨을 겁니다.

아래 정의에 해당 뷰의 동작과 컨텐츠를 나타낸다고 되어있죠. 뷰의 구성을 이곳에 작성해주는 것입니다. 

 

Scene

그리고 현재 SwiftUI에서는 기괴하게 생긴 SceneDelegate와 AppDelegate가 보이지 않습니다.

위 두가지를 대체하는 App프로토콜을 보실 수가 있습니다. 

App을 알아보기 전에 먼저 그 아래에 Scene 타입 인스턴스를 반환하는 body프로퍼티가 있는 것이 보입니다.

그 안에는 위에 있던 View타입인 ContentView가 보입니다.

View 의 그룹단위를 Scene이 관리하고 그 Scene을 App이 관리한다는 거겠죠?

1. Scene은 시스템이 수명주기를 관리하는 앱의 사용자 인터페이스의 일부라고 되어있습니다. 

View는 보여지는 화면 안에서의 하나의 단위였습니다. Scene은 그러한 View들을 수명주기에 따라 관리해주는 단위인 것입니다. 

Scene 타입 인스턴스 Body를 갖는 App

1. 앱의 구조와 동작을 나타내는 타입이라고 합니다. 

2. 앱의 기본 진입점을 이곳에서 설정할 수 있습니다.

이곳에서 변수나 상태를 선언하여 모든 Scene에서 공유할 수 있게됩니다. 

 

 

살펴보면서 느낀 건 UIKit과 다르게 모두 Protocol이라는 점입니다.

프로토콜 지향으로 만들어졌다는 것이죠. Swift 언어 철학게 맞게 SwiftUI가 만들어졌다는 것을 알 수 있습니다.

WindowGroup은 뭘까요?

View들을 묶어줄 수 있는 Container 같죠.

MacOs에서는 여러개의 Window를 띄울 수 있습니다. 여러개의 브라우저를 한번에 띄울 수 있죠?

여기서 각 Scene은 개별 Window라고 합니다.

위와 같이 WindowGroup에서 생성된 모든 Window는 독립적인 상태를 유지합니다.