We are hitting the same Sign in with Apple failure described in thread 837986, with an identical log signature. Posting our team details in case it helps the ongoing investigation.
Team ID: CDLWFYN589 Bundle IDs: br.com.cesto, br.com.cestoparceiros App IDs created: 2026-08-20 (both recreated on that date) Build: TestFlight, iOS 26, physical iPhone
SUMMARY
Every first-time Sign in with Apple authorization fails with "Sign Up Not Completed". The Apple sheet renders correctly, with the right app name and the user's account. The user authorizes. The failure happens AFTER consent, in the SRP exchange with the Apple ID server. Our backend is never reached - signInAsync never returns a credential, so no server-side code of ours participates in the failing step.
DEVICE LOG (akd, 2026-09-05 17:21:06-13, UTC-3)
Client has default access level in SiwA entitlement Fetching developer team for client with ID: <private> Encountered error while fetching developer team: Error Domain=AKSQLError Code=-6003 No applications were found with the provided Client ID: <private> Application has no shared credentials Using personal credential state - 2, error - Error Domain=AKAuthenticationError Code=-7074 presenting authorization UI for request <- sheet appears Got a response from user <- user authorizes No password, but CK is available. Will ask for ck-based auth. Task <59764A72-...> received response, status 200 AppleIDAuthSupport: setError: 2:M2 missing (bad password) Invalid/missing value for key acname: (null) Invalid value for key ut: (null) Invalid value for key authType: (null) SRP authentication with server failed! Error Domain=com.apple.AppleIDAuthSupport Code=2
The server returns HTTP 200 with the server proof (M2) absent. The "bad password" string appears to be the generic label for error 2 rather than a diagnosis - there is no password in this exchange, as the preceding line shows (No password, but CK is available).
WHAT WE HAVE ALREADY VERIFIED
- Capability APPLE_ID_AUTH present on both App IDs, with APPLE_ID_AUTH_APP_CONSENT: PRIMARY_APP_CONSENT (read back through the App Store Connect API).
- com.apple.developer.applesignin: [Default] present in the SHIPPED .ipa, verified with codesign -d --entitlements :- on the extracted payload rather than on the archive.
- Embedded profile is "iOS Team Store Provisioning Profile" and carries the entitlement (security cms -D -i embedded.mobileprovision).
- Bundle IDs match across the project config, Identifiers and App Store Connect.
- No other App ID in the team declares APPLE_ID_AUTH.
- Program License Agreement accepted on 2026-08-25; 2FA active on the account.
- Requesting only fullName, with no email scope, does not change the outcome.
The log line "Client has default access level in SiwA entitlement" is what closes the client-side question for us: the entitlement is present and read correctly ON DEVICE, not merely present in our build output.
QUESTION
Given the confirmation earlier in thread 837986 for team GW7XA5CX69 - same build and same configuration starting to work with no changes on their side - this looks like the same server-side condition affecting recently created App IDs. Could our Team ID be included in that investigation?
Happy to file a Feedback with the full log attached and post the number here if that is the preferred route.