[Pixette]

What does this PR do?

Moves firebase_core_tvos and every Firebase tvOS port that depends on it to Swift Package Manager together, as asked in the first review. Each gets a tvos/Package.swift, so flutter-tvos links it through SwiftPM and leaves it out of the Podfile.

package_info_plus_tvos moved to its own PR, #31.

Package(s) touched: firebase_core_tvos 0.0.4, cloud_firestore_tvos 0.0.2, cloud_functions_tvos 0.0.2, firebase_analytics_tvos 0.0.2, firebase_app_check_tvos 0.0.3, firebase_auth_tvos 0.0.2, firebase_crashlytics_tvos 0.0.3, firebase_messaging_tvos 0.0.2, firebase_performance_tvos 0.0.2, firebase_remote_config_tvos 0.0.2, firebase_storage_tvos 0.0.2. firebase_ai_tvos is left out: it has no core or Firebase SDK dependency.

What changed, by review point:

• Dependents on core: all ten move to SwiftPM in this PR and depend on .package(path: "../firebase_core_tvos"). FirebaseCore is linked once.
• Core constraint: every dependent now requires firebase_core_tvos: ^0.0.4.
• Firebase range: .upToNextMinor(from: "12.15.0") in every manifest, matching the podspecs' ~> 12.15.0.
• REGISTER_LIB: it was not defined under SwiftPM. A #warning probe confirmed it. firebase-ios-sdk vends no FirebaseCoreExtension product, so neither __has_include can match. FLTFirebasePluginRegistry.m now declares +[FIRApp registerLibrary:withVersion:] itself in that case and checks respondsToSelector: before calling it. On the simulator, Firebase's user agent then lists the registered libraries (core-tvos 0.0.4, appcheck, auth-tvos, cls, fcm-tvos, rc) and deploy/swiftpm.
• README and CHANGELOG: they now say flutter-tvos links a plugin that ships tvos/Package.swift through SwiftPM and leaves it out of the Podfile. The READMEs name flutter-tvos 1.3.0 as the minimum.
• LIBRARY_VERSION: in the four Objective-C ports (core, auth, firestore, messaging) it matches each new package version. The Swift ports keep upstream's versionNumber.

Target layout: Swift-only ports are one Swift target. core, auth, messaging and firestore are one Objective-C target each. Crashlytics 5.3.0 mixes Swift and Objective-C, so its sources are split into two folders and two targets, as upstream FlutterFire does. The Objective-C ports gained a <firebase_core/...> import branch, the header path under SwiftPM. The podspecs are kept and still match the sources.

How was it tested?

