firebase-ios-sdk

이 크래시(+[GULNetworkURLSession setSessionInFetcherMap:forSessionID:]에서 호출된 -[NSConcreteMapTable setObject:forKey:]에서 발생하는 EXC_BAD_ACCESS / KERN_INVALID_ADDRESS)는 GoogleUtilities 8.1.0 및 이전 버전의 알려진 버그입니다(GoogleUtilities#228로 추적됨). 이 버그는 GoogleUtilities 8.1.1에서 수정되었으며, 8.1.5까지 추가적인 보강이 이루어졌습니다. Firebase 12.14.0은 GoogleUtilities ~> 8.1만 요구하기 때문에, CocoaPods가 Podfile.lock에 8.1.0을 고정해 둘 수 있습니다. Podfile.lock에서 GoogleUtilities 버전을 확인한 후 pod update GoogleUtilities를 실행하여 8.1.1 이상(8.1.5 권장)을 가져오고 다시 빌드하세요.

이 오류는 스트리밍 callable 함수가 30초 이상 유휴 상태로 유지될 때 발생합니다. firebase-functions(v7.x)는 30초간 비활성 상태가 지속되면 하트비트로 SSE 주석 라인(: ping)을 전송하지만(기본값 heartbeatSeconds: 30), Functions.swift에 있는 Firebase iOS SDK의 파서는 data:로 시작하는 라인만 허용하고 그 외의 모든 라인에 대해 FunctionsError(.dataLoss)를 발생시킵니다.

우회 방법: Cloud Function의 CallableOptions에서 하트비트를 비활성화하거나 값을 늘리세요:

import { onCall } from 'firebase-functions/v2/https';

export const slow = onCall({ heartbeatSeconds: null }, async (req, res) => {
  await new Promise((r) => setTimeout(r, 40_000));
  res.sendChunk('hello');
  return 'done';
});

또는 heartbeatSeconds를 함수의 예상 최대 유휴 시간보다 큰 값으로 설정하세요(예: heartbeatSeconds: 60). 참고: 하트비트를 비활성화하면 중간 프록시나 로드 밸런서가 장시간 유휴 상태인 연결을 닫을 수 있습니다. Node 클라이언트와 웹 SDK는 : ping 주석을 올바르게 처리합니다. 근본적인 해결을 위해서는 iOS SDK가 SSE 명세에 따라 SSE 주석 라인을 건너뛰어야 합니다.

FirebaseDataConnect(11.12.6 이하 버전, main @ be6a46f 포함)에서 Timestamp.init(from:)은 값 범위가 아닌 형식(^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}...)만 확인하는 정규식으로 문자열을 검증한 후, try! Google_Protobuf_Timestamp(jsonString:)을 강제로 시도합니다. 형식과 일치하지만 범위를 벗어난 문자열 — 예: "2026-13-01T00:00:00Z"(월 13), "2026-01-01T24:00:00Z"(시 24), "0000-01-01T00:00:00Z"(연도 0) — 는 정규식을 통과하지만 SwiftProtobuf.JSONDecodingError.malformedTimestamp를 throw하고, try!이 프로세스를 크래시시킵니다. AnyCodableValue.init(from:)이 모든 JSON 문자열에 대해 Timestamp를 가장 먼저 시도하기 때문에, 이러한 값을 담고 있는 GraphQL String 또는 Any/JSON 필드는 모두 크래시를 유발합니다 — 첫 번째 fetch 시 클라이언트 캐시 복원(dehydration) 중에도 발생하므로 해당 쿼리를 실행할 때마다 재발합니다. 수정 방법: CodableTimestamp.swift(약 61~62번째 줄)에서 init(from:) 내의 try!를 try로 교체하세요 — 이니셜라이저는 이미 throws이므로, AnyCodableValue는 기존의 try?를 통해 .string으로 폴백하고, 실제 Timestamp로 디코딩하는 경우에는 DataConnectCodecError를 throw합니다. 테스트가 포함된 PR이 firebase/data-connect-ios-sdk#123에 열려 있습니다. 머지되어 릴리스되면 SDK를 업데이트하세요. 그 전까지는 범위를 벗어난 날짜 형태의 값이 타임스탬프 정규식과 절대 일치하지 않도록 데이터를 정제하고(예: 저장 형식 변경), 클라이언트 캐시를 비활성화해도 Any/JSON 필드에서의 크래시를 완전히 피할 수 없다는 점에 유의하세요.

이것은 Firebase iOS SDK 버전 11.0.0부터 13.1.0까지에 존재하는 알려진 버그입니다(Auth의 Swift 재작성으로 인한 리그레션입니다). addIDTokenDidChangeListener(_:)는 리스너 클로저를 listenerHandles에 저장하지만, removeStateDidChangeListener(_:), removeIDTokenDidChangeListener(_:) 및 deinit은 해당 배열에서 옵저버 *핸들*을 제거하려고 시도합니다. 핸들이 저장된 클로저와 절대 일치하지 않기 때문에 제거는 아무 동작도 하지 않는 작업(no-op)이 됩니다. 추가한 모든 리스너(그리고 리스너가 캡처하는 모든 것)는 Auth 인스턴스의 수명 동안 계속 살아 있으며, Auth.auth()의 경우 이는 앱 세션 전체에 해당합니다. 리스너를 반복적으로 추가/제거하면(예: 화면 단위 또는 리액티브 구독 단위로) 메모리가 무제한으로 누수됩니다.

**해결 방법:** 수정 사항(클로저 대신 옵저버 핸들을 저장하는 방식)이 병합된 Firebase iOS SDK 13.2.0 이상으로 업그레이드하세요.

**이전 버전용 우회 방법:** 유지되는 클로저가 다른 객체를 살아 있게 만들지 않도록 리스너 클로저 내부에서 상태를 약하게(weakly) 캡처하세요:

let handle = Auth.auth().addStateDidChangeListener { [weak self] _, user in
    guard let self = self else { return }
    // handle auth state change
}

Firestore는 Objective-C에서 문서 경로를 검증하며 NSException(FIRInvalidArgumentException)을 발생시키는데, Swift의 do-catch로는 이를 가로챌 수 없습니다. 따라서 잘못된 입력이 들어오면 앱이 항상 크래시됩니다. 유일하게 신뢰할 수 있는 해결책은 document(id)를 호출하기 전에 ID를 직접 검증/정제하는 것입니다. 문서 ID는 /를 포함해서는 안 되고, .이나 ..이어서는 안 되며, 비어 있지 않아야 하고, 1500바이트 이하여야 합니다.

먼저 검증하세요:

func isValidDocumentID(_ id: String) -> Bool {
    return !id.isEmpty
        && !id.contains("/")
        && id != "." && id != ".."
        && id.utf8.count <= 1500
}

guard isValidDocumentID(id) else { return /* 거부 또는 변환 */ }
let docRef = db.collection(recipeShareCollection).document(id)

URL에 더 나은 접근 방식: 원시 URL을 문서 ID로 사용하지 마세요. 대신 해시하세요:

import CryptoKit
let docID = SHA256.hash(data: Data(urlString.utf8))
    .map { String(format: "%02x", $0) }.joined()
let docRef = db.collection(recipeShareCollection).document(docID)