iOS troubleShooting Week 1

이벤트 구현과 방출 방법

먼저 사용자 이벤트 로그를 남기기 위해 사용자의 동작이 어느 뷰에서 일어나는 지 알 필요가 있었습니다.

재사용이 많이 이루어지는 SwiftUI의 특성상 처음엔 각각의 모든 뷰에 이름을 부여할까 고민했지만, 그렇게 하지 않고 자신의 변수 이름을 반환하는 계산 타입 프로퍼티를 구현해 이벤트가 일어나는 뷰를 특정할 수 있었습니다

그러나 재사용이 이루어지는 뷰에서는 어느 뷰에서 이벤트가 발생했는지 구분할 수가 없었습니다. 따라서 재사용이 되는 뷰의 경우엔 각각의 id를 부여하여 이벤트를 분석할 때 구분되도록 하였습니다.

그리고 자연스럽게 뷰의 네이밍에 좀 더 신경을 쓰게 되는 효과가 있었습니다.

extension View {
    static var name: String {
        String(describing: Self.self)
    }
}

이벤트 발생 방법

이벤트를 발생시키는 코드에 대해서 많이 고민해 보았습니다. 처음엔 Button의 액션마다 실행할 코드를 넣어주려는 생각이었는데 가독성도 안 좋아질 뿐더러 비효율적이라고 생각했고, 버튼이 아닌 다른 뷰와의 상호작용도 필요하다고 생각했습니다.

따라서 기존의 동작에 추가로 제스처를 더할 수 있는 simultaneousGesture를 활용하여 버튼의 기존 동작을 유지하면서 필요한 동작을 실행할 수 있는 방법으로 구현하였습니다.

extension View {
    public func emitEventIfTapped(event: Event) -> some View {
        return self.simultaneousGesture(
            TapGesture()
                .onEnded { _ in
                    EventSendManager.shared.eventHandler(event)
                })
    }
}

그러나 예외적으로 탭뷰의 경우 각 탭버튼에 대해 두 가지 동작이 동시에 일어나지 않아서 , 각각의 뷰에 tag를 지정해 TabiView의 selection 속성이 바뀔 때 didSet으로 이벤트를 발생시키도록 구현하였습니다.

기기 간 파편화 문제

기본적으로 시뮬레이터로 iPhone 11 pro를 표준으로 잡고 UI 개발을 시작했습니다. 그러나 개발 동안 사용하던 실기기는 iPhone SE였는데 극단적으로 차이가 있어서 UIScreen.main.bound를 이용하여 최대한 기기 간 동일한 화면을 표시할 수 있도록 했습니다. GeometryReader 또한 고려해 봤으나 속성을 사용할 최하위 뷰까지 전달하는 과정이 가독성이 떨어져 사용하지 않았습니다. 다만 화면 회전 시에 orientation을 감지하여 이미지의 크기를 지정하던 도중 UIScreen.main.bound가 잘 동작하지 않았고 GeometryReader가 더 좋은 방법이라고 생각하여서 사용하게 되었습니다.

TabView 버그

앱 내에서 사용되는 스크롤 뷰의 페이징을 구현하기 위해 UIScroll의 속성을 불러와 사용하였으나, 앱 전체의 스크롤 뷰가 페이징이 되었습니다.

따라서 이러한 방식을 사용할 수 없었고, 결국 기본적인 앨범이나 노래 등을 나타내는 스크롤은 연속 스크롤 그대로 사용하도록 했습니다.

하지만 개발 중 보관함 탭을 구현하기 위해서 필수적으로 페이징이 필요하다고 생각되었습니다. 조금 더 알아보던 중 SwiftUI2.0에서 지원하는 PageTabViewStyle이 있어 적용하게 되었습니다. 처음에는 잘 되는 듯 했으나 탭뷰 내에서 스크롤과 LazyVgrid 등 복잡한 뷰를 구현했을 때 탭이 넘어가지지 않고 화면 구성이 무너지는 문제가 발생했습니다.

결국 복잡했던 뷰의 스크롤 계층을 줄이고 꼭 필요한 부분이 아니면 Lazy가 아닌 일반 VStack을사용하니 버그가 없어지게 되었습니다.

코어데이터 사전형 저장, 마이그레이션 문제

이벤트 저장 방식을 유연하게 만들기 위해 각 이벤트에 파라미터로서 [String: Stting] 딕셔너리 형식을 채택하게 되었는데, 코어데이터에 저장하는 과정이 조금 까다로웠습니다. 처음에는 Transformable 타입을 이용해 Set으로 저장하려 했으나, 1:다 관계로 저장하니 조금 더 수월하게 구현할 수 있었습니다.

초기에 persistenceController 내의 함수를 최대한 제네릭하게 유지하기 위해서 저장할 타입을 외부에서 지정할 수 있도록 구현하였으나, 키값을 따로 저장해야 하는 특성상 내부에서 구체 타입으로 저장하게 되었는데, 뭔가 방법이 조금 더 있을것 같아 조금 아쉬웠습니다.

이벤트가 발생한 시점을 Date형으로 저장해 왔었는데, 개발 중 서버 쪽에서 이벤트 시점을 문자열 형식으로 교환해야 했습니다. 코어데이터 역시 Date타입에서 String타입으로 형식을 바꿔야 했는데, lightweight migration 에서는 타입 변경을 지원하지 않아서 새로운 애트리뷰트를 만들어 주고 버전을 올렸습니다. 아직 개발 중이어서 이렇게 했지만 실제 서비스 중인 앱이라면 직접 마이그레이션 하는 방법을 학습해야겠다고 생각했습니다.

