I had a need to store a localised string in a shared file used by other applications, and noticed that LocalizedStringResource conforms to Codable -- and indeed, if I encode a string from App A, then switch to App B, B is able to read the value and load different localisations of that string out of App A's bundle. Very cool.
This isn't clearly documented (the documentation for LocalizedStringResource just mentions cross-process use, not generally longer-term storage), so I wondered if there are any caveats to be aware of when using this approach?
I am aware that LocalizedStringResource is just a reference, so obviously if App A is deleted, it becomes a kind of dangling reference and will presumably fall back to its default value (which is included in the encoded representation).
But I also noticed that the encoded LSR includes a sandbox extension token. Is there anything in particular to be aware of with that? Is it time-limited?
One thing I did notice, that is quite annoying (potentially a bug) is that if I serialise and deserialise a record containing a LSR, it no longer compares as == to its previous self. That is because the original LSR did not contain a sandbox extension token, but as part of encoding it, that field seems to get populated. I'm not sure if there is a good workaround there; perhaps the extension token could be ignored from ==?
That would result in extension tokens being dropped (e.g. if you had two LSRs in a Dictionary, differing only by the sandbox token, they would still be considered substitutable and already "in" the dictionary), but perhaps that's fine.
Yes, LocalizedStringResource conforms to Codable so that it can be serialized when sending it between two processes. The serialized representation effectively contains a path to the bundle and some extra information to ensure you can read from that bundle. The serialized representation isn't suitable for sending between devices (the path to the bundle may be different) or storing on-disk long term (the path may no longer exist or may have been moved) - it's really designed for sending between two running processes on the same system. If you do deserialize a LocalizedStringResource that is no longer "valid" then it will just fallback to the default value (same behavior as if the key or table didn't exist in the provided bundle without serialization). No need to worry about the specifics of the token you mentioned, LocalizedStringResource handles this gracefully. Please feel free to file a feedback (and share the number here) if you think there's any wording that we could add to the documentation to help improve this and make it clearer.
As for the == issue that you mention, that does sound like a potential bug. Could you file a feedback about that with an attached sample project if possible, or share more about the LocalizedStringResource you're serializing? The sandbox extension should not impact == comparison.
I suspect that the issue might arise from some eager formatting that can happen at serialization time. If your LocalizedStringResource contains any more "custom" arguments that can't be serialized (for example, something formatted with your own FormatStyle, an interpolated argument that is your own NSObject type, etc.) those may be eagerly formatted at serialization time since Foundation is not able to safely serialize them. In those cases (while less common but possible) the LocalizedStringResource may not compare equal since they would behave slightly differently.
