DEV Community

Melroy D Souza
Melroy D Souza

Posted on

I Onboarded 14 Indie Devs to TestFlight This Month. Here's What Actually Confused Them

#reactnative #ios #expo #mobile
  • Every first-timer asks the same four questions in the same order, and the gap between "my build succeeded" and "why can't my friend install it" is where most quit for 2 to 3 days.
  • The real map has eight steps across three separate Apple properties (Developer Portal, App Store Connect, the TestFlight app) and two async waits.
  • After eas submit, watch the App Store Connect Activity tab, not the TestFlight tab. Activity shows "Processing" immediately; TestFlight only shows the build once processing finishes.
  • A pre-flight checklist, an ITMS error decoder, and a live walkthrough with the first tester cut time-to-first-tester from 3 days to 90 minutes.

Running a small Discord for React Native indies, I did unstructured office hours with 14 devs shipping their first TestFlight build this month. Every single one hit the same four walls in roughly the same order.

None of them were technical walls. They were mental-model walls, and every EAS tutorial online is written by people who forgot they exist.

Here's what I saw, in the order they saw it.

The four questions every first-timer asks (in order)

  1. "Do I need a Mac?" (Answer: not for EAS. Yes, eventually, for xcrun when things go wrong.)
  2. "Wait, what's the difference between App Store Connect and my Apple Developer account?"
  3. "I ran eas build and it succeeded. Where's the app?"
  4. "Why can't my friend just... install it?"

Every single time, in that order. And the gap between question 3 and question 4 is where most people quit for 48 to 72 hours, because they don't know what they don't know.

Where the mental model breaks

Here's the actual conceptual map: how devs think it works, versus how it works.

How they think it works:

[my code] --> [EAS] --> [TestFlight] --> [friend's phone]
Enter fullscreen mode Exit fullscreen mode

How it actually works:

[my code]
   --> [EAS builds .ipa, signed with a cert tied to my Apple Dev account]
   --> [eas submit uploads .ipa to App Store Connect]
   --> [ASC processes the build ~5-30 min, may email you an ITMS error]
   --> [ASC exposes the processed build in the TestFlight tab]
   --> [I add internal testers by Apple ID email, they get an email]
   --> [tester installs the TestFlight app first, then accepts the invite, then installs my app]
   --> [external testers need Beta App Review, another 24-48 hr]
Enter fullscreen mode Exit fullscreen mode

Eight steps. Three separate Apple properties (Developer Portal, App Store Connect, the TestFlight app on the phone). Two async waits (processing, review). One place where things silently break: ITMS emails go to your Apple ID, not your dev email, if those differ.

When I draw this on a whiteboard for someone, the reaction is always the same exhale: "oh, that's why the tutorials didn't make sense."

The eas submit moment: relief or panic

The single highest-emotional-swing moment in the whole flow is the first eas submit -p ios --latest. It succeeds and prints something like:

✔ Submitted your app to Apple App Store!
App Store Connect: https://appstoreconnect.apple.com/apps/1234567890/testflight/ios
Enter fullscreen mode Exit fullscreen mode

They click the link. They see an empty TestFlight tab. Panic sets in. "Did it fail? Did I do it wrong?"

No. Apple's processing takes 5 to 30 minutes. Nobody tells first-timers this. Half of them re-run eas submit thinking they missed a step, which creates a duplicate build in ASC. Now they have two builds processing, and one will probably fail with ITMS-90478: Invalid Version, because the second submission carries the same build number.

The fix is small but it works: tell people to keep the ASC Activity tab open in a browser, not the TestFlight tab. Activity shows the "Processing" state immediately. TestFlight only shows the build after processing completes. Different tab, different truth.

Three onboarding fixes that cut time-to-first-tester from 3 days to 90 minutes

After watching people stall in the same spots, here's what actually helped.

Fix 1: a pre-flight checklist that runs before their first eas build.

[ ] Apple Developer account paid ($99/yr, not the free tier)
[ ] Apple ID for App Store Connect access confirmed (may differ from dev email)
[ ] App identifier registered in Certificates, Identifiers & Profiles
[ ] App created in App Store Connect (Name + Bundle ID + SKU)
[ ] TestFlight testers' Apple IDs collected (not phone numbers, not work emails: Apple IDs)
Enter fullscreen mode Exit fullscreen mode

The last one alone saves a day. Testers don't know what their Apple ID is. Half of them think it's their Gmail. It's actually their iCloud address from 2011. Get this list before you submit.

Fix 2: the ITMS decoder ring.

Every first-timer hits at least one of these. Print it, tape it to the monitor:

  • ITMS-90163: Invalid Code Signing → provisioning profile expired or doesn't match your bundle ID. Regenerate via eas credentials.
  • ITMS-90478: Invalid Version → build number collision. Bump ios.buildNumber in app.json, or set "appVersionSource": "remote" and let EAS manage it.
  • ITMS-91053: Missing API declaration → the Privacy Manifest requirement (iOS 17+). Add the relevant NSPrivacyAccessedAPICategory keys to a PrivacyInfo.xcprivacy file.
  • ITMS-90062: Bundle version must be a higher number → same as 90478, more polite.

If you'd rather not memorize any of these, letsdeploy.it exists specifically to catch them before you hit submit. But you'll still hit one once, and the decoder ring turns "3 days stuck" into "20 minutes annoyed."

Fix 3: a live TestFlight walkthrough with the tester on a call.

Sounds like overkill. It isn't. Testers themselves get stuck: they don't have the TestFlight app installed, they click the invite link on desktop instead of phone, or they "already have an account" and get lost in the redemption-code flow. The first tester gets a 15-minute call with you. Every tester after that gets a Loom of that call. Time saved: enormous.

What the community keeps getting wrong in tutorials

After 14 rounds of this, three tutorial-flavored misconceptions worth killing:

1. "You need Xcode installed to use TestFlight." You don't. You need Xcode when signing goes wrong and you want to inspect a .mobileprovision file by hand. For the happy path, eas build && eas submit is enough. Half the people I onboarded were on Windows.

2. "Internal testing is instant, external needs review." Half true. Internal testing (up to 100 people, added as users in ASC) is fast: the build appears within an hour of processing. External testing (up to 10,000 people, invited by email) needs Beta App Review, which averages 24 hours but has spiked to 5 days when a new iOS version drops. Don't promise external testers same-day access.

3. "You can hot-swap builds and testers stay in sync." No. When you push build 42, testers on build 41 don't auto-update. They get a badge in TestFlight and have to open the app there. If you want them on the new build, tell them explicitly, in whatever channel they actually read (spoiler: not email).

The deeper thing I keep noticing: EAS itself is fine. The docs are fine. The gap is the roughly eight concepts between "I wrote code" and "my friend can install it," and none of them are in the EAS docs, because they aren't EAS's problem. They're Apple's ecosystem.

If you're building anything in this space, the empathy exercise is simple: watch one first-timer, silently, for 90 minutes. You'll ship better onboarding by Tuesday.

What was your first TestFlight wall? Mine was waiting 25 minutes on an empty TestFlight tab, convinced I'd broken something.

Top comments (0)