DEV Community

孫昊
孫昊

Posted on

Apple TestFlight's 4-Year-Old 'App Not Available' Bug Just Got Another Report — And Still No Fix

Quick PSA for any indie iOS dev hitting the TestFlight error:

"Could not install [App]. The requested app is not available or doesn't exist."

I went back to Apple Developer Forums today (2026-05-07) to check for any updates on this issue. Here's what I found.

The state of the bug

Thread 674932 — the canonical thread on this error — was first posted in February 2021. Last activity: May 2024. 400+ posts. Zero confirmed Apple fixes.

Thread 809636 — created December 2025. Same exact error: build shows green "Testing" status in App Store Connect, but the iPhone says the app doesn't exist. Apple staff replies: zero. Other devs replying: zero. The poster is just waiting in the dark, like the rest of us.

That's it. Four years. No fix.

What is the bug

You see your build in TestFlight. The build is state=VALID. Your tester is state=ACCEPTED. App Store Connect says "Testing." Press Install on the device, get "not available or doesn't exist."

Common context:

  • App is in PREPARE_FOR_SUBMISSION (never released to App Store)
  • Or: app was previously Removed from Sale
  • Internal tester, not external

If your TestFlight build shows green and you can't install it, you're not alone, and it's not your config.

The one workaround that's actually been replicated

Buried in thread 674932 is one workaround that multiple devs report works:

  1. Submit your app for App Store review.
  2. Wait for approval (~24-72h for free apps with simple functionality).
  3. After approval, TestFlight builds become installable.

The hypothesis: TestFlight's install pathway depends on metadata cache that only fully populates after the app has been in READY_FOR_SALE (or close to it). PREPARE_FOR_SUBMISSION apps never trigger that cache rebuild, so the install lookup fails silently.

Submitting for review doesn't actually require you to release publicly — you can choose "Manual Release" and hold the approved build indefinitely.

What we did

I have 4 iOS apps stuck in this state for 60 days. All builds VALID, all testers ACCEPTED, all metadata complete. Submitting was the only path I hadn't tried.

So this morning I built a small script: asc_submit_for_review.py — pre-flights all the App Store version requirements (build attached, screenshots present, version state submittable), then POSTs to /v1/appStoreVersionSubmissions.

ASC_BASE = "https://api.appstoreconnect.apple.com"

def submit_version(token, version_id):
    payload = {
        "data": {
            "type": "appStoreVersionSubmissions",
            "relationships": {
                "appStoreVersion": {
                    "data": {"type": "appStoreVersions", "id": version_id}
                }
            }
        }
    }
    r = requests.post(
        f"{ASC_BASE}/v1/appStoreVersionSubmissions",
        headers={"Authorization": f"Bearer {token}"},
        json=payload,
        timeout=30,
    )
    return r.status_code in (200, 201)
Enter fullscreen mode Exit fullscreen mode

Pre-flight checks before submitting:

  • Version state is one of PREPARE_FOR_SUBMISSION / DEVELOPER_REJECTED / REJECTED / METADATA_REJECTED
  • Build is attached to that version (via /v1/appStoreVersions/{id}/build)
  • At least one screenshot set exists across locales
  • Required metadata (description, keywords, privacy URL, age rating) is present

If preflight passes, you POST. The version transitions to WAITING_FOR_REVIEW. From there it's Apple's queue.

Why I'm posting this

If you're on day 30+ of debugging this error and have eliminated:

  • Tester state (use /v1/betaGroups/{id}/betaTesters to verify ACCEPTED)
  • Build state (use /v1/apps/{id}/builds to verify VALID + not expired)
  • Apple ID conflict (the "1 Apple ID per tester email" issue from thread 702988)
  • Paid Apps Agreement signed
  • Distribution cert + provisioning profile
  • iOS version compatibility

…then your remaining lever is: submit for review.

Apple has had this report on file since 2021. They're not going to fix it. The forum is where to go for ground truth, not where to wait for resolution.

What I'm watching for

I submitted my canary app this morning. Will report back in 48-72h with what happened. If the workaround holds, I'll merge it into my open-source ASC API toolkit and write up the actual install verification.

If it doesn't hold — if approval comes through and TestFlight still fails — that's a different (and arguably worse) story.

For now, if you're stuck on this bug: don't wait for an Apple fix that's been four years and counting in the making. Submit for review. It costs you nothing if it doesn't work, and it's the one path multiple devs have replicated.

Sources verified 2026-05-07

If you've hit this and want to compare notes, drop a comment with your appStoreState + tester state + how long you've been blocked. Useful data for the next dev who lands here.

Top comments (0)