SwiftUI VS UIKit 에 대한 고민(SwiftUi를 먼저 접하고 나중에 UIKit을 공부한 사람의 입장.....)

작년 Apple Developer Academy 에서 iOS 에 대해 처음 공부를 했다.

 

마지막 프로젝트에서 팀원들과 SwiftUI 를 쓸 것이냐? UIKit을 쓸 것이냐 에 대한 이야기를 나눴었다. 큰 이견없었다. 다들 현업에서 UIKit 을 쓰고 있으니, 당장 1~2년 안에 취업을 할 생각을 가지고 있다면 UIKit 을 하는게 좋겠다 란 얘기가 나와서 UIKit을 썻었다.

 

나의 경우엔 이전 프로젝트에서 UIKit을 거의 안써봤기에 UIKit을 써보고 싶다는 생각을 했었기에 좋았다. 하지만 요즘 혼자 공부를 하면서 저런 이유말고, 왜 UIKit인가? 왜 SwiftUI인가? 에 대한 이유를 찾게 됐다.

 

그렇다면 SwiftUI 는 뭘까?

wwdc19 SwiftUI essentials 를 보면 좋은 UI를 짧게 만들 수 있는 길 이라고 한다.

UIKit 의 UI 요소들을 기반으로 만들었으면 선언형 프로그래밍 프레임워크다.

 

UIKit 은 명시적 프로그래밍인데, 이는 마치 요리로 치면 요리 교습소같다. 필요한 재료들을 나열하고, 그 재료들의 대한 처리를 순서대로 하나하나 자세히 설명을 해준다.

 

영상에선 아보카도 토스트를 만드는 방법에 대해서 명시적으로 나열한다. 

하지만 선언형의 경우 마치 우리가 그냥 설명하듯이 얘기하는 방법이라고 한다.

 

UIKit 코드를 생각해보면 UIView를 상속받는 객체들로 뷰를 준비하고, 그 뷰를 뷰컨트롤러에 추가, 레이아웃 설정, 액션 추가를 하나하나 모든 요소를 개발자가 직접 해준다. 토스트 만드는 방법을 설명하듯이. 하지만 SwiftUI 의 경우는 쓰고 싶은 요소를 만들면 기본적으로 프레임워크에서 사이즈, 위치를 알아서 다 해준다. 

 

또한 View의 스타일을 바꾸기 위해선 view 가 가지고 있는 속성들의 값을 바꿔줌으로서 뷰의 변화를 준다. 하지만 SwiftUI 는 다르다.

View는 따로 불필요한 속성들을 가지고 있지 않다. 

그렇다면 어떻게 스타일의 변화를 주느냐? 

간단하다. modifier를 재공한다. view가 선언이 되면 modifier를 사용하여 생성된 view 를 바꿔주는 새로운 view를 생성한다.

그런식으로 modifier를 여러개 추가함으로 만들어진 view를 통해 새로운 custom된 view를 만들어 준다.

 

이는 modifier도 view 프로토콜을 따르기 때문이다. (최근에 pop란 것도 들으며 공부에 대한 필요성을 느꼈는데.....좀 더 빨리 해야겠다...그걸 알게 되면 SwiftUI 의 view를 그리는 방식의 장점을 더 알 수 있지 않을까....)

 

이러한 속성때문에 애니메이션을 적용시키기도 훨씬 쉬운것 같다. 생성된 view에 animation을 추가하기 때문에, 개발하는 입장에서 어떤view에 animation이 적용이 될지 생각하기 쉽다. 또한 namespace를 쓰게되면, 기존view가 가지고 있는 속성값과 새로운 view의 속성값의 차이를 적절히 변화를 준다. 이걸 이용하면 app store의 팝업 애니메이션을 주는것이 가능하다. UIKit에서는 트랜지션 애니메이션을 위해 기존 뷰의 사이즈와 위치 값을 이용하여 새로운 뷰에 할당해서 애니메이션 효과를 주는등 하나하나 다 설정을 해줘야 했는데....

 

또한 combine을 쓰기 편하다. 

@ObservableObject(Publisher) 와 @ObservedObject(Subscriber) 를 지원한다. 또한 State, Binding 을 통하여 값의 변화를 scene 뒤에서 관리하면 view의 변화를 준다(새로운 view를 생성). 

