Mobile Apps Testflight and Play Store

The Policyholder Portal mobile experience ships as two native apps — one for iOS, one for Android — published under your carrier brand. They share the same data and configuration as your web portal and BriteCore instance, so once you've configured the portal you've configured the apps.

This article covers the lifecycle: how new builds are produced, how they reach test users, and how they reach the public app stores.

The build cadence

Plain-English rule: Configuration changes (colors, copy, templates) reach web in seconds. They reach mobile when the next build is published. Plan launch timing accordingly.

The simulated mobile preview

You don't need to install anything to preview the mobile experience.

1. In the admin console, open Builds in the sidebar.
2. Find your most recent build (top of the list).
3. Click Details.
4. The right pane is a live mobile simulator running the latest build with your latest configuration. Tap through pages exactly as an insured would.

What it's good for: branding validation, copy review, template rendering, end-to-end UAT clicks. What it doesn't catch: native push notifications, biometric sign-in, OS-level keyboard quirks. Test those on a real device via TestFlight or the Play internal track.

TestFlight (iOS testing on real devices)

TestFlight is Apple's pre-release distribution channel. Use it to:

• Hand a real device build to your CSR team for UAT.
• Let your marketing team see the app on their own phones before launch.
• Bug-bash on real devices, real OS versions.

Getting added to TestFlight

1. Have your tester install the TestFlight app from the App Store.
2. Send your BriteCore Implementation Manager their Apple ID email.
3. Implementation adds them to your testing group in App Store Connect.
4. Tester receives an email invitation; they accept it in TestFlight.
5. Your app appears in TestFlight; tester taps Install.

TestFlight build expiry

Each TestFlight build expires 90 days after upload. After expiry, the tester sees a "build expired" message and must wait for a fresh build (which they'll be invited to automatically).

Google Play internal testing track (Android testing on real devices)

The equivalent on Android.

1. Have your tester open Google Play on their Android device, signed in with their Google account email.
2. Send your BriteCore Implementation Manager that Google account email.
3. Implementation adds them to your internal testing track in Play Console.
4. Tester receives an opt-in email with a join link.
5. Tester clicks the link, accepts, then opens Google Play and installs the app.

Internal track build expiry

Internal-track builds don't expire the way TestFlight builds do, but they're replaced on every new release.

Submitting for public release

Public release is coordinated by your BriteCore Implementation Manager — you don't push the button yourself. The flow:

1. Approval — you sign off on the build via email or in your project tracker.
2. iOS submission — Implementation uploads the signed build to App Store Connect; review starts immediately. Apple typically responds in 24–72 hours. Common rejection reasons: missing privacy policy URL, screenshots that don't match the actual app, missing demo account credentials for the reviewer.
3. Android submission — Implementation publishes the build to the production track in Play Console; review typically completes in 2–24 hours.
4. Live in stores — once Apple approves and Google publishes, the app is publicly searchable under your carrier name.

Pre-submission checklist

Before you give the green light, verify:

• [ ] App icon matches your brand (set in Appearance > Square logo).
• [ ] Splash screen renders correctly (tested on simulator and real device).
• [ ] Privacy policy URL is publicly accessible and current.
• [ ] App store screenshots reflect the latest UI (Implementation generates these from your live build).
• [ ] App description copy is approved by marketing.
• [ ] Support contact (email or URL) on store listing is monitored.

Updating apps after launch

Updates are routine and shouldn't be feared.

What requires a new mobile release

In other words: the app shell (icon, splash, navigation skeleton, native code) requires a new release. Everything else inside it updates over the air.

Update cadence

BriteCore typically pushes a fresh build to all carriers every 2 weeks. You don't have to take every release — Implementation will let you know when a release contains a feature or fix you specifically need.

Forced updates

Two scenarios trigger a forced-update prompt for insureds:

• A critical security fix.
• A breaking API change between the app and BriteCore.

The app shows a non-dismissible "Update required" screen until the user updates from the store. This is rare — typically once or twice a year per carrier.

DNS and infrastructure (for the IT-curious)

The web portal lives on your subdomain (e.g., portal.yourcompany.com) via a CNAME to BriteCore's Kubernetes cluster:

portal.yourcompany.com           CNAME   kube-cluster-prod.briteapps.space
dev.portal.yourcompany.com       CNAME   kube-cluster-prod.briteapps.space

The mobile apps don't need DNS records on your side — they reach the portal API directly through *.briteapps.space. TLS, CDN, and DDoS protection are handled by BriteCore.

When to escalate to BriteCore Support

• Build queued but not completing after 60 minutes.
• TestFlight invitation not arriving (check spam first).
• App store rejection — Implementation handles re-submission, but loop them in immediately.
• Forced-update screen appearing for insureds when no security release was announced.

See also

• Branding & Appearance
• Settings & Feature Toggles
• Accessing the Carrier Admin Console