카테고리
IT/개발
직접 만든 앱과 서비스의 개발 기록
App Store 심사 제출을 다시 실행해도 안전한 판정 규칙
서버는 심사 요청을 받았는데 응답만 잃어버리면, 자동화를 다시 실행했을 때 중복으로 거절돼요. DailySudoku의 iOS 제출 자동화에서 버전 상태와 제출 객체 상태를 따로 읽어 재실행을 판정하게 고친 과정을 기록해요.
UMP의 사전 안내와 ATT 요청 순서를 바로잡은 기록
DailySudoku는 앱이 직접 ATT를 요청하는데, Google UMP도 사전 안내 뒤에 ATT를 요청할 수 있어요. SDK 바이너리에서 ATT 호출 흔적을 찾고, 두 요청이 겹치지 않도록 호출 순서를 바꾼 과정이에요.
수출 규정 신고값을 두 파일과 ASC에서 맞추는 검사
암호화 수출 규정 신고값은 Info.plist와 제출 선언 파일 두 곳에 있고, App Store Connect에도 남아요. 세 값이 어긋났는데 성공으로 판정하는 경로와, 그것을 막으려다 재시도를 전부 차단한 회귀를 고친 과정을 기록해요.
병렬 테스트가 전역 알림으로 서로를 건드린 사례
로컬에서는 0.02초에 끝나던 광고 배너 테스트가 CI에서는 45분 제한에 걸렸어요. 러너의 부하를 의심했지만 원인은 병렬로 도는 다른 테스트가 보낸 전역 알림이었어요. 재현 실험으로 가설을 확인하고 NotificationCenter를 주입해 분리한 과정을 기록해요.
리뷰 요청 예약에서 취소된 Task가 끝까지 실행된 경로
승리한 뒤 2초 기다렸다가 스토어 리뷰를 요청하는 예약이, 화면을 벗어나 취소한 뒤에도 실행될 수 있었어요. Task.sleep이 정상 반환한 뒤의 취소는 오류로 돌아오지 않기 때문이에요. 취소 동작을 Swift 6.4에서 다시 확인하고 고친 과정을 기록해요.
Apple Pencil 필기를 스도쿠 숫자로 바꾸는 입력 처리
DailySudoku에서 펜으로 쓴 숫자를 셀에 넣으려면 획을 tap과 필기로 나누고, 여러 획을 묶고, 모델 입력으로 바꾸고, 믿을 수 있을 때만 적용해야 해요. 각 단계의 기준값과 아직 검증하지 못한 부분을 기록해요.
스도쿠 81칸을 VoiceOver와 TalkBack에 알리는 방법
DailySudoku 게임판은 화면에서는 뷰 하나지만 보조 기술에는 81개 칸을 따로 알려야 해요. iOS와 Android에서 칸의 위치·내용·선택 동작을 맞춘 방식과, 아직 실기기로 확인하지 못한 부분을 기록해요.
일일 퍼즐 ID에 생성기 버전이 필요한 이유
DailySudoku의 일일 퍼즐은 날짜에서 seed를 만들어 보드를 생성해요. 생성 방식이 바뀌면 같은 날짜에서 다른 보드가 나올 수 있는데, 날짜만 담은 ID로는 그 차이를 적을 수 없어요. 현재 구조와, ID에 날짜 정책과 생성기 버전을 넣자는 제안을 기록해요.
광고 제거 일회성 구매의 권한을 유지하고 되돌리는 방법
광고 제거 상품은 한 번 사면 끝나는 것처럼 보이지만, 재설치, 대기 중인 결제, 환불을 거치면 구매 직후의 결과만으로는 보유 여부를 알 수 없어요. StoreKit 2와 Play Billing에서 현재 권한을 다시 읽어 캐시를 맞추는 구현과 남은 공백을 기록해요.