DEV Community: Yevhen Beshkarov

Fix the flutterfire upload-crashlytics-symbols error

Yevhen Beshkarov — Wed, 07 Oct 2026 00:00:00 +0000

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:

$PODS_ROOT/FirebaseCrashlytics/run, for CocoaPods;
$BUILD_DIR/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run;
the same SourcePackages path in the DerivedData directory of the project;
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.

SMF 0.3: an open-source Flutter project generator

Yevhen Beshkarov — Tue, 29 Sep 2026 00:00:00 +0000

Say My Frame (SMF) is a free, open-source Flutter project generator whose modules are checked together: its CI generates apps from many combinations of them and analyzes each one. It also sets up Firebase Crashlytics and Analytics all the way to flutter build ipa. You choose what the app needs, such as go_router, tabs at the bottom, get_it, and BLoC or Riverpod, and smf create generates a Flutter project in which these parts already work together. Version 0.3 is out on pub.dev. It does less than the word "generator" might promise, so this post is about what it does today, what it can't do yet, and where I want to take it.

dart pub global activate smf_flutter_cli
smf create my_app --org com.example -m home,bottom_tabs,get_it,bloc --no-input

What you get is a regular Flutter project. It has no SMF package in its dependencies, and nothing in it has to be generated again, so the code is yours from the first commit.

Why SMF 0.3 is a rewrite

SMF 0.1 came out in August 2025, and 0.2 followed in September. Each module brought its own templates, and an engine patched the shared files. It worked for the combinations I had tried.

This September I ran the published 0.2 with Flutter 3.44. It reported success and generated apps that did not build. Some modules assumed go_router or get_it, and CI back then never generated an app or ran the analyzer, so nothing caught it.

0.3 starts from one rule: modules do not know each other.

What the Flutter project generator does today

Modules name roles, not other modules

The start screen needs a router, not go_router. The analytics module logs screen views when the app has a router, whichever router that is. SMF calls these shared parts roles, and there are eight of them: app entry, router, layout, state management, dependency injection, events, crash reporting and analytics. A role can have more than one provider. BLoC and Riverpod both provide state management.

Modules don't edit files either. Shared files, such as bootstrap.dart, have sockets: named places where modules put code without knowing who else puts code there. This is how firebase_analytics hands the router a listener of the screen, and only when the app has a router:

const SocketContribution.item(
  RouterRole.screenListeners,
  Fragment(
    'logFirebaseScreenView',
    imports: [
      ImportRef.app(
        'core/analytics/firebase_analytics_service.dart',
        show: ['logFirebaseScreenView'],
      ),
    ],
  ),
  when: {routerRole},
),

Before it writes a single file, smf create checks the rules. A module may put code only into the sockets of its own roles, of the app entry and of the modules it depends on, and every file of the app has exactly one owner. The tests of every module run the same checks. CI then generates apps from combinations of the modules, 18 of them for the modules of the CLI when I wrote this, runs flutter analyze on each one and runs tests in some of them. The module model and module independence pages of the docs go deeper.

Firebase Crashlytics and Analytics, set up all the way to `flutter build ipa`

Three modules bring Firebase: firebase_core, firebase_crashlytics and firebase_analytics. Before it generates anything, SMF checks the machine for the Firebase CLI, a Firebase login and the FlutterFire CLI. In a terminal it offers to set up what is missing, and asks first. After generation it offers to run flutterfire configure with the ids of the app.

Two details took longer than the rest. With a router, firebase_analytics logs one screen view for each screen the user sees, tab switches included. And on macOS, SMF fixes the Crashlytics build phase that flutterfire_cli 1.4.1 adds, because flutter build ipa fails in that phase when the app uses Swift Package Manager. That story gets a post of its own. Until then, the Firebase guide has the details.

A Flutter app with go_router, tabs, get_it and BLoC or Riverpod

With -m home,bottom_tabs,get_it,event_bus, SMF adds two more modules and tells you why:

Adding flutter_core: the only provider of the app entry role, which every app needs.
Adding go_router: the only provider of the router role, which home requires.

Screens navigate with context.nav.home.home().go(), which doesn't mention go_router. Code that needs a service asks the ServiceLocator of the DI role, which doesn't mention get_it. With bottom_tabs, the destinations of the features become tabs of a NavigationBar, and each tab keeps its own stack. bootstrap() runs the start-up code of the modules in four phases before the first frame. The Android and iOS projects are the ones flutter create writes in Flutter 3.44.

The tour of a generated app goes file by file and names the module that wrote each one.

A plan before anything is written

--explain prints what would be generated and stops. It lists the modules and why each is there, the roles, the dependencies, the commands that would run after generation and the state of the machine:

Modules
  home: requested
  bottom_tabs: requested
  get_it: requested
  event_bus: requested
  flutter_core: the only provider of the app entry role, which every app needs
  go_router: the only provider of the router role, which home requires

Roles
  Layout: bottom_tabs
  Dependency injection: get_it
  Events: event_bus
  App entry: flutter_core
  Router: go_router

For scripts and CI there are --no-input, --skip-external-setup, --strict and exit codes: 0, 1, 64, 70 and 130. SMF renders the app in memory and finishes it in a temporary directory, so a run that fails or that you cancel leaves no half-made app in your project. The reference of smf create lists every option.

Modules of your own

Modules are Dart packages built on smf_contracts, and yours follow the same rules as the built-in ones. The contract harness in smf_pipeline generates in memory every app that matters for your module and checks it. To generate apps with your module, you write a small command of your own with runCli and smfModules. Extending SMF shows how, and one of its pages builds a counter feature with BLoC and Riverpod variants from start to end.

What SMF 0.3 can't do yet

The app you get is a skeleton. There is one feature module, home, a start screen with the name of the app. The tab bar stays hidden until a second screen is a destination, so after smf create you see one screen.
There are no modules for sign-in, networking, localization or theming. The list has eleven modules, and I wanted the foundation to hold before adding more.
SMF creates new apps. It can't add a module to an app you already have.
It generates Android and iOS apps for Flutter 3.44 or newer and Dart 3.12 or newer.
flutterfire configure needs you at the keyboard to log in and pick a Firebase project. In CI, SMF leaves it for later and prints the command.

Where it's going

Two things are next on my list: modules with real screens, and a way to add modules to an app that already exists. There are no dates. SMF is a side project, and I'd rather ship things when they work.

If you have a module in mind, tell me which one on Discord or in GitHub Issues.

Upgrading from 0.2

The state manager is a module now: -m bloc or -m riverpod instead of -s.
--start replaces -r and --route.
--strict and --on-conflict are options of create now, so they go after it: smf create my_app --strict.
Tabs at the bottom are a module of their own, bottom_tabs.
The module API of smf_contracts is new, so modules written for 0.2 need a rewrite.
Apps generated by 0.2 stay as they are. SMF generates an app once and never touches it again.

The same list, with what's new in 0.3, is in the release notes of SMF 0.3.0 on GitHub.

Try the Flutter project generator

dart pub global activate smf_flutter_cli
smf create

SMF is tested on macOS, Linux and Windows. The documentation starts with installation and your first app, the Say My Frame site shows the roles and modules at a glance, and the code is on GitHub. Stars there are welcome, but only if you actually like it.