I am attempting to configure appclips, but I am getting this error in App Store Connect. I created an app clips target in my project, I have checked the XCAsset files and it is included when archived and pushed to App Store Connect. In both my parent and my app clips target I've added the associated domains capabilities, with the following associated same domains for both targets: appclips:akin-server-side-staging.onrender.com appclips:akin-server-side.onrender.com applinks:akin-server-side-staging.onrender.com applinks:akin-server-side.onrender.com My server is configured to serve the following json at all permutations of the staging endpoints and prod endpoints for both well known and aasa without well known. Here is one of them: https://akin-server-side.onrender.com/.well-known/apple-app-site-association Here is the JSON it is returning: {"applinks":{"details":[{"appIDs":["8PJ28P9ZZ8.com.ElevatedUnderdogs.akin1"],"components":[{"\/":"\/appClips\/referral\/venueToUser\/*"}]}]},"appclips":{"apps":["8PJ28P9ZZ8.com.ElevatedUnderdogs.akin1.Clip"]}} And yet I'm still getting Invalid Entitlement: Unknown ID in the store.

Context: Currently in iOS, both “Allow Once” and “While Using the App” location permission decisions yield .authorizedWhenInUse. This conflation prevents apps from knowing whether the user has provided a one-time allowance or a persistent in-use allowance. Problem Statement Ambiguous App Behavior: After a user selects “Allow Once,” the app remains in .authorizedWhenInUse, making it appear to the developer as if the user granted a more persistent “While Using” permission. Poor User Experience: If the user later indicates they want to upgrade to “Always,” developers must guess whether iOS will show another system prompt. This can lead to “dead” button presses or pointless transitions to Settings. Lack of Transparency: The user’s real intention—“I only trust you this one time”—gets lost in .authorizedWhenInUse with no direct or synchronous detection mechanism. Why This Wouldn’t Violate SRP The CLLocationManager’s` Single Responsibility: Manage and expose the user’s current location authorization state. Adding .authorizedOneTime or an isOneTime property fits neatly into that responsibility. It’s still describing the user’s level of trust for location usage, just with more specificity. No Overreach: This doesn’t add new logic outside location permissions—it merely refines the existing state definitions for clarity. Simplifies the Developer Flow: Instead of co-mingling “Allow Once” and “While Using,” the system returns the precise state, letting developers handle transitions more gracefully while abiding by iOS’s privacy rules. Benefits Improved UX: Developers can present more accurate prompts or guidance. If .authorizedOneTime, the app can immediately direct the user to Settings for a persistent upgrade, rather than futilely calling requestAlwaysAuthorization() again. Less Confusion: A distinctly reported “Allow Once” state eliminates guesswork, polling, or timed approaches that degrade user experience. Consistent with iOS’s Privacy Focus: Providing a read-only flag or status for “One Time” aligns with Apple’s approach to clarity around permissions, without letting apps forcibly bypass user intentions.