• Ran the packages' example/ apps (built all 11)
• Verified on tvOS simulator (version: tvOS 27.0, Xcode 27.0, Apple TV 4K 3rd generation)
• Verified on a physical Apple TV (model / tvOS version: ___)
• dart analyze is clean for every touched package and example (only infos in example code that this PR doesn't touch)

All builds use flutter-tvos 1.11.0 with flutter-tvos build tvos --simulator:

• core alone, debug
• each of the ten dependents with only core next to it, debug
• the example/ app of all 11 packages, debug
• all 11 ports in one app, debug and release

In every build: 0 pods in Podfile.lock, the FIRApp class defined once across the binary and embedded frameworks, firebase-ios-sdk resolved to 12.15.0.

On the simulator, the all-ports app ran Firebase.initializeApp and called each dependent plugin. Analytics, App Check, Auth, Crashlytics, Firestore, Messaging, Performance and Remote Config returned. Functions and Storage returned server errors (not-found, object-not-found), so their native side answered. No MissingPluginException.

CI steps run locally for all 11 packages: check_repo.py . and --selftest, release_plan.py, flutter pub get, dart analyze, flutter test, flutter pub publish --dry-run (no warnings). I used Flutter 3.44.6 (CI pins 3.44.0) and 3.47.5.

Not tested: a CocoaPods-only build of the podspecs, and a physical Apple TV.

Versioning & changelog

• Bumped version: in each package's pubspec.yaml, with each podspec's s.version to match
• Added a matching entry at the top of each CHANGELOG.md, under a heading identical to the new version
• The entries call out the behaviour change: the package is linked through SwiftPM and left out of the Podfile. No API change.
• Patch bumps, as in the June SwiftPM pass

Checklist

• Only the Firebase ports are touched
• No secrets, absolute local paths, or TODO/debug leftovers in the diff
• Sibling packages: firebase_ai_tvos is unaffected (no core dependency)

Notes for reviewers

Publish order matters. The dependents need firebase_core_tvos 0.0.4 on pub.dev before they can resolve. Until then, each dependent has a pubspec_overrides.yaml (root and example/) that points at the in-repo core, so CI resolves. Each file says it can be deleted once core 0.0.4 is published, and .pubignore keeps it out of the archive. release.yml publishes candidates in parallel, so core should go first. Published users are safe meanwhile: every published dependent caps core below 0.0.4, so pub never pairs core 0.0.4 with an old podspec-only port. If you'd rather avoid the overrides, I can split this into core 0.0.4 first and the ten dependents after it is published.

Example apps: four examples pinned upstream versions that no core_tvos from 0.0.3 on accepts. They moved to the first versions that do: firebase_core 4.14.0, firebase_analytics 12.4.6, cloud_functions 6.3.6, firebase_performance 0.11.4+6, firebase_remote_config 6.5.6. All are within the packages' own constraints.

Firebase 12.15.x: with .upToNextMinor, an app that also takes another SwiftPM package needing firebase-ios-sdk 12.16 or later cannot resolve. Moving the floor is a separate decision, so I kept 12.15 to match the podspecs.

Messaging privacy manifest: Resources/PrivacyInfo.xcprivacy is not shipped under SwiftPM or CocoaPods today. That predates this PR. I can add it as a SwiftPM resource in a follow-up.

🤖 Generated with Claude Code

[MAUstaoglu]

Thanks for this! The package_info_plus_tvos part looks good, but the firebase part breaks builds as it stands.

Blocking

1. Other firebase pods can't find firebase_core_tvos. flutter-tvos's Podfile skips any plugin that ships a tvos/Package.swift. Nine other ports still declare s.dependency 'firebase_core_tvos' in their podspecs: auth, firestore, functions, app_check, crashlytics, messaging, performance, remote_config and storage. With core 0.0.4, an app that uses any of them fails pod install with "Unable to find a specification for firebase_core_tvos". Even if it resolved, FirebaseCore would be linked twice, once through SwiftPM and once through CocoaPods. The firebase ports need to move to SwiftPM together.
2. firebase_analytics_tvos still pins firebase_core_tvos: ^0.0.1. For a 0.0.x version, that means exactly 0.0.1, which has no Package.swift, so .package(path: "../firebase_core_tvos") can't resolve. An app that also follows the core README (^0.0.4) fails pub get with a version conflict. It should be ^0.0.4.

Should fix

• Firebase version range: .package(url: firebase-ios-sdk, from: "12.15.0") accepts any 12.x, while the podspecs' ~> 12.15.0 only accepts 12.15.x. .upToNextMinor(from: "12.15.0") matches the podspec.
• Library registration under SwiftPM: FLTFirebasePluginRegistry.m only calls registerLibrary when FIRAppInternal.h can be found. Please confirm REGISTER_LIB is still defined in a SwiftPM build. If it isn't, registration is skipped silently.
• README and CHANGELOG: they say CocoaPods projects keep using the podspec and that nothing changes. In flutter-tvos, a plugin that ships a Package.swift is always linked through SwiftPM and skipped by the Podfile.
• LIBRARY_VERSION: it is still "0.0.1", while the package is now 0.0.4.

Suggestion

Could you split package_info_plus_tvos into its own PR? That part can be merged as is. Then move the firebase ports to SwiftPM together in a separate PR, with the core dependency raised to ^0.0.4.

[Pixette]

Thanks for the careful review. You were right on every point. I reworked the PR:

• Split: package_info_plus_tvos is now feat(spm): Package.swift for package_info_plus_tvos #31, with its example app regenerated so it builds with the Package.swift.
• Blocking 1: all ten ports that depend on firebase_core_tvos move to SwiftPM here, together with core. FirebaseCore is linked once.
• Blocking 2: every dependent requires firebase_core_tvos: ^0.0.4.
• Firebase range: .upToNextMinor(from: "12.15.0") everywhere.
• REGISTER_LIB: good catch, it was not defined under SwiftPM, so registration was silently skipped. A #warning probe confirmed it. firebase-ios-sdk vends no FirebaseCoreExtension product, so the registry now declares +[FIRApp registerLibrary:withVersion:] itself when neither header is found, and checks respondsToSelector: first. On the simulator, Firebase's user agent now lists the registered libraries.
• README and CHANGELOG: fixed. The READMEs also name flutter-tvos 1.3.0 as the minimum.
• LIBRARY_VERSION: core's is now 0.0.4, and the other Objective-C ports match their new versions too.

This time I tested much more before pushing:

• Core alone, each dependent alone with core, every package's example app, and all 11 together in debug and release.
• No pods, one FIRApp, firebase-ios-sdk 12.15.0 in every build.
• The all-ports app runs on the tvOS simulator and every plugin answers its calls.
• The CI steps pass locally, including pub publish --dry-run.

One thing to decide: core 0.0.4 has to reach pub.dev before the ten dependents. Until then they resolve through pubspec_overrides.yaml files, kept out of the archives by .pubignore. If you prefer, I can split this into core first and the dependents after. Details are in the PR description.

[MAUstaoglu]

Thanks for the thorough rework: every point from the earlier review is addressed, and CI is green. firebase_core_tvos 0.0.4 will be published before the dependents.