🔥[🐛] Crashlytics throws "No known class method for selector" error on Expo #8127
Comments
|
If this fixed it:
Then you are not actually compiling against the firebase-ios-sdk you think you are compiling against It would be best if you posted text, but I am able to read your graphics at least. The one you posted about your Podfile lockfile:
Does not show what you think it shows, that's an intermediate step showing some constraints in the tree, and that they will be met by 11.4.0 or anything below it You want to see what it finally resolved to. Try this line and see how it goes, your output should match this output (note: the one with the mike@isabela:~/work/invertase/react-native-firebase/tests/ios (firestore-getAggregateFromServer) % cat Podfile.lock |grep FirebaseCore |grep =
- FirebaseCore (= 11.4.0)
- FirebaseCore (= 11.4.0)
- FirebaseCoreExtension (= 11.4.0)
- FirebaseCore (= 11.4.0)
- FirebaseCoreExtension (<= 11.4.0)
- FirebaseCoreExtension (<= 11.4.0)Your compilation error indicates that it will not. And you will have to determine the root cause of why - it will be project-specific, there will no change in this repository in response to the project-specific issue so it will not be actionable here unfortunately |
mikehardy
added
resolution: user
|
@mikehardy Hmm you're right. My bad, that was And I guess this part of I can now see that the problem isn't coming from crashlytics but from not being able to install 11.4.0 ios sdk. Since I'm using I tried manually deleting Podfile.lock file and running Can you give me any clue on where to dig at since I get the same result(10.28.1 being installed) even from fresh expo project w/ only firebase/app installed? I have no idea why cocoapods decides to install 10.28.1 instead of 11.4.0 when Or from this part of Podfile.lock: is it possible to make |
|
Github is a text medium, it would be possible to maybe give you an answer if you just included your Podfile.lock instead of those images which are incomplete, and impossible to copy/paste from etc. Images strongly discouraged.
The simple (but unfortunately vague) answer is "one of your dependencies or your Podfile is pinning it at 10.28.1 somehow" Examine your Podfile.lock and see who is depending on FirebaseCore at that version and why. Make sure you don't have a pin in your Podfile With apologies, I need to emphasize this is not a problem in this repo it is project-specific. It is not actionable by us and we cannot extend unlimited support for all project-specific issues - I won't be able to help further on this one, but perhaps stackoverflow has similar issues with methods to determine why pod versions resolve to unexpected values |
|
Just in case other people with the same problem would see it, I'll share a link to Podfile.lock and re-paste Podfile here so that they can compare with theirs Podfilerequire File.join(File.dirname(`node --print "require.resolve('expo/package.json')"`), "scripts/autolinking")
require File.join(File.dirname(`node --print "require.resolve('react-native/package.json')"`), "scripts/react_native_pods")
require 'json'
podfile_properties = JSON.parse(File.read(File.join(__dir__, 'Podfile.properties.json'))) rescue {}
ENV['RCT_NEW_ARCH_ENABLED'] = podfile_properties['newArchEnabled'] == 'true' ? '1' : '0'
ENV['EX_DEV_CLIENT_NETWORK_INSPECTOR'] = podfile_properties['EX_DEV_CLIENT_NETWORK_INSPECTOR']
use_autolinking_method_symbol = ('use' + '_native' + '_modules!').to_sym
origin_autolinking_method = self.method(use_autolinking_method_symbol)
self.define_singleton_method(use_autolinking_method_symbol) do |*args|
if ENV['EXPO_UNSTABLE_CORE_AUTOLINKING'] == '1'
Pod::UI.puts('Using expo-modules-autolinking as core autolinking source'.green)
config_command = [
'node',
'--no-warnings',
'--eval',
'require(require.resolve(\'expo-modules-autolinking\', { paths: [require.resolve(\'expo/package.json\')] }))(process.argv.slice(1))',
'react-native-config',
'--json',
'--platform',
'ios'
]
origin_autolinking_method.call(config_command)
else
origin_autolinking_method.call()
end
end
platform :ios, podfile_properties['ios.deploymentTarget'] || '13.4'
install! 'cocoapods',
:deterministic_uuids => false
prepare_react_native_project!
target 'testfirebase' do
use_expo_modules!
config = use_native_modules!
use_frameworks! :linkage => podfile_properties['ios.useFrameworks'].to_sym if podfile_properties['ios.useFrameworks']
use_frameworks! :linkage => ENV['USE_FRAMEWORKS'].to_sym if ENV['USE_FRAMEWORKS']
use_react_native!(
:path => config[:reactNativePath],
:hermes_enabled => podfile_properties['expo.jsEngine'] == nil || podfile_properties['expo.jsEngine'] == 'hermes',
# An absolute path to your application root.
:app_path => "#{Pod::Config.instance.installation_root}/..",
:privacy_file_aggregation_enabled => podfile_properties['apple.privacyManifestAggregationEnabled'] != 'false',
)
post_install do |installer|
react_native_post_install(
installer,
config[:reactNativePath],
:mac_catalyst_enabled => false,
:ccache_enabled => podfile_properties['apple.ccacheEnabled'] == 'true',
)
# This is necessary for Xcode 14, because it signs resource bundles by default
# when building for devices.
installer.target_installation_results.pod_target_installation_results
.each do |pod_name, target_installation_result|
target_installation_result.resource_bundle_targets.each do |resource_bundle_target|
resource_bundle_target.build_configurations.each do |config|
config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
end
end
end
end
post_integrate do |installer|
begin
expo_patch_react_imports!(installer)
rescue => e
Pod::UI.warn e
end
end
endFrom what I see until now, I can't find any dependencies or pin in Podfile.lock and Podfile. Since I created a fresh project and only installed firebase/app as its dependency, I actually don't know what more to suspect. Maybe it has to do something with cocoapods or expo? I'll keep looking for a solution since I see that it is now a bigger problem to not being able to install 11.4.0 than not just being able to use crashlytics. I'll post my solution here once I find it. |
|
Found a fix:
Then I got curious why it kept installing 10.28.1 until I ran
If that's true, then I'll be sticking to version it is set to <=11.4.0, but since RNFB version 21.4.0 shouldn't allow versions under 11, it would be something like:
s.dependency 'Firebase/CoreOnly', '>= 11.0.0', "<= #{firebase_sdk_version}"Would this solution be valid? @mikehardy |
|
Oh no - the law of unintended consequences has bitten me/us here, this is a module issue here and is not project-specific, I was wrong here:
There was an upstream build error that affected everyone when firebase-ios-sdk 11.4.0 came out and it was quite messy because transitive deps were allowed to slip to higher versions, thus pulling in the new versions with errors instead of staying on the old versions. In response I made the change from specifying the version with no range to a '<=' in order to stop that: I didn't realize that this would let old versions stay in place instead of upgrading but your analysis here makes it clear to me now. Thank you Your proposed solution would fix your issue right now but is not quite sufficient as we sometimes adopt new APIs released in semver minor versions and we need people to go from (for example) 11.1.0 to 11.2.0 of firebase-ios-sdk in order for the APIs to exist. I think I may need to do an |
mikehardy
added
platform: ios
impact: build-error
This reverts commit d03ab42. the cure was worse than the disease, see: #8127 If we constrain deps to <=, old deps may be used which is invalid If we constrain deps to =, then binary firestore-ios-sdk-frameworks does not resolve If we constrain deps to ~> like FlutterFire it may work However, we constrained this way for a long time without issue until one build break that prompted this commit, and the ~> suffered the build break as well in FlutterFire The break was fixed quickly and had a workaround, so revert appears to be the lesser of all evils
|
In the end a revert was the only thing that tested out correctly, which was a surprise. |
This reverts commit d03ab42. the cure was worse than the disease, see: #8127 If we constrain deps to <=, old deps may be used which is invalid If we constrain deps to =, then binary firestore-ios-sdk-frameworks does not resolve If we constrain deps to ~> like FlutterFire it may work However, we constrained this way for a long time without issue until one build break that prompted this commit, and the ~> suffered the build break as well in FlutterFire The break was fixed quickly and had a workaround, so revert appears to be the lesser of all evils
This reverts commit d03ab42. the cure was worse than the disease, see: #8127 If we constrain deps to <=, old deps may be used which is invalid If we constrain deps to =, then binary firestore-ios-sdk-frameworks does not resolve If we constrain deps to ~> like FlutterFire it may work However, we constrained this way for a long time without issue until one build break that prompted this commit, and the ~> suffered the build break as well in FlutterFire The break was fixed quickly and had a workaround, so revert appears to be the lesser of all evils
|
@mikehardy Glad that this helped. Thanks for your time on resolving the issue! |
Issue
Hi, after updating my firebase to the latest version(21.4.0) to support XCode 16, a new build error from Crashlytics popped up:
I found 2 closed issues related to this(#8065, #8101) but nothing helped so I'm opening a new one with more context.
I was able to reproduce it by creating a fresh expo project and installing firebase/app and crashlytics package:
npx create-expo-app@latest(https://docs.expo.dev/get-started/create-a-project/)npx expo install @react-native-firebase/app @react-native-firebase/crashlyticsapp.json(https://rnfirebase.io/#configure-react-native-firebase-modules)npx expo prebuild --cleannpx expo run:iosor open xcode(open ios/yourproject.xcworkspace) and runI've checked
,
package.jsonofreact-native-firebase/appand firebase sdk version is well fixed to 11.4.0Podfile doesn't contain any version pin on firebase sdk such as
$FirebaseSDKVersion = '11.4.0',and
Podfile.lockfile also shows that 21.4.0 and 11.4.0 is installedThen I found this comment, where
dependencies:@[]got removed from 21.2.0.I tried reverting that line back by modifying
RNFBCrashlyticsInitProvider.mfrom node_modules and the error disappeared!I don't understand the whole context but AFAIK that change was necessary to support firebase-ios-sdk v11?
Any idea if that revert is necessary or is there something I'm missing?
Project Files
Javascript
Click To Expand
package.json:{ "name": "test-firebase", "main": "expo-router/entry", "version": "1.0.0", "scripts": { "start": "expo start", "reset-project": "node ./scripts/reset-project.js", "android": "expo run:android", "ios": "expo run:ios", "prebuild": "expo prebuild --clean", "web": "expo start --web", "test": "jest --watchAll", "lint": "expo lint" }, "jest": { "preset": "jest-expo" }, "dependencies": { "@expo/vector-icons": "^14.0.2", "@react-native-firebase/app": "^21.4.0", "@react-native-firebase/crashlytics": "^21.4.0", "@react-navigation/native": "^6.0.2", "expo": "~51.0.28", "expo-build-properties": "~0.12.5", "expo-constants": "~16.0.2", "expo-dev-client": "~4.0.29", "expo-font": "~12.0.9", "expo-linking": "~6.3.1", "expo-router": "~3.5.23", "expo-splash-screen": "~0.27.5", "expo-status-bar": "~1.12.1", "expo-system-ui": "~3.0.7", "expo-web-browser": "~13.0.3", "react": "18.2.0", "react-dom": "18.2.0", "react-native": "0.74.5", "react-native-gesture-handler": "~2.16.1", "react-native-reanimated": "~3.10.1", "react-native-safe-area-context": "4.10.5", "react-native-screens": "3.31.1", "react-native-web": "~0.19.10" }, "devDependencies": { "@babel/core": "^7.20.0", "@types/jest": "^29.5.12", "@types/react": "~18.2.45", "@types/react-test-renderer": "^18.0.7", "jest": "^29.2.1", "jest-expo": "~51.0.3", "react-test-renderer": "18.2.0", "typescript": "~5.3.3" }, "private": true }firebase.jsonfor react-native-firebase v6:# N/AiOS
Click To Expand
ios/Podfile:AppDelegate.m:Environment
Click To Expand
react-native infooutput:react-native-firebaseversion you're using that has this issue:21.4.0Firebasemodule(s) you're using that has the issue:CrashlyticsTypeScript?YReact Native FirebaseandInvertaseon Twitter for updates on the library.The text was updated successfully, but these errors were encountered: