Extending AppStorage to support other types (Namely Codable)

[brzzdev]

I just created a PR and didn't realise @rafalwojcik had already created one which exposes less of the internals and is all around simpler 👍🏻.

I do see your arguments for keeping parity with the constraints of @AppStorage, but I also think there's a huge need for allowing us some sort of custom override.

Why:

- Legacy usecases
Many of us already have dozens of Codable values in UserDefaults across multiple targets and apps. We could migrate them over to fileStorage, but this is quite time-consuming, prone to errors and lost data, and…

- File storage privacy
Obviously, neither are secure, and you can view both the UserDefaults .plist and the files stored by fileStorage, but UserDefaults is a single file where Data fields are a hex that has to be decoded. fileStorage creates a file for each object that plainly shows the object. I would argue that UserDefaults provides a little more security through obscurity out of the box.

- Standard practice
If you look on GitHub at any other popular library that writes to UserDefaults, I struggle to find one that doesn't offer Codable support. Foil is the only one I could find that warned against it, but even that supports it out of the box.

I think a solution like @rafalwojcik's that makes AppStorageKey flexible enough for everyone's needs, while still allowing you guys to caution against it and recommend fileStorage for Codable objects going forward, is a win-win.

[stephencelis]

Hi @brzzdev,

Thanks for starting a discussion.

I think it's important to reiterate that the library supports defining custom keys outside the core library. So you are free to create a custom CodableAppStorageKey key for this use case, and you could even package it up for folks to use. You might even be able to leverage AppStorageKey<Data> under the hood if you're worried about maintaining that functionality all over again.

I think the core library, though, should probably remain the way it is to discourage storing codable values in user defaults, as Apple does by convention, and as Foil does by documentation. The library doesn't prevent you from achieving the functionality you're asking for, it just doesn't come with that functionality baked into it.

- File storage privacy Obviously, neither are secure, and you can view both the UserDefaults .plist and the files stored by fileStorage, but UserDefaults is a single file where Data fields are a hex that has to be decoded. fileStorage creates a file for each object that plainly shows the object. I would argue that UserDefaults provides a little more security through obscurity out of the box.

I'm not sure I get this argument. Can you explain what could go wrong here?

[myihsan]

The .appStorage static is public and I think that's all you need to define a wrapper.

I have successfully defined a wrapper key.
However, it breaks after updating to 2.* since LoadContinuation.init is package.
As a workaround, I am thinking of defining a wrapper for the value and conforming to RawRepresentable.

Am I missing something?

[kgrigsby59]

I've run into the same problem.

[dadalar]

Same here

[stephencelis]

As of 2.1.1 and #81, you can initialize the continuation types to support this functionality.

[pyrtsa]

Wow this was timely, was working on the same problem and just about to ask why not turn the initialisers public the very minute you published 2.1.1. 🎉