Advanced App Clip Experiences stuck in "Received" — never transition to "Published"

Thanks for the post, interesting that's something in the process.

TN3168: Making your App Clip available in the App Store | Apple Developer Documentation

https://developer.apple.com/forums/thread/804858

There is something I always like to check when deploying AASA files. When the full app is installed, iOS handles the URL invocation locally via your apple-app-site-association (AASA) file and entitlements, bypassing the need to query Apple's App Clip CDN. The fact that this works proves your code, AASA file, and associated domains are configured correctly. The failure for fresh devices is happening because Apple's CDN has not yet been updated with your App Clip's metadata?

Can you provide me a link to your AASA file in your server so we can see why is not syncing into the Apple servers? Is your server preventing or blocking IP address or user agents from requesting the AASA file?

Sometimes, the job queue in App Store Connect simply drops the task. You can often force it to re-queue by making a trivial update:

• Go into App Store Connect > your App > App Clip Experiences.
• Edit one of the Advanced Experiences (e.g., change the subtitle slightly, or modify the header image).
• Save the changes.
• Wait a few hours to see if the status transitions from "Received" to "Published."

If you still believe is a bug, have you filed a bug and have a FB number available?

Thanks

Albert Pascual
  Worldwide Developer Relations.

Thanks Albert. The AASA is publicly accessible with no blocking, no IP filtering, and no user agent restrictions:

https://fanarchy.fans/.well-known/apple-app-site-association

Apple's own CDN already has the current version synced:

https://app-site-association.cdn-apple.com/a/v1/fanarchy.fans

So the AASA sync is working — the issue is the experiences stuck in "Received" and not transitioning to "Published."

We're also seeing inconsistent behavior across devices. QR code scans for the same URL work on some devices but show "App Clip not available" on others. For example, it works on an iPhone but fails on an iPad — same URL, same network, both fresh devices that have never had our app installed.

Interestingly, when we removed /next-game from the App Clip entry in our AASA, QR codes started falling through to Safari where our Smart App Banner meta tag (apple-itunes-app with app-clip-bundle-id) successfully triggers the App Clip card. This workaround is functional but shouldn't be necessary.

We have other App Clip Experiences that we haven't touched at all — /g, /invite, /post, /profile — all also stuck in "Received." These could serve as clean examples if you need to investigate the pipeline issue.

We'll try the re-queue trick (trivial edit to the experiences) and report back. We have a live event tonight (Opening Day) with QR codes depending on this, so any help expediting is appreciated.

App Store ID: 6569229589

@fanarchy

Thank you for the post. It appears that the file is syncing to the servers without any issues. This is excellent news, and I appreciate you providing additional information regarding the problem.

Your discovery of removing the “/next-game” from the AASA file, which causes it to fall back to Safari, is brilliant. This effectively isolates the issue, but still we have the issue in the App Store App Clip publishing.

Safari Smart App Banners do not rely on the App Store Connect "Advanced Experience" database. When Safari loads your page, it reads the <meta name="apple-itunes-app" content="app-id=..., app-clip-bundle-id=..."> tag and cross-references your AASA file locally. Because your AASA and meta tags are perfect, this works flawlessly.

In any case I see the issue is in the configuration on the App Store and you should file a bug for them to take a look at the process with your App Clip. The issue here is the status of the App Clip should eventually become published.

Once you open the bug report, please post the FB number here for my reference.

If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why?

Albert Pascual
  Worldwide Developer Relations.

Thanks Albert, we'll file the bug report.

One more ask: we have a live event tonight with printed QR codes and we're seeing very inconsistent behavior across fresh devices. Some devices load the App Clip perfectly via the Safari Smart App Banner fallback, while others show "App Clip not available". Same URL, same network, all fresh devices that have never had our app installed.

Is there anything else we can try on our end to improve reliability tonight? Any headers, cache settings, or meta tag adjustments that might help the Safari fallback path work more consistently? Or is the inconsistency entirely on the ASC publishing side?

We're running out of ideas and have fans arriving soon. I'm attaching the QR code and the result when it fails. Thanks!

Update with new findings:

We discovered that our /g/{gameId} App Clip experience works perfectly on fresh devices via QR code scan — every time, first try. But /next-game never works on first scan for fresh devices. Both experiences show "Received" status in ASC. The /g experience was created earlier than /next-game.

Our workaround: we deactivated the /next-game ASC experience. Now QR scans fall through to Safari, where — as you explained — the Smart App Banner reads the meta tag and cross-references the AASA locally, loading the App Clip successfully.

Interesting behavior: once a device loads the App Clip binary through the Safari/meta tag path, subsequent QR scans for /next-game invoke the App Clip directly. iOS appears to cache the binary, and the direct invocation works from that point forward.

So the binary, AASA, and meta tags are all correct. Something specific to the /next-game experience is preventing first-time invocation via QR scan on fresh devices, while the older /g experience works fine in the same state.