Xcode 27 won't launch 93% of React Native apps: the UIScene change, and the libraries that crash after it
On 9 September Apple announced that from April 2027, apps uploaded to App Store Connect must be built with the iOS 27 SDK, which means Xcode 27. Built with that SDK, an app that hasn't adopted the UIKit scene life cycle doesn't start. It stops at launch with:
Application failed to launch: UIScene life cycle is required for apps built with this SDK.
Apple announced the rule in TN3187. The check depends on the SDK you build with, not the iOS version on the phone. The same app built with Xcode 26 still runs on iOS 27, so nothing breaks for your users today. It breaks on the day you move to Xcode 27.
I run a health check on several hundred open-source React Native and Expo apps (the set I use to test NativeKeel). As of 11 October 2026:
| | Apps |
|---|---|
| React Native and Expo apps with an iOS target | 628 |
| Not on the scene life cycle yet | 583 (93%) |
| Largest groups | Expo SDK 57 (117), Expo SDK 54 (111) |
That number isn't a judgment on those apps. Until a few weeks ago, no React Native or Expo template used scenes at all.
Where React Native and Expo stand
- React Native 0.88 is the first release whose template adopts it. SceneDelegate.swift starts React Native in the window scene, and Info.plist names it in UIApplicationSceneManifest. 0.88 is still a release candidate (rc.4 on 7 October). 0.87 and earlier have nothing in the template, so the path is to upgrade and copy both files from the Upgrade Helper.
- Expo SDK 57 can opt in. It needs expo 57.0.23+ and expo-build-properties 57.0.20+:
["expo-build-properties", { "ios": { "enableSceneSupport": true } }]
Then run npx expo prebuild again.
- Expo SDK 58 (in beta since 15 September) generates the scene delegate by default.
- SDK 56 and earlier need an SDK upgrade first.
How do you know you've adopted it? Your Info.plist has a UIApplicationSceneManifest with scene configurations, or your app delegate implements application(_:configurationForConnecting:options:). A manifest that only sets UIApplicationSupportsMultipleScenes doesn't count.
The part that bites after you adopt it: AppDelegate has no window
In the 0.88 template the UIWindow belongs to the scene delegate. AppDelegate no longer has a window property at all.
Many iOS libraries still find the screen to present on like this:
UIViewController *root = [UIApplication sharedApplication].delegate.window.rootViewController;
On the new template that line throws:
-[AppDelegate window]: unrecognized selector sent to instance
I searched the iOS sources of popular React Native libraries for this call made without a respondsToSelector: check, and found it in 15 that are still in use. Then I built a fresh React Native 0.88.0-rc.4 app and confirmed the crash with two of them, react-native-blob-util and react-native-google-mobile-ads. Both stopped crashing after one change:
UIViewController *root = RCTPresentedViewController(); // or RCTKeyWindow().rootViewController
Both fixes are open as pull requests (react-native-blob-util#498, react-native-google-mobile-ads#911). For @react-native-firebase/messaging, which makes the call at launch, a fix was already proposed upstream (react-native-firebase#9359).
68 of the 628 apps depend on at least one of these libraries. The most common:
| Library | Apps | When it crashes |
|---|---|---|
| react-native-blob-util | 17 | presenting the open-in / options menu |
| @react-native-firebase/messaging | 17 | at launch |
| react-native-google-mobile-ads | 11 | showing banners, the consent form or the ad inspector |
| react-native-date-picker | 9 | opening the modal picker |
| react-native-image-crop-picker | 9 | opening the picker |
| rn-fetch-blob | 7 | presenting the open-in menu |
Until a release ships the fix, a patch-package patch with the line above works.
The quiet one: deep links stop arriving
With scenes, UIKit hands opened URLs and universal links to the scene delegate. application(_:open:options:) and application(_:continue:restorationHandler:) in AppDelegate aren't called anymore. If your scene delegate doesn't forward them to RCTLinkingManager, nothing crashes. Linking just never fires.
I found this in a wallet app that had already moved to scenes: its zcash: payment links stopped reaching JavaScript, both when the app was running and when the link launched it, because launchOptions was nil and the URL only arrived in the scene's connectionOptions (zingo-mobile#1595). If your app handles deep links, test them after the move: with the app running, and with the app closed.
A checklist
1. Check whether you've adopted scenes (the Info.plist test above).
2. Expo: SDK 57 with enableSceneSupport, or SDK 58. Bare React Native: plan the 0.88 upgrade.
3. List your dependencies against the libraries above and update or patch them before you build with Xcode 27.
4. Forward URLs and user activities from the scene delegate to RCTLinkingManager.
5. Build with Xcode 27 well before April. Test launch, every screen that presents a picker, menu or ad, and deep links from a cold start.
Check your app in one command
npx nativekeel
It reports whether the app has adopted the scene life cycle, which of your installed libraries read the window from the app delegate, and whether URL handlers are still only in AppDelegate. It runs locally, without an account, and doesn't upload your code. If you hit the crash already:
npx nativekeel explain "-[AppDelegate window]: unrecognized selector"
If you upgrade with an AI agent, the same checks are available over MCP, and there's a Claude Code plugin (claude plugin marketplace add AlicanAkyol/nativekeel), so the agent checks this before it starts changing versions. A longer reference with the sources is at nativekeel.com.
If you maintain one of the libraries above and want a hand with the fix, I'm happy to send a PR.
2 comments
Fix the flutterfire upload-crashlytics-symbols error
---
title: Fix the flutterfire upload-crashlytics-symbols error
published: true
date: 2026-10-07 00:00:00 UTC
tags: flutter, firebase, ios, opensource
canonical_url: saymyframe.com
---
flutter run works, flutter build ios works, and then flutter build ipa fails in the build phase that the FlutterFire CLI adds for Firebase Crashlytics. This flutterfire upload-crashlytics-symbols error says that the upload script of Crashlytics is missing. The script is on the disk, but when Xcode archives an app that uses Swift Package Manager, the phase looks for it in the wrong directory. The fix changes one path in the Xcode project, and you have to apply it again after every flutterfire configure.
"Could not find the Crashlytics upload symbols script" in flutter build ipa
The phase named FlutterFire: "flutterfire upload-crashlytics-symbols" uploads the dSYM files of the iOS app to Firebase Crashlytics. With Swift Package Manager, the archive stops in it:
Unhandled exception:
Exception: Could not find the Crashlytics upload symbols script at "/Users/<you>/Library/Developer/Xcode/DerivedData/Runner-<hash>/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run". This usually means CocoaPods or Swift Package Manager has not finished installing "FirebaseCrashlytics" yet, or it was installed to an unexpected location. Try cleaning and rebuilding the project.
#0 UploadCrashlyticsSymbols.run (package:flutterfire_cli/src/commands/upload_symbols.dart:368:7)
Command PhaseScriptExecution failed with a nonzero exit code
**ARCHIVE FAILED**
I got it with flutterfire_cli 1.4.1, the latest version when I wrote this, Flutter 3.44.2 and Xcode 27. The message suggests cleaning and rebuilding. Flutter 3.44 keeps the Swift packages somewhere else, so the script will not turn up in DerivedData however often you clean.
When it fails: flutter build ipa, but not flutter run
You have this case when:
- the Firebase packages of the app come through Swift Package Manager, which Flutter 3.44 uses by default, and not through CocoaPods;
- flutterfire_cli 1.4.1 configured the app on a Mac (it adds the phase only on macOS);
- flutter run and flutter build ios succeed, and the phase uploads the symbols;
- flutter build ipa fails. A comment in the upstream issue reports the same for Product > Archive in Xcode.
If flutter run fails too, with ProcessException: No such file or directory, an older flutterfire_cli wrote the phase. That case has its own section below.
The fix for the flutterfire upload-crashlytics-symbols error
The phase has the path $BUILD_DIR/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run twice. Replace both with $SRCROOT/../build/ios/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run. In the directory of the app:
ruby -e 'f = ARGV[0]; s = File.exist?(f) ? File.binread(f) : ""; t = s.gsub("$BUILD_DIR/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run", "$SRCROOT/../build/ios/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"); if t == s then puts "Nothing to fix in #{f}" else File.binwrite(f, t); puts "Fixed the Crashlytics phase in #{f}" end' ios/Runner.xcodeproj/project.pbxproj
It prints Fixed the Crashlytics phase in ios/Runner.xcodeproj/project.pbxproj, or Nothing to fix in ios/Runner.xcodeproj/project.pbxproj when the file has no such path, for example because you fixed it already. Nothing else in the project changes. You can make the same edit by hand in Xcode: the Runner target, Build Phases, the phase with the name above.
After that, flutter build ipa archives the app and the phase uploads the symbols. flutter run and flutter build ios work as before, because for them both paths are the same directory.
Two caveats:
- flutterfire configure writes the phase again when its script differs from the one it would write. Run the fix after every flutterfire configure.
- The new path assumes that Flutter builds into build. If you changed that with flutter config --build-dir, the path is wrong for you. Flutter exports FLUTTER_APPLICATION_PATH and FLUTTER_BUILD_DIR to the phase, so "${FLUTTER_APPLICATION_PATH}/${FLUTTER_BUILD_DIR}/ios/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run" should follow your setting. I have tried only the default.
Why the phase misses the Crashlytics upload script
The script of the phase looks for the upload script in four places, in this order:
1. $PODS_ROOT/FirebaseCrashlytics/run, for CocoaPods;
2. $BUILD_DIR/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run;
3. the same SourcePackages path in the DerivedData directory of the project;
4. whatever find turns up in $BUILD_DIR and in that DerivedData directory.
With Swift Package Manager, Flutter clones the packages of the app into build/ios/SourcePackages: it passes -clonedSourcePackagesDirPath to xcodebuild. For flutter run and flutter build ios it also passes BUILD_DIR=<app>/build/ios, so the second place has the script. For an archive it leaves BUILD_DIR alone, on purpose:
if (buildAction !=
XcodeBuildAction.archive) // dSYM files aren't copied to the archive if BUILD_DIR is set.
'BUILD_DIR=${globals.fs.path.absolute(buildDirectoryPath)}',
So during flutter build ipa, $BUILD_DIR is the one Xcode picks:
~/Library/Developer/Xcode/DerivedData/Runner-<hash>/Build/Intermediates.noindex/ArchiveIntermediates/Runner/BuildProductsPath
None of the four places has the script. The phase hands flutterfire the DerivedData path of the third place, and that is the path in the error. The stable branch of Flutter had the same lines on the day I wrote this.
$SRCROOT is the ios directory of the app. $SRCROOT/../build/ios/SourcePackages is where Flutter put the packages, whatever $BUILD_DIR says.
ProcessException: No such file or directory with flutterfire_cli 1.4.0 or older
The phase that flutterfire_cli 1.4.0 and older versions write knows only CocoaPods and DerivedData. With Flutter 3.44 and Swift Package Manager it fails in every iOS build, flutter run included:
Unhandled exception:
ProcessException: No such file or directory
Command:
/Users/<you>/Library/Developer/Xcode/DerivedData/Runner-<hash>/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run --validate --flutter-project .../app_id_file.json
Activating flutterfire_cli 1.4.1 does not fix it, because the old phase stays in the Xcode project. Activate it and configure the app again on a Mac, and the new phase replaces the old one:
dart pub global activate flutterfire_cli 1.4.1
flutterfire configure
Then apply the fix above, for flutter build ipa.
Where the fix stands in flutterfire_cli
The upstream issue is invertase/flutterfire_cli#443, open since May 2026. Version 1.4.1, from August, added the lookup in $BUILD_DIR/SourcePackages, which covers flutter run and flutter build ios. The comments of the issue describe the archive case, the latest of them from the end of September. Two open pull requests change the lookup: #444 and #456. #428 is about the same phase in macOS apps, which I have not tried.
When a release with one of them is out, activate it and run flutterfire configure again. You will not need the fix from this post then.
How SMF applies the fix after flutterfire configure
I ran into this while building SMF, a free, open-source Flutter project generator. The launch post of SMF 0.3 says what it does today and what it can't do yet. For an app with Firebase Crashlytics, SMF runs this fix on macOS right after flutterfire configure, and puts the command into the README of the app for the next time you configure it yourself. Its CI archives a generated app with flutter build ipa --no-codesign and the fixed phase. Another job runs the real flutterfire configure and fails when the phase no longer has the path that the fix replaces, so a change upstream shows up as a red job. The Firebase guide of SMF has the details.
Mentions
@NoheDev invertase/reeval Couldn't find the one which suited our needs (evaluating dev tools), so we built one 😬
After 6+ years of service firestore-ios-sdk-frameworks is now archived. The Firebase iOS SDK as of v13 is now SPM only. 🫡 invertase/firestore-ios-sdk-frameworks
Xcode 27 won't launch 93% of React Native apps: the UIScene change, and the libraries that crash after it On 9 September Apple announced that from April 2027, apps uploaded to App Store Connect must be built with the iOS 27 SDK, which means Xcode 27. Built with that SDK, an app that hasn't adopted the UIKit scene life cycle doesn't start. It stops at launch with: Application failed to launch: UIScene life cycle is required for apps built with this SDK. Apple announced the rule in TN3187. The check depends on the SDK you build with, not the iOS version on the phone. The same app built with Xcode 26 still runs on iOS 27, so nothing breaks for your users today. It breaks on the day you move to Xcode 27. I run a health check on several hundred open-source React Native and Expo apps (the set I use to test NativeKeel). As of 11 October 2026: | | Apps | |---|---| | React Native and Expo apps with an iOS target | 628 | | Not on the scene life cycle yet | 583 (93%) | | Largest groups | Expo SDK 57 (117), Expo SDK 54 (111) | That number isn't a judgment on those apps. Until a few weeks ago, no React Native or Expo template used scenes at all. Where React Native and Expo stand - React Native 0.88 is the first release whose template adopts it. SceneDelegate.swift starts React Native in the window scene, and Info.plist names it in UIApplicationSceneManifest. 0.88 is still a release candidate (rc.4 on 7 October). 0.87 and earlier have nothing in the template, so the path is to upgrade and copy both files from the Upgrade Helper. - Expo SDK 57 can opt in. It needs expo 57.0.23+ and expo-build-properties 57.0.20+: ["expo-build-properties", { "ios": { "enableSceneSupport": true } }] Then run npx expo prebuild again. - Expo SDK 58 (in beta since 15 September) generates the scene delegate by default. - SDK 56 and earlier need an SDK upgrade first. How do you know you've adopted it? Your Info.plist has a UIApplicationSceneManifest with scene configurations, or your app delegate implements application(_:configurationForConnecting:options:). A manifest that only sets UIApplicationSupportsMultipleScenes doesn't count. The part that bites after you adopt it: AppDelegate has no window In the 0.88 template the UIWindow belongs to the scene delegate. AppDelegate no longer has a window property at all. Many iOS libraries still find the screen to present on like this: UIViewController *root = [UIApplication sharedApplication].delegate.window.rootViewController; On the new template that line throws: -[AppDelegate window]: unrecognized selector sent to instance I searched the iOS sources of popular React Native libraries for this call made without a respondsToSelector: check, and found it in 15 that are still in use. Then I built a fresh React Native 0.88.0-rc.4 app and confirmed the crash with two of them, react-native-blob-util and react-native-google-mobile-ads. Both stopped crashing after one change: UIViewController *root = RCTPresentedViewController(); // or RCTKeyWindow().rootViewController Both fixes are open as pull requests (react-native-blob-util#498, react-native-google-mobile-ads#911). For @react-native-firebase/messaging, which makes the call at launch, a fix was already proposed upstream (react-native-firebase#9359). 68 of the 628 apps depend on at least one of these libraries. The most common: | Library | Apps | When it crashes | |---|---|---| | react-native-blob-util | 17 | presenting the open-in / options menu | | @react-native-firebase/messaging | 17 | at launch | | react-native-google-mobile-ads | 11 | showing banners, the consent form or the ad inspector | | react-native-date-picker | 9 | opening the modal picker | | react-native-image-crop-picker | 9 | opening the picker | | rn-fetch-blob | 7 | presenting the open-in menu | Until a release ships the fix, a patch-package patch with the line above works. The quiet one: deep links stop arriving With scenes, UIKit hands opened URLs and universal links to the scene delegate. application(_:open:options:) and application(_:continue:restorationHandler:) in AppDelegate aren't called anymore. If your scene delegate doesn't forward them to RCTLinkingManager, nothing crashes. Linking just never fires. I found this in a wallet app that had already moved to scenes: its zcash: payment links stopped reaching JavaScript, both when the app was running and when the link launched it, because launchOptions was nil and the URL only arrived in the scene's connectionOptions (zingo-mobile#1595). If your app handles deep links, test them after the move: with the app running, and with the app closed. A checklist 1. Check whether you've adopted scenes (the Info.plist test above). 2. Expo: SDK 57 with enableSceneSupport, or SDK 58. Bare React Native: plan the 0.88 upgrade. 3. List your dependencies against the libraries above and update or patch them before you build with Xcode 27. 4. Forward URLs and user activities from the scene delegate to RCTLinkingManager. 5. Build with Xcode 27 well before April. Test launch, every screen that presents a picker, menu or ad, and deep links from a cold start. Check your app in one command npx nativekeel It reports whether the app has adopted the scene life cycle, which of your installed libraries read the window from the app delegate, and whether URL handlers are still only in AppDelegate. It runs locally, without an account, and doesn't upload your code. If you hit the crash already: npx nativekeel explain "-[AppDelegate window]: unrecognized selector" If you upgrade with an AI agent, the same checks are available over MCP, and there's a Claude Code plugin (claude plugin marketplace add AlicanAkyol/nativekeel), so the agent checks this before it starts changing versions. A longer reference with the sources is at nativekeel.com. If you maintain one of the libraries above and want a hand with the fix, I'm happy to send a PR.
Fix the flutterfire upload-crashlytics-symbols error --- title: Fix the flutterfire upload-crashlytics-symbols error published: true date: 2026-10-07 00:00:00 UTC tags: flutter, firebase, ios, opensource canonical_url: saymyframe.com --- flutter run works, flutter build ios works, and then flutter build ipa fails in the build phase that the FlutterFire CLI adds for Firebase Crashlytics. This flutterfire upload-crashlytics-symbols error says that the upload script of Crashlytics is missing. The script is on the disk, but when Xcode archives an app that uses Swift Package Manager, the phase looks for it in the wrong directory. The fix changes one path in the Xcode project, and you have to apply it again after every flutterfire configure. "Could not find the Crashlytics upload symbols script" in flutter build ipa The phase named FlutterFire: "flutterfire upload-crashlytics-symbols" uploads the dSYM files of the iOS app to Firebase Crashlytics. With Swift Package Manager, the archive stops in it: Unhandled exception: Exception: Could not find the Crashlytics upload symbols script at "/Users/<you>/Library/Developer/Xcode/DerivedData/Runner-<hash>/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run". This usually means CocoaPods or Swift Package Manager has not finished installing "FirebaseCrashlytics" yet, or it was installed to an unexpected location. Try cleaning and rebuilding the project. #0 UploadCrashlyticsSymbols.run (package:flutterfire_cli/src/commands/upload_symbols.dart:368:7) Command PhaseScriptExecution failed with a nonzero exit code **ARCHIVE FAILED** I got it with flutterfire_cli 1.4.1, the latest version when I wrote this, Flutter 3.44.2 and Xcode 27. The message suggests cleaning and rebuilding. Flutter 3.44 keeps the Swift packages somewhere else, so the script will not turn up in DerivedData however often you clean. When it fails: flutter build ipa, but not flutter run You have this case when: - the Firebase packages of the app come through Swift Package Manager, which Flutter 3.44 uses by default, and not through CocoaPods; - flutterfire_cli 1.4.1 configured the app on a Mac (it adds the phase only on macOS); - flutter run and flutter build ios succeed, and the phase uploads the symbols; - flutter build ipa fails. A comment in the upstream issue reports the same for Product > Archive in Xcode. If flutter run fails too, with ProcessException: No such file or directory, an older flutterfire_cli wrote the phase. That case has its own section below. The fix for the flutterfire upload-crashlytics-symbols error The phase has the path $BUILD_DIR/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run twice. Replace both with $SRCROOT/../build/ios/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run. In the directory of the app: ruby -e 'f = ARGV[0]; s = File.exist?(f) ? File.binread(f) : ""; t = s.gsub("$BUILD_DIR/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run", "$SRCROOT/../build/ios/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"); if t == s then puts "Nothing to fix in #{f}" else File.binwrite(f, t); puts "Fixed the Crashlytics phase in #{f}" end' ios/Runner.xcodeproj/project.pbxproj It prints Fixed the Crashlytics phase in ios/Runner.xcodeproj/project.pbxproj, or Nothing to fix in ios/Runner.xcodeproj/project.pbxproj when the file has no such path, for example because you fixed it already. Nothing else in the project changes. You can make the same edit by hand in Xcode: the Runner target, Build Phases, the phase with the name above. After that, flutter build ipa archives the app and the phase uploads the symbols. flutter run and flutter build ios work as before, because for them both paths are the same directory. Two caveats: - flutterfire configure writes the phase again when its script differs from the one it would write. Run the fix after every flutterfire configure. - The new path assumes that Flutter builds into build. If you changed that with flutter config --build-dir, the path is wrong for you. Flutter exports FLUTTER_APPLICATION_PATH and FLUTTER_BUILD_DIR to the phase, so "${FLUTTER_APPLICATION_PATH}/${FLUTTER_BUILD_DIR}/ios/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run" should follow your setting. I have tried only the default. Why the phase misses the Crashlytics upload script The script of the phase looks for the upload script in four places, in this order: 1. $PODS_ROOT/FirebaseCrashlytics/run, for CocoaPods; 2. $BUILD_DIR/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run; 3. the same SourcePackages path in the DerivedData directory of the project; 4. whatever find turns up in $BUILD_DIR and in that DerivedData directory. With Swift Package Manager, Flutter clones the packages of the app into build/ios/SourcePackages: it passes -clonedSourcePackagesDirPath to xcodebuild. For flutter run and flutter build ios it also passes BUILD_DIR=<app>/build/ios, so the second place has the script. For an archive it leaves BUILD_DIR alone, on purpose: if (buildAction != XcodeBuildAction.archive) // dSYM files aren't copied to the archive if BUILD_DIR is set. 'BUILD_DIR=${globals.fs.path.absolute(buildDirectoryPath)}', So during flutter build ipa, $BUILD_DIR is the one Xcode picks: ~/Library/Developer/Xcode/DerivedData/Runner-<hash>/Build/Intermediates.noindex/ArchiveIntermediates/Runner/BuildProductsPath None of the four places has the script. The phase hands flutterfire the DerivedData path of the third place, and that is the path in the error. The stable branch of Flutter had the same lines on the day I wrote this. $SRCROOT is the ios directory of the app. $SRCROOT/../build/ios/SourcePackages is where Flutter put the packages, whatever $BUILD_DIR says. ProcessException: No such file or directory with flutterfire_cli 1.4.0 or older The phase that flutterfire_cli 1.4.0 and older versions write knows only CocoaPods and DerivedData. With Flutter 3.44 and Swift Package Manager it fails in every iOS build, flutter run included: Unhandled exception: ProcessException: No such file or directory Command: /Users/<you>/Library/Developer/Xcode/DerivedData/Runner-<hash>/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run --validate --flutter-project .../app_id_file.json Activating flutterfire_cli 1.4.1 does not fix it, because the old phase stays in the Xcode project. Activate it and configure the app again on a Mac, and the new phase replaces the old one: dart pub global activate flutterfire_cli 1.4.1 flutterfire configure Then apply the fix above, for flutter build ipa. Where the fix stands in flutterfire_cli The upstream issue is invertase/flutterfire_cli#443, open since May 2026. Version 1.4.1, from August, added the lookup in $BUILD_DIR/SourcePackages, which covers flutter run and flutter build ios. The comments of the issue describe the archive case, the latest of them from the end of September. Two open pull requests change the lookup: #444 and #456. #428 is about the same phase in macOS apps, which I have not tried. When a release with one of them is out, activate it and run flutterfire configure again. You will not need the fix from this post then. How SMF applies the fix after flutterfire configure I ran into this while building SMF, a free, open-source Flutter project generator. The launch post of SMF 0.3 says what it does today and what it can't do yet. For an app with Firebase Crashlytics, SMF runs this fix on macOS right after flutterfire configure, and puts the command into the README of the app for the next time you configure it yourself. Its CI archives a generated app with flutter build ipa --no-codesign and the fixed phase. Another job runs the real flutterfire configure and fails when the phase no longer has the path that the fix replaces, so a change upstream shows up as a red job. The Firebase guide of SMF has the details.