[MAUstaoglu]

Why

The weekly Upstream compatibility run of 2026-10-19 (39239870688) failed on the four Firebase rows. FlutterFire released firebase_core 5.0.0, firebase_auth 7.0.0, firebase_messaging 17.0.0 and firebase_storage 14.0.0 on 2026-10-15, followed by 5.1.0, 7.0.1, 17.0.1 and 14.0.1 on 2026-10-23. Their platform interfaces now require firebase_core ^5.0.0.

• Our auth, messaging and storage packages required firebase_core ^4.0.0, so the new majors did not resolve with them.
• firebase_core_watchos failed only the new-major check against tool/upstream_versions.yaml.

What changed upstream (Dart surface)

• firebase_core 5.x: native SDK moves (Apple SDK 13, Android BoM 35). initializeApp(demoProjectId:) now builds placeholder options in a valid format. firebase_core_platform_interface is unchanged at 8.1.1.
• firebase_auth 7.0.x, platform interface 9.1.1–9.1.2:
  • The method-channel streams forward a signed-out first native callback and skip a null that follows a null.
  • User.updateProfile passes only the fields it is given.
• firebase_messaging 17.0.x, platform interface 4.11.x:
  • New register, unregister, onRegistered and onUnregistered (Firebase Installation ID registration).
  • getToken, onTokenRefresh and deleteToken are deprecated.
  • Apple-only changes to background-message handling.
• firebase_storage 14.0.x, platform interface 6.0.8–6.0.9:
  • The method-channel task keeps metadata in error snapshots.
  • putString keeps the custom metadata of a data URL.

What changed here

Package	Version	Dependencies	Behaviour
firebase_core_watchos	0.1.1 → 0.1.2	unchanged (firebase_core_platform_interface: ^8.0.0)	none; README and example on firebase_core 5.1.0
firebase_auth_watchos	0.1.1 → 0.2.0	firebase_core: ^5.0.0, firebase_auth_platform_interface: ^9.1.1	the change streams no longer repeat their first value for the SDK's listener install call, or a signed-out state, and still report a sign-out that install call carries
firebase_messaging_watchos	0.1.1 → 0.2.0	firebase_core: ^5.0.0, firebase_messaging_platform_interface: ^4.11.0	the four FID registration members are not implemented yet (UnimplementedError)
firebase_storage_watchos	0.1.1 → 0.2.0	firebase_core: ^5.0.0, firebase_storage_platform_interface: ^6.0.8	none

tool/upstream_versions.yaml moves the Firebase rows to 5.1.0, 7.0.1, 17.0.1 and 14.0.1, in the same commit as every README snippet. The examples move to the new majors. Each package has a CHANGELOG entry, and the README and PORTING_REPORT.md are updated.

Decisions

• Auth, messaging and storage support only the new majors. The interface versions that work with firebase_core 5 require it, and the app-facing packages move together. Apps on the old majors keep 0.1.1.
• firebase_core_watchos gets a patch release, 0.1.2. Its dependencies did not change. It works with firebase_core 4.12.1 and later, and with 5.x.
• Auth streams match upstream. The SDK calls each listener once when the plugin installs it, with the user it has when the call runs, and that bumps the native counter. A stream subscribed before any other auth call therefore emitted its first value twice. Before, a listen that navigates on each event could navigate twice on the watch.
  • A move that is only that install call is now left out when it reports the value the stream last emitted.
  • It is still emitted when the user changed before the call ran. The auth-state listener reports a uid only once, so for authStateChanges it can be the only report of a sign-out.
  • As in 7.0.1, a null that follows a null is skipped.
• The FID registration API is not implemented on the watch yet. It needs FIRMessaging's registerWithCompletion: and unregisterWithCompletion:, which arrived in Firebase Apple SDK 12.16.0. The watch links 11.x (Package.resolved pins 11.15.0). Moving the native SDK needs its own Simulator and device check.
• No native code changes. The newer Apple SDK that the new majors use on iOS and macOS (13.x with Swift Package Manager, 12.19.x with CocoaPods) does not apply to the watch.

Tests

• firebase_auth_watchos, 13 → 23:
  • each of authStateChanges, idTokenChanges and userChanges through a signed-in start, a signed-out start, and a sign-out that the install call carries;
  • updateProfile forwarding an explicit null.
  • The existing stream test now starts after the install call, as the native counters do.
• firebase_messaging_watchos, 15 → 16: the four FID registration members throw UnimplementedError and make no native call.
• firebase_storage_watchos, 14 → 15: putString (base64, as 14.0.1 sends a data URL) hands the custom metadata to the native upload.
• firebase_core_watchos: 8, unchanged.

Verification

Run locally with Flutter 3.47.5 and Dart 3.13.4, the CI pin:

• pub get for the four packages, and dry-run resolution of the four examples against the new majors. CI's flutter pub get also resolves each ./example.
• dart format on the four packages.
• check_versions, check_readme_snippets, check_example_constraints, symcheck, check_test_names, check_words.sh and check_generated_ignored.sh.
• dart pub publish --dry-run: 0 warnings for each of the four packages.
• Format, versions, README snippets, test names and words were checked at every commit.

Not run locally:

• flutter analyze, flutter test and pana. The Mac had under 15 GiB of space left on its data volume, and this lane's rule is to run no heavy job then. This PR's CI runs analyze and test, and the upstream workflow's pana job scores the packages.
• The examples were not rebuilt on the Simulator. The CHANGELOGs, READMEs and porting reports say so.

Two independent review passes read the diff against the upstream sources. Their findings are fixed in this branch:

• the SDK version of the FCM registration API;
• the updateProfile claim about the server;
• the duplicate first user;
• a sign-out that the install call carries;
• per-commit consistency;
• wording.

Three native findings are left for a follow-up, because they need a Simulator build:

• the current-user snapshot reads the user before the counters;
• after FirebaseApp.delete() and a re-created app of the same name, the listeners are not installed again;
• idTokenChanges and userChanges can still emit a signed-in user twice when the SDK restores or signs in that user while the listeners are installed. The CHANGELOG and the porting report list this as a known difference. Installing the listeners from a later main-queue block would remove it.

After merge

• Publish firebase_core_watchos 0.1.2 first, then the three 0.2.0 packages, and record them in tool/published.yaml.
• Until then, the upstream job's "from pub.dev" resolution keeps failing for auth, messaging and storage, because 0.1.1 needs firebase_core 4.
• The games_services row also stays red until games_services_watchos 0.2.0 is published.