Daily Learning Log (2026-07-13 ~ 07-19)

2026-07-13 (일)

학습 주제 — 빌드·링킹·렌더링 내부 동작

📄 빌드·링킹·렌더링 Q&A — 문서 링크
- 빌드 스크립트 타이밍: pre()=컴파일 전(R.swift), post()=링킹 후(dSYM 업로드)
- dSYM: 디버그 심볼 파일, 크래시 주소→소스 위치 변환(symbolication), UUID로 매칭
- 심볼 테이블 vs 디버그 심볼: 심볼 테이블은 함수→주소, DWARF는 +소스파일/줄번호/타입
- Static 링킹: .a는 .o 아카이브, 링커가 필요한 .o만 추출해 합침
- reduce vs reduce(into:): 결과 같음. reduce=복사, into=수정(inout). 컬렉션엔 into 효율적
- CAShapeLayer: 벡터 경로 레이어, strokeEnd 애니메이션, 확대해도 선명
- 래스터라이즈: 벡터→비트맵 변환, 픽셀마다 계산이라 무거움
- 렌더링 파이프라인: CAShapeLayer=Render Server가 래스터라이즈, draw()=메인스레드가 래스터라이즈
- frame.origin만 변경: 텍스처 재사용 (합성만). size 변경 시 다시 래스터라이즈
- Lottie 동작: JSON 파싱 → 레이어 트리 구축 → 프레임마다 키프레임 보간 → 레이어 속성 업데이트
- CALayer 상속: CAShapeLayer, CAGradientLayer, CATextLayer 등은 CALayer 서브클래스
- 레이어별 래스터라이즈: 벡터(CAShapeLayer)는 필요, 비트맵(CGImage)이나 빈 컨테이너는 불필요
- CGImage = 비트맵: layer.contents에 CGImage 있으면 래스터라이즈 없이 GPU 합성만

오답노트

CAShapeLayer가 메인스레드에서 그린다고 착각: 속성 설정만 메인스레드, 실제 래스터라이즈는 Render Server
frame 바꾸면 항상 텍스처 재생성?: origin만 바꾸면 재사용, size 바꿔야 재생성
Lottie가 JSON을 직접 넣는다고 착각: 키프레임 보간 후 적용. JSON 값 그대로 넣는 게 아님

2026-07-14 (화)

학습 주제 — CA 렌더링 심화 + 링킹(two-level namespace)

📄 렌더링 심화 — 빌드·링킹·렌더링 Q&A
- frame ≠ contents: frame=위치·크기, contents=그림(텍스처). 별개 속성. frame 바꿔도 contents 안 바뀜(액자 옮겨도 사진 그대로)
- 콘텐츠 생성 주체 3가지: draw(CoreGraphics)=CPU / 이미지 디코딩=CPU / CAShapeLayer·그라디언트=GPU 래스터화. 합성은 항상 GPU
- 래스터화 ≠ 디코딩: 래스터화=벡터→픽셀(GPU), 디코딩=압축이미지→픽셀(CPU). 이미지는 이미 래스터라 디코딩만
- 크기 변경 시 콘텐츠 재생성?: 기본 X — GPU가 기존 텍스처 스케일해 합성. contentMode=.redraw일 때만 draw 다시
- 회전(transform): frame은 바뀌나 bounds 불변 → layoutSubviews 안 됨. layout 트리거는 bounds.size
- draw: 메인스레드(CPU)가 CoreGraphics로 layer.contents(비트맵) 생성. 무거우면 렉
📄 링킹 심화 — 모듈화·빌드·링킹 Q&A
- 앱+dynamic B가 같은 static A 의존: A 2벌 로드되나 duplicate 에러 안 남. 진짜 문제는 싱글턴/전역 상태 별개
- two-level namespace: dyld가 (소속 이미지, 심볼 이름)으로 바인딩 → 앱/B가 각자 자기 A 참조
- 맹글링 이름 ≠ 소속 이미지: 맹글링 모듈명은 A(같음), 구분은 소속 이미지(앱 vs B). static은 흡수돼 이미지 갈림(2벌), dynamic이면 공유(1벌)

오답노트

frame 변경=contents 변경 착각: 별개. frame(위치·크기)만 바뀌고 contents(그림)는 그대로
이미지도 GPU 래스터화 착각: 이미지는 디코딩(CPU). 래스터화는 벡터(GPU)만
회전하면 layoutSubviews 착각: transform 회전은 bounds 불변 → layout 안 됨
맹글링 이름이 앱/B라 안 겹친다 착각: 맹글링 모듈명은 A(같음). 구분은 two-level 소속 이미지

2026-07-15 (화)

학습 주제 — Swift Concurrency Task Isolation 심화

📄 Swift Concurrency 마스터 로드맵 — 문서 링크
- async let / withTaskGroup: 자식 Task는 전역 executor에서 실행. @MainActor 함수에서 호출해도 await 전에 다른 스레드에서 시작됨
- Task { } vs Task.detached: Task는 caller의 actor 상속 (MainActor 유지), detached는 상속 없음
- SE-0461 (Swift 6.2): nonisolated async 함수가 caller의 actor를 상속하도록 변경. 이전(SE-0338)과 반대
- @concurrent: SE-0461 이후 명시적으로 전역 executor에서 실행하려면 @concurrent 사용
- @Sendable 클로저: 다른 isolation domain으로 보낼 때 필수. 캡처 값이 Sendable 아니면 외부 수정 시 data race 위험
- GlobalActor (@MainActor 등): 전역적으로 공유되는 단일 actor 인스턴스. 메서드·타입에 적용 가능
- AsyncSequence/AsyncStream: 시간에 따라 비동기로 값을 방출. 콜백 API를 async/await으로 변환할 때 사용
- withTaskGroup 에러 처리: throwing은 하나 실패 시 자동 취소, non-throwing은 수동으로 Result/Optional 처리
🔗 참고 링크: ChatGPT 대화 (SE-0461 상세)

오답노트

async let이 MainActor에서 실행된다고 착각: 자식 Task는 await 전에도 전역 executor에서 시작됨. MainActor 유지 안 됨
nonisolated async가 전역 executor라고 착각 (Swift 6.2): SE-0461 이후 caller 상속. @concurrent 써야 전역
@Sendable이 단순 타입 표시라고 착각: 캡처 값의 data race 방지가 핵심. non-Sendable 캡처 시 외부 수정 위험

2026-07-16 (목)

학습 주제 — GCD Barrier & Swift Concurrency 보강

📄 DispatchQueue Barrier 동작 원리
- Barrier 핵심: concurrent queue에서 읽기-쓰기 동기화. barrier 작업 중에는 해당 큐의 다른 모든 작업 대기
- Reader-Writer 패턴: 읽기=sync (동시 실행), 쓰기=async(flags: .barrier) (단독 실행)
- sync vs async: sync는 반환값 지원, async는 Void 반환. 결과 필요 없으면 async가 호출자 안 막아서 유리
- concurrent queue + sync: 여러 스레드가 동시에 sync 호출해도 동시 실행됨 (sync는 "내 블록 끝날 때까지 나를 기다려"일 뿐)
- 쓰기에 sync barrier?: 결과를 바로 사용할 게 아니면 불필요. async barrier로 충분
📄 Actor vs Concurrent+Barrier 비교
- Actor: serial executor라 읽기도 순차 실행 → 읽기 많으면 느림
- Concurrent+Barrier: 읽기 동시 실행 → 읽기 중심이면 빠름
- 결론: 대부분 actor로 충분. 읽기 성능 중요하면 barrier 패턴 고려
📄 Swift Concurrency 로드맵 — 문서 링크 (어제 내용 보강)
- withThrowingTaskGroup cooperative cancellation: 즉시 끝남이 아니라 취소 신호 → 완료 대기 → 에러 전파
📄 unowned vs weak — 비동기 콜백에서의 위험
- 문제 상황: VC→Player 소유, Player 콜백이 VC를 unowned 캡처. 네트워크 지연 시 VC 해제 후 콜백 실행 → 크래시
- 생존 체인: URLSession → completion(strong) → Player → onComplete → VC(unowned) 💥
- 해결책 1: onComplete에서 [weak self] (VC) — Player 작업은 완료, UI만 스킵
- 해결책 2: URLSession에서 [weak self] (Player) — 체인 전체 깔끔히 해제
- 핵심: unowned는 "얘가 나보다 먼저 죽을 일 없어"라는 확신 필요. 비동기 작업 끼면 weak가 안전

📄 Actor 내 Task { } isolation 상속과 실행 순서

