@Shared Keychain / swift-composable-architecture-keychain

[MonkeyBizScott]

I have been exploring the @Shared functionality in the Beta, specifically the persistence strategies. I think it would be useful to include the Keychain as one of TCA's supported persistence strategies. Personally, I use a library called KeychainSwift to interact with the Keychain. It greatly simplifies the process of using the Keychain. As previously discussed with @stephencelis, we could create a new package like swift-shared-keychain or swift-composable-architecture-keychain. I would love to help bring this persistence strategy to TCA.

[ph1ps]

One problem I see, is that there is no way to observe the Keychain like you can do with AppStorage/UserDefaults and files. So if the community will implement this, it has to come with the downside of not always up to date state (except if some polling mechanism is implemented, which I am not sure is a good idea)😕.

Also I cannot think of a good way, how to specify all of the attributes at the initialization point. Maybe we can collect some ideas here.

And one more thing, https://developer.apple.com/documentation/security/1401659-secitemadd#4098451 mentions some performance considerations, like dispatching the SecItemAdd on a non-main queue. This means it would probably make sense to implement a debouncing behavior similar to files.

[StuSharpe]

Regards keychain attributes, could we not just make these part of the param list for the persistence strategy? eg:

extension PersistenceKey {
  public static func keychain<Value>(_ key: String,  
                                     accessGroup: String,
                                     serviceName: String,
                                     accessType: KeychainItemAccessibility) -> Self
  where Self == KeychainPersistenceKey<Value> {
      KeychainPersistenceKey(key, accessGroup: accessGroup, serviceName: serviceName, accessType: accessType)
  }
}

public struct KeychainPersistenceKey<Value>: PersistenceKey, Hashable, Equatable {
    public init(_ key: String,
                accessGroup: String,
                serviceName: String,
                accessType: KeychainItemAccessibility) {
         // TODO
    }
   
    public func load(initialValue: Value?) -> Value? {
        //TODO
    }
    public func save(_ value: Value) {
        //TODO
    }
}

You could then declare your own set of params in a single key like so:

extension PersistenceKey {
    public static func myAppKeychain<Value>(_ key: String) -> Self
    where Self == KeychainPersistenceKey<Value> {
        keychain(key, accessGroup: "MyApp", serviceName: "MyAppService", accessType: .whenUnlocked)
    }
}

@Reducer
struct ChildFeature {
  @ObservableState
  struct State {
      @Shared(.myAppKeychain("password")) var password: String? = nil
  }
}

[ph1ps]

@StuSharpe Good idea! To cover all edge cases for users I'd probably even create a struct to house all the attributes in (https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute_keys_and_values).

[ph1ps]

And I guess the most obvious consideration would be, which data would you allow to be added with the wrapper.

Only allow Data itself or like some other wrappers maybe String as well?

[StuSharpe]

It should probably work much like the UserDefaults persistence, in that it should handle all regular data types for maximum convenience, eg:

@Shared(.myAppKeychain("password")) var password: String? = nil
@Shared(.myAppKeychain("superSecretLocalHashKey")) var hashKey: Data? = nil
@Shared(.myAppKeychain("launchCount")) var launchCount: Int = 0
@Shared(.myAppKeychain("accountCreationDate")) var accountCreationDate: Date? = nil

Thats what most of the existing Keychain wrapper libs do I think.

[ph1ps]

Does it support Date, Int and so on? I thought it just takes Data. Could you point me to a documentation, where this is mentioned?

[StuSharpe]

No, I don't think the iOS keychain calls support different types (from memory). But the type-conversion stuff would just be additional processing that the persistence strategy could do.

Could get away with just Strings and Data to begin with I think.

[StuSharpe]

Hmm, now that I think about it. Supporting different types may be a bad idea because SharedSate persistence strategies don't have an error-reporting mechanism.

There would be too much potential to (say) save something as String, then attempt to read it later as an Int - this would silently fail. Might be better to keep it the wrapper as thin as possible for now.