It’s a device from the testing department, and it cannot be debugged. Currently, I’m exporting the logs by writing them to a file.The error occurs regardless of whether the group is correct or not. The same IPA file is installed on both this problematic device and the normally functioning devices.

Thanks for your reply.I'm not sure which ID I'm getting, but this issue only happens on a few individual devices. Could I add an AppIdentifierPrefix entry to info.plist with the value set to $(AppIdentifierPrefix), then retrieve the currently used group by calling [[NSBundle mainBundle] objectForInfoDictionaryKey:@"AppIdentifierPrefix"];? Since the keychain group prefix is formatted as ., I'm having trouble getting the correct TeamID.

Thank you for your explanation. I will pay attention to these details in the future.

Hello, I have already read SecItem: Pitfalls and Best Practices. If I do not set kSecAttrAccount right now, is it possible that I cannot read the keychain items correctly? In addition, if Keychain Sharing is enabled for the app, but I do not specify kSecAttrAccessGroup when saving keychain data, will the storage location be the same as when Keychain Sharing is disabled?My data stores a string of encrypted secret keys.

I am using the iOS platform. I would like to ask: when using kSecClassGenericPassword, is the kSecAttrAccount attribute required? I did not set kSecAttrAccount and kSecAttrAccessible when saving data on older iOS versions. Will this cause problems when querying Keychain items on iOS 26?

The user is not able to upload the diagnostic report for some reasons. Is there any way for me to work around this problem? How can I fix this value to one instead of having two values switching randomly? This situation is seriously affecting the user experience. At present, this client has reported this issue to us many times, but I still cannot get access to the user's mobile phone to troubleshoot it. I upload this value to the server as part of the registration data, and verify this value locally during authentication. From the user's registration database records, it can be seen that there are only two values for this user, and they keep switching constantly. Sometimes the switch happens once a month, and sometimes once a week. Could this possibly be caused by an API bug?

Could there be a caching situation for this value in the system? And what is the basis for generating this value?

The user previously upgraded to version 26.1, then downgraded to 18.6.2 for certain reasons, and has now upgraded back to 26.1. Currently, an issue has occurred once on version 26.1 where two values keep switching back and forth. Since we record this value on the server during user registration, we noticed that the user’s value has changed. Moreover, this value will not change randomly, and the user stated that they have not modified the facial recognition data of the device.

The click event of this button.

I add this " ShowsConfigurationUI ProvidesPasskeys "

crash report