firebase-ios-sdk
firebase-ios-sdk copied to clipboard
firebase
[FR]: Add support for SPM, binary distro
Description
@ncooke3 made a great progress introducing firestore as binary distribution through firebase. Good progress, but we need the distro of all related to firebase iOS in that way.
Because it's time consuming in CIs and in local to build third party code, that should be pre-compiled to plug and play.
Thanks.
API Proposal
No response
Firebase Product(s)
AB Testing, Analytics, App Check, App Distribution, Authentication, Crashlytics, Database, DynamicLinks, Functions, In-App Messaging, Installations, ML Model Downloader, Messaging, Performance, Remote Config, Storage
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
+1 to this!
Someone already did the work of putting up a GitHub repository that mirrors the Firebase binaries: https://github.com/akaffenberger/firebase-ios-sdk-xcframeworks
I've used this in the last app that I made, and was really satisfied by how well it worked. Builds are much faster (both locally and on CI) and Xcode doesn't need to index all of the Firebase source code.
It would be great if Google would host the binaries so I don't have to trust a third-party mirror. In fact, why not make it the default. It would save many millions of collective CI-minutes (and carbon emissions with that!) that are spent compiling the Firebase SDK and its dependencies each time.
Google already hosts XCFrameworks for another product: the Google Maps iOS SDK. (Which is closed source) You can see it in the Podfile
+1 as well!
Enabling a binary distribution would cut at least 25-30 seconds off every full build (for a typical M1 mac in our environment) and dramatically simplify the work the build system would have to do during compilation. It would also cut down greatly on the SPM package resolution wasted time when starting Xcode, etc.
While it's really wonderful to be able to see the Firebase source code, 99% of the time, it's simply not necessary. If we still had a source code distro to fall back to, we could still use that in a pinch if we needed to step into Firebase code for some reason.
Is there any updates if the Firebase team will eventually work on this @paulb777? I'm asking since the linked issue had a discussion going on which eventually died off because the issue was locked.
As pointed out by others a lot of developers would greatly benefit from this. Our main motivation is to reduce SPM cache size and therefore speed up build times.
We just wound up punting and going with the manual install at this point. Little frustrating as we'll have to script as well as manually check every Firebase update for new/changed frameworks though. Definitely will lead to slower adoption of Firebase updates given the extra effort involved. SPM solution would be better and more reliable/stable.
UPDATE: Take that back. We got bit by the issue with SwiftUI previews and are unfortunately reverting to SPM till this request gets resolved.
Hi @jesus-mg-ios, no updates to share at this time.
Also, @mthormann-dhi, ICYMI, the Promises issue you linked to has since been fixed.
One usability factor slowing this down is that there is no way to support both Xcode 14 and Xcode 15 with a single binary installation and also support VisionOS early adopters.
@paulb777 Maybe stupid question then related to your response but wouldn't the zip file with the .xcframework files that we pull when installing manually need to be updated with different versions as well? I'm just seeing one set of files currently. Or is that just an issue specific to deploying binaries w/SPM?
Out of curiosity, why do we need 2 xcframeworks for different Xcode versions?
We do have the same issue with the zip distribution. There is no way to build visionOS with Xcode 14 and binary distributions are only forward compatible.
However, there is not significant demand for visionOS support from zip distribution, while there is from the SPM distribution.
@ncooke3 I am not seeing the issue with broken SwiftUI preview and manual install fixed (Xcode 14.3.1, Firebase 10.14.0). Still getting crash from preview every time. Maybe this is a different crash?
`Date/Time: 2023-08-25 13:08:10.9592 -0400 Launch Time: 2023-08-25 13:08:09.3807 -0400 OS Version: macOS 13.5.1 (22G90) Release Type: User Report Version: 104
Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: MyApp [11473]
Triggered by Thread: 13
Last Exception Backtrace: 0 CoreFoundation 0x180437324 __exceptionPreprocess + 160 1 libobjc.A.dylib 0x180051274 objc_exception_throw + 56 2 CoreFoundation 0x180445e3c +[NSObject(NSObject) instanceMethodSignatureForSelector:] + 0 3 CoreFoundation 0x18043b224 forwarding + 1308 4 CoreFoundation 0x18043d50c _CF_forwarding_prep_0 + 92 5 MyApp 0x1022c18e0 -[GDTCCTUploadOperation updateNextUploadTimeWithResponse:forTarget:] + 52 6 MyApp 0x1022c1098 __54-[GDTCCTUploadOperation uploadBatch:toTarget:storage:]_block_invoke + 56 7 MyApp 0x1021c3e48 __56-[FBLPromise chainOnQueue:chainedFulfill:chainedReject:]_block_invoke.18 + 52 8 libdispatch.dylib 0x180132ee4 _dispatch_call_block_and_release + 24 9 libdispatch.dylib 0x180134708 _dispatch_client_callout + 16 10 libdispatch.dylib 0x18013c95c _dispatch_lane_serial_drain + 1256 11 libdispatch.dylib 0x18013d3dc _dispatch_lane_invoke + 392 12 libdispatch.dylib 0x180149608 _dispatch_workloop_worker_thread + 768 13 libsystem_pthread.dylib 0x1b1834878 _pthread_wqthread + 284 14 libsystem_pthread.dylib 0x1b183363c start_wqthread + 8`
Hi @mthormann-dhi, just to double check, what version of Promises are you seeing in your Podfile.lock/Package.resolved. If you are manually integrating via xcframeworks, you find find the version by finding the Promises xcframework (I believe it should be in the FirebaseAnalytics directory), picking any architecture slice, and then inspecting the Info.plist within any of the architecture slice folders (the architecture specific Info.plist will have the library version; the Info.plist at the root of the xcframework does not).
It was manual install (not pods) and is showing 2.3.1 in both FBLPromises and PromisesSwift frameworks which I thought should have fixed this. Interestingly looks like someone maybe forgot to update the info.plist on FirebaseAnalytics (shows 10.13.0 vs 10.14.0 in FirebaseAnalyticsSwift and the other frameworks).
SPM install of 10.14.0 is just fine. Just manual that is still broken for me.
FirebaseAnalytics (shows 10.13.0 vs 10.14.0 in FirebaseAnalyticsSwift and the other frameworks)
This is a side effect of the current release process. When FirebaseAnalytics does not change between releases, the previous release's binary artifact is re-used. This differs from open-source SDKs like FirebaseAnalyticsSwift which are rebuilt each release, regardless of whether they have changed since the last release.
It was manual install (not pods) and is showing 2.3.1 in both FBLPromises and PromisesSwift frameworks which I thought should have fixed this.
Hmm, agreed. What version of Xcode are you using?
Latest stable 14.3.1. I've killed DerivedData, clean build, etc. and still seeing the same crash on the SwiftUI canvas. Everything else is just fine (running, Firebase functionality, etc.).
Do you have -ObjC passed to Other Linker Flags build setting? If not, could you try re-building with it?
Yes that's been set from the start on the app target and I double-checked again. I've also looked and don't see Promises used by any other library in our app. Should I just spin another bug and reference that older closed one at this point?
Yep, a new bug sounds good. And are you able to share a minimal reproducible example?
Will do that. I'll have to work on a minimal example. It's happening in our main app which isn't minimal or shareable. In the meantime, I'll just hope this issue here moves along so I can avoid manual install at all 😀.
@ncooke3 is it ongoing or stalled? Is there any ETA for the full binary distribution through SPM?
Hi @jesus-mg-ios, there is no ongoing work to address this feature request. For those that haven't, please leave a 👍 on the original post in this issue. These reactions can help get this work prioritized.