Skip to main content

iOS Alpha (TestFlight) Developer Setup

Purpose​

This guide explains how each developer gets the iOS alpha app through TestFlight using the alpha lane.

Use this when:

  • you need production-like iOS validation before main
  • you need stable tester distribution through Apple TestFlight

Alpha lane definition​

  • Branch lane: alpha
  • EAS build profile: alpha
  • iOS distribution type: store (TestFlight/App Store Connect path)
  • Install target: internal/external TestFlight tester groups

Prerequisites​

Each developer needs:

  • access to the mobile repo
  • TestFlight app installed on iPhone
  • Apple ID added to the correct TestFlight tester group
  • App Store Connect access (or at minimum tester invite acceptance)
  • Expo/EAS project access if they are expected to queue builds

One-time team setup (release owner)​

  1. Confirm alpha profile uses store distribution in eas.json.
  2. Confirm App Store Connect app record exists for com.attunelogic.mobile.
  3. Ensure internal tester group includes all developers who need alpha access.
  4. Define who queues alpha builds and who submits/promotes in App Store Connect.
  5. Share expected turnaround times:
    • build time
    • Apple TestFlight processing time

Per-developer onboarding (required once)​

Step 1: Accept TestFlight invite​

  1. Open the invite email for the alpha app.
  2. Accept with the same Apple ID used on the iPhone.
  3. Confirm the app appears in TestFlight.

Step 2: Install TestFlight app build​

  1. Open TestFlight on device.
  2. Select the alpha app listing.
  3. Install latest available build.

If no build appears, use troubleshooting below.

Build and publish flow (release owner / designated builder)​

From the mobile repo:

eas build --platform ios --profile alpha

Then submit if needed:

eas submit --platform ios --profile alpha

If your team uses build intent branches:

git push origin build/alpha

That queues build creation locally via pre-push hook. Submission to TestFlight still must be completed.

Day-to-day developer flow​

  1. Work on feature/*.
  2. Merge through normal PR approvals into beta.
  3. Promote beta -> alpha through PR approvals.
  4. Release owner ensures a fresh alpha iOS build is available in TestFlight.
  5. Developers install/update from TestFlight and validate.
  6. Defects are fixed and promoted again through the same branch flow.

Troubleshooting​

"I do not see the app in TestFlight"​

Check:

  1. You accepted the invite email.
  2. You are signed into TestFlight with the invited Apple ID.
  3. You are added to the correct tester group for this app.

"I see the app, but no build is available"​

Check:

  1. Latest alpha build finished in EAS.
  2. Build was submitted to App Store Connect/TestFlight.
  3. Apple processing has completed (can take time).
  4. Build is enabled for the tester group.

"My change is not in the TestFlight build"​

Check:

  1. Change was promoted to alpha (not only beta).
  2. A new alpha native build was created after that merge.
  3. You installed the newest TestFlight build number.

"I only see old UI/code after install"​

  • Pull down to refresh in TestFlight.
  • Verify build number/version changed.
  • Confirm whether the change is JS-only OTA or native-impacting.
  • For native-impacting changes, a new alpha binary is required.

Operational reminders​

  • alpha is the canonical TestFlight lane.
  • beta is ad hoc/internal lane for earlier validation.
  • production is the App Store lane after final approvals.