LINE LIVE iOS의 SwiftUI
새로운 UI 프레임워크
- 라인 다이브 앱: UIKit + MAV 패턴
Massvie ViewController문제점 발생 → 새로운 로직, UI를 추가할 때 뷰 컨트롤러 내에 추가해야 함- 명령형 언어인 UIKit 프레임워크의 특성으로 인해 생기는 부작용을 코드 분리, 경량화를 통해 손쉽게 해결 가능
- 선언형/함수형 프레임워크인 리액트, 플러터, SwiftUI 도입
SwiftUI-only 프레임워크
- 위젯 킷
- 액티비티 킷
- 스위프트 차트
- UIKit 프레임워크에 추가되는 새로운 리소스가 전무한 반면 SwiftUI에는 지속적으로 관련 리소스 추가 및 피드백 반영 중
Migration
- 현존 컴포넌트 또는 개발 스케줄에 영향을 미치지 않도록 마이그레이션
- 해당 작업을 실행할 때 있어 UIKit 비용과 비교
Debug Panel
- 인터널 디버그 빌드 화면에만 뜨는 패널
- 개발자 및 QA 팀만 볼 수 있음
More Complicated scene
- 앱내 로그 뷰
- API 리퀘스트 등 기록 및 표시 가능한 뷰
- 필터링, 로그 등 네비게이션 기능, 데이터 공유, 기본 아키텍쳐를 검증하는 단계
Tool App
- 다운로드 가능한 리소스를 검사하기 위한 스탠드얼론 앱
- 라인 라이브 앱 내의 동시성을 리팩터링하는 프로젝트
- 네트워킹, 리소스 사용 효율성 등 검증
Limited use in Production
- 필요하다면 적은 비용으로 롤백 가능
- A/B 테스트 가능
- 프로덕션 빌드하기로 검증
New Feature
- 특정 모듈만을 SwiftUI로 구현
- UIKit 프레임워크와 통합 가능
- 애니메이션, 셀프 레이아웃 등 복잡한 구현
디버그 패널부터 디버그 로거, 조사 앱, 간단한 신에서 복잡한 신까지 5 단계의 통합 과정을 거침으로써 팀 내에서 SwiftUI 통합 과정을 거침
Risk
ObservedObject
- Log List를 구축했을 때 문제점 발생
- 중첩되었을 때 해당 파라미터의 변경 이벤트를 뷰에 전달하지 못함 →
@Binding을 통해 먼저 받은 뒤 직접$사인 프로퍼티를 통해 값을 전달함 - 수정된 값이 루트 오브젝트에 직접 적용
- 해당 오브젝트를 사용하고 있는 뷰라면 모두 변경 권한을 가지고 있다는 점에서 위험성 존재
Dependency Injection
- SwiftUI의 기본적인 뷰 하이어러키: 순수 자식 뷰 - 부모 뷰
@State를 받아들이지 않고 주어진 데이터만으로 UI를 그리는 순수한 자식 뷰- 해당 자식 뷰로 구성된 부모 뷰
- 해당 뷰의 UI를 그릴 때 삽입하는 데이터는 부모 뷰가 API를 통해 외부 리소스를 얻어온 뒤 해당 데이터를 자식 뷰에 전달
- 자식 뷰 자체에서 API 통신이 필요할 수 있음: 의존성 주입 문제 발생. 유저 인증 등 실제 실행 시에만 유효한 경우가 예시
- 의존성 문제를 해결하기 위해서는 뷰를 더 작게, 데이터를 직접 호출하지 않는 순수 자식 뷰가 가장 좋음
TCA
The Composable Architecture:Store를 통해 현재State를 감싼 뒤 뷰를 실행. 뷰를 통해 액션 전송 가능. 액션은State가 변경될 수 있다는 신호로 해당 신호를Reducer가 캐치- TCA를 통해 자식 뷰에 전달하는 의존성을 보다 안전하게 전달 가능
- 복잡한 상태 관리: 단일한 상태 관리 메커니즘으로 가독성 높은 코드 작성
- 의존성 주입 수행의 어려움 해결: 컴포넌트 단위를 작게 만들어 독립적이고 통합 가능하도록 구성, 안정적이고 확장 가능하며 컴파일러 친화적인 코드 작성 가능
Before Fully Adoption
- 뷰 라이프 사이클 확인
- 레이아웃 시스템 체크
- 최신 버전 통합성 확인 필요
결론은, SwiftUI가 '미래'다! 생각해 볼 키워드는 TCA.
JUST DO IT