This doesn't even work in Objective-C. There are a number of reasons NSLocalizedString could return a string that is pointer-equal to key even though it got it out of the NSBundle, the most likely being tagged pointer strings.
But stepping back, what are you going to do with the answer? If it's to track down strings that are missing localizations, there is the built-in NSShowNonLocalizedStrings default you can use instead. Or is it something else?
The behavior isn't contractual; even if NSLocalizedString is returning distinct objects today, it could stop doing so in iOS 20 or whatever. So you shouldn't rely on it.
Not sure, but that's more of an Apple frameworks question than a Swift question. I think your best bet really is what @Cyberbeni already said, though: if you pass an empty string as the fallback value, or something like "MISSING LOCALIZATION", you can check against it by value. (It may also be worth filing a bug against Apple to add a variation of the API that returns an Optional instead.)
i have this feeling that by iOS 20 time either i could be dead, or objective-c could be dead, or NSLocalizedString could be dead. if neither of the latter two things happens - apple should probably keep the current (unwritten) behaviour to not break too many existing (by the time) apps.
actually thanks! this comment somehow triggered my mind and finally brought me to what i wanted. here you are, a fully robust swift native way to check localized string absence:
let s1 = NSLocalizedString("key", value: "value1", comment: "")
let s2 = NSLocalizedString("key", value: "value2", comment: "")
let isStringMissing = s1 != s2