> So it’s not ok to use « whitelist » or « blacklist » in your source code in xcode when coding in swift
Can you explain what you mean by this? This seems to suggest there's some kind of compiler error or warning in Xcode when using those terms, but I just tried it and there's no such thing. No one is preventing you from using those terms, as far as I can see — some people have chosen to stop using them, but they're not forcing their decision on you.
I have an example of Apple _forcing_ you to change terminology.
Apple decided to rename the function IOMasterPort() to IOMainPort() and marked IOMasterPort() as deprecated, for what would appear to be non-technical reasons. You can see that they did it hastily and poorly; e.g. in the documentation of most functions that take a port, the type definition has been renamed "mainPort" but the parameter is still labeled "masterPort" https://developer.apple.com/documentation/iokit/1514494-iose...
If you use IOMasterPort(), Apple nags you to use their new wording instead. If you follow their advice, your program immediately stops working on macOS < 12.0, those OSes don't have an _IOMainPort symbol. If you reject their advice, your program stops working on macOS 13.0, that OS doesn't have an _IOMasterPort symbol
Welcome to the wonderful world of software. You need to use the _exact_ version of the library. Any other version will make the program not compile or crash.
In this case, IOKit is an essential framework of macOS. You can't solve this by using a specific version of the library (or saying that your executable requires a specific version of the library). Apple's backwards compatibility is so bad, you require two versions of your program, one for pre-macOS 13, and one for post macOS 13, just because Apple are feckless
By comparison, Windows still has source-compatibility with their Win16 APIs https://duckduckgo.com/?q=site%3Alearn.microsoft.com+%22comp... so if you have an application from 1995, it will probably still compile. Microsoft wouldn't deprecate OS functions lightly, and they certainly wouldn't deprecate them simply so they could rename them. The Linuxes and BSDs similarly maintain backwards compatibility far better than Apple, even for functions they know to be irredeemably insecure like gets()
Can't you just add a compiler conditional to use one function if macOS < 12, and the other function on macOS >= 12? How is this different than any other API migration?
You can, and from that point on you have to build and maintain two binaries which only vary by which version of the OS they run on. Instead of just having one file to download, your users need to look at a system info panel to find out which OS they're running, and download the right version, because running the wrong one will print some cryptic error about being unable to resolve a _IOMainPort symbol
By comparison, there is no problem running a binary from Windows 95 on Windows 11, nor is it a problem to run old (static) Linux binaries on modern Linux
What's so awful about this is that Apple is forcing this API breakage for one reason only: to get the word "master" out of the name of one of their low-level API calls. Not a security issue. Not a performance issue. Not a maintenance issue. With this breaking change, Apple virtue-signals about how _little_ it cares about backward compatibility
Can you explain what you mean by this? This seems to suggest there's some kind of compiler error or warning in Xcode when using those terms, but I just tried it and there's no such thing. No one is preventing you from using those terms, as far as I can see — some people have chosen to stop using them, but they're not forcing their decision on you.