Skip to content

Flutter Firebase build errorFlutter: “Error: Member not found: ‘FirebaseAppPlatform.verifyExtends’”

A Flutter build stops with Error: Member not found: ‘FirebaseAppPlatform.verifyExtends’, pointing into firebase_core inside your .pub-cache. The project uses an old firebase_core, but pub resolved firebase_core_platform_interface 4.5.2 or later, which changed the internal API that old firebase_core calls. It usually appears when an older app is built again on a new machine or CI, or when one Firebase package is upgraded and the others are not.

Short answer

Upgrade every Firebase package together: flutterfire update (FlutterFire CLI) raises them all, or raise firebase_core and each firebase_ and cloud_ package in pubspec.yaml by hand, then flutter pub get and fix any compile errors. If you can’t upgrade yet, add a dependency override as a stopgap (plugin_platform_interface: ^2.1.3, which the FlutterFire maintainers suggest, or firebase_core_platform_interface: 4.5.1) and remove it after the upgrade.

Why the member is missing, and the fix

  1. 01

    An old firebase_core with a newer platform interface

    “change internal verifyToken API to verify” pub.dev, firebase_core_platform_interface 4.5.2 changelog

    firebase_core accepts newer releases of firebase_core_platform_interface, so a fresh pub get (a new machine, a CI cache miss, a deleted pubspec.lock) pulls the newest one it allows. Version 4.5.2 replaced the internal verify methods (FlutterFire pull request 9711) that older firebase_core releases still call, so the build breaks with no change in your code. The lasting fix is current Firebase packages.

    dart pub global activate flutterfire_cli
    flutterfire update
    # or by hand: flutter pub outdated, then raise firebase_core and every
    # firebase_ / cloud_ package in pubspec.yaml to the Resolvable or Latest column
    flutter pub get
    flutter run
  2. 02

    One Firebase package upgraded, the others left behind

    Upgrading firebase_messaging or firebase_auth on its own can pull the new interface while firebase_core stays old. Keep all FlutterFire packages on current versions at the same time, starting with firebase_core.

  3. 03

    You need a build today: a dependency override

    “You can use dependency_overrides to temporarily override all references to a dependency.” Dart, Package dependencies

    When you can’t update yet, the FlutterFire maintainers suggest overriding plugin_platform_interface; pinning firebase_core_platform_interface to 4.5.1 is the other workaround the issue thread confirms. Use one of them. Either keeps the whole app on old Firebase SDKs, so treat it as a stopgap and delete it once the packages are upgraded.

    # pubspec.yaml (stopgap only)
    dependency_overrides:
      plugin_platform_interface: ^2.1.3
      # or instead: firebase_core_platform_interface: 4.5.1

Checked against the vendor’s docs on : pub.dev: firebase_core_platform_interface changelog (4.5.2); FlutterFire issue #9806: Member not found after firebase_core_platform_interface 4.5.2; FlutterFire pull request #9711: verifyToken replaced by verify; Dart: Package dependencies (dependency_overrides).

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: Flutter pub “version solving failed” · Flutter “:app:compileFlutterBuildDebug” failed · Android google-services “version conflict” · Plugin “com.google.gms.google-services” not found

Questions

More on this error

Why did it break when nothing in my code changed?

Because pub picked newer versions of packages you don’t list yourself. A fresh clone, a CI cache miss or a deleted pubspec.lock runs version solving again. Commit pubspec.lock for apps so every machine builds the same versions.

The upgrade breaks other code. What then?

Upgrade firebase_core first, then each Firebase plugin, and fix the compile errors flutter analyze lists after each step. Each plugin’s changelog on pub.dev lists its breaking changes.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.