3rd party 프레임워크 생성 문제

어느 앱에서나 저희가 만든 이벤트 수집기를 만들 수 있도록 서드파티 프레임워크 제작을 목표로 했습니다. 실제 기기의 iOS와 시뮬레이터의 iOS의 CPU 아키텍쳐가 달라 Universal Framework를 제작해야 한다는 것을 알게 되었고, 인터넷에 검색하면 나오는 스크립트를 이용하여 만들려고 했는데, 잘 만들어지지 않았습니다.

처음에는 왜 그런지 몰라서 여러 방법을 시도했는데, 스크립트를 한줄한줄 보다 보니 iOS 빌드와 시뮬레이터 빌드를 합치는 lipo 명령어가 오류가 나는 것을 알 수 있었습니다. Apple에서 M1 CPU를 출시하여 ARM CPU를 지원하면서 이제 시뮬레이터에서도 arm64 아키텍쳐가 포함되어 중복되어 합쳐지지 않았습니다. 따라서 빌드 옵션으로 arm64를 제외하여 다시 시도하여 Universal Framework를 만들게 되었습니다.

그러나 바로 다음날 Xcode의 12.3 업데이트가 있었는데, 업데이트를 하고 나니 이번엔 서드파티 프레임워크의 빌드를 제대로 하지 못하는 문제가 발생했습니다. 이 부분은 Xcode의 문제여서 저희가 해결할 수 없다고 생각했고, 결국 CocoaPod을 이용해 배포하면서 더 좋은 결과를 얻을 수 있었습니다.

다크모드

네이버 VIBE 앱이 기본적으로 대부분의 UI가 검정색으로 되어 있어 개발 초기에는 다크모드를 따로 생각하지 않고 있었습니다. 그러다가 VIBE에도 흰색의 테마가 있다는 것을 알게 되었습니다.

다크모드/라이트모드 구현을 위해 Color scheme을 나누어서 구현했는데, 구현하고 나니 다크모드를 컨트롤할수 있는 기능이 iOS에 있어서 단일 앱 하나에 대해 사용자가 임의로 다크모드로 변경할 수가 없었습니다.

당연히 다크모드를 사용하지 않는 사용자에게도 VIBE의 기본 색상인 어두운 테마를 보여줘야 한다고 생각했고, 여러 방법 중 preferredColorScheme을 뷰에 지정해 주어 구현했습니다. 다만 modal 뷰가 올라오는 부분과 같이 하위 뷰가 아닌 새롭게 만들어지는 부분에서는 각각 지정해 주어야만 했습니다.

성능 이슈

앱이 시작하자마자 보이는 Today 뷰는 구현한 뷰 중에서 가장 복잡한 뷰입니다. 뷰에 보이지 않는 부분은 미리 로드하지 않는 LazyVStack과 모두 로드하는 VStack의 두종류 중 어느 부분을 쓸지 고민했는데, Lazy는 정말 많은 데이터를 불러올 때 사용하는 것으로 알고 있었고, 몇 가지 컨텐츠로 고정되어 있는 저희의 뷰와는 맞지 않다고 생각했습니다. 그런데 막상 테스트를 해보니 어째서인지 LazyVStack이 cpu 게이지도 20프로대에 머물고 스크롤이 매끄러운 반면 오히려 미리 로드를 하는 VStack이 로딩시간을 충분히 주어도 cpu 사용량이 100프로에 다가가며 더 성능이 나오지 않았습니다. 뭔가 잘못한 걸 수도 있어 검색해보니 메모리 이슈가 있다는 듯 했지만 확실한 이유는 찾을 수 없었습니다. 결국 LazyVStack을 사용하게 되었습니다.

그 외 이슈

개발하는 내내 뭔가 자잘한 SwiftUI 탓이라고 생각되어지는 버그가 많았습니다. 사실 UIKit 기반으로 프로젝트를 진행할 때에도 그렇긴 했는데, 빌드를 클린시키거나 Xcode의 DerivedData를 비워주니 대부분의 문제가 해결되었습니다.

그러던 중 iPad mini5 실제 기기 동작에서 갑자기 CPU 게이지가 100프로에서 고정되는 버그가 있었습니다. 앱 시작 후 아무런 동작을 취하지 않았는데도 최대치를 유지하고 앱이 멈추었습니다. 이런 문제는 시뮬레이터에서는 발생하지 않고 실제 기기에서만 발생했는데, 앱을 재설치해도 나아지지 않아 혹시나 하는 마음에 iPad를 초기화하니 해결 되었습니다.

시뮬레이터에서만 존재하는 버그가 있는 것 같습니다. 가로스크롤 뷰와 스택뷰를 조합해 구현한 부분에서 분명히 가로 스크롤임에도 불구하고 세로로도 스크롤이 되는 버그가 있었는데, 실제 기기에서는 정상적으로 동작하여 다행이라고 생각했습니다.

회전 인식

화면이 회전했을때 뷰가 다시 그려지는 줄 알았는데 그렇지 않아서, UIScreen.main.bound가 적용되지 않았습니다. 이에 따라 GeometryReader를 적용해 이 문제를 해결했습니다.

아이패드 호환

LazyVGrid에서 adaptive를 적용하면 자동으로 화면 크기에 맞춰서 셀들이 생성됩니다. 하지만, MiniVibe앱의 UI는 VerticalScroll안에 HorizontalScroll이 있는 구조여서 LazyVgrid의 adaptive를 적용할 수 없었습니다. 따라서 셀 크기를 계산하여 적용시켜줬습니다.