They already had GCD and Operation provided by the platform, which worked perfectly with Swift, and dealt with concurrency very nicely.
They weren’t under any pressure at all to have any other ‘async’ story early on and so intentionally chose to focus on other fundamentals and take their time to build something that would be well designed and additive.
I argue that GCD, etc, don't actually work perfectly with Swift, though. Swift functions use a flavor of "checked errors" in the function signature via the `throws` keyword. When you're passing around callbacks or implementing Operation, there's no where to allow a `throws` function. Very similar problem to Java with checked exceptions and closures.
The early versions of Swift didn't even have a standard Result type, IIRC.
So even today, you will see some Swift functions that have `throws` in the signature and some that return `Result<T>`.
If you agree that it's not idiomatic (and maybe I can get you to agree that it's more than just non-idiomatic when it comes to async operations that can fail), then are you actually refuting my original comment: "It's weird for the official language of a mobile app ecosystem to not have a pretty strong async story pretty early on, IMO."?
Maybe it was the right call in the end (I'm of the opinion that it literally doesn't matter. Apple could ask us to develop in COBOL or even something as crazy as Objective-C and we'd all still do it), but I still think it's fair to say it was weird/surprising to have awkward/difficult async tools for an official mobile OS language.
Having developed shipping apps in swift 1.0, using GCD, it wasn’t any more awkward than using GCD with objective C, indeed generally it was easier because Swift is more concise.
I guess in relation to your original statement, I am refuting it.
They had a strong solution which was pretty easy to use, and as good as the language they were replacing, and well integrated with the platform.
The idea that they ‘didn’t have a strong solution’ doesn’t really hold from my point of view.
It was strong, and working which gave them the luxury of time to develop an idiomatic solution as the language matured.
If there really hadn’t been a strong solution in place, I would have agreed with you.
They weren’t under any pressure at all to have any other ‘async’ story early on and so intentionally chose to focus on other fundamentals and take their time to build something that would be well designed and additive.