Swift is a relatively young language (ten years) and ~3 years ago a lot of things were brand new or had relatively recently been refactored. Also Apple released it to the public before it was really finished - and did the final work finishing off the language out in the open with collaboration as any well run open source project should be developed.

For the first five years or so it was barely ready for production use in my opinion, and it sounds like tried to use it when it was ready but still had a bit of rough edges such as docuemntation.

For example async/await was added around when you looked into it and that obviously made a lot of documentation relating to threads out of date (from memory they pretty much deleted all of it and started the long process of rewriting it, beginning with very basic docs to get broad coverage before having detailed coverage).

And before that the unicode integration wasn’t quite right yet — they did the tough work to make this work (most of these characters are multiple bytes long):

let greeting = "Hello, 🌍! こんにちは! 🇮🇳"

for character in greeting {
    print(character)
}

And this evaluates to true even though the raw data of the two strings are totally different:

let eAcute: Character = "\u{E9}" // é
let combinedEAcute: Character = "\u{65}\u{301}" // e followed by  ́

if eAcute == combinedEAcute {
    print("Both characters are considered equal.")
}

I hated how strings were handled in the original Swift, but it’s great now. Really hard to write documentation when fundamentals like that are changing. These days though, swift is very stable and all the recent changes have been new features that don’t affect existing code (or already written documentation). For example in 2023 they added Macros - essentially an inline function (your function won’t be compiled as an actual function - the macro code will be embedded in place where it’s “called”).

You define a Macro like this:

macro func assertNotNil(_ value: Any?, message: String) {
    if value == nil {
        print("Assertion failed: \(message)")
    }
}

And then if you write this code:

assertNotNil(optionalValue, message: "optionalValue should not be nil")

… it will compile as this:

if optionalValue == nil {
    print("Assertion failed: optionalValue should not be nil")
}

Notice it doesn’t even do any string interpolation at runtime. All of that happens at compile time! Cool stuff although it’s definitely a tool you can shoot yourself in the foot with.

is [Swift] using fibers instead of real OS threads(?)

There are similarities to fibres, I’d say they’re solving the same problem, but they’re not really the same thing.

It uses libdispatch which is built on top of “real OS threads” though on some kernels (especially BSD ones) it takes advantage of non-POSIX standard OS threading features (it can run without them, but runs better with them).

Essentially you give the dispatcher a set of tasks, and the dispatcher will execute those tasks on as many threads as makes sense for the available hardware (this is where kernel integration helps, because the number of available CPU cores depends on the current workload for all processes, not just your process, and it changes from one millisecond to the next). The general goal is to keep every CPU core fully loaded, unless QoS has been set low which would prioritise battery life (and might, for example, use “efficiency cores” or avoid “turbo boost”).

What are these things/what is this comparing?

It’s a simple variable assignment, such as person.name = "bob", where the compiler has recognised the value might be accessed concurrently from multiple threads and may need to pause execution for a task that is waiting for the lock to be released. But of course, since the goal is to keep the CPU core active, it doesn’t just pause the code running on that core - it’s likely to start executing something else on the same core while waiting.

OperationQueue and DispatchQueue are basically the same, but OperationQueue has additional scheduling / dependency features which come with a slight performance overhead. If your execution tasks are slow and have minimal interaction with other threads, such as resizing half a million images, then you wouldn’t notice the performance overhead. But if you have very short operations that interact with each other (or if you just don’t need any of those management features) then DispatchQueue is the way to go.

They’re largely the same in basic use:

dispatchQueue.async {
   // your code here
}

operationQueue.addOperation {
 // your code here
}

Swift on the server is a new thing that seems to be gaining traction