Post

Replies

Boosts

Views

Activity

Reply to Sign in with Apple: "Sign Up Not Completed" for every App ID in our team — framework returns canceled (1001) with empty userInfo
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.
Sep ’26
Reply to Sign in with Apple: "Sign Up Not Completed" for every App ID in our team — framework returns canceled (1001) with empty userInfo
Still affected as of 27 August 2026 — could Apple apply the same server-side team-registration fix here? Team ID: A7L782V843 Bundle ID: com.perfectlyhuman.chezmoi TestFlight: 1.0.1 (9) Device: iPhone, iOS 26.0 (23F84) The native Sign in with Apple sheet opens and authentication completes, but the sheet then shows “Sign Up Not Completed.” The app receives AuthenticationServicesCore.AuthorizationError Code=2 / a cancellation-style result and no identity token, so no request reaches Supabase or our backend. The App ID has APPLE_ID_AUTH enabled as a primary App ID, and the signed binary and embedded provisioning profile include com.apple.developer.applesignin = [Default]. We have a sysdiagnose captured immediately after reproducing the failure and can provide it privately on request. This matches the resolved reports in this thread; no app-side configuration change has resolved it for us.
Aug ’26
Reply to Sign in with Apple: "Sign Up Not Completed" for every App ID in our team — framework returns canceled (1001) with empty userInfo
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.
Replies
Boosts
Views
Activity
Sep ’26
Reply to Sign in with Apple: "Sign Up Not Completed" for every App ID in our team — framework returns canceled (1001) with empty userInfo
Still affected as of 27 August 2026 — could Apple apply the same server-side team-registration fix here? Team ID: A7L782V843 Bundle ID: com.perfectlyhuman.chezmoi TestFlight: 1.0.1 (9) Device: iPhone, iOS 26.0 (23F84) The native Sign in with Apple sheet opens and authentication completes, but the sheet then shows “Sign Up Not Completed.” The app receives AuthenticationServicesCore.AuthorizationError Code=2 / a cancellation-style result and no identity token, so no request reaches Supabase or our backend. The App ID has APPLE_ID_AUTH enabled as a primary App ID, and the signed binary and embedded provisioning profile include com.apple.developer.applesignin = [Default]. We have a sysdiagnose captured immediately after reproducing the failure and can provide it privately on request. This matches the resolved reports in this thread; no app-side configuration change has resolved it for us.
Replies
Boosts
Views
Activity
Aug ’26