DEV Community: Melroy D Souza

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

Melroy D Souza — Wed, 29 Jul 2026 04:47:34 +0000

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)

"Do I need a Mac?" (Answer: not for EAS. Yes, eventually, for xcrun when things go wrong.)
"Wait, what's the difference between App Store Connect and my Apple Developer account?"
"I ran eas build and it succeeded. Where's the app?"
"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]

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]

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

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)

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.

How to Vibe-Check an AI-Generated React Native Codebase Before You Ship

Melroy D Souza — Wed, 22 Jul 2026 10:46:14 +0000

Three AI failure modes no test catches: duplication instead of reuse, style drift, and tests that mock the hard part.
A 20-minute review pass: find what should have been reused (3 min), read the tests and ignore the impl (7 min), run it on a device (5 min), ask the "six months from now" question (5 min).
The bar for AI-generated code should be higher than for human code — a human is committing their reputation to what they wrote. The AI isn't.
Rewrite when the pattern would set a precedent. Accept when the failure is small and isolated.

Claude Code will produce a working React Native feature in 20 minutes that would have taken you four hours. Tests pass. Typecheck passes. You ship it.

Six weeks later you're wondering why the codebase feels harder to work in than it should.

What happened: the AI made choices that were locally correct and globally corrosive, and no automated check caught them.

Here's how to catch them yourself.

The three failure modes

1. Duplication instead of reuse. The AI didn't know useUser() existed, so it wrote its own version. Or it wrote three functions that all normalise a phone number, none of them quite the same.

2. Style drift. Your codebase uses styled-components. The AI generated a screen with inline StyleSheet.create because that's more common in its training data. Both work. Now your codebase has two styling systems.

3. Test-driven wishful thinking. The AI wrote a test that mocks the tricky part. Test passes. The tricky part still doesn't work in production.

None of these are caught by tests, typecheck, or linting.

The 20-minute review pass

For every AI-generated PR:

Minutes 1–3: Find the smallest new thing that should have been reused

Search the codebase for the function name. If two exist, decide which one stays.
Check the imports. Did the AI pull in a new library when an existing one would work?

Minutes 4–10: Read the tests, ignore the implementation

What are the assertions actually checking — the important behaviour, or the easy behaviour?
Are the mocks hiding the hard part?
Would this test still pass if the implementation was return true for the happy path?

Minutes 11–15: Run the feature end-to-end on a device

Don't trust "tests pass." Open the app and do the flow.
Empty state? Error state? Slow network?

Minutes 16–20: The "six months from now" question

If someone joined the team in six months, would they know why this exists?
Will the naming still make sense when the product has changed?
Would you be embarrassed if this was on your GitHub?

Reject the PR if any of the above smells. The AI can rewrite it in five minutes; you save yourself weeks of drag.

What good AI-generated code looks like

Reuses existing helpers instead of inventing new ones.
Follows existing patterns — styling, error handling, state management — without being told to.
Tests assert on user-visible behaviour, not implementation details.
Function and variable names match the codebase's conventions.
Comments explain why, not what.

If your CLAUDE.md is doing its job, most of these are automatic. If it isn't, you'll see the failure modes above in every PR.

When to accept vs. rewrite

Accept when: the failure is small (one duplicate helper), the risk is low (isolated feature), and the fix cost is high (refactoring would take longer than the value it returns).

Rewrite when: the pattern would set a precedent (the next five features would follow it), the risk is high (it touches shared code), or the code just feels foreign in the codebase.

The bar for AI-generated code should be higher than for human-generated code, not lower. A human is committing their reputation to what they wrote. The AI isn't.

Setting up guardrails past one dev

If you're on a team using AI heavily:

Require a CLAUDE.md in every repo. Update it every time you catch the AI going in a wrong direction.
Shift the code review focus. Human reviewers should focus on the failure modes above, not on "does this work" — the AI will make it work.
Run a weekly AI code-quality review. Grep for patterns the AI introduced, refactor duplicates, and update CLAUDE.md so the next PRs don't repeat them.

The takeaway

AI code that you don't review will make your codebase worse over time. AI code that you review carefully will make you 3× faster without the tax.

The difference is entirely in your review discipline.

One thing that reduces the failure modes at the source: pointing the agent at a codebase that already has conventions rather than an empty folder. Applighter ships Expo + Supabase templates with the patterns and agent docs already in place, so there's less for the AI to invent.

What's the worst thing an AI has quietly done to your codebase? Mine wrote a third phone-number formatter.