Skip to content

feat(spm): retro-compatible SPM support for RN 0.77 old-arch (v23.8.8 + 3 maintainer cherry-picks + FBValidation logs)#3

Closed
jsnavarroc wants to merge 7 commits into
mainfrom
feat/spm-with-selective-maintainer-fixes
Closed

feat(spm): retro-compatible SPM support for RN 0.77 old-arch (v23.8.8 + 3 maintainer cherry-picks + FBValidation logs)#3
jsnavarroc wants to merge 7 commits into
mainfrom
feat/spm-with-selective-maintainer-fixes

Conversation

@jsnavarroc

@jsnavarroc jsnavarroc commented Jul 14, 2026

Copy link
Copy Markdown
Owner

Contexto

PR interno de mi fork personal para validar retro-compatibilidad del setup SPM + RN 0.77 (Paper) + API namespaced contra el core Mediastream core-old-arch.

NO es un PR hacia upstream Invertase — ese es el #8933 y sigue OPEN con CHANGES_REQUESTED.

Este PR consolida un snapshot estable v23.8.8 + fixes SPM del maintainer que se puede empaquetar y consumir desde el core en producción hasta que Invertase mergee y publique v25.x/v26 oficial.

Composición de la rama (feat/spm-with-selective-maintainer-fixes)

