App review rejected due to using passkeys?

I submitted an app for beta app review. My app uses passkeys exclusively for registration and auth, so in the reviewer instructions, I said as much. The onboarding flow asks for three bits of info, and then attempts to create a passkey. I told the reviewer they could make up whatever they liked for those fields.

My app was rejected with "We have started your beta app's review, but we were unable to successfully access all or part of the app. In order for us to continue the review, we need to have a way to verify all app features and functionality. Typically this is done by providing a demo account that has access to all features and functionality in your beta app."

It then goes on to tell me "To help us proceed with the review of the app, please provide a user name and password in the Beta App Review Information section of App Store Connect."

It is not possible to provide webauthn credentials like this. I replied to their message accordingly, but I have yet to hear back.

Has anyone else run into this?

Answered by JetForMe in 906855022

I finally found the issue: mode=developer on the associated domains links causes a phone without the developer support enabled to emit

Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Unable to verify webcredentials association of <redacted BundleID> with domain <redacted hostname>. Please try again in a few seconds."

I had seen this in the simulator and thought it was temporary, as retrying almost always worked. But on an actual device without developer mode set, this error kept happening (and was silently ignored by my UI).

IMO mode=developer should have no effect if a) AASA developer mode is not enabled, or b) the app came from the App Store and not TestFlight. At the very least the error description doesn't match the conditions.

I submitted an app for beta app review.

What is the thing that you refer to as the beta app review? If you casually use the word 'beta,' that action alone will prompt them to reject your submission.

It is not possible to provide webauthn credentials like this.

I don't know what 'this' is or why that's is not possible, but they are not going to take your word at its face value. If I were you, I would show them a screen-capture video to show them how things are put altogether.

I don't know what 'this' is or why that's is not possible, but they are not going to take your word at its face value. If I were you, I would show them a screen-capture video to show them how things are put altogether.

I'm referring to TestFlight app review. I never used the word "beta" in my discussion with them, and that's not the reason it was rejected.

What is the thing that you refer to as the beta app review? If you casually use the word 'beta,' that action alone will prompt them to reject your submission.

You must not be familiar with app store submission, so let me try to explain it in simple terms. In their web form they have fields for me to provide them a username and password to a demo account so that they can log in and exercise the app.

It is not possible to give them a passkey via a form like this. "This" refers to the web form.

Maybe you don't know what passkeys are. They are a cryptographic key used for authentication, and they are stored in the keychain (Passwords). I can't give one to someone else in a text field.

The rejection does not necessarily mean that passkey-only authentication is prohibited. It means the reviewer could not obtain complete access, and the request for a username and password may be a generic response.

First, reproduce the onboarding flow using the processed TestFlight build on a clean device, a different Apple ID and an external network. Check the production logs and verify:

  • the associated-domain file and relying-party ID are available publicly;
  • passkey registration reaches the production backend;
  • no invitation, email verification, region restriction or pre-existing account is required;
  • a newly created reviewer account immediately receives enough sample data and permissions to test every feature.

Update Beta App Review Information with numbered steps beginning at a clean installation. State explicitly that the app has no password authentication and that the reviewer should create a new passkey. Attach a short recording of the exact TestFlight build completing this flow and ask Apple for the failing screen or approximate timestamp so you can match it to your logs.

If fresh passkey registration cannot reliably provide a complete review environment, add an explicit, fully disclosed demonstration mode containing representative data. Do not embed a passkey, private key or hidden authentication bypass in the binary. The demo path should be visible to App Review, isolated from real user accounts and documented in the review notes.

I would update the instructions and evidence before uploading another build unless your logs identify a client-side or associated-domain defect.

You must not be familiar with app store submission

In the past 15 and a half years, I have gotten more than 400 Mac applications and iOS apps approved.

Accepted Answer

I finally found the issue: mode=developer on the associated domains links causes a phone without the developer support enabled to emit

Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Unable to verify webcredentials association of <redacted BundleID> with domain <redacted hostname>. Please try again in a few seconds."

I had seen this in the simulator and thought it was temporary, as retrying almost always worked. But on an actual device without developer mode set, this error kept happening (and was silently ignored by my UI).

IMO mode=developer should have no effect if a) AASA developer mode is not enabled, or b) the app came from the App Store and not TestFlight. At the very least the error description doesn't match the conditions.