Post

Replies

Boosts

Views

Activity

ASAuthorizationAppleIDProvider isAvailableAsync returning false globally on TestFlight (Builds 52-62) - App ID entitlements verified
Hey everyone, I'm hitting an absolute brick wall with Sign in with Apple on an Expo/React Native project distributed via TestFlight. The native API (isAvailableAsync() via expo-apple-authentication) is returning false globally across multiple physical devices, different user Apple IDs, and different network environments. We have completely ruled out a local code crash—the framework initializes, but the local iOS kernel is explicitly returning a hard false on the availability check before even attempting to present the modal sheet. Here is exactly what we have isolated and verified based on DTS documentation: Identifiers & App ID Setup: Team ID: NJ5JQ25956 (Luxor Interactive LLC) iOS Bundle Identifier: com.myoseph.carswipeapp App ID Capabilities: Checked and verified that "Sign in with Apple" is explicitly enabled on the Apple Developer Portal for this explicit bundle ID. Credentials & Provisioning Purge: We suspecting a cached provisioning profile or identifier cross-talk (our Android layout previously used a different package string, though we just unified it to com.myoseph.carswipeapp across the configuration scripts to rule out cryptographic hash collisions). We completely revoked and purged all old Distribution Certificates and App Store Provisioning Profiles from both the build engine cache and the Apple Developer Portal. Regenerated a completely fresh Distribution Certificate (Serial: 7383AE36E5D21E93F3F0B907D3A87DF3) and a brand-new, active Provisioning Profile (ID: L328ZDW2A4). Entitlements Inspection: Inspecting the compiled .ipa container structure shows the explicit com.apple.developer.applesignin entitlement key array is correctly present and injected. Despite having pristine, newly-minted cryptographic certificates tightly bound to a verified App ID, Build 62 on TestFlight still rejects the authentication framework instantly at the OS level. Is there a known propagation lag on Apple's identity database servers for newly updated Team ID capabilities, or is there an internal backend entitlement lock on our corporate Team ID container that isn't reflecting on the developer portal UI? Any insights or a sanity check from DTS would be an absolute lifesaver. Thanks in advance.
0
0
21
6h
ASAuthorizationAppleIDProvider isAvailableAsync returning false globally on TestFlight (Builds 52-62) - App ID entitlements verified
Hey everyone, I'm hitting an absolute brick wall with Sign in with Apple on an Expo/React Native project distributed via TestFlight. The native API (isAvailableAsync() via expo-apple-authentication) is returning false globally across multiple physical devices, different user Apple IDs, and different network environments. We have completely ruled out a local code crash—the framework initializes, but the local iOS kernel is explicitly returning a hard false on the availability check before even attempting to present the modal sheet. Here is exactly what we have isolated and verified based on DTS documentation: Identifiers & App ID Setup: Team ID: NJ5JQ25956 (Luxor Interactive LLC) iOS Bundle Identifier: com.myoseph.carswipeapp App ID Capabilities: Checked and verified that "Sign in with Apple" is explicitly enabled on the Apple Developer Portal for this explicit bundle ID. Credentials & Provisioning Purge: We suspecting a cached provisioning profile or identifier cross-talk (our Android layout previously used a different package string, though we just unified it to com.myoseph.carswipeapp across the configuration scripts to rule out cryptographic hash collisions). We completely revoked and purged all old Distribution Certificates and App Store Provisioning Profiles from both the build engine cache and the Apple Developer Portal. Regenerated a completely fresh Distribution Certificate (Serial: 7383AE36E5D21E93F3F0B907D3A87DF3) and a brand-new, active Provisioning Profile (ID: L328ZDW2A4). Entitlements Inspection: Inspecting the compiled .ipa container structure shows the explicit com.apple.developer.applesignin entitlement key array is correctly present and injected. Despite having pristine, newly-minted cryptographic certificates tightly bound to a verified App ID, Build 62 on TestFlight still rejects the authentication framework instantly at the OS level. Is there a known propagation lag on Apple's identity database servers for newly updated Team ID capabilities, or is there an internal backend entitlement lock on our corporate Team ID container that isn't reflecting on the developer portal UI? Any insights or a sanity check from DTS would be an absolute lifesaver. Thanks in advance.
Replies
0
Boosts
0
Views
21
Activity
6h