actor ImageLoader {
    enum State {
        case progress(Task<UIImage, Never>)
        case complete(UIImage)
    }
    var cache: [String: State] = [:]

    func image(for url: String) async throws -> UIImage {
        if let state = cache[url] {
            switch state {
            case .progress(let task): return await task.value  // 기존 Task 대기
            case .complete(let image): return image
            }
        }

        let task = Task { await download(url: url) }  // ← 동기, 예약만
        cache[url] = .progress(task)                   // ← 동기, 바로 실행
        let result = await task.value                  // ← 여기서 suspend!
        cache[url] = .complete(result)
        return result
    }
}

Task { } 생성: 동기적으로 즉시 반환. caller suspend 안 함. Task는 "예약"만 됨
Actor 내 Task: actor isolation 상속 → actor가 비어야(await 만나야) Task body 시작
안전한 이유: let task = Task { }; cache[url] = .progress(task) 사이에 await 없음 → 원자적 실행
Class였다면?: Task가 global executor에서 병렬 실행 → cache 업데이트 전에 다운로드 완료 가능 → Data Race!
withCheckedContinuation과 비교: 둘 다 클로저/생성은 동기. 차이는 suspend 시점 (Task=안 함, continuation=클로저 후)

📄 Hit Testing & Responder Chain
- 이벤트 흐름: iOS → UIApplication → UIWindow → Hit Testing → 찾은 뷰부터 Responder Chain
- Hit Testing (위→아래): Window부터 재귀적으로 subview 탐색, 터치 지점의 가장 깊은 뷰 찾기
- Hit Test 통과 조건: isUserInteractionEnabled, !isHidden, alpha > 0.01 모두 만족해야 함
- subviews.reversed(): z-order 때문. 위에 그려진(나중에 추가된) 뷰부터 체크
- Responder Chain (아래→위): 찾은 뷰 → Superview → ... → ViewController → Window → Application → AppDelegate
- super.touchesBegan(): 호출하면 다음 responder로 전달, 안 하면 체인 끊김
- UIControl (Button 등): 터치를 target-action으로 변환하고 super 안 부름 → 체인 끊김

오답노트

unowned면 항상 안전하다고 착각: 비동기 작업(네트워크, 타이머)이 끼면 생존 순서 보장 안 됨. URLSession이 클로저 retain → Player 생존 → VC 해제 후 접근 → 크래시
Task { }가 바로 병렬 실행된다고 착각: Actor 내에서는 isolation 상속해서 actor가 비어야 실행. Class면 global executor에서 진짜 병렬 → 순서 보장 없음
Responder Chain이 위에서 시작한다고 착각: Hit Testing(위→아래)으로 뷰 찾고, 그 뷰부터 Responder Chain(아래→위) 시작
opaque(some View)는 호출부가 "프로토콜 타입"만 안다고 착각: 아니다. 구체 타입은 하나로 고정돼 있고 컴파일러는 정확히 안다 — 이름만 가려진 것. "프로토콜 타입만 안다"는 any View(existential) 설명. some은 identity 보존 + 정적 디스패치라 SwiftUI diffing이 가능

📘 복습 정리: SwiftUI some View 심화 — §8 opaque vs any 구분 · §9 방향/타입정체성/컴파일러/diffing/existential 박싱 · §10 프로토콜≠타입/정적디스패치/body재실행2층/identity=타입+위치/AnyView

2026-07-17 (금)

학습 주제 — SwiftUI 렌더링 내부: identity vs type vs struct

📄 대전제: identity는 "값"이 아니라 "위치"로 정해진다
- 저장/@State 값이 바뀌어도 identity는 그대로(그래서 상태가 살아남음)
- identity가 바뀌는 건 ① 위치 이동(if/else 분기) ② .id() 변경 ③ ForEach 요소 id 변경
📄 property wrapper의 getter "훅킹"
- count 읽기 = State<Int>.wrappedValue getter 호출 → 그 안에 "이 뷰가 count에 의존" 등록 코드가 얹혀 있음(의존성 추적)
📄 노드 vs struct — 헷갈림의 근원
- struct 값 = 매 업데이트 재생성되는 일회용 설계도(쌈). identity 노드/트리 = 그래프 스토리지에 지속되는 실체
- 상태값만 바뀌면 노드 파괴 X → in-place 갱신. 노드 파괴는 identity/type 바뀔 때만
- identity 노드 ≠ identity 트리(노드는 트리의 한 점)
📄 소유 vs 참조
- 노드가 소유(source of truth): @State·@StateObject·@GestureState
- 참조만: @Binding(포인터)·@ObservedObject(관찰만)·@Environment(읽기만)
- 일반 저장 프로퍼티(var k=0)는 그래프 스토리지에 안 남음 — struct와 함께 재생성, 부모가 매번 넘겨주는 입력
📄 body 재호출 기준 & 상태 끌어올리기
- body 재호출 기준 = "입력 값이 직전과 달라졌나"(@State/일반 무관). 같으면 스킵
- ProgressView↔Text 토글 = 타입 변경 → identity 변경 → 서브트리 통째 파괴·재생성
- state lifting: Parent가 @State count 소유, 자식은 @Binding 참조 → 자식 노드가 파괴·생성돼도 원본은 안정적 상위에 있어 보존(자식 노드끼리 같아서가 아님)
- 번외: class의 private func=정적 디스패치, private let=디스패치 아닌 직접 오프셋 접근

오답노트

❌ "identity는 내부 프로퍼티(값)가 바뀌면 바뀐다" → 아니다. identity는 위치로 정해지고, 값 변화는 body 재호출만 유발
❌ "if/else의 두 CounterView는 결과가 같으니 같은 뷰" → 코드 구조상 분기 슬롯 2개라 identity A/B로 다름 → 토글 시 @State 리셋
❌ "state lifting에서 ChildView·OtherView의 identity 노드가 같다" → 다르다(둘 다 파괴·생성). count 보존은 원본을 Parent 노드가 소유해서
❌ "@State 아닌 일반 프로퍼티가 바뀌면 body 재호출 안 한다" → 값이 달라지면 @State든 일반이든 재호출
❌ "노드 파괴·재생성 = struct 재생성과 같은 것" → struct는 늘 재생성(값), 노드는 identity/type 바뀔 때만 파괴
❌ "ForEach는 인덱스를 id로 써도 됨" → 자리 바꾸면 상태가 항목이 아니라 자리에 눌러앉아 꼬임. 고유·안정 id(UUID) 써야 상태가 항목 따라감
❌ "일반 변수도 사용(read)할 때만 body 재호출" → 부모 주입 프로퍼티는 값이 다르면 안 써도 재호출(.equatable()로만 최적화). "사용할 때만"은 @State 의존성 추적에만 해당
❌ "@State 아닌 일반 프로퍼티도 런타임에 변경 가능" → View는 불변 값 타입, self 못 바꿈(컴파일 에러). 변경하려면 @State여야 함
❌ "바인딩으로 받은 상태도 if/else면 사라진다" → 상태는 소유자(부모) 노드에 저장. 부모는 안 죽으니 유지. 자식은 참조(포인터)만이라 자식이 죽어도 원본 멀쩡 = state lifting 원리

📘 복습 정리: SwiftUI some View 심화 — §11 identity vs type vs struct / 훅킹 / 백킹스토어 / 소유 vs 참조 / 상태 끌어올리기 / private func·let 디스패치 · §12 ForEach id / State 박스 재연결 / body 재호출 트리거(의존성추적 vs 주입) / 모디파이어 래퍼타입 / state lifting 오해 교정

2026-07-18 (토)

학습 주제 — SwiftUI 렌더링 내부 정리·정정 (등록 타이밍/인과관계)

📄 의존성 등록 타이밍(핵심)
- 등록은 body 평가 중 getter가 호출되는 순간. identity 생성 때(X)·쓰기 때(X, 쓰기는 무효화 트리거)가 아님
- 등록은 매 body 평가마다 지웠다 다시 그림 → "이번 body에서 실제 읽은 것"만 구독
- 저장 위치: SwiftUI 내부 의존성 그래프(attribute graph). struct가 아님
📄 body ↔ struct 인과
- body 호출 ⟹ 자식 struct 재생성(참). struct 재생성 ⟹ body 호출(거짓, diff 스킵 가능)
- body는 "자식"을 만듦. 자기 자신 struct는 부모 body가 만든 것
- body=설계도 생성, 실제 픽셀은 별도 렌더 층(분리)
📄 body 재호출 순서: struct 생성 → 필드/상태 diff(부모 주입값+자신 @State) → 달라졌으면 body 호출
📄 일반 프로퍼티 참조타입 함정: let vm = MyClass()는 vm 내부 변경 가능하나 SwiftUI가 모름 → UI 갱신 X → @StateObject/@Observable 필요
📄 ForEach "상태가 항목을 따라감": 안정적 id면 @State가 자리가 아닌 항목(id)에 붙어 정렬해도 따라감. ModifiedContent도 View 준수

