iOS app beta testing with TestFlight: what nobody tells you

TestFlight beta testing beyond the basics: 90-day build expiry, Beta App Review, feedback screenshots, simulator vs device, and why you still need a Mac. By betatest.ing team · October 12, 2026 · 7 min read.

Key takeaways

  • TestFlight builds expire 90 days after upload for every tester; calendar the date and upload a fresh build before it hits.
  • External testing needs Beta App Review for the first build of each version; a missing demo account or placeholder screens will delay it.
  • Tester feedback and screenshots land in App Store Connect and Xcode Organizer, not your inbox; check them daily.
  • The simulator cannot run TestFlight and lacks camera, real push, sandbox IAP, Apple Pay and real performance; keep real devices on the oldest and newest iOS you support.
  • Building, signing and device testing require Apple hardware; a hosted service removes that requirement for the testing part.

In this article

  1. The numbers that shape your plan
  2. The 90-day expiry will surprise you once
  3. Beta App Review is real review
  4. Where feedback and screenshots actually go
  5. The simulator cannot run TestFlight, and other hardware facts
  6. Why Apple hardware is still needed, and what that means for automation
  7. A TestFlight checklist that fits on one screen
  8. What to test that TestFlight will not tell you
  9. Related guides
  10. Automating the repetitive part

TestFlight is the only sanctioned way to put a pre-release iOS build on someone else's iPhone, and the basics are well covered: upload a build, add testers, send invites. What catches teams is everything around the basics. This post collects the parts that are usually learned the hard way, with references to Apple's TestFlight documentation and the App Store Connect help where they apply.

The numbers that shape your plan

From Apple's documentation:

  • Internal testers: up to 100 people who hold a role on your App Store Connect team. No review. Builds are available as soon as processing finishes.
  • External testers: up to 10,000 people, invited by email or through a public link. The first build for a new version goes through Beta App Review before external testers can install it.
  • Build expiry: every build expires 90 days after upload, for internal and external testers alike.
  • Builds per version: you can have many builds under one version number, and testers see the newest you have enabled for their group.

Those four facts drive the rest of this post.

The 90-day expiry will surprise you once

Ninety days feels long when you upload. It is not. A beta that starts in October with monthly builds reaches January with the October build dead for everyone who did not update, and TestFlight does not auto-update testers unless they have the setting on. Expired builds simply stop launching; testers see a message that the beta has expired and, if they do not know what that means, they assume your app is broken.

What to do:

  • Put the expiry date in your project calendar when you upload each build.
  • Upload a new build at least every six to eight weeks even if nothing changed, so there is always a live build.
  • Tell testers in the welcome note that builds expire and that TestFlight will show them an update.
  • If you run a long private beta instead of launching, consider whether the App Store with a limited feature flag would serve you better than a permanent beta.

Beta App Review is real review

External testing requires Beta App Review for the first build of each version and sometimes for later ones. It is lighter than App Store review, but it applies the App Store Review Guidelines, it can take a day or more, and it can reject. Common reasons that stop a beta before it starts:

  • No demo account in the Beta App Review Information, so the reviewer cannot get past login.
  • Placeholder content or screens that say "coming soon".
  • Crashes on launch on the reviewer's device, often an older iPhone or iPad.
  • Missing or vague "What to Test" notes.
  • Permission prompts without purpose strings that explain why.

Plan the first external build a week before you need testers on it. Use internal testing for the daily loop, since it skips review entirely.

Where feedback and screenshots actually go

Testers can send feedback from inside the TestFlight app, and on iOS they can take a screenshot and tap "Share Beta Feedback" to send it with annotations and a comment. Crash reports are sent with the tester's consent, and TestFlight asks them for a comment after a crash.

Where it lands: App Store Connect, under TestFlight, in the Feedback section, with screenshots and crash feedback as separate lists. It also shows up in Xcode's Organizer under Feedback. It does not email you, and it is not in your bug tracker. Someone must check it daily, or testers conclude that nobody reads it.

Also be aware that feedback includes device, OS version, battery, free space and connection type. That context is more useful than most written bug reports, so encourage testers to use it instead of messaging you a screenshot in a chat app with no details.

