[Public Beta] Valet 4 wishlist

[dfed]

I'll be using this issue to track what we'll want to do in our next major version.

• Allow for customizing kSecAttrService on Mac: Allow kSecAttrService to be a customer-friendly string on Mac #140
• Remove Xcode 9 Support: [Valet 4.0] Drop support for Xcode 9, Xcode 10, Swift 4.0, and Swift 4.2 #190
• Dropping Xcode 10 support: [Valet 4.0] Drop support for Xcode 9, Xcode 10, Swift 4.0, and Swift 4.2 #190
• Drop Swift 4 support: [Valet 4.0] Adopt Swift 5 syntax, and enable support for SinglePromptSecureEnclaveValet on tvOS #191
• Consider renaming SecureEnclaveValet per @gravisman – non-biometric keychain items are also stored in the Secure Enclave under the hood. Proposed name: UserPresenceValet This item is being removed, since the current naming aligns with Apple's documentation.
• Bring SinglePromptSecureEnclaveValet to the tvOS target (LocalAuthentication was enabled in tvOS 10): [Valet 4.0] Adopt Swift 5 syntax, and enable support for SinglePromptSecureEnclaveValet on tvOS #191
• Get rid of Accessibility's always and alwaysThisDeviceOnly, since these values have been deprecated: [Valet 4.0] Remove .always accessibility specifier #197
• Move away from @discardableResult and towards a throws API. We're already letting folk ignore errors. Let's enable that in a more idiomatic way: [Valet 4.0] Convert APIs to throw rather than return booleans or enums #198
• Support keychain sharing via App Groups in addition to keychain access groups. Support sharing keychain items using App Groups #230
• Update README to include migration steps required to update to Valet 4: [Valet 4.0] Update migration guide #221

If you want us to include more action items in this list, please file an issue for the change you'd like, and link that issue to this one.

[piersebdon]

The above are all great suggestions but @dfed are you going to still be involved in maintaining Valet?
It seems that you have joined Airbnb now and being the major contributor to Valet, would be great to know how Valet will be maintained going forward?

[dfed]

@Piers12, I left Square a few years ago at this point, but I absolutely have been and intend to continue staying involved + helping improve Valet. I'm glad the above list is exciting to you! If there's something in particular you'd like from Valet, please file an issue 🙂

[piersebdon]

@dfed that's great to hear. I was deciding on wether to use a third party for using keychain in my iOS app and if so which one. The Swifty response from yourself means I think I'll push ahead with using Valet for my own project. Will let you know if there is anything that I would like Valet to add.
Keep up the great work!

[dfed]

I've created develop--4.0. Branched off of bb7745c. Time to get cracking.

[dfed]

We should consider getting rid of Accessibility's always and alwaysThisDeviceOnly in this breaking change, since these values have been deprecated.

Edit: this is addressed with #197. Added to the root list above.

[dfed]

Another idea: we could move away from @discardableResult and towards a throws API. We're already letting folk ignore errors. Let's consider doing it in a more idiomatic way.

Edit: this is addressed with #198. Added to the root list above.

[dfed]

We'll also need to add a section to our README to discuss how to update to Valet 4, since there will be a few breaking changes.

Things to include in the README update:

• How to migrate keys written using an always or alwaysThisDeviceOnly accessible Valet.
• How to migrate Objective-C code from 3 to 4 (API changes)
• How to migrate Swift code from 3 to 4 (API changes)
• New version numbers in the "Installation" section
• How to explicitly include the App ID prefix for the shared access group identifier
• tbd

[dfed]

We may want to stop automagically grabbing the sharedAccessGroupPrefix from the keychain in Valet 4.0. We're going to start supporting the significantly more modern App Groups keychain API, which lessens the benefit of being able to programmatically identify the sharedAccessGroupPrefix.

What makes sharedAccessGroupPrefix-derivation difficult to continue maintaining is that we are no longer utilizing the deprecated always accessible API. The complexity can be seen in #197; specifically, deriving the shared access group prefix requires generating a keychainQuery to be a failable operation. Would be great to jettison this logic.

Update: Doing this in #218

[dfed]

Valet 4 is now in beta! There is no more expected development on the develop--4.0 branch. If you feel like being on the bleeding edge, please update and let us know in this issue how the new API is treating you! The latest sha is tagged with the git tag 4.0.0-rc1.

Note that Airbnb has already released with the develop--4.0 branch with no issue.