Base: feature/spm-dependency-support (HEAD del PR invertase#8933, commit eaa09eafb) — snapshot v23.8.8 con:

  • feat SPM support (base del PR)
  • fix analytics FirebaseAnalyticsCore + WithoutAdIdSupport
  • fix app FirebaseInstallations explicit SPM product
  • fix review feedback (spacing, Expo docs, SPM comments)
  • fix Cursor Bugbot findings

Cherry-picks selectivos del maintainer (3, sin TurboModules ni remove-namespaced):

  1. 268677a07 — fix: harden RNFirebaseDisableSPM boolean check
  2. bd553ef89 — fix: explicitly declare Photos framework on PHAsset/PHAssetResource packages (adapted, sin HEADER_SEARCH_PATHS de TurboModules)
  3. 6b95cdf29 — fix(ios): embed Firebase SPM package frameworks

Instrumentación temporal (para validación con core-old-arch):
4. 062a9ba62 — chore(logs): add [FBValidation/*] NSLog on native bridge methods (Analytics, Crashlytics, DatabaseQuery)

Por qué NO se traen commits post-v25.1.0 del main upstream

El main upstream tiene 15 commits refactor(*): remove deprecated namespaced API (2026-06-26/27) + 3 commits feat(*): migrate to TurboModules (2026-06-30/07-03) que rompen la API namespaced usada por el core-old-arch.

Los fixes SPM valiosos posteriores (auth/crashlytics/storage method files, Swift bridge helpers) están inextricablemente ligados a esa migración TurboModules y no son cherry-pickables sin refactor completo del core.

Ver análisis detallado en la conversación del PR invertase#8933 upstream.

Validación end-to-end en core-old-arch (RN 0.77 + Paper + Xcode 26)

Los 4 pilares validados con evidencia numérica (logs [FBValidation/*]):

Pilar JS side SDK native Estado
Arranque ✅ CrashlyticsBootstrap log Validado
Analytics logEvent 12 llamadas 12 llamadas Match 1:1
Database refs/on/off 9 acciones 10 llamadas Cascada completa
Database callback con datos 182 children reales Backend real
Crashlytics bootstrap Validado
Crashlytics recordError Endpoint disponible en global.__FBValidation.triggerCrashlyticsTest()

Configuración: SPM activo + FirebaseSPMGate embed + Podfile con post_install (embed SPM frameworks, header search paths). Modo de consumo: tarballs generados con ./scripts/pack.sh (no incluido en este PR, es tooling local).

Archivos afectados vs main

  • packages/analytics/RNFBAnalytics.podspec (harden boolean check)
  • packages/analytics/ios/RNFBAnalytics/RNFBAnalyticsModule.m (+ NSLog logEvent)
  • packages/app/RNFBApp.podspec (Photos.framework guard PHAsset)
  • packages/app/__tests__/firebase_spm_test.rb (nuevo — tests del boolean check)
  • packages/app/firebase_spm.rb (embed SPM frameworks + boolean check)
  • packages/crashlytics/ios/RNFBCrashlytics/RNFBCrashlyticsModule.m (+ NSLog log/recordError/setAttribute/sendUnsentReports)
  • packages/database/ios/RNFBDatabase/RNFBDatabaseQueryModule.m (+ NSLog once/on/off)
  • packages/storage/RNFBStorage.podspec (Photos.framework guard)
  • tarballs/react-native-firebase-*-23.8.8.tgz (prebuilt tarballs para consumo directo)

Test plan

  • Build core-old-arch tvOS Xcode 26 sin errores
  • Install en simulador Apple TV 4K (3rd gen) tvOS 26.4
  • Verificar logs NSLog compilados en Frameworks/RNFB*.framework binarios
  • Home renderiza + Player VOD/Live reproduce
  • Analytics: eventos JS→native 1:1 (screen_view, player_ready, video_views)
  • Database: value_callback_fired con 182 children reales del backend
  • Crashlytics bootstrap: setAttributes + log al start
  • Crashlytics recordError test: pendiente activar triggerCrashlyticsTest()
  • Session watcher: pendiente con login (requiere customerId en storage)

Cómo revisar este PR

Diff visible en GitHub: este PR muestra las diferencias vs main de mi fork. Los 4 commits nuevos están claros y separados.

IMPORTANTE: NO hacer merge sin revisión manual. Este es un PR de estabilización, no automerge.

Rollback plan

Si algo se rompe: git reset --hard feature/spm-dependency-support (HEAD del PR invertase#8933 upstream) devuelve el fork al estado sin cherry-picks ni NSLog, y sigue funcionando en producción.

jsnavarroc and others added 7 commits April 17, 2026 11:17
FirebaseInstallations is a transitive dependency of FirebaseCore.
With SPM dynamic linking, transitive frameworks are not embedded
automatically — they must be declared explicitly as SPM products.

Without this, dyld crashes at launch with:
'symbol not found in flat namespace _FIRInstallationIDDidChangeNotification'
Stop ignoring .tgz files inside tarballs/ folder so the corporate Mediastream
fork can serve prebuilt packages directly from this branch via git+ssh URL.

Used by tvOS projects that cannot consume tarballs from private GitHub
Releases (HTTP 404 without auth) and need an alternative install path.
- analytics: include FirebaseAnalytics/IdentitySupport when
  $RNFirebaseDisableSPM forces CocoaPods on RN >= 0.75. The previous
  `unless defined?(spm_dependency)` guard skipped the IdentitySupport
  block even when the user explicitly opted out of SPM.

- installations: remove redundant `#import "FirebaseInstallations/
  FIRInstallations.h"` from RNFBInstallationsModule.m. The symbols
  are already provided by the conditional import block above (via
  <Firebase/Firebase.h> on CocoaPods or @import FirebaseInstallations
  on SPM). The quoted header path was a CocoaPods-only artifact that
  could fail to resolve in SPM mode.
Add an RNFB SPM post-install patch that injects an app-target build
phase for Firebase SPM dynamic frameworks. The phase copies frameworks
built under Xcode's PackageFrameworks directory into the app Frameworks
folder when they were not already embedded by CocoaPods.

This fixes release launches where RNFBStorage links FirebaseStorage,
FirebaseStorage links FirebaseAppCheckInterop, but the app bundle does
not contain FirebaseAppCheckInterop.framework. The fix keeps Storage
declaring only the public FirebaseStorage product and avoids requiring
consumers to install App Check or add a Podfile workaround.

Also regenerates the iOS test project so the new embed phase is present.
@jsnavarroc
jsnavarroc force-pushed the feat/spm-with-selective-maintainer-fixes branch from 062a9ba to 6b95cdf Compare July 14, 2026 18:46
@mikehardy

Copy link
Copy Markdown

Solo estoy aqui para decir hola 👋 y que internamente este - lo de SPM en totalidad - es nuestro prioridad mas alto ahora - vamos a aterrezar el PR upstream de alguna manera dentro de poco

@jsnavarroc

Copy link
Copy Markdown
Owner Author

Closing without merge — findings

Closing this PR because it turned out to be redundant with main of the fork and doesn't add usable value on its own. Leaving the notes here for future reference.

What this PR tried to do

Take the stable base of PR invertase/react-native-firebase#8933 (feature/spm-dependency-support, HEAD eaa09eafb) and cherry-pick 3 valuable maintainer commits (3b9cd9eea, a11663051, e4595a52c) selectively, keeping the branch on the v25.x/Old-Arch line and avoiding the v26-shape refactors (refactor(*): remove deprecated namespaced API + feat!: migrate to TurboModules) that landed on main on 26-jun to 03-jul.

Why it didn't work as expected

  1. The 3 cherry-picks are duplicates of commits already in main. When russellwheatley pushed his SPM fixes directly to jsnavarroc/react-native-firebase:main (~9-14 jul), those 3 SHAs (3b9cd9eea, a11663051, e4595a52c) were included. Cherry-picking them onto an older base just created new SHAs (268677a07, bd553ef89, 6b95cdf29) with the same content, so GitHub reports mergeStateStatus: DIRTY even though there's no real net addition.

  2. The branch is a subset of main, not a superset. Merging it into main would be a downgrade — main has more commits (docs, diagnostics, method files, etc.) on top of those same 3 fixes.

  3. Root cause of the confusion: I built this branch from feature/spm-dependency-support (the historical base of PR feat(ios): add SPM dependency resolution support alongside CocoaPods invertase/react-native-firebase#8933) instead of from the actual current head of PR feat(ios): add SPM dependency resolution support alongside CocoaPods invertase/react-native-firebase#8933, which is main. That was a git mistake on my end.

What's actually the right path (moved to PR invertase#8933 upstream)

The real problem is separate and much larger: PR invertase#8933 upstream has drifted from a pure "SPM support" PR into being coupled with v26-shape refactors that break v25.x/Old-Architecture consumers.

I'm posting the full technical analysis (with reproducible Build A vs Build B evidence) in invertase/react-native-firebase#8933 as a comment to @russellwheatley.

The rama that actually works

Kept alive on the fork: feature/spm-dependency-support at HEAD bc90cdafe — the original PR base plus a clean cherry-pick of e4595a52c (embed Firebase SPM frameworks). That's the branch I'm proposing invertase#8933 upstream should retarget to.

@jsnavarroc jsnavarroc closed this Jul 14, 2026
@github-actions

Copy link
Copy Markdown

In order to prioritize work in this repository, closed issues and pull requests do not regularly receive attention.

If the underlying issue or pull request still requires attention, opening a new issue with a reproduction
after testing with current versions, or reposting the pull request as a new PR may be the most effective way forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants