Closed Hesamedin closed 1 year ago
I am able to pass the build process by commenting FirebaseFirestore
out however the build time increases to 40 minutes (previously 15 min).
Indeed, and this is the correct location for the issue.
There are notes here: https://github.com/firebase/firebase-ios-sdk/issues/10383 Where it was repointed at the FlutterFire repo: https://github.com/firebase/flutterfire/issues/9761 (and there is some triage there)
But this is likely to be the location of the root cause I think.
Myself and @russellwheatley have reproduced this, so we do see the issue.
temporary workaround is to remove this pre-compiled version of Firestore and compile during build
That seems painful, but it is not that bad combined with use of https://ccache.dev/ (via https://github.com/hendrikmuhs/ccache-action perhaps, and an integration like the one described for react-native but that will work for Flutter as well with a Podfile change https://reactnative.dev/docs/0.69/build-speed#xcode-specific-setup).
You can see something similar in action in a publicly available repo here:
...and we set Xcode up to use relative paths directly on command line instead of as Podfile post install but theory is same: https://github.com/invertase/react-native-firebase/blob/f2d1363b89fb046388f8336b08852c1ea0c285f2/tests/package.json#L62
Okay, so things I have tried that have not worked yet:
Thoughts I have had that I have not had time to try:
Any thoughts, experiments + results welcome
The most interesting lead I currently have:
FirebaseFunctions is the only other product that will include FirebaseSharedSwift dependency (FirebaseDatabase and FirebaseRemoteConfig also have it in their Swift implementation/podspecs, but they aren't pulled in as dependencies when you include them in a Flutter project. It's the obj-c implementation/podspec that does not have FirebaseSharedSwift as a dependency).
Here is the FirebaseRemoteConfig + Firestore pods for example. Note it does not include FirebaseSharedSwift as a pod:
Now, when I have the dependencies Firestore + FirebaseFunctions in my flutter project, I see FirebaseSharedSwift hoisted into the pods:
If we look in the build directory. We can see the FirebaseSharedSwift framework has a different structure & different files to the one that are inside XCFrameworkIntermediates/FirebaseFirestore
directory:
FirebaseSharedSwift
pod build:
XCFrameworkIntermediates/FirebaseFirestore/Base/FirebaseSharedSwift
build:
My theory is that it is looking on the wrong path for FirebaseSharedSwift
, and something like adding this XCFrameworkIntermediates/FirebaseFirestore/Base/FirebaseSharedSwift
as a search path on the FirebaseFirestore target is a likely solution. Or something along those lines 🤷♂️. That's about as far as I've got.
@russellwheatley interesting point. You are right about Firebaes AppConfig. I had a task to integrate this lib and functionality into my project. I added the latest version of this lib then the iOS build asked me to update FirebaseFirestore to 10.0.0. Then I have no choice but to upgrade all other Firebase dependencies, too. I even use Firebasebase cloud functions in my projects. This is the list of my project's dependencies:
I wonder if the FirebaseSharedSwift part should be purged from the repack here and "replaced" with a podspec level dependency? Or if the compilation of the zip distribution somehow encodes things in such a way that won't work for some reason (possibly related to inability to interop in that way between zip distribution and cocoapods distribution).
For obj-c stuff zip + pods interop between shared sub-modules was possible as we would include leveldb sometimes (when realtime database was not also included) but we would not include leveldb other times (when realtime database was included, since it brings in leveldb itself).
For swift stuff (like this new FirebaseSharedSwift submodule) is zip+pods interop still possible? Do we need to programmatically include it or exclude it depending on what other packages are here (like leveldb) or would that "never include it + depend on it via cocoapods" style be better, or does none of that work either 😆
I wonder if the FirebaseSharedSwift part should be purged from the repack here and "replaced" with a podspec level dependency? Or if the compilation of the zip distribution somehow encodes things in such a way that won't work for some reason (possibly related to inability to interop in that way between zip distribution and cocoapods distribution).
I've tried adding it to the podspec and it didn't work although I didn't remove the FirebaseSharedSwift
framework from the FirebaseFirestore
directory 🤔.
It does work fine when FirebaseFunctions
isn't also a dependency which makes me think it is looking in the wrong place. The logs below are more detailed than the ones logged in the issue description. It shows the undefined symbols are coming entirely from FirebaseFirestoreSwift
. Maybe the linker is looking in the Pods/FirebaseSharedSwift
. My reading of the error is that it knows the functions are declared but not defined. The linker cannot find them.
For obj-c stuff zip + pods interop between shared sub-modules was possible as we would include leveldb sometimes (when realtime database was not also included) but we would not include leveldb other times (when realtime database was included, since it brings in leveldb itself).
The other problem we have is that FirebaseSharedSwift
is only a dependency of FirebaseFunctions
& FirebaseFirestore
for now, but it's probable it'll be used in other Firebase products. So we ought make it future proof if it does become a dependency on other products. (Having said that, I'd take a solution for just FirebaseFunctions
for now 😄 ).
I'll continue looking into it with fresh eyes this morning and see if I can get any further.
If I add FirebaseSharedSwift.xcframework
to "Linked binary with libraries" it actually builds but immediately crashes with:
but this time, it is coming from FirebaseFunctions
:
This makes me assume that once FirebaseFunctions
is included, it is the Pod/FirebaseSharedSwift
that takes precedence over the XCFrameworkIntermediates/FirebaseFirestore/Base/FirebaseSharedSwift.xcframework
which FirebaseFirestore
appears to be incompatible with. But when you explicitly link FirebaseSharedSwift.framework
, then the XCFrameworkIntermediates/FirebaseFirestore/Base/FirebaseSharedSwift.xcframework
takes precedence which FirebaseFunctions
is incompatible with. Maybe.
So...are Swift-based shared modules not compatible across zip + Pod distribution styles? :thinking: I wonder if the premise of this module should be altered and instead of pulling the zip and re-packing it, it should have a cocoapod-based app (with dependency on FirebaseSharedSwift...), do a compile Pod-style and pack that, then have a podspec that depends on FirebaseSharedSwift That would be a big restructure and I've never attempted anything that style, so it could be a complete non-starter / fail at even a proof-of-concept stage
Just trying to brainstorm through it :)
So...are Swift-based shared modules not compatible across zip + Pod distribution styles? 🤔 I wonder if the premise of this module should be altered and instead of pulling the zip and re-packing it, it should have a cocoapod-based app (with dependency on FirebaseSharedSwift...), do a compile Pod-style and pack that, then have a podspec that depends on FirebaseSharedSwift That would be a big restructure and I've never attempted anything that style, so it could be a complete non-starter / fail at even a proof-of-concept stage
Just trying to brainstorm through it :)
I'll try this method. I was trying to keep FirebaseSharedSwift
private to FirebaseFunctions
(not sure if this is even possible), but your way would be future proof and thus preferable 😄
This may be the moment - at the "brainstorming a proof of concept" stage - to gently inquire with @paulb777 and see if they are aware of limitations around zip (repacked into Pod) distribution interop with Swift all pod compile/link, or if they have any other brainstorms that could be useful
aware of limitations around zip (repacked into Pod) distribution interop with Swift all pod compile/link
This is the kicker. It's a long road to walk only to find they are not compatible 😓
I think I have a solution for FlutterFire and RNFB at least, and maybe completely, but I'm not sure what else relies on this framework and how they use it. (I did try and precompile the Pod and include as part of this umbrella framework locally but I got a ton of errors that exacerbated the problem).
~My tentative solution is here.~
I have a PR here.
I noticed that the errors were actually coming from FirebaseFirestoreSwift
and realised that we didn't need it as we already have the FirebaseFirestore
framework shipped. So I removed FirebaseFirestoreSwift
from the Base
subspec.
Reading more about FirebaseFirestoreSwift
in the README.md it says:
The FirebaseFirestoreSwift module does not provide any additional utility to Objective-C projects, and therefore is not recommended for non-Swift projects.
Which is why I think we don't need it. My app now builds successfully with FirebaseFunctions
& FirebaseFirestore
. Not gonna lie, that was tough. But I have learnt a lot 💪
I think the next step is to detect if the FirebaseFirestore
Pod is part of a FF or RNFB project and remove FirebaseFirestoreSwift
for them, just to be safe.
Hello @russellwheatley and @mikehardy , I'm getting this error on my Ionic/cordova project, using https://github.com/dpa99c/cordova-plugin-firebasex and precompiled FirebaseFirestore pod
The issue on cordova-plugin-firebasex repo : https://github.com/dpa99c/cordova-plugin-firebasex/issues/782
The error is :
Undefined symbols for architecture arm64:
"_$s19FirebaseSharedSwift0A11DataDecoderC0D16DecodingStrategyO6base64yA2EmFWC", referenced from:
_$sSo12FIRFirestoreC22FirebaseFirestoreSwiftE7DecoderCAEycfC in FirebaseFirestoreSwift(EncoderDecoder.o)
_$sSo12FIRFirestoreC22FirebaseFirestoreSwiftE7DecoderCAEycfc in FirebaseFirestoreSwift(EncoderDecoder.o)
Thanks for your input, I'm open to try some solutions locally, but as is I'm not sure what to configure in Podfile to make it work
@QuentinFarizon I'm not familiar with the targets defined by cordova that would allow detection of firestore already included there. You'll need to propose a PR that alters the podspec and detects something about your Cordova build that indicates if it already has firestore included or not, then you can key off that to remove the FirebaseFirestoreSwift pod for it as well
@mikehardy do you know where I can check these targets ?
@mikehardy Apart from fixing it on your side, do you know of any file I could manually modify to avoid this error ?
@mikehardy do you know where I can check these targets ?
No, sorry. I have no experience with Cordova
@mikehardy Apart from fixing it on your side, do you know of any file I could manually modify to avoid this error ?
You might be able to PR something in the podspec where you check for an environment variable or something as well as the react-native / flutter items, as an manual override. And if you define that variable then you can also exclude the problematic Pod framework
It appears you already have an environment variable available?
IOS_USE_PRECOMPILED_FIRESTORE_POD=true
from https://github.com/dpa99c/cordova-plugin-firebasex/issues/782#issuecomment-1331908415
@mikehardy Yes, my build is OK when not using your precompiled Firestore Pod, but it takes 20 additional minutes
No, sorry. I have no experience with Cordova
I mean, where can I look to give you this information ?
@QuentinFarizon your comment does not seem to take into account my comment - I've provided an outline of a feasible solution, even including pertinent cordova details. The approach I outline should work, but you'll have to do the work to make it work
@QuentinFarizon Update this part of the podspec. You're trying to detect the Firestore framework for Cordova. For example, the Flutter Firestore framework is called, cloud_firestore
. If it exists, you need to exclude FirebaseFirestoreSwift
framework from the build.
@mikehardy @russellwheatley I did get that !
What I don't get is how to find how is called the Cordova Firestore framework. In which file should I look into ? Sorry, I'm not very familiar with the iOS/Pod system and namings
I suggest given unfamiliarity with the targets to rely on detection if an environment variable instead, as mentioned above. You already have one you can detect, also as mentioned
Oh ok I see, but IOS_USE_PRECOMPILED_FIRESTORE_POD is not an environment variable
I figured out it could be any environment variable, so a generic one could cover other uses cases than Cordova's : https://github.com/invertase/firestore-ios-sdk-frameworks/pull/68/files
Hello, I used
9.6.0
without any problem in my Flutter project. I updated almost all of my dependencies and then I had no choice but to updateFirebaseFirestore
to10.0.0
. By doing this, I cannot build my project for iOS. This is what I see in the log of Azure CLI for the following command:Output Log (Click me)
2022-10-20T16:51:59.3448730Z ##[section]Starting: Build for iOS (Debug) 2022-10-20T16:51:59.3465320Z ============================================================================== 2022-10-20T16:51:59.3465740Z Task : Flutter Build Task 2022-10-20T16:51:59.3466040Z Description : Build a Flutter application project. 2022-10-20T16:51:59.3466320Z Version : 0.3.5 2022-10-20T16:51:59.3466530Z Author : Hey24sheep 2022-10-20T16:51:59.3466900Z Help : [More Information](https://github.com/hey24sheep/azure-flutter-tasks) 2022-10-20T16:51:59.3467340Z ============================================================================== 2022-10-20T16:51:59.5789140Z [command]/Users/runner/work/1/s/flutter/bin/flutter build ios --no-codesign --build-number=12899 --target=lib/main_dev.dart 2022-10-20T16:52:29.2558220Z Running "flutter pub get" in s... 28.4s 2022-10-20T16:52:30.6795910Z Warning: Building for device with codesigning disabled. You will have to manually codesign before deploying to device. 2022-10-20T16:52:49.0210410Z Building com.ATCO.CustomerOutageNotification for device (ios-release)... 2022-10-20T16:59:11.8309070Z Running pod install... 374.0s 2022-10-20T17:05:19.0617120Z Running Xcode build... 2022-10-20T17:05:19.0620560Z Xcode build done. 367.2s 2022-10-20T17:05:20.5896710Z Failed to build iOS app 2022-10-20T17:05:20.5915480Z Error output from Xcode build: 2022-10-20T17:05:20.5916530Z ↳ 2022-10-20T17:05:20.5918620Z ** BUILD FAILED ** 2022-10-20T17:05:20.5919480Z 2022-10-20T17:05:20.5919820Z 2022-10-20T17:05:20.5920390Z Xcode's output: 2022-10-20T17:05:20.5920800Z ↳ 2022-10-20T17:05:20.5940100Z Writing result bundle at path: 2022-10-20T17:05:20.5940800Z /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/flutter_tools.CuwB9v/flutter_ios_build_temp_diryBTe5y/temporary_xcresult_bundle 2022-10-20T17:05:20.5941270Z 2022-10-20T17:05:20.5941680Z 1 warning generated. 2022-10-20T17:05:20.5943120Z /Users/runner/work/1/s/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_local_notifications-9.9.1/ios/Classes/FlutterLocalNotificationsPlugin.m:13:3: warning: 'UILocalNotification' is deprecated: first deprecated in iOS 10.0 - Use UserNotifications Framework's UNNotificationRequest [-Wdeprecated-declarations] 2022-10-20T17:05:20.5944210Z UILocalNotification *_launchNotification; 2022-10-20T17:05:20.5944550Z ^ 2022-10-20T17:05:20.5945340Z In module 'UIKit' imported from /Users/runner/work/1/s/ios/Pods/Target Support Files/flutter_local_notifications/flutter_local_notifications-prefix.pch:2: 2022-10-20T17:05:20.5946770Z /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS16.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UILocalNotification.h:18:12: note: 'UILocalNotification' has been explicitly marked deprecated here 2022-10-20T17:05:20.5947740Z @interface UILocalNotification : NSObject