BuddyBoss's framework swap (React Native → Flutter) is a mobile-app-shell change, not a platform change. Almost all of our custom code lives server-side in WordPress and is insulated from it. We're committing to a dual bridge: ride the new BuddyBoss 3.0 app now for stability, build a HealthKit + Health Connect bridge for member health data, and begin our own Flutter app for theforce.health as a long-term, owned exit asset — phased, no forced cut-over.
This is part of the "BuddyBoss 3.0" rollout — three releases: the admin redesign (May 2026), the Next-Generation BuddyBoss App (late May), and ReadyLaunch (June). The app itself was rebuilt from React Native onto Flutter.
| Dimension | Old app (React Native) | New app (Flutter) |
|---|---|---|
| UI framework | React Native (JS bridge to native) | Flutter (compiles to native ARM) |
| Light / Dark mode | Limited | Full, synced to device setting |
| Performance | Good, but JS-bridge overhead on heavy screens | Smoother scroll/animation, faster cold start |
| Who maintains it | BuddyBoss | BuddyBoss (they carry the OS-update burden) |
| Custom native plugins | Written for React Native | Must be re-implemented as Flutter plugins |
We scanned the workspace for our custom BuddyBoss code. The honest finding: the migration touches the mobile shell, and our customization lives a layer below it, in WordPress.
scfa-360-tracker-bridge plugin (med reminders + milestone notifications to the BuddyBoss bell and mobile push) works through core BuddyPress notifications. The Flutter app reads those automatically — no rebuild needed for the framework swap.You asked to move toward Apple Health and Google Fit ASAP. One fact changes the plan: there is no live "Google Fit" to integrate with anymore.
| Platform | What we integrate with today |
|---|---|
| iOS | Apple HealthKit — fully supported in Flutter |
| Android | Google Health Connect — the replacement for Google Fit, which Google deprecated and removed |
Good news: Flutter has mature, well-supported packages (health, flutter_health_fit, heka_health) for pulling steps, heart rate, sleep, and activity from both. This lines up directly with PHIT scoring and Live It tracking. The health bridge is a Flutter plugin we'd build either way — so health integration does not force the own-app decision; it's feasible on both tracks. The open question is whether BuddyBoss exposes those hooks natively, or whether we build the plugin ourselves.
Two parallel tracks. Track A keeps members on a stable, vendor-maintained app today. Track B builds the asset we own — the one that matters for monetization and exit.
The live member app. Stable, vendor-maintained, fast to value.
theforce.health's own app — the long-term exit asset we control.
Per your direction, we're cataloging the pre-Flutter custom code in Airtable so it can be deleted with confidence.
scfa-360-tracker-bridge plugin and the ffh-sickle-sense-coins plugin — plus group/activity data exports.Three questions: (1) does the Next-Gen app support custom native plugins, and is our customization migrated; (2) does it expose HealthKit / Health Connect hooks natively; (3) resubmission + QA guidance.
Re-run the legacy-code archive table and log each component with its rebuild verdict. Then we can clear the old source with confidence.
Verify our notification bridge and brand assets render correctly in the new Flutter app, light and dark, before members feel any change.
Stand up the Flutter shell, CI build pipeline, and a HealthKit / Health Connect proof-of-concept that writes into PHIT. Decide build-it-internally vs. contract a Flutter dev.
BuddyBoss stays the live app until our own app reaches feature + stability parity. No cut-over date is set until parity is proven.
The strategic direction (dual bridge) and the legacy archive are already approved. To put the next steps in motion, we need: