Sorry, I'm not sure I follow. If the position were reversed, and the Switch natively supported Swift but you wanted to write a game in C++ and there weren't existing tools to do so, would you not be in a similar situation, asking "Do waste time I could be spending on the game making a C++ stack, or do I just use Swift?"
At the end of the day, certain support for a platform comes down to motivation whether a business interest, or personal interest:
Nintendo Switch software is largely written in C++ because Nintendo has used C++ for decades, and their tooling is focused around C++. When they were working on the Switch hardware, they could have opted to rewrite all of their tooling around a different language and gone with that, but it's hard to motivate such a change without sufficient benefit. If they want to, they certainly can support Swift as a first-class language, so you could write your game for the Switch just the same
Rust is ported to many platforms in large part because the types of folks who like Rust enough to port it tend to really like Rust and want to write it everywhere, even on the GBA. That's a non-trivial part of the community's identity, and the excitement some have for the language leads them to port it to various platforms. If someone were sufficiently excited about porting Swift to the GBA so they could write ROMs in Swift, they certainly could do it
If someone wanted to write a toolchain for Darwin platforms that produced more portable Darwin executables that statically linked in all libraries without ever touching the OS, they certainly could do it
None of these cases involve a technical limitation or hurdle that Swift needs to cross — it comes down to someone putting in the time and the effort to do it. You can't write Swift games for the Switch or the GBA because no one has had the motivation to put in the effort to make it possible, and you can't write OS-independent Darwin executables because Apple has no business interest to put in the effort to make it possible, and it seems other developers' needs have been sufficiently met by the current capabilities of Swift on Darwin platforms to subdue interest in building alternative options.
So to be clear about answering your original question of
it's not a limitation of the language — it's just the work hasn't been done yet to make it easy.
I don't disagree, it's just that unfortunately the amount of required excitement is currently very large. You can:
Create a new toolchain
Which is a somewhat excessive amount of work for what is just linking a different library and asking llvm to compile for a different target. If there's no dependencies, why, I would still like to compile my code even if a platform is not added in some switch statement.
If all I had to do was spend a month or so patching the stdlib and runtime for a new platform, that would actually be manageable, in contrast to implementing a new target in a large, sparsely documented C++ codebase and compiling a toolchain.
It requires someone who who likes Swift enough to make a one, and at the same time is good at C++.
It's not the same as with Rust, their compiler is self-hosted. For the most part you don't need to learn an unrelated language to work on something, you just need to be good at Rust.
I think this very much unnecessarily oversimplifies the amount of work needed to enable a new platform for any compiled language. As I participated in a port of the Swift toolchain and core libraries previously, I can say there's a large amount of steps you have to follow to make sure everything works. And Swift is not unique in this regard.
The fact that Rust is available for more platforms doesn't mean it was easy for them. Someone had to implement the ports and to keep them maintained, and that time could've been spent on other features. For example, Rust put no work into ABI stability at all, which makes it a "worse" language but from a different perspective. I'm sure there are more features at which Rust is "worse" than Swift, Objective-C interop is another one. It's natural that different languages and their maintainers have different priorities.
Making a compiler self-hosted requires a substantial amount of effort. In fact, it makes bootstrapping on a new platform harder, since instead of relying on an existing C++ compiler you need to cross-compile the compiler itself as a first stage, which may be not so trivial and increases build and iteration time significantly.
I previously had a work-in-progress port of Swift to Musl on Alpine Linux, and that only progressed to some degree precisely because I could build and test directly on the Alpine Linux host with a C++ compiler already available and working well there. If Swift were self-hosted I instead would need a custom cross-compilation setup specifically for a combination of my build platform and target platform. And that's only an example of a different flavor of Linux, not some embedded platform with a different CPU architecture.
Swift is also becoming increasingly self-hosted. You're very welcome to participate in developing new SwiftSyntax, Swift Driver, and SIL optimizer codebases all written in Swift if you think that would make ports to other platforms easier for you.
I did not suggest that it was easy, nor did I criticise Swift for not being self-hosted. I just said that if a language is, then it just takes being good at the language and some compiler knowledge to contribute. C++ is not the kind of language you can just start using based on experience with something else, like Swift. You need C++ experience specifically.
Porting everything to a new platform is difficult enough by itself, and C++ is not making it easier. It would be cool if I could define all the platform specific differences in a json file, without needing to change the actual compiler, something possible with Rust. (I am just talking about adding a platform as a target, not porting the compiler)
But, well, the original question was if it's possible to get a macOS toolchain. And the answer is no, there probably isn't any point to arguing over the difficulty of porting Swift to other platforms.
There's not that much more C++ you need to know for porting Swift to a new platform than you need for porting Rust. Most of platform support is implemented in LLVM, clang, and linkers, which Rust also relies on and those are all written in C++. I can say from my experience of maintaining a port that contributor's knowledge of the intricacies of the binary format, CPU architecture, and system programming in general is much more important than knowledge of C++.
Not all platform differences can be defined in a JSON file. If you're at a state where all nuances of a platform are already supported in the compiler and related tooling, modifying or adding a property in a JSON file is not much easier than modifying a switch statement. And at that point, modifying switch statements in C++ is not that different from modifying switch statements in Swift. But again, if enabling more platforms was that easy, it would've been done already.
As was already said by other posters in this thread, the answer is yes, it's possible. But this wasn't prioritized so far. And I personally don't know of contributors currently working on this and submitting PRs for review. If your point is that C++ is the main reason for that, you're very welcome to participate in areas that bring us closer to having a self-hosted compiler.
Yep, GitHub is notoriously slow to update their available OS versions, especially since macOS 13 will require them to update their underlying Mac hardware (largely 2013 Mac Pros). They don't expect the updated OS to be available until the second half of the year. Luckily their self hosted runners are pretty easy to run, if you have the hardware.
IMO, Swift vs C++ is basically irrelevant - even if the compiler was written entirely in Swift, porting to a new platform would still require very particular low-level technical expertise that few developers possess. You absolutely could learn it, but it would take patience, regardless of the language.
As for the Nintendo Switch - it certainly would be possible to port the Swift runtime to it. We don't need anything particularly unique, and given it can run a WebKit-based browser, I'm sure the OS will provide all the interfaces needed by the runtime.
As for Rust - the Rust Switch port is listed as Tier 3, which is the lowest tier they have. It only supports no_std development (which is really, really bare-bones). Looking at the repository, it seems like a hobby project from 2 individuals who made some tweaks to some linker scripts half a year ago and got something running.
It's cool that people do things like that, and I'm personally a big fan of the homebrew gaming community, but... like, I wouldn't make decisions about which language I should program my game in based on the existence of projects like that.
I do agree with everything
I don't think anyone understands what I meant.
Spending that much time with a language I don't like would be frustrating, not fun.
By "patching the stdlib and runtime" only I meant adding numbers, pointers, some basic types and an array, definitely not implementing anything close to the entire language complete with a new toolchain.
And as far as I can tell that's impossible because the compiler can only work with targets it fully supports.