BuddyBoss Next-Gen App & The Dual Bridge

The Bottom Line

Fact-check first: the Next-Gen BuddyBoss app is still React Native — the "rebuilt on Flutter" claim was a rumor; BuddyBoss support and their own developer docs confirm it. The upgrade is real (light/dark mode, performance, new build pipeline) but it's an app-shell refresh, not a framework swap. Our custom code is server-side WordPress and insulated either way. The critical new fact: BuddyBoss has NO native HealthKit / Health Connect hooks, and won't let us import our own SDK libraries yet. That makes our own FFH Flutter app the realistic vehicle for Apple Health + Health Connect data — which sharpens, not changes, the approved dual-bridge strategy.

1 · What actually changed — verified

Part of the BuddyBoss 3.0 rollout: admin redesign (May 2026), the Next-Generation BuddyBoss App (late May), ReadyLaunch (June). We asked BuddyBoss support directly; their answers are folded in below.

Dimension	Old app	Next-Gen app (verified)
UI framework	React Native	Still React Native — NOT Flutter
Light / Dark mode	Limited	Full, synced to device setting
Performance	Good	Faster, refreshed UI
Custom features	Custom dev	Your own Git repo merges with the core repo at build time — customizations ship in iOS + Android builds
Native libraries / SDKs	Limited	Still limited to BuddyBoss-supported libraries; importing your own SDKs is "planned for the future"
Who maintains it	BuddyBoss	BuddyBoss (they carry OS updates + store builds)

The dark-mode catch still applies: our brand assets (white logos, coins) assume light or navy backgrounds. A deliberate visual QA pass in both modes is required before members see the new app.

2 · Official answers from BuddyBoss support

We asked the three questions from v1 of this explainer. Received June 5, 2026.

Q1 — Custom native plugins & migration of our customization?

The Next-Gen app lets us maintain our own Git repository of custom code that merges with the app's core repo during the build — our customizations are included in the iOS and Android builds. BUT direct installation of new native libraries is limited to BuddyBoss-supported ones; importing our own SDK libraries is only "planned for the future."

Good for UI tweaks Blocks our own native SDKs for now

Q2 — Native HealthKit / Health Connect hooks?

No native hooks exposed. "If you require such integrations, custom development might be necessary" — and per Q1, we can't import the needed health SDKs ourselves yet. BuddyBoss points to their Custom Development team or third-party developers.

Health data can't ship inside the BuddyBoss app near-term

Q3 — Resubmission & QA guidance?

Standard store-compliance guidance: review Apple/Google guidelines, QA before resubmission. BuddyBoss provides a compliant environment but final responsibility for compliance is ours.

No surprises — plan a QA pass

3 · Apple Health & "Google Fit" — the corrected path

Two corrections now locked in. First: there is no live "Google Fit" — Google deprecated and removed it; the Android target is Google Health Connect, alongside Apple HealthKit on iOS. Second: per BuddyBoss support, that data pipeline cannot ship inside their app today.

Vehicle	Can it carry member health data?
BuddyBoss Next-Gen app	Not now. No native health hooks; own SDK imports not yet allowed. Possible later via BuddyBoss Custom Development ($) or when SDK imports open up.
FFH-owned Flutter app (Track B)	Yes, day one. Flutter's mature health packages read HealthKit + Health Connect (steps, heart rate, sleep, activity) and can POST straight into PHIT via our existing WordPress/Supabase REST endpoints.

Strategic consequence: the health bridge — the thing we want "ASAP" — is now the clearest reason Track B exists. It also gives Track B a sharp, affordable v1 scope: a lightweight FFH Health Companion app that syncs Apple Health / Health Connect into PHIT and Live It trackers, rather than boiling the ocean with a full community app on day one.

4 · The dual-bridge strategy — sharpened

Same approved strategy, now with verified facts shaping each track's scope.

Track A · Now

Ride the BuddyBoss Next-Gen app

The live member community app. Stable, vendor-maintained.

Visual QA in light + dark mode (brand assets)
Confirm our notification bridge post-upgrade
Use the custom-repo merge path for UI tweaks only
No health SDKs here until BuddyBoss opens imports

Track B · Build

FFH-owned Flutter app — v1 = Health Companion

theforce.health's own app, scoped to win fast.

v1: HealthKit + Health Connect sync → PHIT & Live It
Own App Store / Play Store presence (exit asset)
Grows toward full community parity over time
No forced cut-over from BuddyBoss

Why own it: with the monetization/exit lens, the app is a balance-sheet asset. Renting forever caps that value. The dual bridge de-risks: members never feel the transition, and we build ownership on our own timeline — starting with the health feature BuddyBoss can't give us.

5 · Legacy-code archive — done

Logged in Airtable: base "CURRENT PRO 2025 – 2026 FFH Senior Editorial" → table "Legacy Code Archive - BuddyBoss Migration" (5 records).

Verdict: all FFH custom code is server-side WordPress (scfa-360-tracker-bridge, ffh-sickle-sense-coins) — none of it needs rebuilding for the app upgrade. The notification bridge keeps working through core BuddyPress notifications.
Now confirmed by support: the workspace scan's finding holds — we have no app-shell customization at risk. The "verify with BuddyBoss" open item is closed.
Data exports (groups XML, activity CSV) are archived; safe to clear from working folders after reconciliation.

6 · Next steps

Done · June 5

BuddyBoss support answers received

Custom-repo merge path confirmed; no native health hooks; own SDK imports not yet allowed; standard store-compliance QA on us.

Done · June 5

Legacy-code archive complete

Airtable table built and populated with rebuild verdicts. Old code can be cleared with confidence.

Next 2 weeks

Dark-mode + bridge QA on the Next-Gen app

Verify the notification bridge and brand assets render correctly in light AND dark mode before members feel any change.

Next 30 days

Scope Track B v1 — the FFH Health Companion app

Flutter shell + CI pipeline + HealthKit/Health Connect proof-of-concept writing into PHIT. Decide internal build vs. contract Flutter dev, and set the budget envelope.

Ongoing

Run the bridge in parallel

BuddyBoss stays the live community app. Watch for BuddyBoss opening custom SDK imports — if that lands, revisit whether any health features belong in Track A too.

Decision Requested

One greenlight to move

The support ticket and archive are done. The strategic direction (dual bridge) is approved. What's left:

Greenlight Track B v1 scoping — the FFH Health Companion app (Flutter, HealthKit + Health Connect → PHIT). Decide: internal build vs. contract developer, and the budget envelope. This is the fastest honest path to "Apple Health ASAP."

BuddyBoss shipped its Next-Generation app — we now have official answers from their support team. Here's the verified picture, what it means for FFH, and the dual-bridge plan.