Beta Testing Your Rork App with TestFlight: from Internal Testers to Public Launch

Prerequisites, and the route you pick first

Three things: an Apple Developer Program membership ($99/year), a Rork Max subscription if you're generating a native iOS app, and — maybe — a Mac.

Whether you need the Mac depends on the route you choose. This is the first real decision.

Rork's generated projects usually retain their Expo structure, which makes the EAS route meaningfully lighter — it removes the code signing step where most people stall. The sections below follow the EAS path, with Xcode differences noted where they matter.

Step 1: Create the app record in App Store Connect

Sign in at appstoreconnect.apple.com and go to My Apps → + → New App.

Only one field here is permanent: the Bundle ID. Platform, name, and SKU can all be adjusted later. Get the Bundle ID wrong and you're creating a fresh app record.

For a Rork Max export, it lives in app.json (or app.config.js) under ios.bundleIdentifier. If you exported a native project instead, check CFBundleIdentifier in Info.plist.

{
  "expo": {
    "name": "MyApp",
    "slug": "my-app",
    "version": "1.0.0",
    "ios": {
      "bundleIdentifier": "com.yourname.myapp",
      "buildNumber": "1"
    }
  }
}

A single character of drift between this string and App Store Connect will reject the upload. Copy and paste it.

Step 2: Build and upload

The EAS route

Add a production profile and submit configuration to eas.json. You can omit credentials like appleId — EAS will prompt for them interactively.

{
  "cli": { "version": ">= 5.0.0" },
  "build": {
    "production": {
      "ios": {
        "resourceClass": "m-medium"
      }
    }
  },
  "submit": {
    "production": {
      "ios": {
        "ascAppId": "1234567890"
      }
    }
  }
}

ascAppId is the numeric ID in your App Store Connect URL (the .../apps/1234567890/... segment). From there it's two commands:

# Build — EAS generates credentials interactively if none exist
eas build --platform ios --profile production
 
# Ship the most recent build to App Store Connect
eas submit --platform ios --latest

The first run asks for your Apple ID and an app-specific password. If two-factor authentication is on — and it should be — your regular password won't work, so generate one at appleid.apple.com beforehand to avoid stalling mid-flow.

The Xcode route

Export from Rork Max via Export → Xcode Project and open the .xcodeproj. Under your target's Signing & Capabilities tab, select your Team and confirm the Bundle Identifier matches App Store Connect.

Set the device selector to "Any iOS Device (arm64)", then Product → Archive. When Organizer opens, choose Distribute App → App Store Connect → Upload, and leave signing on "Automatically manage signing" unless you have a reason not to.

If you're creating certificates by hand: Xcode → Settings → Accounts → Manage Certificates for the Apple Distribution certificate, then Certificates, Identifiers & Profiles → Profiles at developer.apple.com/account for the App Store provisioning profile.

Export compliance — where most builds get stuck

This is the trap from the opening. App Store Connect requires a declaration about whether your app uses non-exempt encryption, and until it's answered, the build reaches no one.

Answering it in the dashboard every upload is easy to forget, so declare it permanently in app.json:

{
  "expo": {
    "ios": {
      "bundleIdentifier": "com.yourname.myapp",
      "infoPlist": {
        "ITSAppUsesNonExemptEncryption": false
      }
    }
  }
}

Read the question carefully: it asks about non-exempt encryption, not encryption in general. HTTPS traffic and Apple's own platform crypto APIs are exempt, which is why most apps are correctly false.

Set it to true if you ship custom or proprietary encryption — a messaging app with its own end-to-end protocol, for instance. Expect follow-up questions and, in most cases, a request for export documentation. If you aren't certain which side you're on, inventory what your app actually uses before you commit to false. This is not a field you want to answer wrong.

Processing after upload usually takes 5–15 minutes, occasionally 30–60 during busy periods.

Step 3: Get the build to testers

Open the TestFlight tab for your app in App Store Connect.

For internal testing, pick a group, enable the build, and add testers. They'll get an email link that opens the TestFlight app. The prerequisite is that each person already exists as an App Store Connect user — invite them under Users and Access first.

For external testing, create an external group, add the build, and hit Submit for Review.

One field matters more than it looks: What to Test. Leaving it blank, or writing "bug fixes," is a plausible way to get bounced back from review. Describe what you want exercised and what's new. It also appears verbatim in the tester's TestFlight app, so it directly shapes the feedback you get back.

External testers can be invited individually by email or through a public link. Public links spread easily, but you lose track of who's in the group and the feedback arrives without context. Start with individual invites.

Step 4: Feedback, and the 90-day clock

TestFlight's real advantage is in-app feedback. Testers can send a screenshot and a note without leaving the app, and it lands under TestFlight → Feedback alongside crash reports.

If crash reports never arrive, check the tester's device rather than your integration: Settings → Privacy & Security → Analytics & Improvements → Share with App Developers has to be on.

Builds expire after 90 days

This one is easy to miss. Every TestFlight build has a 90-day expiry. Past that point testers can't launch it and see "Beta Has Expired" instead.

If you're planning a long beta, treat 90 days as one cycle and schedule a refresh build inside it. The "everyone suddenly lost access" story almost always traces back to this.

Shipping updates

After a fix, increment ios.buildNumber and rebuild. Keep the version string (1.0) fixed and move only the build number — that's the normal TestFlight cadence.

# after bumping buildNumber
eas build --platform ios --profile production --auto-submit

--auto-submit chains the upload onto a successful build, which pays for itself during a tight fix cycle. Enabling the new build in TestFlight notifies testers automatically.

Pre-submission checklist

Once the beta has settled, work through these before filing for review.

Crash rate. Check the TestFlight crash reports for your primary flows. Under 1% is the target.

Screen sizes and OS versions. Verify basic operation on a small device (iPhone SE), a current iPhone, and iPad if you support it. Confirm launch on the minimum iOS version you've declared.

Network conditions. Test beyond Wi-Fi — cellular and a throttled connection. Xcode's Network Link Conditioner or the on-device Developer settings will simulate this.

Permission strings. If you use camera, microphone, or location, make sure NSCameraUsageDescription and friends say something specific. Thin placeholder text draws review comments.

Privacy policy and screenshots. Policy URL configured, and screenshots prepared for each required size (6.9", 6.7", and so on).

Triage table

Notes from running several apps

Across a few apps in parallel, the expensive part of TestFlight has never been the technical setup. It's the back-and-forth with testers.

Early on I handed builds out with "let me know if anything seems off." What came back was mostly "feels kind of slow" and "it's confusing" — impressions I couldn't act on. That wasn't the testers' failing. I hadn't told them where to look.

Now the What to Test field holds at most three numbered flows: "1) first launch through setup completion, 2) behavior when opened offline, 3) where you land after dismissing the paywall." The narrower the ask, the more specific the reports.

The other change was how I use internal testing. I used to check the release build on my own device and, if it looked fine, push straight to external. Now every build goes through internal testing first and I install it via TestFlight on my own phone before anything goes out. Behavior that held up in a development build can shift under release-build optimization. It costs a few minutes and it noticeably cut down my first-round external rejections.

Beta windows got shorter too. Long betas don't produce more feedback — reports cluster in the first few days and then go quiet. Cutting at one or two weeks and moving to the next build, with the 90-day expiry in mind, turned out to iterate faster.

Wrapping up

The failure modes in TestFlight skew toward settings that don't announce themselves: an unanswered compliance question, an expired build, an empty What to Test field. None of them raise an error, and all of them stop distribution.

If you're about to push your first build, start by adding ITSAppUsesNonExemptEncryption: false to app.json. One line removes the single most common reason builds go nowhere.