Started updating @jeremy-prater’s work, here:
Ultimately we need to move to use the standard build script, cross-compiling stdlib and Foundation(s) with CMake is hairy. It took me about three days to get to the point where swift-hello-world would build (granted, I am completely new to Yocto).
Being one of the creators of OpenEmbedded, I can feel your pain 
– It's kind of ridiculous that after decades of autotools and friends, we (as a profession) are still struggling with cross compilation.
Ah, interesting! The other issue I ran into is the philosophical conflict between packages at the system and the language level, I suppose something Swift shares with Go and Rust. Yocto doesn't allow network access in the compile task, so I needed to a new swift_package_resolve task that runs between do_unpack and do_patch and give it access to both the network and SSH_AUTH_SOCK (as the environment is scrubbed). This also provides the opportunity to resolve submodules within the package dependencies themselves.
You are a true chad! I've heard and experienced that Yocto recipes can be painful to deal with, with not enough good documentation and examples to learn how to use it effectively...
But yeah, this is great work. I am excited for these things, because at my company we use Yocto for our custom armv7 board and being able to use something like meta-swift instead of custom build scripts would be fantastic!
I only knew of Yocto on Monday, and now on Friday I have an embedded Linux distribution with a bunch of Swift daemons (all nicely integrated with systemd, thank you!). Now, I'm still yet to test on real hardware, and the next step of integrating Flutter will probably be as painful as Swift, but it's nonetheless quite impressive.
PS. Yocto isn't as weird as one might think from reading comparisons with Buildroot. The oddest thing is BitBake, the recipe definition language, which is a curious mix of Python, shell script, and its own thing.