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.