이걸 봤을때 웹프로그래밍에서 React가 떠올랐고, Rudex를 통해 상태관리가 용이하여 반응형 웹을 만들기 편해졌다고 하는 것처럼, 이러한 트렌드를 따라 가고 견재하기 위해 SwiftUI 를 만든것이 아닌가 싶다.

 

하지만 이런 편의성이 재공한다고 다 좋은것은 아닌 것 같다. SwiftUI 를 몇 달 써보다가 UIKit 를 써보며 처음엔 그냥 불편하다는 생각만 들었다. 선언해주면 끝나는게, 재료 준비하고 다듬고, 올려놓고 모든걸 다 적어줘야 하니... 하지만 그만큼 내가 원하는 것을 정확하게 정해줄 수 있다. 프레임워크의 간섭이 적은 만큼. 

식당 메뉴로 비교하면 SwiftUI 는 세트메뉴갔다. 세트메뉴는 식당에서 정해준 항목이기에 가끔 내가 만족하는 메뉴들을 선택할 수 없고 그래서 단품으로 시켜야 하는지 고민을 주는.....프레임워크가 알아서 해주는 것이 많은만큼 그게 가끔 나를 충족 못시켜준다.....

 

그럼에도 불구하고 SwiftUI 를 해야한다는 생각은 강하게 든다. 

최근 아이폰에 위젯, 다이나믹아일랜드 등이 생기고 있다. iOS 개발자가 되기로 하기 전부터 IT 기기에 관심이 많았는데, 애플은 사용자와의 interactive를 중요하게 생각한다. 그렇기에 신제품의 생기는 기능은 애플이 추구하고 앞으로 나아가려고 하는 방향을 예측하게 한다. 좋은 앱을 만든다 = 사용자의 최고의 인터랙션을 준다 라고 생각된다.

 

위젯 개발 및 다양한 멀티플랫폼과의 상호작용이 되는 앱이 나중엔 필수적일 것이고 그러기 위한 최적의 환경은 SwiftUI 가 될 것이다.

잘하면 모든 앱이 나중에는 SwiftUI 로 바뀌게 될 수 있다. 

 

그래도 UIKit은 아직 버리기엔 시기상조한 것 같다.

wwdc 에서 UIKit을 검색해보면 최근에도 계속해서 발표가 되어지고 있다. 특히 가장 최근엔 SwiftUI와 UIKit 을 함께 사용하는 영상이 올라왔다. 

이걸 생각해보면 세가지 생각이 든다.

1. 애플에선 UIKit 에서 SwiftUI 로 개발 환경의 변화를 주기 위한 시도가 있다.
2. SwiftUI 로 UIKit 의 모든 요소를 커버하기엔 아직 무리가 있다. 그렇기에 적절히 섞어 사용할 수 있도록 가이드를 준다. 그러면서 1번을 노린다.
3. 아직 현업에서 UIKit의 사용이 너무 많이 퍼져있기에 새로운 것을 계속 제공해준다. > 취업을 위해선 UIKit을 알아야한다. 아직 회사에선 SwiftUI 로 프로젝트를 바꾸는 작업을 진행하기엔 비용대비 메리트가 크지 않을 수 있다.

내 생각을 정리하자면,

• SwiftUI를 사용하면 코드가 짧아지고, 간단하게 앱을 만들 수 있다 > 개발비용이 적다
• 또한 위젯, 멀티 디바이스를 커버하기에 유리하다.
• 하지만 아직 UIKit의 모든 기능을 커버하지는 못한다.
• UIKit을 공부하다 보니 SwiftUI 의 View 요소들에 대한 이해도가 조금은 올라간다.
• SwiftUI 와 UIKit을 같이 사용할 수 있는 방법이 있고, 그렇기에 ObservableObject 사용도 가능하다.(Combine을 사용하기 편해진다) 

정도인데 결국엔 커리어 전환을 위해선 두 개의 프레임워크를 다 공부하고, 전부 사용하여 사용자 경험을 가장 좋게 이끌어 낼 수 있는 방법을 고민하면서 앱 개발을 진행해야할 것 같다.

공부할 것이 너무 많다. 하면 할수록 나무가지 퍼지듯 해야할 목록이 늘어난다.....취업준비도 해야하는데..........