Lockbox.m : Updated to use the newer iOS 15 NSKeyedArchiver calls

[apple-ihack-geek]

This quiets the deprecation warning when targeting iOS 15 or later.

[apple-ihack-geek]

this should address #66

[granoff]

So it turns out that using [NSObject class] is not a great idea. Xcode surfaces the following runtime issue while running the tests in the sample project:

*** -[NSKeyedUnarchiver validateAllowedClass:forKey:]: NSSecureCoding allowed classes list contains [NSObject class], which bypasses security by allowing any Objective-C class to be implicitly decoded. Consider reducing the scope of allowed classes during decoding by listing only the classes you expect to decode, or a more specific base class than NSObject. This will become an error in the future. Allowed class list: {(
    "'NSObject' (0x7ff84324e1d0) [/Library/Developer/CoreSimulator/Volumes/iOS_22A3351/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib]"
)}

So basically, this circumvents secure coding best practices.

I need to think about whether accepting this pull request is a good idea with respect to the intended best practices of the newer APIs. You might consider a newer alternative library, Strongbox. It's a Swift implementation of Lockbox that relies on NSSecureCoding protocol conformance to ensure the new APIs can be used.

[apple-ihack-geek]

So using NSObject here is the equivalent of using the old [unarchiver decodeObjectForKey:key]; on old line 215 new line 223 that master branch is using at least form a security perspective. I suspect Apple, when they do disable their functionality, will do so at the same time. Personally I think this is better, because now the developer will get both a compile time and runtime warning that they need to upgrade, where as before it was only a compile time warning. If you want, we can make our compile time deprecation warning a little stronger.
But ultimately the decision is up to you.