square / Valet

Valet lets you securely store data in the iOS, tvOS, or macOS Keychain without knowing a thing about how the Keychain works. It’s easy. We promise.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

(Some folks) await async support

pwesten opened this issue Β· comments

πŸ‘‹πŸ»πŸ˜πŸ™πŸ»

Additional context: Apple documentation explicitly says:

SecItemUpdate blocks the calling thread, so it can cause your app’s UI to hang if called from the main thread. Instead, call SecItemUpdate from a background dispatch queue or async function.

and now that we have async/await functionality, it feels like a great time/opportunity to make this properly asynchronous.

We should absolutely mark Valet objects as @unchecked Sendable since they are already thread-safe.

We could also make a breaking change to make Valet objects actors rather than final classes: that would be the correct model for a type that is both thread-safe and shouldn't operate on the main queue. However, enabling values to be read synchronously is valuable to consumers: even though doing keychain operations on main queue is not a good practice, I wouldn't want to prevent a consumer from being able to read keychain values from main if they so desire. My 2c is that the most flexible way forward is to conform to @unchecked Sendable and let consumers write their own actor wrapper around Valet to ensure that they don't synchronously read from keychain on the main queue.

Longer-term, in our next breaking API change (which we're overdue for – we're still supporting Xcode 11), it may make sense to:

  1. Remove the locks within Valet types and remove @unchecked Sendable, effectively making Valet types unsafe for use across multiple threads.
  2. Expose Valet initializers to consumers and remove the static methods that always return the same instance of a Valet object.
  3. Create ValetActor (would love a better name here) types that are of type actor and wrap the final class Valet types.

This approach would create consumer flexibility, remove our use of locks (which I'm honestly not sure we need today – I never read the open-source Security framework's SecItem calls to determine if they were already thread-safe), and create async APIs for folk who are optimizing for main queue performance.

Open to suggestions here. I'm also open to re-assigning ownership of this task – I haven't worked for Square since 2016 and am trying to focus my open source time on projects hosted on my own page.