Apple is open sourcing Swift Build

Is Swift actually serious about embedded?

Of course! Tons of examples here: https://github.com/apple/swift-embedded-examples

At WWDC24, we shared a session on embedded Swift, which is available on YouTube: https://www.youtube.com/watch?v=LqxbsADqDI4

More documentation on embedded Swift tooling here: https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSw...

(Disclosure: I work at Apple.)

Yes, there was an entire WWDC ‘24 talk about it…

https://developer.apple.com/videos/play/wwdc2024/10197

Swift is a great language, but it is unfortunately still held back by the stigma of being perceived as only usable on Apple platforms.

And until packages are actually shipped for all mainstream distros, the stigma is completely accurate.

No, neither "just install a tarball" nor "just install this docker image" count.

Working on it: https://github.com/swiftlang/swiftly?tab=readme-ov-file

Although opinions inside Apple about Swift vary, they seem to be investing in low level Swift for embedded, kernel use, and programming the “Secure Enclave” subsystem.

They certainly have many opportunities to use it for headphones, AirTag, flash driver, etc, beyond the very believable but less embedded use in kernel/Secure Enclave.

See also the wwdc session where they propose swift for building smart home thingies https://youtu.be/LqxbsADqDI4?si=KTYWPLdjGgTwK1UB

Distro packaging for programming language ecosystems is so often hopelessly out of date. I’ve never used a distro toolchain or packages to build production software for any language Python’s age or younger.

Outside of C/C++/Fortran pretty much every project I see on Github prefers things like Rustup or Nix for toolchains to navigate around Debian/Ubuntu/RHEL’s “stability” approach.

I remember when all Linux projects used to be install a source tarball and do the configure, make config, make, make install dance.

That hasn't prevented Linux to take over most UNIX workloads.

Bringing synopsis here for those who may not click:

swiftly is a CLI tool for installing, managing, and switching between Swift toolchains, written in Swift. swiftly itself is designed to be extremely easy to install and get running, and its command interface is intended to be flexible while also being simple to use. The overall experience is inspired by and meant to feel reminiscent of the Rust toolchain manager rustup.

Wow! I’m really surprised by the ESP32 work here [1]. This looks super interesting! And, personally, unexpected.

This is the kind of thing that makes you want to quit your job and just tinker all day again.

[1] https://github.com/apple/swift-embedded-examples/blob/main/e...

Swift is unbelievably cool but I wonder about using Swift for an embedded project as opposed to just C or with FreeRTOS for a more capable system. Is interoperability possible - as in FreeRTOS+swift?

I disagree vehemently. For any active language, distro packages should be at most 3 years old.

And for any language that's stable enough to be worth using, "3 years old" is good enough.

Yes, one use case is to eventually replace the Safe C dialect Apple uses for iBoot firmware.

Or containers. The Swift project is pretty good about keeping their Docker images up to date.

Why should it not, one of the design goals of Swift as C, Objective-C and C++ replacement was painless interop with those languages.

Thus it is more an issue of Swift embedded toolchain being able to be used alongside FreeRTOS on the specific hardware target.

For the most part, yes, it should be very achievable. Embedded Swift basically just produces an object file that looks like any object file from a C compiler. The objects mostly rely on very basic primitives like malloc/memcpy so it's pretty freestanding (you can turn off allocations, too). It also has very good support for importing C headers into Swift code so you can interop easily.

Probably the biggest roadbump for something like FreeRTOS is the asynchronous support though. Embedded Swift's async support is still extremely rudimentary and I didn't find much about how to extend it/attach it to other control loops. I think it only supports single-threaded execution right now as well.

Python, Java, C#, JavaScript, Go, Ruby all improve so substantially in 3 years time, I can’t square the advantages of using a distro package for any of them versus using at least the latest LTS from upstream. What is so great about the distro package versus upstream, that it is worth being 2-3 years behind?

Mostly I hear “stability”, but I have encountered far more frustrations dealing with 3 year old software as a developer, than I ever have dealing with 6 month old software. If I have good test coverage, a way to deterministically reproduce my build environment, reliable CI, and a way to release packages and bugfixes to my users quickly, it seems the risk & blast radius of a 6 month old toolchain is quite limited.

Python is by some measures the most popular programming language, its first release was in 1991, and over the last 3 years performance improved significantly, see https://lost.co.nz/articles/sixteen-years-of-python-performa...

I imagine the only case I want an ancient toolchain is if I’m building libraries or software predominantly consumed by Debian stable or RHEL users / system package ecosystem, or I am doing some kind of high-assurance thing involving formal verification where I’m probably using a non-distro verified toolchain instead. I’ve never been too interested in either of those domains though.

