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.
Update: Found the root cause and fixed it, posting in case it helps anyone else hitting error 1000/1001 with Sign in with Apple on a Capacitor project.
Root cause: My Xcode project (App.xcodeproj) was missing CODE_SIGN_ENTITLEMENTS in the build settings, and intermittently DEVELOPMENT_TEAM as well. Without the entitlements file properly linked, ASAuthorizationController had no valid presentation anchor, so the Apple sign-in sheet would fail silently or throw error 1000/1001.
This was made trickier by two things:
- The community Capacitor Apple Sign In plugin doesn't implement ASAuthorizationControllerPresentationContextProviding out of the box, so I had to add a small Swift file (with an Objective-C bridging header) that explicitly provides the presentation anchor.
- Running npx cap sync wipes the entitlements/build settings each time, so the fix has to be reapplied after every sync (I ended up scripting this so I don't forget).
Fix steps:
- Create an App.entitlements file with the Sign in with Apple capability enabled.
- In Xcode, under Signing & Capabilities, confirm the entitlements file is linked (CODE_SIGN_ENTITLEMENTS in Build Settings should point to it).
- Confirm DEVELOPMENT_TEAM is set correctly (this can silently reset too).
- Add a small class conforming to ASAuthorizationControllerPresentationContextProviding that returns your key window as the anchor, and wire it into the sign-in flow via a Swift/Obj-C bridge if you're using the community plugin.
- Re-verify all of the above after every cap sync, since sync regenerates the Xcode project and drops these settings.
Once that was in place, Sign in with Apple worked end to end, verified via Supabase auth logs (auth.users / auth.identities).
Hope this saves someone the days I spent on it.