App identifiers
Every applicationId/bundle ID, which Firebase app it maps to, and what's live in the app stores. Build flavors added 2026-09-24 so a staging and a production install can sit on the same device at once.
User App
| Staging (existing — live in Play Console/TestFlight) | Production (new, 2026-09-24) | |
|---|---|---|
| Android applicationId | com.techzora.dailymeet.android | com.dailymeet.prod.android |
| iOS bundle ID | com.techzora.dailymeet.ios | com.dailymeet.prod |
| App display name | "Daily Meet Staging" | "Daily Meet" |
| Firebase project | vibeconnect-7c601 — both flavors are separate apps inside this one project, not separate projects | |
Host App ("Daily Meet Celeb")
| Staging (existing — live in Play Console/TestFlight) | Production (new, 2026-09-24) | |
|---|---|---|
| Android applicationId | com.techzora.dailymeethost.android | com.dailymeet.prod.celeb.android |
| iOS bundle ID | com.techzora.dailymeethost.ios | com.dailymeet.prod.celeb.ios |
| App display name | "Daily Meet Celeb Staging" | "Daily Meet Celeb" |
| Firebase project | hostvibeconnect — both flavors are separate apps inside this one project | |
The two Firebase projects (User vs. Host) are intentionally separate and always have been — that's unrelated to the staging/production split. Each project now just has two apps per platform instead of one.
How a build picks which identity it is
Every flutter run/flutter build needs two flags together — Flutter's own --flavor (which applicationId/bundle ID and native config get used) and this project's own APP_FLAVOR dart-define (which FirebaseOptions the Dart side picks). They are separate mechanisms and Flutter does not link them automatically:
flutter run --flavor production --dart-define=APP_FLAVOR=productionAll scripts in daily-meet-app/scripts/ and every VS Code launch config already pass both — see Build & release. A release-mode build with no DAILY_MEET_API_BASE_URL define falls back to AppConfig.productionApiBaseUrl (hardcoded to https://api.dailymeet.in) — it never silently falls back to a local address.
Play Console (Android)
| App | Package (staging identity) | Console app ID | Track |
|---|---|---|---|
| Daily Meet (User) | com.techzora.dailymeet.android | 4972800892756444104 | Internal testing |
| Daily Meet Celeb (Host) | com.techzora.dailymeethost.android | 4973509712324431832 | Internal testing |
Developer account: admin@dailymeet.in (personal Google account). Both apps are on the Internal testing track only — this is intentional, not a limitation waiting to be fixed; the user has said beta/testing-only, never a public production release, until explicitly decided otherwise.
The new com.dailymeet.prod.* applicationIds are not yet on Play Console or App Store Connect — they only exist as local debug builds today, verified by installing on a physical device. Publishing them (even to Internal testing) means creating brand-new app listings from scratch, since Play Console/App Store ties a listing to its bundle ID permanently. Not started yet.
Signing
Current release-mode builds (staging and production flavors alike) use debug signing. There is no keystore/provisioning-profile configuration in either repo yet — that's a separate, not-yet-started piece of work, required before any build can go to Play Store production or TestFlight external testing.