추가 학습 — 메모리·런타임·동시성 학습노트 정리(관련 기존 문서에 분산 반영)

📄 class vs struct 선택 기준 / struct 안 class 공유 함정 → 값/참조 메모리 처리 문서
- 값/참조 의미론 + identity 기준. struct 복사해도 내부 class는 주소만 복사 → 공유(값 의미론 깨짐)
📄 retain cycle 진단 / weak vs unowned / 순환참조 아닌 누수 → ARC 생명주기 문서
- 비동기 콜백엔 weak 기본(unowned는 해제 후 접근 크래시). Timer/Notification/DispatchWorkItem은 weak self와 별개로 invalidate/remove/cancel 필요
📄 스택/힙 · CPU 레지스터·캐시 · main() → 메모리·스택 심화 문서
- 스택 할당=SP 이동 명령 하나(공짜), 힙=탐색+락+ARC+캐시미스. 스택은 아래로 자람(SP=낮은주소). L1 코어전용/L3 공유. main()은 pre-main(dyld) 후 RunLoop
📄 스레드 컨텍스트 스위칭 vs suspend / continuation / executor → Swift Concurrency 심화 문서
- suspend는 스레드 전환 아님(같은 스레드+다른 task). continuation=재개지점+살아남는 지역변수를 힙에, executor가 job을 스레드에 배정. leaf 하나만 resume하면 리턴 사슬로 자동 cascade

오답노트

❌ "의존성 등록은 identity 생성 때 or 쓰기 때 한다" → body 평가 중 getter 읽는 순간. 쓰기는 등록이 아니라 무효화 트리거
❌ "body 재실행되면 자기 자신 struct도 재생성" → 자식만. 자기 struct는 부모 body가 만듦
❌ "struct 재생성되면 항상 body 호출" → 값 같으면 diff로 스킵
❌ "일반 프로퍼티가 참조타입이면 내부 바꿔서 UI 갱신 가능" → SwiftUI가 변화 모름. 상태 래퍼(@StateObject/@Observable) 필요
❌ "ForEach는 인덱스를 id로 써도 됨" → 삽입/삭제/정렬 시 상태가 엉뚱한 항목에 달라붙음. Identifiable+UUID 써야
❌ "자신의 @State가 변하면 자기 struct도 재생성" → 아니다. 부모가 다시 만들 때만 재construct. 자기 @State 변화는 기존 struct로 body만 재실행
❌ "부모 @State가 변하면 부모 body가 돈다" → 아니다. 그 값을 읽은(wrappedValue) 뷰만 돈다. $count를 넘기는 것(projectedValue)은 읽기가 아님 → 아무도 count를 안 읽으면 박스 값만 갱신되고 화면 그대로

📘 복습 정리: SwiftUI some View 심화 — §13 등록 타이밍(body 평가 중 getter) / body↔struct 인과 / body 재호출 순서 / 일반 프로퍼티 참조타입 함정 / 의존성 그래프 저장 위치 · §14 인덱스 id 함정 / diff 순서 / 자기 @State와 struct / 바인딩 전달≠읽기 · §15 @State/@StateObject/@ObservedObject/@Observable 차이(소유 vs 관찰, 신형 정밀추적) · §16 후속(박스=힙 / 생명주기 소유 / coarse vs fine / @Bindable) · §17 확인(래퍼vs매크로vs프로토콜 분류 / @StateObject엔 @Observable 못넣음 / var·let 규칙 / iOS17 Observation 답변 프레이밍)

2026-07-18 (토) — iOS 웹뷰 학습 시작

학습 주제 — WKWebView 기본 & 아키텍처 (Tier 1 ①)

