4 ms·

Of course! Tons of examples here: https://github.com/apple/swift-embedded-examples https://github.com/apple/swift-embedded-examples At WWDC24, we shared a sess

Of course! Tons of examples here: https://github.com/apple/swift-embedded-examples 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 https://www.youtube.com/watch?v=LqxbsADqDI4 More documentation on embedded Swift tooling here: https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSwift/UserManual.md https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSw... (Disclosure: I work at Apple.)

wslh 2y ago
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/esp32-led-blink-sdk/main/Main.swift https://github.com/apple/swift-embedded-examples/blob/main/e...
sgt 2y ago
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?
- pjmlp 2y ago
  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.
  - josteink 2y ago
    > 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.
- aseipp 2y ago
  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.
- robterrell 2y ago
  If you look at the blinking LED sample, it's pulling in the freertos header: #include "freertos/FreeRTOS.h" So presumably yes?
nozzlegear 2y ago
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!
elforce002 2y ago
Hi Tim. I liked your work with dart/flutter. Are you guys working on overhauling Xcode? The DX is atrocious.
- sgt 2y ago
  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.
  - cosmic_cheese 2y ago
    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.
  - seviu 2y ago
    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
    - andrekandre 2y ago
      > Xcode used to be good at around version 3. before the merging of interface builder into xcode: it never recovered...
    - frizlab 2y ago
QuinnyPig 2y ago
Encountering an Apple employee in the wild is like spotting a unicorn.
- mdswanson 2y ago
  Tim is a unicorn.
- talldayo 2y ago
  Encountering an Apple employee on HN is like finding a Papa John's employee in the food court.

wslh 2y ago

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/esp32-led-blink-sdk/main/Main.swift https://github.com/apple/swift-embedded-examples/blob/main/e...

sgt 2y ago

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?

pjmlp 2y ago
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.
- josteink 2y ago
  > 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.
aseipp 2y ago
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.
robterrell 2y ago
If you look at the blinking LED sample, it's pulling in the freertos header: #include "freertos/FreeRTOS.h" So presumably yes?

nozzlegear 2y ago

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!

elforce002 2y ago

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

sgt 2y ago
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.
- cosmic_cheese 2y ago
  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.
- seviu 2y ago
  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
  - andrekandre 2y ago
    > Xcode used to be good at around version 3. before the merging of interface builder into xcode: it never recovered...
  - frizlab 2y ago

QuinnyPig 2y ago

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

mdswanson 2y ago
Tim is a unicorn.
talldayo 2y ago
Encountering an Apple employee on HN is like finding a Papa John's employee in the food court.