Apple is open sourcing Swift Build

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.)

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?

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.

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?

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.

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

  > Xcode used to be good at around version 3.

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

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.