A TestFlight build that appears greyed out in App Store Connect cannot be selected for internal or external testing, and the cause is almost always the status badge sitting next to the build row. Apple documents the exact set of statuses that disqualify a build, and one of them, Missing Compliance, accounts for most of these reports.
Short answer
A greyed out build is one App Store Connect treats as not available for testing. Apple's App build statuses reference lists five disqualifying states: Missing Compliance, Invalid Binary, Not Available for Testing, Expired, and Rejected. Most reports trace to Missing Compliance, which Apple's export compliance for beta builds page clears in two ways: click Manage on the row and answer the encryption questions, or set ITSAppUsesNonExemptEncryption in Info.plist so every future build clears the gate at upload.
What you should know
- Greyed out is a UI signal, not a status. App Store Connect dims any build row whose status sits in the disqualifying group named in Apple's build statuses reference.
- Missing Compliance is the most common cause. Apple gates beta distribution on export compliance before a build is selectable for internal or external testing.
- An Info.plist flag eliminates the per-build prompt. Setting ITSAppUsesNonExemptEncryption once removes the recurring Missing Compliance state for apps without custom encryption.
- Invalid Binary is a permanent block on the row. A row flagged Invalid Binary cannot be cleared by changing metadata; you re-archive and upload a fresh build under a higher CFBundleVersion.
- Expired rows drop after 90 days. Apple's published 90-day TestFlight availability window is hard, and the row stays visible but dimmed as a record.
- Beta Review and Compliance Review are separate gates. A build cleared for compliance can still sit in Beta Review without becoming testable to external groups.
What does "greyed out" actually mean in App Store Connect?
App Store Connect does not surface "greyed out" as its own status; the visual effect comes from one of the disqualifying values Apple names in App build statuses. When a build carries Missing Compliance, Invalid Binary, Not Available for Testing, Expired, or Rejected, the row dims and the build cannot be added to a test group, submitted for Beta App Review, or attached to an App Store submission. Apple treats every one of these states as ineligible for distribution.
The useful question is not "how do I un-grey the row," but "which of the five states is the row carrying, and what does Apple document for that state?" The Builds tab itself prints the status label next to the row, even when the row is dimmed, so the label is always the source of truth.
Which build statuses prevent you from selecting a TestFlight build?
Apple's build statuses page lists five values that block selection: Missing Compliance, Invalid Binary, Not Available for Testing, Expired, and Rejected. Two further states (Waiting for Review and In Beta Review) leave the row visible at full brightness but not yet available to external testers, which can look similar at a glance. The distinction matters because the right action differs by state, and treating a queue wait as a configuration problem produces unnecessary uploads.
| Status | Visual treatment | What it blocks | First action |
|---|---|---|---|
| Missing Compliance | Dimmed row, yellow label | TestFlight and App Store selection | Click Manage and answer questions, or set Info.plist key |
| Invalid Binary | Dimmed row plus ITMS email | Everything | Fix cited issue, upload new build with higher CFBundleVersion |
| Not Available for Testing | Dimmed row | TestFlight distribution | Fix provisioning profile to include the bundle ID |
| Expired | Dimmed row | Selection (90-day window passed) | Upload new build under same short version |
| Rejected | Dimmed row | Beta distribution | Fix flagged issue and upload new build |
| Waiting for Review | Normal row, yellow badge | External tester selection only | Wait for Beta App Review |
| Ready to Test | Normal row, green badge | Nothing | Add testers |
The dim treatment is consistent across the five disqualifying rows, which is why "greyed out" reads as a single problem to most developers even when the underlying causes are five separate ones.
How do you clear a Missing Compliance status the right way?
Apple's export compliance for beta builds page describes the documented path. Open the TestFlight tab, click the build row, then click Manage next to the build to answer the encryption questions. If the app uses only Apple-provided cryptography or none at all, the build clears Compliance on Save, the row brightens, and the status moves to Ready to Test or Ready to Submit.
For apps using custom encryption that falls under U.S. Department of Commerce regulations, Apple's app encryption documentation page describes the documentation upload, with a review window Apple states is approximately two business days for complete submissions. The Compliance label sits at Waiting for Export Compliance Review or In Compliance Review while Apple's reviewers check the documentation, and only resolves to a passing status (Ready to Test or Ready to Submit) once cleared.
For most no-code builders and AI-coded apps that ship through tools like FlutterFlow, Bubble, or Expo, the encryption surface is limited to HTTPS via system frameworks, which Apple treats as exempt. Those apps usually answer the questionnaire with a single No.
When should you use the Info.plist flag instead of the questionnaire?
The Info.plist key is the better default for almost every app that does not bundle its own cryptography. The per-build questionnaire is repetitive: every new build raises Missing Compliance again until answered. Adding the ITSAppUsesNonExemptEncryption Boolean to Info.plist (or to the Xcode target Info pane, which writes the same key) tells App Store Connect the answer at upload time, so a fresh build moves from Processing to Ready to Test or Ready to Submit without a prompt.
Apple's complying with encryption export regulations documentation covers when the value can be set to NO (no encryption used, or only exempt cryptography such as HTTPS via Apple-provided frameworks) and when the value must be YES with a CCATS or ERN on file. The decision is the same whether the build goes through TestFlight first or directly to App Store, so the Info.plist key fits both paths.
Two practical points. The key is read at upload, so the first build after adding it is the first one that benefits; older builds keep their Missing Compliance state. Second, setting the key to YES without uploading the required documentation produces a Waiting for Export Compliance Review state that itself blocks selection, so the value should match the app's actual cryptography use.
Why is the build still greyed out after you answered compliance?
Three causes account for most of these reports. The answer applied to a different build, often the previous version that still sits in the TestFlight list, while the current build remains in Missing Compliance. The App Store Connect web cache held the old state; a hard reload of the TestFlight tab or a fresh sign-in usually surfaces the cleared status. The answer was saved against the App Information section rather than the per-build Manage flow, which is the one Apple uses for beta selection on the specific row.
A fourth, less common cause: the build is no longer in Missing Compliance but has rolled into a different disqualifying state since the answer (for example, the 90-day Expired window quietly elapsing on a build that sat in Waiting for Review for weeks). The row label is the source of truth, not memory of the last action taken.
How does an Invalid Binary or Expired row differ from a Missing Compliance row?
The three statuses share the dim row treatment, but they are not the same problem and the documented path forward differs sharply.
Invalid Binary is raised after a static check on the uploaded artifact. The build never reaches Processing in a useful sense; Apple sends an ITMS email naming the rejection reason (a common one in 2024 to 2026 has been Privacy Manifest gaps under Apple's required reason API rules). No setting in App Store Connect clears the state; the only path forward is a re-archive with the cited issue resolved and a new CFBundleVersion.
Expired is the 90-day TestFlight availability window passing. Apple's beta testing documentation states the 90-day limit, and the row stays visible afterwards as a record. Bringing the same code back into TestFlight means a fresh upload under the same CFBundleShortVersionString with an incremented CFBundleVersion.
For builders shipping no-code or AI-coded apps, an external pre-upload scan against an OWASP MASVS profile can also catch silent Privacy Manifest, entitlement, and ATS issues that turn into Invalid Binary later. PTKD.com (https://ptkd.com) is one of the platforms focused on that pre-submission static check for APK, AAB, and IPA artifacts.
What to watch out for
The first trap is uploading a fresh build to clear a Missing Compliance row. The new build raises the same Missing Compliance state on upload; the cleanest action stays the Manage flow on the existing row or the Info.plist key for every future build.
The second trap is treating the App Information encryption answer as the per-build answer. Apple's documentation describes the App Information flow as a separate workflow for documentation upload and the assignment of a key value. The per-build Manage flow under TestFlight is the one that gates the specific build row for beta selection.
The third trap is reading Waiting for Review as a configuration error. The row is fully visible, not dimmed, and is on Apple's clock. Beta App Review medians shift week to week; pinging Apple Developer Support on a Waiting for Review row inside the first day does not move the queue.
The fourth trap is forgetting that the compliance posture can change between versions. If the app's encryption surface changes (a new SDK ships with custom cryptography, for example), the next build can return to Missing Compliance even when the previous one cleared. The answer is not sticky across the cryptography change; the questionnaire (or the documentation upload) needs to run again under the new surface.
Key takeaways
- Read the row label, not the visual treatment. "Greyed out" is the same dim rendering across five disqualifying states; the label next to the row names which one applies.
- Use the Info.plist key as the default. Setting
ITSAppUsesNonExemptEncryptionin Xcode removes the recurring Missing Compliance prompt for apps without custom encryption. - Treat Invalid Binary and Expired as fresh-upload paths. No App Store Connect setting clears either state; a new build under a higher CFBundleVersion is the documented response.
- Pre-upload checks have a place in the loop. Some teams add an external scanner aligned with OWASP MASVS to catch Privacy Manifest, entitlement, and ATS issues that turn into Invalid Binary; PTKD.com (https://ptkd.com) is one option in that category.
- Anchor every claim in its lane. Confirmed: Apple's five disqualifying statuses and the Info.plist encryption key. Observed: the 2026 pattern of cross-checked compliance answers under same-sprint metadata edits. Inferred: that App Store Connect cache freshness explains a share of "I answered but it is still greyed out" reports.
