Subject: Sign In with Apple consistently fails with AuthorizationError 1000 (empty userInfo) immediately after successful biometric authentication — native delegate logging confirms failure occurs before authorization is returned to app App ID: com.andresalecina.vant
Team ID: C6GK7Z5GY2
Services ID: com.andresalecina.vant.signin Summary:
Sign In with Apple fails 100% of the time in our native iOS app (Capacitor 7 wrapper) with error code 1000 and completely empty userInfo. The native authentication sheet displays correctly and the user completes Face ID successfully, but authentication fails immediately afterward. Critical new evidence (delegate-level logging):
We instrumented both ASAuthorizationControllerDelegate callback methods directly with NSLog to determine exactly where the failure occurs: authorizationController(controller:didCompleteWithAuthorization:) — never fires. Confirmed across multiple fresh test attempts. authorizationController(controller:didCompleteWithError:) — fires every time, receiving: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000 "(null)" with completely empty userInfo. This confirms the failure originates inside AuthenticationServices itself, before any authorization object is ever returned to our app. Our app code is not receiving a token, credential, or authorization of any kind to process — there is nothing for our code to mishandle. Everything already verified clean on our end: Sign In with Apple capability present in Xcode target and confirmed in Apple Developer Portal (Primary App ID, not grouped) Entitlement com.apple.developer.applesignin confirmed present in both the development-signed binary and the App Store distribution provisioning profile Team ID in the compiled binary matches the entitlement (verified via codesign -dv and codesign -d --entitlements) Provisioning profile freshly regenerated after capability was added Apple Developer Program License Agreement and Developer Agreement both fully accepted, no pending items Reproduces identically on two separate physical devices (one iOS 27 beta, one non-beta), on both WiFi and cellular Reproduces with a completely clean Apple ID test account (no prior Family Sharing/managed account involvement, confirmed adult standard account) Device clock, timezone, and Screen Time/Content & Privacy Restrictions confirmed not a factor Native plugin code reviewed line-by-line: uses stock ASAuthorizationAppleIDProvider().createRequest(), standard .fullName/.email scopes only, robust presentation anchor resolution (no detached/fake UIWindow) Timeline:
The Sign In with Apple capability was added to this App ID within the past 24–48 hours (it was missing entirely on our initial rejected App Store submission). Error 1000 has persisted consistently across many rebuilds since the capability was added, which raises the possibility of a propagation delay on Apple's authentication backend, but this has now exceeded typical propagation windows for other capabilities we've observed (Push Notifications, Associated Domains). What we're asking:
Can you verify, on Apple's side, whether App ID com.andresalecina.vant under Team C6GK7Z5GY2 is fully provisioned and active on Apple's Sign In with Apple authentication backend? All client-side, code-side, and account-side factors we can verify are confirmed correct; the delegate-level logging above confirms the failure is occurring before any authorization is returned to the client, which points to a state on Apple's servers that isn't visible to us through the standard Developer Portal UI. Happy to provide device sysdiagnose logs, the full Xcode archive, or a minimal reproduction project (bare SwiftUI, no Capacitor/Supabase) if useful.