That category is about a tool that formats Swift source files by applying standard indentation and line breaks. Your question rightly belongs here in “Using Swift”.
Those are an ancient holdover from C, which you don’t want to touch unless something forces you to. Just use direct string interpolation:
let rtlIsolate = "\u{2067}"
let ltrIsolate = "\u{2066}"
let firstStrongIsolate = "\u{2068}"
let popDirectionalIsolate = "\u{2069}"
let arabic = "السيارة"
let sentence
= "“the car” is “\(rtlIsolate)\(arabic)\(popDirectionalIsolate)” in Arabic."
I chose the RTL isolate because it was known to be Arabic, and in that case explicitly using RTL will force even a string with no directionally strong characters like ...! to properly appear as “!...”.
If you don’t know what is being interpolated, you can use the “first strong isolate”, so that the rendering engine will pick the direction based on the first character with unambiguous direction in whatever string it is given. It won’t be able to tell what to do with strings like “...!”, but it will still get 99% of strings right, and the origin of the interpolated string can correct it by wrapping the string with directional specifiers before passing it to you.
These methods are just forwarding to C. I assume so, but I don’t now any more that what the documentation says.
The system default has nothing to do with Swift. I am pretty sure this is referring to what you get when you run locale in a terminal. If so, then it is entirely configurable by the user. And since they are controlled by the environment, they can also be modified at will by other pieces of the program.
You never have to specify an encoding when interpolating Swift strings. All Swift strings are in Unicode. Encoding only matters when converting to and from binary data, such as when loading a file.
Ultimately it means the system attempts to choose the right special characters above for you. But frankly it isn’t something you should ever trust a machine to do.
Swift strings are just a sequence of characters in memory, and always uses logical order. Whatever rendering engine you use to display the string—such as SwiftUI or AppKit—may or may not support bidirectional text. But none of them are part of the open source Swift project, so you would have to go ask at their particular sites. (Though I assume they would all answer “yes” in 2020.)
It looks like UTF‐8 (from the Swift string) was reinterpreted as though it were Latin‐1 (the system encoding). Again, that won’t happen if you stick to the Swift APIs and stay away from the ones intended only for interoperating with C.
You really don’t want to do such things anyway: