Menu
NavigationStack 문제(응답 없음, 예기치 않은 pop, 크래시), build 실패(SPM resolution, "No such module", build가 멈추는 경우), 또는 메모리 문제(retain cycle, leak, deinit이 호출되지 않는 경우)를 디버깅할 때 사용합니다. iOS/macOS를 위한 체계적인 진단 워크플로우입니다.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
TCA(The Composable Architecture)로 Feature를 구축하거나 reducer 구조화, state 관리, effect·navigation 처리, TCA feature 테스트를 할 때 사용합니다. @Reducer, Store, Effect, TestStore, reducer 조합 패턴을 다룹니다.
iOS 17+ SwiftUI patterns를 구현할 때 사용합니다: @Observable/@Bindable, MVVM architecture, NavigationStack, lazy loading, UIKit interop, accessibility (VoiceOver), 비동기 작업(.task/.refreshable), 또는 ObservableObject/@StateObject에서 마이그레이션하는 경우.
구현한 화면의 스크린샷·UI hierarchy를 Zeplin 시안 스펙과 항목별로 대조해 PASS/DIFF를 보고합니다.
SwiftUI 코드를 리뷰·정리하거나 soft-deprecated API를 점검할 때 사용합니다. view 구조 분리, dataflow/environment 검토, ForEach identity, localization, deprecation 마이그레이션을 다룹니다. (신규 구현 패턴은 swiftui-patterns 스킬 사용)
device 또는 simulator에서 스크린샷, UI hierarchy, 터치 interaction을 통해 iOS 앱 동작을 확인합니다.
async/await 코드를 작성하거나, strict concurrency를 활성화하거나, Sendable 오류를 수정하거나, completion handler로부터 마이그레이션하거나, actor로 공유 상태를 관리하거나, 동시성을 위해 Task/TaskGroup을 사용할 때 사용합니다.
| name | swift-diagnostics |
| description | NavigationStack 문제(응답 없음, 예기치 않은 pop, 크래시), build 실패(SPM resolution, "No such module", build가 멈추는 경우), 또는 메모리 문제(retain cycle, leak, deinit이 호출되지 않는 경우)를 디버깅할 때 사용합니다. iOS/macOS를 위한 체계적인 진단 워크플로우입니다. |
iOS/macOS 개발을 위한 체계적인 디버깅 워크플로우입니다. 이 pattern들은 구조화된 진단 접근 방식을 따라 몇 시간이 아닌 몇 분 안에 근본 원인을 파악하는 데 도움이 됩니다.
내용이 필요할 가능성이 조금이라도 있다면 항상 참조 파일을 로드하세요. pattern을 놓치거나 실수를 하는 것보다 context를 확보하는 것이 낫습니다.
| 참조 | 로드 시점 |
|---|---|
| Navigation | NavigationStack이 응답하지 않음, 예기치 않은 pop, 딥링크 실패 |
| Build Issues | SPM resolution, "No such module", 의존성 충돌 |
| Memory | Retain cycle, 메모리 증가, deinit이 호출되지 않음 |
| Build Performance | 느린 build, Derived Data 문제, Xcode 행(hang) |
| Xcode Debugging | LLDB 명령어, breakpoint, view debugging |
"미스터리한" 문제의 80%는 예측 가능한 pattern에서 비롯됩니다.
체계적으로 진단하세요. 절대 추측하지 마세요.
필수 선행 확인을 건너뛰기 — 진단(clean build, Simulator 재시작, Xcode 재시작)을 실행하기 전에 곧바로 코드 수정으로 뛰어들면 헛수고를 하게 됩니다. 항상 필수 확인부터 시작하세요.
한 번에 여러 가지를 변경하기 — "DerivedData도 삭제하고 Simulator도 재시작하고 Xcode도 종료해보자"는 식으로 하면 실제로 어떤 수정이 효과가 있었는지 구분할 수 없습니다. 한 번에 하나의 변수만 변경하세요.
원인을 안다고 가정하기 — "NavigationStack이 작동을 멈췄으니 내 reducer 문제일 것이다" — 실제로는 오래된 DerivedData가 원인이었습니다. 진단 트리는 이러한 가정을 방지합니다. 트리를 따르고, 추측하지 마세요.
메모리 기본 사항을 놓치기 — deinit이 호출되지 않는 것은 retain cycle이지만, 초보자들은 흔히 architecture를 탓합니다. 리팩터링 전에 Instruments로 leak을 확인하세요. 직관이 아니라 데이터입니다.
문제를 격리하지 않기 — 전체 앱으로 테스트하면 진단이 복잡해집니다. 문제가 되는 기능만 담은 최소한의 재현 가능한 예제를 만드세요. 격리를 통해 근본 원인이 드러납니다.
