SwiftUI vs UIKit

 IOS에 대해서 공부를 하려고 보니 어느새 UI도 다양한 방식으로 분화되고 있다는 사실을 깨닫게 되었습니다. 안드로이드에서 선언형 UI 개발에 대해서 안 지 얼마 되지 않았는데, 그 때 자주 접했던 키워드인 SwiftUI에 대해서 찾아보다 보니, UIKit라는 이름의 기존 UI 개발 방식과 애플에서 새로 발표한(WWDC 19에서 발표되어 지금은 꽤 오래된) SwiftUI라는 개발 방식이 존재한다는 사실을 알 수 있었습니다.

 SwiftUI라는 친구가 어느덧 3년이 넘었고 만으로도 2년이 넘었으니 꽤나 많은 자료들이 나오고 있습니다. 이러한 개발 방식의 분화는 기존 개발자들에게 새로운 기술 스택을 요구하기는 하지만, 기존 코드를 효율적으로 변경시킬 수 있다는 기대감을 주곤 하죠!(하지만 실무에서 개발하고 있는 사람이 아니라면 트렌드 파악을 꾸준히 해야한다는 점에서 개발보다는 검색에 조금 더 시간을 쏟아야 하는 부담감이 있긴 합니다.)

 하여튼, 이러한 SwiftUI와 UIKit가 무엇인지, 어떤 차이가 있고 장단점이 무엇인지 기록해두려고 합니다.

---

 SwiftUI란?

 Apple에서 기존 IOS UI의 문제점을 보완하고 더 간소화된 UI를 구성할 수 있게 하기 위해 개발한 Swift용 Ui 프레임워크입니다. 하지만 정확하게 UIKit을 대체하는 것은 아닙니다.

• 선언형 UI
• 데이터 주도
• no storyBoard

 

 선언형 UI

 요즘 Ui는 선언형이 대세인 듯 합니다. 안드로이드도 새로운 UI 개발 방식으로 선언형 UI인 jetpack compose를 내놓았고, 기존 하이브리드 앱을 제작할 수 있게 새로 만들어진 flutter도 선언형 UI를 활용하더니 IOS에도 이미 선언형 UI라는 친구가 존재합니다. 결국 모바일은 선언형 UI로 통일되고 있다고 볼 수 있겠네요.

 

데이터 주도

 데이터 주도 기반이라는 것은 기존 UI는 상태값을 데이터의 변경에 따라 개발자가 적용시켜주는 것이었다면, 이제는 데이터의 값 변경에 따른 UI 변경까지 기본 UI의 개념으로 두겠다는 뜻으로 보입니다. 이는 데이터의 변경에 따른 상태 파악을 프레임워크 내에 둬서 좀 더 강한 추상화를 시키겠다는 의미로 볼 수 있겠습니다.

 

No StoryBoard

 스토리보드를 사용하지 않습니다! 사실 IOS에서 스토리보드는 책을 통해 공부를 할 때 제일 많이 사용하고 실무에서는 스토리보드 대신 코드 기반으로 UI 작성을 하기 때문에 잘 사용하지 않기는 하지만, SwiftUI에서는 아예 연동되어 있지 않다고 볼 수 있습니다.

 

 UIKit이란?

 UIKit은 IOS 애플리케이션의 사용자 인터페이스(UI)를 구현하고 이벤트를 관리하는 프레임워크로 storyBoard를 지원하고 IOS의 기본 UI 프레임워크입니다.

• 이벤트 중심
• 상속 기반

 

이벤트 중심

 선언형 UI가 데이터의 상태에 따라 UI를 새로그려주는 형태라면, UIKit은 어떤 이벤트가 발생했을 때 UI를 새로 그려준다고 생각할 수 있습니다.

 

상속 기반

 모든 UI는 상속을 기반으로 합니다. 이는 뷰가 클래스임을 의미합니다. 그리고 뷰에 여러가지 기능들을 담아두었다는 것을 알 수 있습니다. 하지만 이 상속 기반으로 만들어진 UI는 그 특성으로 인해 레거시 코드가 점차 늘어나기 시작했고, SwiftUI라는 친구가 등장하게 되는 계기가 되었다고 합니다.

 

 무엇을 사용해야 할까?

 사실 코딩할 때 어떤 프레임워크나 라이브러리를 사용할 때 제일 중요한 것은 내가 사용하려는 환경에 맞는 것이냐가 제일 중요합니다. 가끔은 단점이 치명적이어도 써야만 하는 이유가 있죠. 그리고 불편하더라도 혼용해야 하는 경우도 존재하구요. 그렇다면 무엇을 언제 사용해야 할 지에 대한 고민이 필요한 거 같습니다.

 SwiftUI의 가장 큰 장단점은 최신 코드라는 것입니다. 기존 UI에 대한 코드의 단점을 극복하기 위해 나온 코드일 뿐 아니라, 새로운 패러다임을 따라가고 있다는 점이 제일 큰 장점이죠. 거기다 항상 새로운 것은 러닝커브가 존재하기 마련인데, 의외로 SwiftUI는 러닝커브가 낮은 것을 장점으로 꼽는 경우가 많더라구요. 실제로 제가 Swift를 거의 다루지 못하는 터라 코드를 보는데 어려움이 들지만, 확실히 기존 UI와 나란히 놓고 봤을 때 SwiftUI가 좀 더 보기 편한 느낌이 있긴 합니다. 하지만, 결국 SwiftUI는 개발된지 얼마 되지 않았기 때문에 연구된 방식도 적고, 검색시 나오는 게시글도 분명 기존의 방식보다 훨씬 적을 겁니다. 더욱이 오픈소스 역시 얼마 되지 않을 수 있습니다.(결국 최신 코드는 항상 어느정도 시간이 지나야 한다는 것이죠.)

 그러나 기존에 UIKit으로 적용되어 있는 모든 IOS 앱들을 갑자기 SwiftUI로 바꾸는 것에는 무리가 있을 겁니다. 개발 초창기에 만해도 지원하지 않는 기능들이 존재하는 것으로 보였으니까요. 그리고 새로운 패러다임을 적용하는 것은 분명히 리소스가 드는 작업이죠.

 하지만 하나의 기업이 밀어주는 코드는 결론적으로 추후에는 사용해야 합니다. 당장 IOS 개발자로 취직하겠다면 아무래도 둘 다 알고 가는 것이 맞지만, 그게 아니라면 애플에서 밀어주고자 하는 SwfitUI를 공부하는 것이 맞다고 생각합니다.(무조건 UIKit으로만 작업하겠다는 생각은 이제는 조금 접어둬야 할 것 같습니다.)

---

 모바일 쪽은 안드로이드와 IOS가 완벽하게 잡고 있는 터라 각 OS의 트렌드는 결국 회사의 방향성에 따라서 움직일 수 밖에 없다고 생각합니다. (안드로이드의 jetpack이나 IOS의 스위프트처럼요.) 이게 옳은 방향은 아니라고 생각하지만, 회사에서 자신의 OS에 대해서 점유율을 올리기 위해 더 좋은 프레임워크를 개발한다면 나쁘지 않은 방향으로 흘러가리라 생각은 합니다. 또한 안드로이드와 IOS 모두 선언형 UI를 사용하면서 플러터라는 프레임워크도 다시금 살펴볼 필요가 있지 않나 생각됩니다. 하이브리드 그 자체의 기본적인 성능이나 이슈가 어느정도 해결된다면 고려볼 수 있는 선택지가 될 수 있다고 봅니다.