SwiftUI + TCA를 1년간 사용하고 느낀점.

2023.06.19 ~ 포토위젯에서 iOS개발자 1년차를 맞이하였다.

오랜만에 회고록을 남겨보려 한다. 

 

포토위젯에서 작업한 프로젝트들을 기준으로 정리해보려 한다.

포토위젯에 입사 후 가장 어려웠던 것은 사실상 처음 다뤄보는 기술들에 적응하기 였다.

SwiftUI와 TCA, 이 둘은 그동안 익숙해져 있던 UIKit과 MVVM방식과 많이 차이가 있었다고 느꼈다.

SwiftUI

관계를 맺어 조건을 주는 오토레이아웃 방식이 아닌, 이 위치에는 이 뷰가 들어갈거야! 그 다음 이 위치에선 이 뷰가 들어갈거야! 라고 선언하는 듯 한 느낌이 들었다.

그리고 문법이 Swift가 맞나..? 싶을 정도로 간결했다. (자세히 이해하려 들며 읽어보면 역시 스위프트이긴 하다.)

 

- UIKit과의 차이점

SwiftUI는 익숙해지면 생산성은 UIKit보다 훨씬 좋다고 느껴졌다. 개발속도가 엄청 빠르다는걸 체감했다.

물론, "어..? 이거 왜이러지?" 하는 내용들도 많아서 이런 벽에 부딪히면, 몇시간이고 진땀을 빼곤 했다..

이때 가장 난감한 질문은

ㄴ (그래서 이 기능 언제까지 가능할까요? 이번 빌드에 포함할 수 있어요?)

 

- @SwiftUI PropertyWrapper

@State @Binding 등의 스유프로퍼티래퍼와 뷰가 갱신되는 조건을 간단히라도 알고 있어야 하며, 애니메이션은 참 어렵다는 것을 새삼 알게 되었다. 또한 .onChange등의 modifier가 있지만, 이 안의 코드들은 모두 메인쓰레드에서 실행된다는 것을 명심해야 한다.. 괜히 로직을 적었다가 뷰가 버벅이는 것을 보고 알게되었다..

 

SwiftUI는 포토위젯에서 선택이 아닌 필수이다. 애초에 위젯뷰 구현은 스유로밖에 할 수 없기 때문이다.

 

TCA

"TCA를 사용한다고요? 트렌디하고 MZ하시네요~"

선언형UI를 사용하는 리엑트의 Redux패턴을 보며 만들어진 아키텍쳐로 알고 있다.

그래서 RxSwift + MVVM처럼 SwiftUI + TCA라고 불린다고 알고 있다.

ReactorKit과 데이터 흐름은 같았다.

View에서 Action을 받고 이를 Store로 전달, Store에서는 Action에 맞는 로직으로 State를 업데이트 해주며, View는 이 State를 바라보고, 변경점에 맞게 UI를 업데이트 한다.

이러한 큰 흐름은 MVVM과도 크게 다르지 않다고 생각했다.

하지만 내부에서의 사용방법은 기존의 방법들과 천차만별이였다.

네비게이션 화면전환 방식에는 NavigationStack(Path), NavigationTree(Destination) 이렇게 두가지가 존재하며, 해당 방식은 TCA에서 독자적으로 만든 caseLet등을 사용한다. 정말 어려워서 몇번이고 문서를 보면서 개발했다.

이외에도 IfLetStore, store.Scope방식 등으로 화면전환을 하고, 각각의 Store들은 부모자식 관계에 있다.

자식에게서 발생한 Action은 부모에서도 감지가 가능하고, 이는 곧 성능저하에도 영향을 미칠 수 있다는 사실을 알게 되었다.

러닝커브가 정말 높고, 에러가 발생한 상황에도 정확한 스택추적이 어렵다. (TCA내부 코드는 이해할 수 없을정도로 난이도가 높고 복잡하다.)

이런 점이 TCA의 단점이라고 생각한다. 일단 어렵고, 정말 복잡하다. 에러 디버깅이 쉽지 않다.

같이 공부했던 친구들이 자주 하는 질문 중 하나가 "TCA를 추천하세요?" 이다.

그럼 항상 같은 대답을 준다. "장점도 많은데, 추천은 안할 것 같습니다.."

TCA의 단점만 이야기하는 것 같은데, 물론 장점도 있다.

TCA의 의존성 관리 방법이다.

Dependency에서 TestValue와 LiveValue를 별도로 관리하기에, 테스트에 정말 용이하며, 의존성관리에서도 너무 편하게 사용하고 있다.

의존성 주입이 아닌, 의존성 당겨오기 방식이다.

아쉽지만 포토위젯은 테스트코드를 작성하지 않는다.

 

포토위젯의 서비스 특성 상 딥링크로 한페이지만 더해주는 방식이 더 어울리기에, NavigationStack방식을 채택하였다.

또한 화면내에서 상세 설정은, State변수를 설정해주는 방식으로 해결하였다.

State를 변경해주다 보니 reducer의 .onChange도 많이 활용하였다.

또한 bottomSheet로 올라오는 화면은 모두 Destination State를 만들어 관리하였다.

 

SwiftUI는 UIKit을 기초로 만든 프로젝트에서 빠르게 개발을 원하는 Section에서 SwiftUI로 개발하여 맞추는것이 꽤 좋은 방법이라고 생각한다. 상황에 따라서 두가지의 방법 모두를 채택하여 사용할 수 있기 때문이다.

TCA에 대한 생각은 아직도 모호하다... 장점과 단점이 명확한 아키텍쳐 라이브러리이다.

확실한건 일단 너무 어렵다.. ( 에러상황에 대한 핸들링이 어렵다.. )