Embedded Swift examples: the same language from a Raspberry Pi to an STM32 with no SDK at all

What Embedded Swift is, and what this repository is for

The repository is a set of demonstration projects of Embedded Swift, and the README defines the term. Embedded Swift is a compilation and language mode that enables development of baremetal, embedded and standalone software in Swift. The distinction from ordinary Swift is the word mode, because Swift on a microcontroller is not the same product as Swift on a server. It compiles to freestanding binaries with no operating system underneath, no Objective-C runtime and no dynamic libraries, and the compiler drops the parts of the language and standard library that need those things. The repository exists to show that this is workable across real hardware, and it points to a blog post introducing the repository, a Swift forums thread about it, a further discussion of Embedded Swift, the Embedded Swift vision document in the swift-evolution repository, and the language documentation itself. The licence is Apache-2.0 and the primary language is Swift.

The catalogue, read as a map of the hardware landscape

The catalog table lists twenty examples with a platform, an SDK, a description and a photograph, and reading the platform column shows the range. There is the ESP32-C6-Bug, the ESP32-C6-DevKitC-1 and the plain ESP32-C6, the nRF52840-DK, the Raspberry Pi 4B, the Pi 5, the Pico, the Pico 2, the Pico W, the Pico 2W, and the STM32F746G-DISCO, plus a QEMU target running NuttX on RISC-V. The SDK column is where the real information sits. Some examples are built on the ESP-IDF, the Zephyr SDK or the Pico SDK, and others list no SDK at all, and those are the ones doing baremetal work directly. A project can blink an LED on a Pico with Swift MMIO and no vendor layer, or on a Pico with the Pico SDK, and the fact that both exist side by side is the most useful thing in the table, because it shows what Embedded Swift needs and does not need from the platform vendor.

What the baremetal examples actually do

The examples with no SDK are the interesting ones, and their descriptions are specific. rpi-4b-blink and rpi-5-blink blink the Pi's status green LED repeatedly using Swift MMIO, so memory mapped IO without a board support package. rpi-pico-blink blinks an LED with no SDK at all. rpi-pico2-neopixel controls Neopixel LEDs using the RP2350 PIO, which is the part of the RP2350 designed for exactly that job. stm32-blink blinks an LED on the STM32F746G-DISCO, stm32-uart-echo echoes user input over UART, stm32-neopixel drives a WS2812 strip over SPI, and stm32-lcd-logo animates the Swift logo on the board's built-in LCD. stm32-lvgl is the largest of them, a baremetal setup of LCD, touch panel and DRAM using the LLVM Embedded toolchain for ARM, rendering graphics and animations and reacting to input via LVGL, with a macOS and Linux SDL based host simulation app alongside it. The host simulation is the detail an embedded developer will notice first, since it is what makes the LVGL code debuggable on a laptop.

The SDK-based examples, and the ESP32 ones

The SDK examples cover the same ground with vendor support underneath. esp32-led-blink-sdk blinks the onboard LED with Swift and the ESP-IDF, and esp32-led-strip-sdk drives a NeoPixel strip the same way. esp32-uart-echo is a UART echo example that uses Swift's print() and readLine(), so it is demonstrating that the standard library conveniences survive in an embedded context. nrfx-blink-sdk blinks an LED with Swift and Zephyr, and rpi-pico-blink-sdk does the same with the Pico SDK. rpi-picow-blink-sdk is the one with a bit of character, blinking an LED to signal SOS in Morse code repeatedly with the Pico SDK, which is a small demonstration that you are writing a program and not wiring a timer. And there is the example that is not an LED at all, the harmony project on the Raspberry Pi Pico W, a bluetooth speaker and ferrofluidic music visualiser with the firmware, electrical and mechanical designs fully available.

The two examples that teach something different

Two entries in the catalogue are not blinking exercises, and they are the ones worth starting with. rpi-pico-lldb is a tutorial project for debugging Embedded Swift with LLDB, and it deliberately contains bugs to find and fix, which is a better way to learn a tool than a working example, because you cannot debug something that has nothing wrong with it. And nuttx-riscv-blink blinks a virtualised LED in QEMU using the Apache NuttX RTOS, which is the one example in the set that needs no hardware at all, and therefore the one a developer without a board can run. The catalogue also notes the platform and SDK columns for both, QEMU with NuttX and the Pico with no SDK.

The two common build steps, and the note about SDKs not being endorsements

Each example contains its own build and deployment instructions, but there are a couple of common steps for many of them. You install swift using the embedded Swift installation instructions, and you install uv, described as an extremely fast Python package and project manager, using its own installation instructions. The uv dependency is worth noticing, because it is a Python tool in a Swift repository, and it points to how the example scripts are driven. The catalogue ends with a note that matters for how you read the table: the SDK integration examples, Pico SDK, Zephyr SDK and the rest, are not recommendations or endorsement, and the same is true for the build system choice, Make, CMake, SwiftPM or shell scripts. The stated reason is that Embedded Swift aims to be versatile, allowing integration into existing SDKs and build systems, and the example projects show some of the possibilities. So the table is a survey, not a recommendation.

Community examples, and the warning that comes with them

There is a Community Examples section with its own warning, and the warning is the first thing in it. Community projects linked there are not officially supported by the team, and they may not always be compatible with the latest nightly Swift toolchain builds. That is an honest statement about what a linked repository can promise, and it is a specific risk, because the examples depend on nightly toolchain builds and a toolchain that moves will break code that was written against it. The community list includes swift-matter-examples, an Embedded Swift Matter application running on the ESP32-C6, and m5stack-nano-c6-bare-swift, a baremetal Swift project for the M5Stack NanoC6 running without any C, assembly or ESP-IDF, described as pure Embedded Swift from bootloader. The second one is a notable claim, because a project with no C at all is a much stronger demonstration than one built on top of a vendor SDK.

The repository layout, and the state of the project

The top level of the repository is the catalogue itself, with a directory per example, so the twenty directories with names like esp32-led-blink-sdk, harmony, nuttx-riscv-blink, rpi-pico-lldb, stm32-lvgl and stm32-uart-echo map directly onto the table. Alongside them are Sources/, which is the DocC documentation source the catalogue images are pulled from, a Documentation/ directory, a Tools/ directory, a Package.swift with a Package.resolved so the examples build as a Swift package, and the shared configuration files, a .swift-format, a .swiftformatignore, a .swift-version and a .flake8 for the Python scripts. The last push to the repository was on 2026-10-15, the repository is not archived, and there are no GitHub releases, since the artefacts here are examples to clone rather than a package to install. The topics list names the platforms directly, esp32, nrf, raspberrypi and stm32, which is a compact statement of the range the collection covers.

Editorial conclusion

Embedded Swift examples suits a developer evaluating whether Swift is viable for a microcontroller, and who wants to see the same language across three different hardware families and four different build approaches before committing. It is the wrong choice as a set of production starting points, because the documentation says each example carries its own instructions and that the SDK integrations are demonstrations rather than recommendations, and a poor fit if you need a maintained abstraction layer, since this is a set of standalone projects rather than a library. Before you start, read the catalogue rather than picking a project, because the most instructive examples are the ones with no SDK at all, and note the community section warning that those projects are not officially supported and may not work with the latest nightly toolchain.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. swiftlang/swift-embedded-examples on GitHub