The simulator cannot run TestFlight, and other hardware facts

The iOS Simulator in Xcode runs your app compiled for the Mac's architecture. It does not run TestFlight builds, it does not have the App Store, and it is not a device for several things you need to beta test:

  • Camera and photo capture: no camera. Photo library picking works with sample images.
  • Push notifications: real APNs delivery to the simulator depends on the Xcode and macOS version and Apple silicon; local simulated pushes are possible but are not the same as a background delivery on a locked phone.
  • In-app purchases: work only with a StoreKit configuration file or the sandbox; the App Store sandbox flow with a real Apple ID happens on devices.
  • Apple Pay, NFC, Bluetooth, cellular, Face ID: Face ID can be simulated with a menu item; the rest need hardware.
  • Performance and thermals: meaningless on a Mac.

So the simulator is for layout, localization, dynamic type, dark mode and quick regression. Real devices are for everything that touches the system. Keep at least one device on the current iOS release and one on the oldest version you support. If you can, keep one on the current iOS beta, because iOS users adopt new versions quickly and a September iOS release can break an app that was fine in August.

Why Apple hardware is still needed, and what that means for automation

Building and signing an iOS app requires Xcode, which requires a Mac. Running the simulator requires a Mac. Installing on a device for automated testing requires a Mac connected to the phone or a cloud service that owns both. There is no Linux or Windows path.

For a team without Macs, the options are:

  1. Cloud CI with macOS runners for building and simulator tests.
  2. A hosted device cloud for real iPhones.
  3. A service that owns the Macs and devices and runs the testing for you.

betatest.ing is in the third category: you upload an .ipa or connect a build, and the AI beta tester runs it on iOS simulators and real iPhones that we host, so you do not need a Mac to get device-level test results. Internal distribution still goes through your TestFlight.

A TestFlight checklist that fits on one screen

Before the first external build:

  • Beta App Review Information filled in: demo account, contact, notes.
  • "What to Test" written for this build, two or three bullets.
  • Privacy policy URL set, because Apple shows it to testers.
  • Purpose strings for every permission you request.
  • Crash reporting confirmed on a TestFlight build, not just debug.
  • Internal round done on at least two real devices.

During the beta:

  • Check App Store Connect feedback and crashes daily.
  • Note the expiry date of each build.
  • Upload a new build after each fix batch; TestFlight supports many builds per version.
  • Re-test on the device and iOS version that produced each bug.

Before submitting to the App Store:

  • Remove or disable beta-only UI and test endpoints.
  • Confirm the version and build number increment.
  • Run the App Store checklist for guideline items like account deletion and Sign in with Apple.

What to test that TestFlight will not tell you

TestFlight tells you about crashes and what testers choose to write. It will not tell you that:

  • The keyboard covers the submit button on an iPhone SE.
  • Dynamic Type at the largest accessibility size truncates your pricing.
  • VoiceOver reads your icon buttons as "button".
  • The app loses the form when a call comes in.
  • Universal links open Safari instead of the app because the association file is stale.
  • The restore purchases button does nothing after a reinstall.

Those come from deliberate testing: a list of flows, a set of devices and settings, and someone or something walking through them on each build. The mobile app beta testing guide has a longer list, and the beta test plan generator produces a plan you can hand to testers.

Related guides

Automating the repetitive part

Every build, somebody should install it, log in, walk the core flows on a small and a large iPhone, switch to large text and dark mode, deny then grant each permission, go offline mid-request, and capture screenshots and a recording of anything wrong. Doing that by hand on every TestFlight build is where teams stop doing it.

An AI beta tester does that part on hosted simulators and real devices, following goals rather than brittle scripts, and files each problem with steps, severity, annotated screenshots and a recording. It also runs a Store readiness check for the guideline items Beta App Review and App Store review tend to catch. Your TestFlight testers remain essential for what a hosted device cannot reproduce: a week of real notifications, their own photo library, their own commute.

Start for $1 and run an iOS beta pass on real iPhones without owning a Mac.

Related guides

Each ends with a test task you can send to your AI beta tester.

All beta testing guides

Keep reading

All articles

Sources