For example, for kSecAttrAccessible, the Apple developer documentation states: "Choose the most restrictive option that meets your app’s needs so that the system can protect that item to the greatest extent possible." It doesn't seem that Tink can do this.
It also sets kSecAttrSynchronizable to false, which for some users also might not be what they want.
Another point is that it sets kSecClass to kSecClassGenericPassword, which intuitively feels wrong (though I can imagine that there is a very good reason for this).
In general, I feel it might be better if the user sets these attributes.
Tink ObjC has integration with the iOS keychain in https://github.com/tink-crypto/tink-objc/blob/main/Tink/core/TINKKeysetHandle.
However, when adding a keyset to the keychain, the attributes are set by Tink (e.g. https://github.com/tink-crypto/tink-objc/blob/main/Tink/core/TINKKeysetHandle.mm#L288-L296). In general, I don't find it clear that Tink choosing these attributes for the user is the correct choice.
For example, for kSecAttrAccessible, the Apple developer documentation states: "Choose the most restrictive option that meets your app’s needs so that the system can protect that item to the greatest extent possible." It doesn't seem that Tink can do this.
It also sets kSecAttrSynchronizable to false, which for some users also might not be what they want.
Another point is that it sets kSecClass to kSecClassGenericPassword, which intuitively feels wrong (though I can imagine that there is a very good reason for this).
In general, I feel it might be better if the user sets these attributes.