spm: enable Mac Catalyst for FirebasePerformance and FirebaseInAppMessaging (discussion)

[mikehardy]

Speculative / discussion draft PR. Opening this to ask maintainers whether the current SPM-under-Catalyst behavior for Firebase Performance and Firebase In-App Messaging is intentional and permanent, and — if not — whether a change like this (with any additional source or CI work that Google requires) is worth polishing into a real proposal.

Summary

Under SPM on Mac Catalyst, the umbrella .target entries FirebasePerformanceTarget and FirebaseInAppMessagingTarget gate their real product dependencies with .when(platforms: [.iOS, ...]) that omits .macCatalyst. The consequence is that a Mac Catalyst app that lists FirebasePerformance / FirebaseInAppMessaging as SPM products only links the empty SwiftPM-PlatformExclude/*Wrap dummies (FirebasePerformanceTarget.o / FirebaseInAppMessagingTarget.o) and never compiles the real modules.

This draft adds .macCatalyst to the platform conditions for Performance and In-App Messaging wrap-target dependencies. Firebase App Distribution is intentionally left iOS-only in this draft (App Distribution's model is genuinely iOS-tester-only).

Concretely:

     .target(
       name: \"FirebaseInAppMessagingTarget\",
       dependencies: [
-        .target(name: \"FirebaseInAppMessaging\", condition: .when(platforms: [.iOS, .tvOS])),
+        .target(name: \"FirebaseInAppMessaging\",
+                condition: .when(platforms: [.iOS, .tvOS, .macCatalyst])),
       ],
       path: \"SwiftPM-PlatformExclude/FirebaseInAppMessagingWrap\"
     ),
...
     .target(
       name: \"FirebasePerformanceTarget\",
       dependencies: [.target(name: \"FirebasePerformance\",
-                             condition: .when(platforms: [.iOS, .tvOS, .visionOS]))],
+                             condition: .when(platforms: [.iOS, .tvOS, .visionOS, .macCatalyst]))],
       path: \"SwiftPM-PlatformExclude/FirebasePerformanceWrap\"
     ),

The Package already declares .macCatalyst(.v15) in `Package.platforms` and uses .macCatalyst alongside .iOS / .tvOS / .macOS for many other targets (Auth, Firestore, Analytics helpers, GoogleAppMeasurementIdentitySupport, etc.), so the style matches existing precedent in the same file.

Questions for maintainers

1. Was omitting .macCatalyst for FirebasePerformanceTarget and FirebaseInAppMessagingTarget under SPM intentional and permanent?
2. If not permanent, would a real (non-draft) PR along these lines have a chance once any additional source guards / CI matrix updates you require are in place?
3. Is there context I'm missing about historical Catalyst issues specific to these two products (Performance instrumentation, IAM UI presentation) that motivated the SPM-only exclusion? The CocoaPods podspecs are s.ios + s.tvos, and Catalyst apps consuming those via CocoaPods historically got the iOS slice through the Firebase/Firebase.h umbrella — so this is asking why SPM diverges.

Compile fitness note (speculative — please treat as discussion)

I have not verified full build-and-link of a Catalyst target against this Package.swift on Google's CI matrix. Notes on source-level fitness:

• Firebase Performance: the sources already handle Catalyst explicitly for CoreTelephony, e.g. `FirebasePerformance/Sources/FPRNanoPbUtils.h`:
  ```objc
  #if __has_include("CoreTelephony/CTTelephonyNetworkInfo.h") && !TARGET_OS_MACCATALYST
  ```
  and MobileCoreServices / QuartzCore link settings are already .when(platforms: [.iOS, .tvOS]) (Catalyst has both frameworks available).
• Firebase In-App Messaging: many .m sources gate on TARGET_OS_IOS || TARGET_OS_TV || TARGET_OS_VISION. TARGET_OS_IOS is 1 under Mac Catalyst (Catalyst is an iOS-derived variant), so these guards should pass on Catalyst. There is a separate FirebaseInAppMessaging_iOS sub-target (resources) that is .when(platforms: [.iOS]) and remains iOS-only; I did not attempt to broaden it here.

If Google CI reveals additional source-level Catalyst issues (availability annotations, missing UIKit-on-macOS APIs, IAM display flows, etc.) I'm happy to iterate on this branch, or to close it and let the team address it in whatever way fits your roadmap. The main ask is the policy question above.

Consumer context (why this came up)

React Native Firebase supports Mac Catalyst demos in its release qualification. In invertase/react-native-firebase#8933 we're qualifying an SPM-first path (SPM as the default resolver). On Catalyst:

• SPM path (current upstream): correctly honors these platform conditions and links only the wrap dummies. The RNFB Objective-C++ modules that @import FirebasePerformance; / @import FirebaseInAppMessaging; therefore fail to compile on Catalyst.
• CocoaPods path (historical): Catalyst apps consumed the iOS podspecs and the RNFB modules compiled and linked through the Firebase/Firebase.h umbrella. So this worked historically without any RNFB-side change.

We're going to land RNFB-side stubs on Catalyst for those two products regardless (mirroring what App Distribution already does), and cite this PR from those stub comments. But the root question — whether upstream SPM's exclusion is intentional — belongs here.

Related: invertase/react-native-firebase#8933.

Not in scope

• No source, header, or CI changes.
• No change to Firebase App Distribution (kept iOS-only — App Distribution's testers-workflow is genuinely iOS-only in practice).
• No podspec changes.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

[mikehardy]

Hey you all 👋 similar to my last post over here (on a Storage race condition thing) - I am driving an agent harness to post this stuff, but I'm doing my best to make sure it's not slop ;-)

This is a real question, and macCatalyst really did seem to work for these products via Cocoapods. It also compiled and appeared to work for App Distribution via Cocoapods but on reflection that didn't seem to make sense (App Distribution for a "desktop app" isn't really a thing is it? Even if getting to "desktop" from "ios compat" which is how I think of the macCatalyst build type)

So I didn't propose for App Distribution, but perf and in-app-messaging seem like they should be okay

Also similar to before I get completely snowed under by github notifications but I would love to collaborate if it's useful and am available via direct pings in email or gmail chat or similar

Cheers

[ncooke3]

Thanks, @mikehardy! At this time, I would prefer not to expand our supported surface area for Performance and In-App Messaging. Since neither product is currently supported on macOS (as seen in our CocoaPods distribution), adding Mac Catalyst support would result in a configuration that's largely untested. These platform gaps are currently documented at https://firebase.google.com/docs/ios/learn-more, and more assessment would need to be done to determine how these products fit into a desktop experience.

[mikehardy]

Understood - supported surface area is definitely different than saying "it compiled" and macCatalyst is definitely niche. Closed and I'll edit related comments in rnfb before merge to remove uncertainty. Thanks