Description
Cloud Firestore native SDK fails with EHOSTUNREACH on physical iPhone while REST and Simulator succeed
Environment
- Firebase Apple SDK: 12.17.0 (revision
33a468adfdb75b53f05a37e7c886ca7c962b5c17)
- gRPC (grpc-binary): 1.69.1
- Installation method: Swift Package Manager
- Affected platform: physical iPhone 14 (iPhone14,7), iOS 26.6 (build 23G71)
- Xcode: 26.6 (build 17F113)
- Swift: 6.3.3 (swiftlang-6.3.3.1.3 clang-2100.1.1.101)
- macOS (development machine): 26.5.2 (build 25F84)
- 12.17.0 was confirmed to be the latest stable release on the GitHub Releases page at the time of writing.
Problem
On one physical iPhone, the native Firestore SDK cannot complete a server read: every
attempt fails with FIRFirestoreErrorDomain code 14 (UNAVAILABLE). Enabling gRPC's own
transport-level debug logging shows the underlying cause is EHOSTUNREACH ("No route to
host") when gRPC's C-core attempts a raw socket connection to Firestore's resolved
addresses -- for both IPv4 and IPv6.
On the same device, at the same time:
- A plain
URLSession HTTPS request to firestore.googleapis.com succeeds.
- The equivalent read performed against Firestore's REST API (over
URLSession, not
gRPC) succeeds with HTTP 200.
- Firebase Auth's own network calls (token refresh) succeed.
The identical native-SDK query succeeds on the iOS Simulator, on the same Mac, on the
same Wi-Fi network, against the same Firebase project.
Minimal reproduction
A throwaway SwiftUI app containing only FirebaseCore and FirebaseFirestore (no
Firebase Auth, no Messaging, no Storage, no App Check, no custom AppDelegate, no
third-party dependencies, no FirestoreSettings overrides, no emulator host) reproduces
the failure. This strongly indicates the failure is independent of the larger production app's
architecture, dependency injection, and launch sequence.
import SwiftUI
import FirebaseCore
import FirebaseFirestore
@main
struct ProbeApp: App {
init() { FirebaseApp.configure() }
var body: some Scene { WindowGroup { ContentView() } }
}
struct ContentView: View {
var body: some View {
Text("Firestore Transport Probe")
.task {
do {
let snapshot = try await Firestore.firestore()
.collection("public_collection")
.limit(to: 1)
.getDocuments(source: .server)
print("SUCCESS, documents: \(snapshot.documents.count)")
} catch {
let e = error as NSError
print("FAILURE domain=\(e.domain) code=\(e.code)")
}
}
}
}
### Reproducing the issue
Always / 100%
### Firebase SDK Version
12.17.0
### Xcode Version
26.6 (build 17F113)
### Installation Method
Swift Package Manager
### Firebase Product(s)
Firestore
### Targeted Platforms
iOS
### Relevant Log Output
```shell
If using Swift Package Manager, the project's Package.resolved
No response
If using CocoaPods, the project's Podfile.lock
No response
Description
Cloud Firestore native SDK fails with EHOSTUNREACH on physical iPhone while REST and Simulator succeed
Environment
33a468adfdb75b53f05a37e7c886ca7c962b5c17)Problem
On one physical iPhone, the native Firestore SDK cannot complete a server read: every
attempt fails with
FIRFirestoreErrorDomaincode 14 (UNAVAILABLE). Enabling gRPC's owntransport-level debug logging shows the underlying cause is
EHOSTUNREACH("No route tohost") when gRPC's C-core attempts a raw socket connection to Firestore's resolved
addresses -- for both IPv4 and IPv6.
On the same device, at the same time:
URLSessionHTTPS request tofirestore.googleapis.comsucceeds.URLSession, notgRPC) succeeds with HTTP 200.
The identical native-SDK query succeeds on the iOS Simulator, on the same Mac, on the
same Wi-Fi network, against the same Firebase project.
Minimal reproduction
A throwaway SwiftUI app containing only
FirebaseCoreandFirebaseFirestore(noFirebase Auth, no Messaging, no Storage, no App Check, no custom
AppDelegate, nothird-party dependencies, no
FirestoreSettingsoverrides, no emulator host) reproducesthe failure. This strongly indicates the failure is independent of the larger production app's
architecture, dependency injection, and launch sequence.
If using Swift Package Manager, the project's Package.resolved
No response
If using CocoaPods, the project's Podfile.lock
No response