📄 iOS 웹뷰 학습 로드맵 문서 신설 → iOS 웹뷰(WKWebView) 학습 (Tier1~3, 한 주제씩 누적)
📄 WKWebView 아키텍처
- UIWebView(사용 금지, 앱 프로세스 렌더·JIT 없음) vs WKWebView(별도 프로세스·Nitro JIT)
- 멀티 프로세스: App / WebContent(렌더·JS) / Networking / GPU → 크래시 격리·메모리 격리·JIT로 빠른 JS
- 모든 앱↔웹 통신이 프로세스 경계 넘는 IPC라 비동기(evaluateJavaScript가 async인 이유)
- WKWebViewConfiguration은 생성 시점에만 적용(만든 뒤 변경 무효)
- 같은 WKWebsiteDataStore 공유=세션 공유, .nonPersistent()=시크릿

오답노트

❌ "웹뷰 렌더링도 앱 프로세스에서 돈다" → WKWebView는 WebContent 별도 프로세스. 그래서 웹 크래시가 앱을 안 죽임
❌ "웹뷰 만든 뒤 configuration 바꾸면 반영됨" → 생성 시점에만 적용. 설정은 생성 전에 끝내야 함
❌ "evaluateJavaScript는 바로 값 반환" → 프로세스 경계 IPC라 비동기(completion/async)
❌ "JIT는 어느 프로세스나 됨" → iOS W^X 정책상 앱 프로세스는 JIT 금지, WebContent만 특별 엔타이틀먼트로 허용
❌ "allowsContentJavaScript는 브리지 스크립트 얘기" → 페이지 자체 JS 실행 허용 축. 브리지 주입/evaluateJavaScript와 별개

📘 §1 후속 Q&A 8문항 정리됨(멀티프로세스 담당/JIT 원리/Configuration 클래스/JS 허용/websiteDataStore/세션 공유/영구저장 예시/IPC 비동기) → 웹뷰 학습 문서 §1

2026-07-18 (토) — 이미지 메모리·디코딩·캐싱 학습노트 정리

학습 주제 — 이미지 디코딩·다운샘플·캐싱·네트워크 심화

📄 이미지 메모리 심화 → 대형 이미지 메모리 문서 §학습노트
- 파일크기≠메모리: 압축(작음) vs 디코딩(픽셀W×H×4). 4000×3000 → 48MB
- point/pixel: scale은 pt→px 변환에만(원본 픽셀에 또 곱하면 중복). 뷰 축소해도 디코딩 메모리 안 줆
- Downsampling: ImageIO로 처음부터 작게 디코딩(피크 없음) ≠ 풀디코딩 후 축소
- 디코딩 시점(lazy·렌더 시 메인) vs 스레드: 옵션=타이밍, 큐=스레드(별개). 메인 디코딩=UI 전체 hitch
- 2단 캐시: 메모리(디코딩 UIImage)/디스크(압축 Data). NSCache(자동 방출·스레드안전·용량). 캐시키에 크기 포함
- URLCache=네트워크만 절감(디코딩 매번). ETag 재검증(304)·불변 URL로 stale 해결
- 셀 재사용: Task 취소 + isCancelled/URL identity 이중 확인. session.data throw vs checkCancellation은 다른 시간창
- ShouldCache=false(다운샘플 피크 절약, source 수명만)/true(반복 접근 재사용). dataTask vs downloadTask(디스크 스트리밍)

오답노트

❌ "뷰(frame) 작게 하면 이미지 메모리 줆" → UIImage→CGImage→디코딩버퍼 참조는 그대로. 표시만 축소. downsample 필요
❌ "원본 픽셀 크기에 scale 곱함" → 중복. scale은 pt→px에서만
❌ "ShouldCacheImmediately:true면 백그라운드 디코딩" → 시점만 제어, 스레드는 큐가 결정
❌ "URLCache 있으면 디코딩도 아낌" → 네트워크만. 디코딩은 별도 메모리 캐시 필요(층 다름)
❌ "네트워크 중 취소는 checkCancellation이 잡음" → session.data가 throw. checkCancellation은 완료~디코딩 전 틈 담당

2026-07-19 (일) — 웹뷰 Tier 1 ②

학습 주제 — WKNavigationDelegate (네비게이션 제어)

📄 네비게이션 제어 → 웹뷰 학습 문서 §2
- decidePolicyFor navigationAction(요청 전, .allow/.cancel/.download) = URL 가로채기 핵심 → 커스텀 스킴·딥링크·tel/mailto 외부 앱 분기
- navigationResponse(응답 후, 상태코드·MIME 기반). action=나가기 전, response=받은 후
- WKNavigationAction: navigationType(.linkActivated=클릭/.other=JS)·targetFrame(nil=새 창)
- 생명주기: didStartProvisional → didCommit → didFinish. 실패=대부분 didFailProvisionalNavigation(커밋 전)
- 뒤로가기: allowsBackForwardNavigationGestures·canGoBack/goBack, 네이티브 통합(웹 히스토리 먼저)

