Update, September 14: Sign in with Apple is now working for us, including in our actual Expo/Supabase app. Sharing what we found in case it helps others.
We reproduced the failure in a minimal native Swift app using AuthenticationServices, with no Expo or Supabase involved. The app received authorization error 1001; with Apple’s Accounts/AuthKit logging profile installed, device logs showed the underlying rejection: -24000 / Invalid client. The cancellation-style error did not mean we had manually canceled.
The most actionable finding: although the provisioning profile embedded in our failing builds had the correct Sign in with Apple entitlement and a future expiration date, Apple’s API reported its state as INVALID.
We then built the same native test with a freshly generated ACTIVE provisioning profile, keeping the same bundle ID, developer team, distribution certificate, SDK, and request parameters. It succeeded. An Expo build using that same fresh profile also succeeded, including the Supabase identity-token exchange. We subsequently verified login, onboarding, session persistence after restart, and sign-out/sign-in in the actual app.
Caveat: this is a successful recovery, not proof that the profile alone caused or fixed the problem. We cannot rule out Apple-side state changes or propagation during testing, and we don’t know why the previous profile was invalid. Our successful tests so far are internal/ad hoc builds; we have not yet verified the updated App Store distribution.
For anyone still stuck, checking the profile’s current status with Apple, rather than relying only on its embedded entitlements and expiration date, seems worth investigating. We did not need to change our production bundle ID, upgrade the Expo Apple-auth wrapper, or change Supabase’s provider configuration.
Also, a correction to my earlier post: I mistakenly labeled the App ID resource identifier as our Team ID. Our actual Team ID is GNNA76QH2C.
Topic:
Privacy & Security
SubTopic:
Sign in with Apple
Tags: