fix(firebase_core_tvos): regenerate Pigeon for the 14-element payload and drop the interface pin

[TheNoumanDev]

The problem

firebase_core_platform_interface 8.1.0 removed recaptchaSiteKey from CoreFirebaseOptions, shortening the Pigeon payload:

interface	payload
7.0.0, 7.0.1	14 elements — predates the field
7.1.0, 8.0.0	15 elements
8.1.0, 8.1.1	14 elements — field removed

0.0.2 pinned to the 15-element window (>=7.1.0 <8.1.0). That stopped the crash but froze the package below current firebase_core, which declares ^8.1.0 from 4.13.0 on. This regenerates instead, so the pin can go.

// removed — index 14 on a 14-element list, via a bare NSArray subscript
pigeonResult.recaptchaSiteKey = GetNullableObjectAtIndex(list, 14);

Sources

firebase_core 4.13.0 — the last release whose iOS implementation is still Objective-C (4.14.0 rewrote it in Swift), and the first on the 14-element payload.

Diffed before copying; the delta is exclusively recaptchaSiteKey — 18 lines in messages.g.m, 7 in messages.g.h, 3 in FLTFirebaseCorePlugin.m. Nothing tvOS-specific lived in them.

Constraints

firebase_core_platform_interface: ^8.1.0, matching what firebase_core declares for itself. A closed window was considered and rejected: arity moved during one add/remove cycle — 7.1.0 added recaptchaSiteKey for reCAPTCHA support that was "gradually rolling out", 8.1.0 withdrew it when that moved to the provider API — across 23 published minor lines. If it moves again firebase_core breaks identically, so a caret keeps this package in step with upstream.

firebase_core: ^4.13.0 — earlier releases ship a native side expecting 15 elements.

Verified

$ python3 .github/scripts/check_repo.py .   # OK — 25 packages
$ flutter pub get                           # firebase_core=4.14.0  interface=8.1.1
$ dart analyze                              # 8 infos, all avoid_print in the example
$ flutter test                              # All tests passed!
$ flutter pub publish --dry-run             # clean once committed

Payload arity: Dart _toList 14 entries ↔ native fromList: indices 0–13 ↔ native toList 14 entries.

Not verified on hardware — measured at the protocol level, not observed as a working Firebase.initializeApp(options: ...) on an Apple TV.

Dependents and release order

The ten Firebase _tvos packages declare firebase_core_tvos: ^0.0.1, which admits 0.0.3 — no constraint bumps needed elsewhere.

This must publish before firebase_app_check_tvos can be widened past its firebase_app_check: ">=0.4.5 <0.4.6" pin: 0.4.7 requires firebase_core ^4.14.0 → interface ^8.1.1, which only resolves once 0.0.3 is out. That package also needs the getTokenResult handler and the 5th activate argument noted on #18 — not in this PR.

[TheNoumanDev]

@MAUstaoglu @DenisovAV — could you take a look? This is the last blocker before we can use the tvOS plugins in our app, now that it's on Flutter 3.47.1 with firebase_core 4.14.0 / interface 8.1.1.

Once it's published, I'll follow up on firebase_app_check_tvos — its pin can only widen after 0.0.3 is out.

[MAUstaoglu]

Thanks, this looks good. I diffed the three native files against firebase_core 4.13.0 and they match exactly. Nothing else in the repo still uses recaptchaSiteKey or the old makeWithApiKey: signature. A few small things:

1. CHANGELOG is too long. Our entries are short and just say what changed (see 0.0.2). Please cut it to 3–4 lines: the regenerated Pigeon files, the new ^8.1.0 constraint, and the new minimum firebase_core. The history and release-note quotes fit better in the PR description.
2. Remove the "Breaking" label. Users on older firebase_core still resolve to 0.0.2, so nobody's build breaks. If it really were breaking, the version should go to 0.1.0 instead of 0.0.3.
3. example/pubspec.yaml still says firebase_core: ^4.11.0. Please bump it to ^4.13.0 so it matches the package.
4. Stale comments in other examples (can be a follow-up). Several examples still pin firebase_core: 4.11.0 with comments about the 15-field payload (analytics, ai, app_check, crashlytics, performance, remote_config, cloud_functions). They still resolve, but the comments will be out of date once this is published.
5. Please test on the simulator before we publish. Run the example with flutter-tvos run on an Apple TV simulator and confirm Firebase.initializeApp(options: ...) returns without errors. Checking the payload length alone isn't enough.

About the ^8.1.0 range: I'm fine with it. If a future version adds a field at the end, our native code just ignores it. Only removing a field crashes, and that's rare enough that tracking upstream is worth it.

[TheNoumanDev]

Hey @MAUstaoglu, updated PR with your points and also tested it against the simulator, works fine.