PRpranshuchittora·Sep 29, 2026
In Firebase SDK is crashing all iOS apps since this morningfirebase
firebase-ios-sdk
C++2019–2026
firebase / firebase-ios-sdk
firebase-ios-sdk
Firebase SDK for Apple App Development
Data & DatabasesSecurity & PrivacyAI & Machine LearningMobile & DesktopCommunication & SocialLibraries & SDKs
8Distinct people
10Mentions
0Explicit recommenders
7KGitHub stars
What to know before exploring
What it is
Firebase SDK for Apple App Development
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year10 dated mentions
Observed mentions: 2019-01-31 18:17:14 UTC to 2026-09-29 08:30:36 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 2 | 2 |
What Hacker News says
10 sourcesThey've acknowledged the issue now: https://github.com/firebase/firebase-ios-sdk/issues/16728#is...
Absolutely wild that such a widespread SDK could crash everyone with a serverside change.
In Tell HN: Firebase service causing iOS crashes across many appsFirebase reporting crashes due to Firebase
4 points · Open discussionTell HN: Firebase service causing iOS crashes across many apps
See: https://github.com/firebase/firebase-ios-sdk/issues/16728
Seems like a server-side change.
7 points · Open discussionThanks for the positive words! Any limitations in the transpiler (such as some advanced generics) will only be limitations on the Android side – the iOS side can still do anything that is support in Swift. We discuss this a bit at https://skip.tools/docs/platformcustomization/
> Also, using SwiftUI cross-platform makes me think that many android libraries would be a no-go.
A unique feature of Skip is that the Kotlin/Android side is free to integrate with whatever gradle libraries it wants (see https://skip.tools/docs/dependencies/). Similarly, the Swift side can have any SwiftPM dependencies it wants.
Only your own transpiled modules, and the core Skip modules, will need to support transpilation. You can then include any native dependencies via your app's transpiled code that branches based on which platform/language you are targeting. So
Read the rest
, for example, the Swift/SwiftUI side of the project can depend on the SwiftPM "https://github.com/firebase/firebase-ios-sdk.git" dependency, and the Kotlin/Compose side can depend on the Gradle "com.google.firebase:firebase-bom" dependency. This is what we ourselves do in the various integration modules we have (such as SkipFirebase, for this particular example).
https://github.com/firebase/firebase-ios-sdk/issues/6115
https://github.com/material-components/material-components-w...
Two examples that come to mind but there are plenty
In Google Groups ending support for UsenetIt's 2023 and you still can't build iOS Firebase apps with Bazel
1 points · Open discussionOne common use case with a third-party library is for deep linking [1]. The deep link is copied with javascript in the browser, then after installing the app it can open right to where you were on the web.
[1] https://github.com/firebase/firebase-ios-sdk/blob/c8625ec52e...
In Reddit and LinkedIn apps also caught copying and pasting clipboard contentsI was confused for a moment because I thought the Firebase SDK was open source.
Interestingly, though, the Android version appears to be only partly open source. I did not find an explanation as to why some of the source is not available, it is mentioned on the Github repository but not explained. In any case, I don’t see the code for Cloud Messaging in there.
It may not be that it is done out of secrecy, though. A cursory glance of the iOS SDK shows what seems to be the full iOS portion of Firebase Cloud Messaging:
https://github.com/firebase/firebase-ios-sdk/tree/master/Fir...
Though that also raises its own question: doesn’t iOS effectively enforce APNS, and all third party providers actually must go through that? I imagine going through a single provider really can improve battery life. Each push provider needs to background fetch.
FW
Read the rest
IW, as far as I know, FCM and APNS are both free to use indefinitely. I’ve always found this a bit perplexing since I can’t even really fathom how many messages an app like Facebook or Twitter would push per month. I wonder what the odds are of this ever changing. The cynical viewpoint could go either way.
At face value, this really does seem problematic for open source projects. Can a GPL app link to (the non-open parts of) the Firebase SDK? My guess would be no.
Hope this can be resolved :( There’s some really great stuff on F-Droid, like Amaze file manager.
(Disclosure: I work for Google, but not on Android. I don’t even use Android phones anymore.)
The backend is almost entirely custom, though many common low-level open-source components are used pervasively. For example, for components written in C++ we use Abseil, Google Test, etc.
The SDKs are all open source and make use of other open source components:
* Android: https://github.com/firebase/firebase-android-sdk/tree/master/firebase-firestore
* iOS: https://github.com/firebase/firebase-ios-sdk/tree/master/Firestore
* Web: https://github.com/firebase/firebase-js-sdk/tree/master/packages/firestore
For example, the iOS SDK uses LevelDB for local key-value storage and gRPC for communication with the backend.
In Google Cloud Firestore NoSQL database is in GA