Thanks for that link to the examples repo. I had just started looking into embedded Swift for an rp2350 project a couple days ago, but (being a novice in embedded hardware/microcontrollers) I got the impression from the Swift website that the device wasn't supported yet and I'd need an rp2040 instead. It looks like there's an example project for the rp2350 in that repo though, so I'm going to be playing with this tonight!

If you look at the blinking LED sample, it's pulling in the freertos header:

  #include "freertos/FreeRTOS.h"

So presumably yes?

Go has been shipping for more than a decade as a .tgz and does not have this stigma at all ...

Anyway, you probably missed the following

https://www.swift.org/install/linux/

I see packages for all major distros there.

But people will probably mention some distro not listed and say the mainstream distro support is a farce. For some reason people have set the bar for Swift incredibly unrealistically high and there will always be something wrong it.

Your loss though. Swift is amazing. Both on MacOS and Linux.

Hi Tim. I liked your work with dart/flutter. Are you guys working on overhauling Xcode? The DX is atrocious.

Encountering an Apple employee in the wild is like spotting a unicorn.

Apple probably has use cases for this and they’re bringing it into the open as a nice marketing thing. I wouldn’t count on long term support or compatibility beyond current priorities for Apple (same as their other SDKs for iOS, macOS etc).

Both GCC and Clang have shipped support for major updates to C and C++ within the last 3 years. If C and C++ aren't stable enough, what is?

Tim is a unicorn.

> Why should it not, one of the design goals of Swift as C, Objective-C and C++ replacement was painless interop with those languages.

This is actually a very good quality. I'm exploiting that for all it's worth in a job project where I'm gradually (file by file) converting a legacy codebase from Objective-C to Swift.

Providing an exit-strategy for Objective-C is good enough reason for me to at least have a basic working knowledge of the language.

Did something happen with Xcode? I used it around 5 years ago, and it was pretty good and fast. I don't think it had dark mode but that's not too important to me.

Agreed. It's not like they didn't have enough time to fix it either. And they seem semi-capable of creating usable UI's elsewhere.

The thing is, when it comes to applications, both Apple and Microsoft compete with their own customers; which makes a pretty solid motivation for providing shitty developer experiences.

Encountering an Apple employee on HN is like finding a Papa John's employee in the food court.

Xcode is fine as long as you skip Interface Builder and make a point to keep your SwiftUI views lightweight. For the latter my rule of thumb is to try to cap nesting in any given view at 3 levels and to break code out into new components for anything deeper, which is a good practice since readability starts declining steeply past 2-3 levels deep anyway.

It doesn’t have all the whizbang features of Jetbrains IDEs, but my experience is that those sorts of features only work correctly sometimes and can be as much of a hindrance as they are a help.

No refactoring tools, lack of autocomplete, having multiple targets break compilation, errors in the ui, crashes running unit tests, it freaks out when switching git branches, spm can’t handle proxy servers, never ending indexing… List goes on and on. Xcode used to be good at around version 3. Everything that came after that has been disastrous.

Meanwhile Android Studio or VS Syudio are tools which are a joy to use and are built to help you and not to be constantly on your way

Fact is Apple should do like Google and admit there are better ides out there

And is there any actual need to use those right now? No.

I lived through the C++11 transition (which was the only actually significant improvement C++ has ever had), and as much as GCC 4.6 was enticing, it really wasn't a burden to keep supporting GCC 4.4 in stable software. Only for ground-breaking development (which takes long enough to stabilize that stable distros will have the new GCC) is it worth starting to use the new features unconditionally.

Now, C++ does have a much better source-level compatibility story than most languages (e.g. `#if ... #define constexpr /* compiler too old */`), but that just means that newer languages have no excuse for refusing to learn from its successes.

If you actually click through, there is exactly one actual distro package there, and it is labeled "experimental". Everything else is exactly what I complained about - something that does not integrate into a real system.

That's not what I call "actually usable on non-Apple systems".

I just picked a random, notable feature (std::format) and the LTS my systems are currently on (22.04). The current Clang in universe is 14, which doesn't have a complete std::format implementation. That's one of the most popular features from a 5 year old language standard that many people are using today and yet it's still not available on a common LTS version without adding the LLVM repos.

  > Xcode used to be good at around version 3.

before the merging of interface builder into xcode: it never recovered...

Have a look at today's Swift track FOSDEM talks.

I hate the other IDEs tbh

Yeah Xcode has its quirks but so does everything else. Nothing is perfect in this world.

What actually bothers me is Apple is now apparently trying to copy other IDEs (poorly) and making theirs worse for it. E.g. the new commit view which is an atrocity. They had something buggy yes, but at least decent. Now they have something buggy AND with a terrible UX.