앱스토어 리젝 대응(크래시 로그 분석방법)
리젝 발생
앱스토어에 앱 심사를 맡기고 하루 뒤 이슈를 발견했다고 메일이 왔다
확인해보니 앱 런치 동안에 크래시가 발생해서 리뷰를 할 수 없다고 한다
그러면서 크래시가 발생했을 당시의 크래시 로그 5개를 첨부
해주며 절차를 따라 이슈를 해결하라고 알려준다
내가 테스트할 땐 별 문제 없었기 때문에 크래시로그 분석을 시작했다
크게 순서는
1. 리젝 발생
2. 크래시 로그 분석
-i. symbolicate
-ii.원인식별
3. 문제해결
크래시 로그 분석-symbolicate
크래시로그에는 크래시의 원인과 스레드에서 실행되고 있던 모듈들과 코드가 기록되어있다
크래시로그를 보고 바로 해석 가능하다면 베스트!
하지만 위의 이미지처럼 크래시 로그의 일부는 16진수로 이루어져있어 알아볼 수 없다
이것을 사람이 알아볼 수 있게 식별하는 과정을 symbolicate(16진수로 이루어진 주소값을 Symbol로 전환)라고 한다
Xcode로 Symbolicate하기
애플 문서를 따라가다보면 Xcode를 통해 손쉽게 symbolicate하는 방법을 알려준다
하지만 Xcode 버전차이인지 실제 테스트와는 약간은 달랐다
아래에 공식문서와 현재(2024.8)의 차이를 기록했다
애플 공식문서
View Device Logs 버튼을 통해 크래시 로그들을 symbolicate하여 볼 수 있다
작동환경: Xcode Version 15.4
내가 따라해보니 Xcode의 버전이 달라서 그런지 약간의 차이가 있었다
Open Recent Logs -> 로그 선택하게 되면
Debug Navigator를 통해 크래시가 발생한 당시의 스레드가 symbolicate 된것을 확인할 수 있다
MacSymbolicator로 Symbolicate하기
나의 경우 5개의 크래시로그를 비교분석하기 위해 오픈소스 앱인 MacSymbolicator를 사용하여 symbolicate 후 따로 파일로 저장
크래시로그 파일을 드랍하여 가져다두면 자동으로 dSYM 파일을 찾아주기 때문에 일일이 찾을 필요가 없다!
크래시 로그 분석-원인 식별
문서에서는 크래시의 원인에 패턴이 있다고 설명해준다
패턴을 알기 위해 봐야하는 두가지 섹션은
Exception 섹션과 Backtraces 섹션이다
실제 내가 받은 크래시로그이다
문서에서 Exception Type에 따른 크래시 패턴을 설명해준다
이미지의 1번을 보면 나는 EXC_CRASH(SIGKILL)이라고 적혀있다
또 2번을 보면 scene-create라고 되어있다
1. EXC_CRASH(SIGKILL)
이는 앱이 반응이 없을 때 watchdog를 앱을 종료시키는 패턴이다
2. scene-create
나의 경우 앱의 scene이 생성되는 과정에서 워치독에 의해 앱이 종료됐다
간단히 말하면 앱 초기화 과정에서 종료됐기 때문에 앱이 켜지지도 못한채로 리젝을 당했던 것이다..
워치독이 앱을 종료하는 이유
메인 스레드를 상당 시간동안 차단하는 앱을 종료한다
아래 중 내 앱은 동기 네트워킹에 해당하는데
CoreLocation의 위치사용권한을 요청하는 과정에서 권한에 따른 UI 업데이트를 동기로 실행하다보니 발생한 문제였다
- 동기 네트워킹
- 대용량 JSON 파일이나 3D 모델과 같은 대량의 데이터 처리
- 대용량 Core Data 저장소에 대한 가벼운 마이그레이션을 동기적으로 트리거
- Vision을 통한 분석 요청
결론
크래시 원인을 찾기위해 크래시로그를 분석하여보았다
처음 크래시로그를 마주했을 때 온통 외계어 같고 상당히 정신이 혼미했다
또 문서를 따라가다 Xcode 버전 차이로 인해 정신에 혼미가 가중됐었다
하지만 차근차근 문서를 분석하여 원인을 발견하고 문제를 해결할 수 있었다!
출처