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）。しかし、Firebase iOS SDKの Functions.swift 内のパーサーは 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クライアントとWeb 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 をスローし、try! によってプロセスがクラッシュします。AnyCodableValue.init(from:) はすべての JSON 文字列に対して最初に Timestamp としてのデコードを試みるため、このような値を保持する GraphQL の String や Any/JSON フィールドはすべてクラッシュを引き起こします。これには初回フェッチ時のクライアントキャッシュのデハイドレーションも含まれ、そのためそのクエリを実行するたびに再発します。修正方法: CodableTimestamp.swift (約 61〜62 行目) で、init(from:) 内の try! を try に置き換えます。このイニシャライザはすでに throws しているため、AnyCodableValue は既存の try? を通じて .string にフォールバックし、実際の Timestamp としてデコードする場合は DataConnectCodecError がスローされます。テスト付きの 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 以降にアップグレードしてください。修正（クロージャではなくオブザーバーハンドルを格納する変更）がマージされています。

**旧バージョンでの回避策:** 保持されたクロージャが他のオブジェクトを生き続けさせないよう、リスナークロージャ内で状態を弱参照でキャプチャしてください:

let handle = Auth.auth().addStateDidChangeListener { [weak self] _, user in
    guard let self = self else { return }
    // 認証状態の変化を処理する
}

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 /* reject or transform */ }
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)