Closed abegehr closed 2 years ago
Hmm - it's supposed to work, I'm not aware of anything specific for arm64, failure wise, we've heard no other reports and I use an arm64 machine from time to time.
Let me confirm it's supposed to be working, in the meantime, there is also a more global "let's speed up Xcode builds" solution you can apply using ccache (available from brew). I recognize you're a flutter developer but I haven't written it up specifically for flutter, I just recently collaborated with the react-native team to document how we (Invertase, via my CI work) do it here though and you can see all the steps - which should apply equally to flutter - https://reactnative.dev/docs/build-speed#local-caches
For your specific issue, I wonder if it is not detecting that you need leveldb for some reason? This was the source of a lot of trouble for me and I'm still not satisfied fully with the outcome
Witness: https://github.com/invertase/firestore-ios-sdk-frameworks/pulls?q=is%3Apr+leveldb
https://github.com/invertase/firestore-ios-sdk-frameworks/issues/2#issuecomment-746894897
You might try:
If your build fails due with missing 'leveldb' symbols, pod FirebaseFirestore/WithLeveldb as the pod name instead of pod FirebaseFirestore, reinstall pods and try rebuilding.
Anecdotal evidence from users of my plugin that there may be an issue with Apple Silicon after updating from v8.11.0 to v9.1.0
Thanks for the extra context, I'll check this on an m1 machine today
I'm unable to reproduce this on my M1 machine.
I think there are two issues. I think the original poster had issues with the podspec's detection of leveldb, and should be able to resolve it using one of the less-automatic / more-certain methods of reference.
@dpa99c I think your problem is different - the biggest change between v8 and v9, in my opinion was this: you must use_frameworks!
in your podfile now. Perhaps that is the problem? Also some of the header files moved around.
I have not landed the PR for react-native-firebase to use firebase-ios-sdk v9+ yet as I'm still collaborating with the apple sdk team on a couple details, but you may examine my forward port efforts here to see what we had to change:
https://github.com/invertase/react-native-firebase/pull/6274/files
Most of the diff noise is testing stuff these two commits are the real effort, small, but important
We already had static framework in our react-native-firebase podspecs, you may be interested in how we link based on the Podfile variable consuming libraries may set:
That's a lot of extra information for you to hopefully get moving, for me - with no reproduction I have no action here. I believe it is working fine on M1, both firebase-ios-sdk v8 and v9
I'm having a similar problem with @dpa99c. (v8.15.0 > v9.1.0) The following error occurs when building on the device.
Error
error: no such module 'FirebaseFirestore'
Warning
warning: [CP] FirebaseFirestore.xcframework: Unable to find matching slice in 'ios-arm64_x86_64-simulator ios-arm64 ios-arm64_x86_64-maccatalyst' for the current build architectures (arm64 armv7) and platform (-iphoneos).
warning: [CP] gRPC-Core.xcframework: Unable to find matching slice in 'ios-arm64 ios-arm64_x86_64-simulator ios-arm64_x86_64-maccatalyst' for the current build architectures (arm64 armv7) and platform (-iphoneos).
warning: [CP] Libuv-gRPC.xcframework: Unable to find matching slice in 'ios-arm64_x86_64-maccatalyst ios-arm64_x86_64-simulator ios-arm64' for the current build architectures (arm64 armv7) and platform (-iphoneos).
warning: [CP] gRPC-C++.xcframework: Unable to find matching slice in 'ios-arm64 ios-arm64_x86_64-maccatalyst ios-arm64_x86_64-simulator' for the current build architectures (arm64 armv7) and platform (-iphoneos).
warning: [CP] BoringSSL-GRPC.xcframework: Unable to find matching slice in 'ios-arm64 ios-arm64_x86_64-maccatalyst ios-arm64_x86_64-simulator' for the current build architectures (arm64 armv7) and platform (-iphoneos).
warning: [CP] FirebaseFirestoreSwift.xcframework: Unable to find matching slice in 'ios-arm64 ios-arm64_x86_64-simulator ios-arm64_x86_64-maccatalyst' for the current build architectures (arm64 armv7) and platform (-iphoneos).
warning: [CP] abseil.xcframework: Unable to find matching slice in 'ios-arm64_x86_64-simulator ios-arm64_x86_64-maccatalyst ios-arm64' for the current build architectures (arm64 armv7) and platform (-iphoneos).
warning: [CP] leveldb-library.xcframework: Unable to find matching slice in 'ios-arm64 ios-arm64_x86_64-maccatalyst ios-arm64_x86_64-simulator' for the current build architectures (arm64 armv7) and platform (-iphoneos).
One thing is confirmed, it succeeds or fails depending on the project option value.
Build Active Architecture Only = Yes
> Build SuccessBuild Active Architecture Only = No
> Build FailI hope it helps to figure out the cause.
I exclude those things in typyical builds, personally, I use this stanza in my automated reproductions:
Which generates something like in the post_install block of Podfile
installer.aggregate_targets.each do |aggregate_target|
aggregate_target.user_project.native_targets.each do |target|
target.build_configurations.each do |config|
# Arch selection is needed to work across M1/Intel macs, became necessary when App Check was added
config.build_settings['ONLY_ACTIVE_ARCH'] = 'YES'
config.build_settings['EXCLUDED_ARCHS'] = 'i386'
end
end
aggregate_target.user_project.save
end
This is one of things I file away in the "wow, Xcode is irritating to work with" category. Curious if it helps anyone else
Anecdotal evidence from users of my plugin that there may be an issue with Apple Silicon after updating from v8.11.0 to v9.1.0
I confirm I have the same issue. I fixed by using this https://github.com/dpa99c/cordova-plugin-firebasex/issues/735#issuecomment-1140775999 I've tried this method too https://github.com/dpa99c/cordova-plugin-firebasex/issues/735#issuecomment-1141900552, but got this result https://github.com/dpa99c/cordova-plugin-firebasex/issues/735#issuecomment-1148536526
Sorry for the delay, and apologies that this is not 100% on target yet, but I am working to forward port react-native-firebase to firebase-ios-sdk v9.1.0 and while we normally don't use this precompiled version of the framework in our code, I can assert that when I turn it on, it works fine on my M1 machine.
So I do not think there is a general problem with the precompiled artifact, there must be something more subtle at play.
All our work on the react-native-firebase module is open, repro is via our e2e harness which may be run like so https://github.com/invertase/react-native-firebase/blob/main/tests/README.md and my repro branch showing success is pushed here at the moment https://github.com/invertase/react-native-firebase/tree/%40mikehardy/firestore-ios-frameworks-v9-repro
I haven't done a reproduction with FlutterFire in a while however I will note that they use the precompiled framework: https://github.com/firebase/flutterfire/blob/2854cbcb5a2e604ace8dc55993893e5ffdbff5a8/packages/cloud_firestore/cloud_firestore/example/macos/Podfile#L53 https://github.com/firebase/flutterfire/blob/2854cbcb5a2e604ace8dc55993893e5ffdbff5a8/packages/cloud_firestore/cloud_firestore/example/ios/Podfile#L54
...just still on v8 at the moment https://github.com/firebase/flutterfire/blob/2854cbcb5a2e604ace8dc55993893e5ffdbff5a8/packages/firebase_core/firebase_core/ios/firebase_sdk_version.rb#L3
so as soon as they forward-port to firebase-ios-sdk v9 it will either show up - confirming this issue - or it will not show up and we will be 2/2 on "works for us" 🤔 . [Edit: forward port for FlutterFire to firebase-ios-sdk v9 is in progress but not in a state where it may be used as a repro yet]
This looks much more like an issue with how leveldb is linked in versus an M1 Issue. M1 should be fully supported in both v8 and v9. The Podfile.lock may provide additional clues.
My LevelDB sub-specs should help with this, unfortunately I do not think it is actionable otherwise. After releasing react-native-firebase v15 last week and working through user upgrade issues I had a chance to come back around here and test using this optimization in our test app, it works fine and I confirm I was definitely using it:
[mike@yv ~/work/Invertase/react-native-firebase (main *)]$ cat tests/ios/Podfile.lock |grep FirebaseFirestore
- FirebaseFirestore (~> 9.2.0)
- FirebaseFirestore (9.2.0):
- FirebaseFirestore/AutodetectLeveldb (= 9.2.0)
- FirebaseFirestore/AutodetectLeveldb (9.2.0):
- FirebaseFirestore/Base
- FirebaseFirestore/Base (9.2.0)
- FirebaseFirestore (from `https://github.com/invertase/firestore-ios-sdk-frameworks.git`, tag `9.2.0`)
FirebaseFirestore:
FirebaseFirestore:
FirebaseFirestore: 4e108dcc1385ab5d596d630f2d28a4dfcaad04fe
With regret that I cannot reproduce and thus solve everyone's issues, I don't think there is anything wrong with this particular distribution
I'm unable to reproduce this on my M1 machine.
I think there are two issues. I think the original poster had issues with the podspec's detection of leveldb, and should be able to resolve it using one of the less-automatic / more-certain methods of reference.
@dpa99c I think your problem is different - the biggest change between v8 and v9, in my opinion was this: you must
use_frameworks!
in your podfile now. Perhaps that is the problem? Also some of the header files moved around.I have not landed the PR for react-native-firebase to use firebase-ios-sdk v9+ yet as I'm still collaborating with the apple sdk team on a couple details, but you may examine my forward port efforts here to see what we had to change:
https://github.com/invertase/react-native-firebase/pull/6274/files
Most of the diff noise is testing stuff these two commits are the real effort, small, but important
invertase/react-native-firebase@6832782
We already had static framework in our react-native-firebase podspecs, you may be interested in how we link based on the Podfile variable consuming libraries may set:
That's a lot of extra information for you to hopefully get moving, for me - with no reproduction I have no action here. I believe it is working fine on M1, both firebase-ios-sdk v8 and v9
The configuration of the cordova Plugin developed by @dpa99c seems to be correctly configured for use_framework!
Here is the generated PodFile. @mikehardy Can you confirm it's ok?
source 'https://cdn.cocoapods.org/'
platform :ios, '11.0'
use_frameworks!
target 'My Application' do
project 'My Application.xcodeproj'
pod 'Firebase/Core', '9.1.0'
pod 'Firebase/Auth', '9.1.0'
pod 'Firebase/Messaging', '9.1.0'
pod 'Firebase/Performance', '9.1.0'
pod 'Firebase/RemoteConfig', '9.1.0'
pod 'Firebase/InAppMessaging', '9.1.0'
pod 'FirebaseFirestore', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git', :tag => '9.1.0'
pod 'Firebase/Crashlytics', '9.1.0'
pod 'Firebase/Functions', '9.1.0'
pod 'Firebase/Installations', '9.1.0'
pod 'GoogleSignIn', '6.2.1'
end
I cannot confirm it is okay, I do not use cordova. It seems correct but I won't offer false comfort on something I don't personally use, you'll have to test it and see, and that is confirmation.
I can confirm that firebase-ios-sdk v9 is old and likely not compatible with current iOS versions. v10.1.0 is current.
Hi @mikehardy , thanks for your quick answer. I was only asking for a podfile configuration check. Maybe you can detect a missing parameter/option. We'll give a shot with the v10.
I'm facing
Undefined symbol
errors when trying to build and run a flutter app with the precompiled FirebaseFirestore pod installed on an Apple Silicon MBP. When I removepod 'FirebaseFirestore', :git => 'https://github.com/invertase/firestore-ios-sdk-frameworks.git', :tag => '8.15.0'
from the Podfile, it builds and runs as expected (though way slower 😅). – Should the pre-compiled FirebaseFirestore pod support developing on Apple silicon?Build log on simulator:
Flutter doctor:
Podfile: