For an existing iOS generic-password Keychain item, what documented public API or query contract can establish that its returned SecAccessControl has no additional authentication, application-password, or operation-specific constraints? The item must remain WhenUnlockedThisDeviceOnly, in an exact access group and identity, and non-synchronizing. An unknown or unverified item must be refused without modifying, deleting, or replacing it.
An attribute-only creation with no explicit access-control object can return a SecAccessControl when data and attributes are read. We observed this on an iOS 26.5 Simulator. The returned object compared different from a freshly created zero-flags object. We are not treating either that comparison or a successful no-UI read as proof of its complete constraints.
The public interface we reviewed exposes creation and type identification; constraint inspection and serialization appear in private headers. Evaluating one operation also does not describe the item's complete policy. Is there a supported discriminator we have missed? If not, is there a documented creation-provenance and persistent-item-identity contract that establishes this property across relaunch, and what limitations apply to existing or recreated items?
Please clarify the supported contract rather than private implementation details. We need to preserve refusal of unverified existing items while using the public Keychain APIs correctly.
There’s no supported way to read the kSecAttrAccessControl property. Even if you could get back at SecAccessControl object — and I’m not sure that’s true — it has no getters.
I’m pretty sure I cover that in SecItem: Pitfalls and Best Practices… oh… well… kinda. Check out the Add-only Attributes section.
Given that, there’s really only one useful thing you can do with kSecAttrAccessControl, namely, configure it when creating an item using SecItemAdd. For most folks that’s sufficient, because they know how they created the item because… well… they created it. The only time this breaks down is when you have multiple versions of your app and they use different access control settings. In that case I think your best option would be to use some other attribute, like kSecAttrService, to ‘version control’ your use of this property.
You should feel free to file an enhancement request for better APIs for this. And if you do, please post your bug number, just for the record.
We observed this on an iOS 26.5 Simulator.
You can’t do meaningful work with SecAccessControl on the simulator. A real device is the only relevant test here.
constraint inspection and serialization appear in private headers.
I presume you found those in the Darwin open source. I want to be clear that things you find in Darwin are implementation details, not supported APIs. I mean, you know that already (-: but I just wanna be clear about that for anyone else reading this thread.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"