오답노트

❌ "navigationAction과 navigationResponse는 같은 시점" → action=요청 나가기 전, response=응답 받은 후
❌ "로딩 실패는 didFail" → 대부분 커밋 전 실패라 didFailProvisionalNavigation. didFail은 커밋 후(드묾)
❌ "새 창 열기도 NavigationDelegate에서" → 새 창은 WKUIDelegate(§4). targetFrame nil로 감지만
❌ "didCommit = 로드 완료" → 본문 도착 시작+표시 확정(옛 페이지 교체 시작). 완료는 didFinish
❌ "decisionHandler 안 불러도 됨" → 반드시 1회 호출, 안 부르면 웹뷰 멈춤
❌ "네비게이션은 사용자 클릭으로만" → JS가 location.href로 프로그램 이동 가능(.other). navigationType으로 구분

📘 §2 후속 Q&A 12문항 정리됨(앱 프로세스 판단·decisionHandler·navigationResponse·provisional/commit 의미·리다이렉트 조건·커밋 후 실패·JS 프로그램 이동·체크질문 답) → 웹뷰 §2

📘 §2 실전 후속: 리다이렉트 콜백 파라미터(WKNavigation만)·navigationResponse=헤더만·didCommit 역할·.download 전환(WKDownloadDelegate, iOS14.5+)·iOS14 blob 다운로드 우회(JS FileReader→base64→postMessage→네이티브 저장) → 웹뷰 §2

2026-07-19 (일) — 웹뷰 Tier 1 ③

학습 주제 — JS ↔ Native 브리지

📄 JS ↔ Native 브리지 → 웹뷰 학습 문서 §3
- JS→Native: WKScriptMessageHandler + postMessage(채널 이름). message.body 타입 브리징(NSNumber/NSString/NSDictionary/NSArray/NSNull), JSON 딕셔너리만
- Native→JS: evaluateJavaScript(IPC 비동기), callAsyncJavaScript(iOS14+ arguments 안전 전달)
- WKUserScript 주입: .atDocumentStart(페이지 스크립트보다 먼저)/.atDocumentEnd(DOM 후), forMainFrameOnly
- 양방향: WKScriptMessageHandlerWithReply(iOS14+ Promise) / callbackId + evaluateJavaScript
- 보안: 핸들러가 iframe 포함 모든 콘텐츠에 노출 → forMainFrameOnly·origin 검증·App-Bound Domains

오답노트

❌ "add(self, name:)는 그냥 등록" → ContentController가 self를 강하게 잡아 retain cycle → VC deinit 안 됨. WeakScriptMessageHandler 래퍼 + deinit에서 removeScriptMessageHandler 필수
❌ "evaluateJavaScript에 문자열 조합으로 값 넣기" → injection 위험. callAsyncJavaScript arguments로 안전 전달
❌ "message.body로 커스텀 타입 전달" → JSON 직렬화 가능 타입만(NSDictionary 등)
❌ "removeScriptMessageHandler 안 해도 됨" → 잔존/같은 이름 재등록 시 크래시(NSInvalidArgumentException)

2026-07-19 (일) — 웹뷰 Tier 1 ④

학습 주제 — WKUIDelegate (JS 대화상자·새 창·파일 선택)

📄 WKUIDelegate → 웹뷰 학습 문서 §4
- JS alert/confirm/prompt는 기본으로 안 뜸 → runJavaScript*Panel 구현해 네이티브 얼럿으로. completionHandler(())/Bool/String? 필수
- 새 창(target="_blank"·window.open): createWebViewWith → (A)같은 웹뷰 load+return nil (B)팝업 생성(넘어온 configuration 필수)+return popup
- webViewDidClose(window.close), 파일 업로드는 iOS 자동, 미디어 권한 requestMediaCapturePermissionFor(15+)

오답노트

❌ "JS alert은 자동으로 뜬다" → WKWebView는 안 띄움. WKUIDelegate 구현 안 하면 무시
❌ "completionHandler 안 불러도 됨" → JS가 그 자리에서 영원히 멈춤(alert 동기 API)
❌ "팝업 만들 때 새 configuration으로" → 넘어온 configuration 써야 세션·프로세스 유지. return popup만(내가 load하면 이중)
❌ "새 창은 NavigationDelegate에서 연다" → 감지만 거기(targetFrame nil), 실제 생성은 createWebViewWith(UIDelegate)

2026-07-19 (일) — 웹뷰 Tier 2 ⑤

학습 주제 — 쿠키·세션 공유 (WKHTTPCookieStore)

📄 쿠키·세션 공유 → 웹뷰 학습 문서 §5
- 웹뷰 쿠키 저장소(WKWebsiteDataStore.httpCookieStore)는 URLSession(HTTPCookieStorage)과 분리 → 네이티브 로그인해도 웹뷰 로그아웃
- WKHTTPCookieStore.setCookie로 주입(비동기). 주입 완료 후 load(타이밍 함정, DispatchGroup)
- document.cookie는 HttpOnly 못 넣음 → WKHTTPCookieStore가 정석. URLRequest 헤더는 그 요청 1번만
- 웹→네이티브: WKHTTPCookieStoreObserver. 같은 dataStore 공유 = 여러 웹뷰 세션 공유

오답노트

❌ "네이티브 로그인하면 웹뷰도 자동 로그인" → 쿠키 저장소 분리. WKHTTPCookieStore로 주입 필요
❌ "쿠키 주입하고 바로 load" → setCookie 비동기라 첫 요청에 쿠키 누락. completion에서 load
❌ "document.cookie로 세션 쿠키 주입" → HttpOnly는 JS 접근 불가

2026-07-19 (일) — 웹뷰 Tier 3 ⑨

학습 주제 — 웹뷰 성능

📄 웹뷰 성능 → 웹뷰 학습 문서 §9
- 3가지 병목: ① 프로세스 cold start ② 네트워크 ③ 파싱·실행·렌더. 측정 먼저(estimatedProgress·performance.timing·os_signpost)
- cold start 해결(임팩트 최대): 프리워밍(about:blank 미리 로드)·재사용 풀·processPool 공유
- 네트워크: 캐시(WKWebsiteDataStore·URLCache)·프리페치·페이로드 축소·WKContentRuleList 차단
- 체감: 네이티브 셸/스켈레톤 먼저·진행바. 프로세스 종료 시 reload 복구

오답노트

❌ "웹뷰 느리면 그냥 캐시" → 병목이 cold start/네트워크/렌더 중 어디인지 측정 먼저. cold start면 프리워밍이 임팩트 최대
❌ "프리워밍=미리 데이터 받기" → 웹뷰 미리 생성+about:blank로 WebContent 프로세스를 앞당겨 기동하는 것
❌ "실측만 중요" → 체감(네이티브 셸/스켈레톤)도 실측만큼 중요

2026-07-19 (일) — 스크롤 hitch

학습 주제 — 스크롤 끊김(hitch) 원인과 해결

📄 스크롤 hitch → 스크롤/테이블/컬렉션뷰 문서 §12
- hitch = 프레임 예산(60fps 16.67ms / 120fps 8.33ms) 초과 → 프레임 드롭
- 스크롤은 메인 스레드에서 돎 → 프레임마다 메인 작업(Layout·Display)이 예산 넘으면 끊김
- 주범 5: 동기 이미지 디코딩·오토레이아웃·오프스크린 렌더링(cornerRadius+masksToBounds·shadow)·블렌딩·무거운 셀 구성
- 해결: 백그라운드 디코딩+다운샘플, 높이 캐싱, shadowPath·미리 둥근 이미지, isOpaque 블렌딩 감소, prefetch
- 측정: Instruments Core Animation(Offscreen 노랑/Blended 빨강)·Time Profiler·Animation Hitches

오답노트

❌ "스크롤 끊김은 GPU 문제" → 주로 메인 스레드 작업이 프레임 예산 초과. 스크롤이 메인에서 돎
❌ "cornerRadius는 공짜" → masksToBounds/콘텐츠와 함께면 오프스크린 렌더링 유발. shadow도 shadowPath 없으면 매 프레임 오프스크린
❌ "이미지 늦게 뜨는 건 어쩔 수 없음" → 메인 동기 디코딩이 원인. 백그라운드 디코딩+다운샘플로 해결(이미지 노트 연결)