Skip to content

Add the ability to set preferImmediatelyAvailableCredentials on passkey requests - #405

Merged
jhaven-stytch merged 1 commit into
mainfrom
jordan/add-preferImmediatelyAvailableCredentials
Jan 5, 2026
Merged

Add the ability to set preferImmediatelyAvailableCredentials on passkey requests#405
jhaven-stytch merged 1 commit into
mainfrom
jordan/add-preferImmediatelyAvailableCredentials

Conversation

@jhaven-stytch

Copy link
Copy Markdown
Contributor

Linear Ticket: No ticket

Changes:

  1. Adds the ability to set preferImmediatelyAvailableCredentials on passkey requests
  2. Bumps version for publishing

Notes:

  • Before, we were explicitly setting this to true on registration requests and not setting it (defaulting to false) on authentication requests. Now, it is configurable by the developer in both flows. Notice that the default values, however, are different between register and authenticate. That is to preserve compatibility with the previous behavior.

Checklist:

  • I have verified that this change works in the relevant demo app, or N/A
  • I have added or updated any tests relevant to this change, or N/A
  • I have updated any relevant README files for this change, or N/A

@jhaven-stytch
jhaven-stytch requested a review from a team as a code owner December 23, 2025 21:40
* remote options, and false otherwise
*/
public data class PasskeyCredentialOptions(
val preferImmediatelyAvailableCredentials: Boolean = false,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On iOS we name this boolean preferLocalCredentials, suggest we align both names since they cover the same functionality.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I slightly disagree, and think that our iOS SDK is in the wrong here.

preferImmediatelyAvailableCredentials is the actual name of the parameter for both iOS and Android; if someone is reading the documentation for either provider, and trying to implement our SDKs, I think it's better to expose the naming they will be familiar with, instead of hiding it behind a Stytch-specific flag

It would obviously be a larger change, but I would prefer to change the name in iOS (deprecate/rename) than change it here.

But I'm not deadset one way or the other ¯\_(ツ)_/¯

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In agreement! I primarily care about alignment here so the devx on both is the same; I have no opinion on the actual name of the flag.

I'm totally comfortable changing iOS if you think this name is more correct (note that would be a breaking change so we'll have to just be button'd up on the changelog).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chris-stytch on iOS, we actually don't pass bools for options like on Android, but instead, explicit ASAuthorizationController.RequestOptions types, and the preferLocalCredentials flag toggles setting the type. Aside from "hiding" the implementation detail that a developer might search for, this is also a little brittle if new RequestOptions are added in the future.

So, what I did on iOS is mark the .default(preferLocalCredentials: Bool) enum case as deprecated with a note to switch to .options([]), where a developer can pass the explicit options they want.

See: stytchauth/stytch-ios#588

@jhaven-stytch

Copy link
Copy Markdown
Contributor Author

Code Coverage

Overall Project 71.61% -0.07% 🍏
Files changed 28.57%

File Coverage
PasskeysImpl.kt 69.32% -2.56%
Passkeys.kt 33.33% -66.67%

@jhaven-stytch
jhaven-stytch merged commit e6cdaf9 into main Jan 5, 2026
4 checks passed
@jhaven-stytch
jhaven-stytch deleted the jordan/add-preferImmediatelyAvailableCredentials branch January 5, 2026 21:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants