Embedded Swift ile IoT Firmware: 6.4 Yol Haritası

Embedded Swift, Swift dilini mikrodenetleyici sınıfı donanımlarda çalıştırmak için tasarlanmış bir derleyici modudur ve 15 Eylül 2026'da yayınlanan Swift 6.4 ile birlikte önemli bir olgunluk eşiğini geçti. Bu yazıda embedded swift iot firmware geliştirmenin Ekim 2026 itibarıyla sınırlarını, Swift 6.4'ün gerçekte neyi değiştirdiğini ve bir IoT cihazını iOS uygulamana bağlarken karşılaşacağın gerçek mimari kararları ele alıyoruz.

💡 Pro Tip: Embedded Swift, "Swift'in küçültülmüş bir lehçesi" değil; tam Swift'in bir alt kümesidir — Embedded modda derlenen kod, normal Swift'te de derlenir, tersi her zaman doğru olmaz.

İçindekiler

• Embedded Swift Nedir, Hangi Kısıtlarla Çalışır
• Neden bu ayrım önemli
• Swift 6.3 Tabanında Gelen Embedded Temeli
• Araç Zinciri Kurulumu ve İlk Firmware
• Bellek ve Binary Bütçesi: Gerçekte Ne Biliyoruz
• Swift 6.4 İle Gelen Embedded İyileştirmeler
• IoT Cihaz + iOS Eşleştirme Mimarisi
• Üretimde Kullanılır mı? (Ekim 2026)
• SSS
• Embedded Swift hangi donanımlarda kullanılabiliyor?
• Embedded Swift ile normal Swift arasındaki kısıtlar neler?
• Swift 6.4 embedded tarafında ne getirdi?
• Embedded Swift firmware'i bir iOS uygulamasına nasıl bağlanır?
• Embedded Swift projeme hangi Swift sürümüyle başlamalıyım?
• Sonuç
• Kaynaklar

Embedded Swift Nedir, Hangi Kısıtlarla Çalışır

Embedded Swift'in resmi çerçevesi, swift-evolution deposundaki "A Vision for Embedded Swift" dokümanında çizildi; dokümanın kendi ifadesiyle motivasyon "to achieve a first class support for embedded platforms and unblock porting and using Swift in small environments". Resmi konumlandırma net: runtime reflection (Mirror API'leri) ve ABI kararlılığı gibi masaüstü/sunucu Swift'ine özgü özellikler devre dışı bırakılır, buna karşılık dilin geri kalanı büyük ölçüde aynı kalır.

Swift 6.4 öncesinde en somut kısıtlardan biri existential tiplerdi: yalnızca AnyObject ile kısıtlanmış protokoller any olarak kullanılabiliyordu. Swift 6.4 ile bu tablo değişti — artık Any dahil tüm any tipleri Embedded Swift'te destekleniyor. Buna karşın generic bir fonksiyonu doğrudan any P değeri üzerinde çağırmak hâlâ mümkün değil; derleyici "cannot use generic instance method ... on a value of type 'any P' in Embedded Swift" hatasını veriyor. Yani existential'ları taşıyabilirsin, ama generic dispatch için hâlâ somut tiplere ihtiyaç duyarsın.

Donanım tarafında da bir ayrım var ve bu ayrımı atlamak yaygın bir hata: Embedded Swift, ARM Cortex-M ve RISC-V mimarili çok sayıda mikrodenetleyicide resmi örnek projeleri bulunan hedefler arasında yer alır — STM32F746G-DISCO, Raspberry Pi Pico / Pico 2 / Pico W, Nordic nRF52840-DK ve Espressif'in RISC-V tabanlı ESP32-C6'sı (esp32-led-blink-sdk, esp32-led-strip-sdk, esp32-uart-echo) resmi örnek deposunda kendi projeleriyle duruyor. Resmi doküman burada iddiayı bilinçli olarak sınırlıyor: "Embedded Swift is not a complete one-click solution to program all embedded boards and MCUs" — linker script'i, flash formatı ve yükleme aracı hâlâ donanım üreticisinin araç zincirinden gelir. Klasik Xtensa mimarili ESP32 / ESP32-S2 / ESP32-S3 ise bu listede yok; Swift Forums'taki ilgili başlığın ifadesiyle "newer MCUs are based on RISC-V and are supported by the upstream compiler, those using Xtensa require a custom compiler build". "ESP32'de Embedded Swift çalışır" demek, hangi ESP32 varyantından bahsettiğine göre doğru ya da tamamen yanlış olabilir.

Neden bu ayrım önemli

Bir IoT firmware'i tasarlarken donanım seçimini Embedded Swift desteğine göre yapıyorsan, ürün spesifikasyonunu netleştirmeden önce mimariyi teyit etmen gerekir. Örneğin ESP32-C6 RISC-V tabanlıyken, geliştirici topluluğunda hâlâ en yaygın referans donanım olan klasik ESP32 (Xtensa LX6) bu listenin dışında kalıyor ve özel bir derleyici derlemesi gerektiriyor.

Swift 6.3 Tabanında Gelen Embedded Temeli

Swift 6.3, 24 Mart 2026'da yayınlandı ve embedded ortamlar için iyileştirmeleri öne çıkan başlıklardan biri olarak duyurdu. Bu sürümle gelen iki özellik, IoT firmware + host uygulama (Swift tarafında yazılmış bir CLI, sunucu bileşeni ya da C tabanlı bir SDK) entegrasyonunu doğrudan ilgilendiriyor:

• @c attribute: Swift fonksiyonlarını ve enum'larını C koduna açmanı sağlıyor — mevcut bir C tabanlı firmware/HAL katmanına Swift fonksiyonu enjekte etmek için kullanışlı.
• Module selector (::): Aynı isimde birden fazla import edilmiş modül olduğunda Swift'in hangi modülde arama yapacağını netleştirmene izin veriyor — büyüyen bir embedded proje ağacında isim çakışmalarını çözmek için.

Araç Zinciri Kurulumu ve İlk Firmware

Embedded Swift ile başlamanın en gerçekçi yolu, resmi swift-embedded-examples deposundaki hedeflerden birini kendi donanımınla eşleştirmek. Depo; ESP32 (ESP-IDF üzerinden), nRF52840-DK (Zephyr), Raspberry Pi Pico W (Harmony ile Bluetooth hoparlör örneği) ve QEMU/NuttX üzerinde RISC-V hedeflerini kapsıyor. STM32 tarafında ise swift.org/get-started/embedded sayfası, Swift MMIO kullanarak tamamen baremetal (işletim sistemi olmadan) bir yol öneriyor.

Bir Swift paketinde Embedded modunu açmanın iki yolu var: bayrakları hedefe Package.swift içinde swiftSettings ile vermek ya da resmi örneklerdeki gibi bir toolset JSON dosyasında toplamak — ikisini birlikte kullanmana gerek yok. Birinci yol şöyle görünür:

1// Package.swift — embedded hedef için derleyici bayrakları
2let package = Package(
3    name: "BlinkFirmware",
4    targets: [
5        .executableTarget(
6            name: "BlinkFirmware",
7            swiftSettings: [
8                .enableExperimentalFeature("Embedded"),
9                .unsafeFlags(["-wmo"]) // whole-module optimization zorunlu
10            ]
11        )
12    ]
13)

Whole-module optimization (-wmo) zorunludur: derleyici embedded modda wmo olmadan doğrudan hata veriyor. Bütünsel derleme ayrıca runtime metadata'sının büyük kısmını derleme zamanında elemeye olanak tanır.

İlk firmware'in için giriş noktasını resmi örnekten kopyalamak en güvenli yol: swift-embedded-examples deposundaki baremetal stm32-blink örneği @main struct Application biçimini kullanıyor. @_cdecl ise ayrı bir senaryo — C tarafındaki bir SDK'nın beklediği giriş fonksiyonunu (ör. ESP-IDF'in app_main'i) Swift'te vermek için işine yarar:

1// Application.swift — STM32F746G-DISCO kartında I1 pinindeki LED'i yakıp söndürür
2// (swift-embedded-examples/stm32-blink örneğinin yapısı)
3import STM32F7X6
4import Support
5 
6@main
7struct Application {
8    static func main() {
9        // I portuna AHB1 saatini ver
10        rcc.ahb1enr.modify { $0.raw.gpioien = 1 }
11 
12        // I1 pinini push-pull, düşük hızlı, pull-down output olarak kur
13        gpioi.moder.modify { $0.raw.moder1 = 0b1 }
14        gpioi.otyper.modify { $0.raw.ot1 = 0b0 }
15        gpioi.ospeedr.modify { $0.raw.ospeedr1 = 0b00 }
16        gpioi.pupdr.modify { $0.raw.pupdr1 = 0b10 }
17 
18        var enable = false
19        while true {
20            gpioi.odr.modify { $0.raw.odr1 = enable ? 1 : 0 }
21            enable.toggle()
22            delay(milliseconds: 100)
23        }
24    }
25}
26 
27func delay(milliseconds: Int) {
28    for _ in 0..<10_000 * milliseconds { nop() }
29}

Derleme komutu hedef mimariye (triple) göre değişir ve baremetal hedeflerde toolset/SDK tanımı olmadan çalışmaz. Resmi stm32-blink Makefile'ının kullandığı satır şöyle:

1# swift-embedded-examples/stm32-blink/Makefile'daki derleme çağrısı
2swift build \
3  --build-system native \
4  --configuration release \
5  --triple armv7em-apple-none-macho \
6  --toolset Tools/Toolsets/stm32f74x.json

SwiftPM'siz, doğrudan derleyiciyle çalışmak istersen resmi "Learning the basics of Embedded Swift" sayfasının kanonik biçimi swiftc -target <target triple> -enable-experimental-feature Embedded -wmo input1.swift ... -c -o output.o şeklinde; hedef üçlüsü aynı zamanda çıktının ELF mi Mach-O mu olacağını belirliyor. Hedef donanımına göre gerçek pin haritası ve linker script'i ise mutlaka donanım üreticisinin (ör. STMicroelectronics, Nordic, Raspberry Pi Foundation) referans dokümanından alınmalı.

Bellek ve Binary Bütçesi: Gerçekte Ne Biliyoruz

Embedded Swift'in resmi konumlandırması net bir hedef ortaya koyuyor: "kilobayt ölçeğinde ölçülen anlamlı programlar üretmek" (swift.org/get-started/embedded). Bunu mümkün kılan mekanizma, runtime reflection'ın tamamen kaldırılması, generic'lerin mümkün olduğunca derleme zamanında monomorfize edilmesi ve whole-module optimization'ın zorunlu tutulmasıdır — bu üçü birlikte, tipik Swift runtime'ının mikrodenetleyicilerde en çok yer kaplayan kısımlarını devre dışı bırakır.

Resmi kaynaklarda büyüklük mertebesini veren üç somut rakam var. swift.org/get-started/embedded sayfası Playdate el konsolundaki Conway's Game of Life uygulaması için "In just 788 bytes of resulting compiled code" diyor. Embedded Swift dokümantasyonunun giriş sayfası genel ölçeği "Small binaries that can be as tiny as a few hundred bytes for 'Hello World'-like programs (fully self-contained)" diye tarif ediyor ve runtime kütüphanesi için "is itself less than a kilobyte in size, and is eligible to be removed if unused" ifadesini kullanıyor.

Burada dürüst olmak gerekiyor: bu rakamlar mertebe göstergesidir; hedef donanım başına resmi bir bütçe tablosu yayınlanmış değil — bütçe, seçtiğin hedef mimari, kullandığın kütüphane yüzeyi (ör. concurrency library'yi dahil edip etmediğin) ve derleyici optimizasyon seviyesine göre değişen bir değişken. Kendi projen için gerçek rakamı almanın tek güvenilir yolu, arm-none-eabi-size (ya da hedefine uygun size aracı) ile kendi derlediğin binary'yi ölçmek ve bunu commit'ten commit'e izlemektir; internette dolaşan tekil "X KB'a sığdı" anekdotları donanım/kütüphane bağlamı olmadan proje planlamasına taşınmamalı.

Swift 6.4 İle Gelen Embedded İyileştirmeler

20 Ağustos 2026'da Swift Language Steering Group üyesi Doug Gregor, "Embedded Swift Improvements Coming in Swift 6.4" başlıklı yazıda o an geliştirme snapshot'larında test edilebilen bir dizi iyileştirmeyi duyurdu. 15 Eylül 2026'da Swift 6.4 resmen yayınlandı (Xcode 27 sürüm notlarının ifadesiyle "Xcode 27 includes Swift 6.4") ve bu iyileştirmeler artık geliştirme önizlemesi değil, kararlı sürümün bir parçası:

• Tüm any existential tipleri destekleniyor — önceden yalnızca AnyObject ile sınırlanmış protokoller kullanılabiliyordu, şimdi Any dahil tüm existential'lar Embedded Swift'te geçerli.
• Metatype'lara tam destek — existential metatype'lar dahil.
• "Untyped throws" tam destekleniyor — hata yönetimi artık masaüstü Swift'e daha yakın.
• String → Double ayrıştırma API'leri Embedded Swift'e taşındı.
• Concurrency kütüphanesi throwing task/task group destekliyor — asenkron firmware kodunda hata yayılımı artık mümkün.

Bu maddelerin hepsi, IoT firmware'inde daha önce workaround gerektiren senaryoları (ör. hata kodu yerine gerçek throws kullanmak, birden fazla protokolü tek bir any değişkende taşımak) doğrudan destekleniyor hale getiriyor.

Somut bir örnekle göstermek gerekirse, 6.3'te bir sensör soyutlaması yazarken AnyObject kısıtına takılıyordun; 6.4'te aynı protokolü sınıf-dışı tiplerle de existential olarak taşıyabiliyorsun:

1// Swift 6.4 öncesi: yalnızca AnyObject-kısıtlı protokoller "any" olabilirdi
2protocol SensorReading: AnyObject {
3    var celsius: Double { get }
4}
5 
6// Swift 6.4: struct tabanlı bir protokol de artık "any" olarak taşınabiliyor
7protocol SensorReading {
8    var celsius: Double { get }
9}
10 
11struct TemperatureSample: SensorReading {
12    let celsius: Double
13}
14 
15func logReading(_ reading: any SensorReading) {
16    // Embedded Swift 6.4'te derlenir; 6.3'te struct-tabanlı
17    // protokoller için "any" kullanımı desteklenmiyordu.
18    print(reading.celsius)
19}

Sınır hâlâ duruyor: logReading içinden generic bir metodu reading üzerinden çağırmaya çalışırsan (ör. bir generic map), derleyici seni somut tipe geri yönlendirir — existential taşımak serbest, ama generic dispatch hâlâ statik çözümleme istiyor.

IoT Cihaz + iOS Eşleştirme Mimarisi

Burada net olmak gerekiyor: swift.org'un resmi Embedded Swift kaynaklarında, bir mikrodenetleyici firmware'ini bir iOS companion app'e bağlayan resmi bir "eşleştirme mimarisi" dokümanı yayınlanmış değil — Embedded Swift dokümantasyonu donanım tarafına, iOS SDK dokümantasyonu ise host tarafına odaklanıyor, ikisini birleştiren resmi bir rehber bulunmuyor. Bu, pratikte iki taraf arasındaki köprüyü kendi mimarin içinde kurman gerektiği anlamına geliyor.

Pratikte en olgun köprü katmanı Bluetooth Low Energy (BLE) üzerinden çalışıyor: firmware tarafı GATT servisleri yayınlıyor, iOS tarafı ise Core Bluetooth ile bu servislere bağlanıp veri değişimini yönetiyor. Bu ikili mimariyi uçtan uca kurarken hangi GATT karakteristiklerini tanımlaman ve iOS tarafında bağlantı kopmalarını nasıl toparlaman gerektiğini Core Bluetooth ve BLE rehberimizde ayrıntılı işledik. Gerçek bir üretim vakasında bu köprünün offline-first bir senkronizasyon katmanıyla nasıl birleştiğini ise ESP-Point vaka çalışmasında bulabilirsin — burada firmware Swift ile değil ama mimari desenler (bağlantı kopması, kuyruklama, çakışma çözümü) doğrudan Embedded Swift tabanlı bir firmware'e de uygulanabilir.

Aşağıdaki tablo, Swift 6.3 ile 6.4 arasında Embedded Swift'te değişen üç yeteneği özetliyor — firmware kod tabanını 6.4'e taşırken hangi workaround'ları kaldırabileceğini görmek için:

Üretimde Kullanılır mı? (Ekim 2026)

Burada iki resmi kaynak farklı şeyler söylüyor ve ikisini de bilmen gerekiyor. Resmi doküman Embedded Swift'i hâlâ deneysel olarak niteliyor: docs.swift.org/embedded sayfasındaki not "Embedded Swift is experimental. Public releases of Swift do not support Embedded Swift, yet." diyor, kurulum sayfası da "Since Embedded Swift is still experimental and not yet supported in public Swift releases, you'll need to use a development toolchain." diyerek swiftly install main-snapshot ile geliştirme snapshot'ı kurmanı öneriyor. Buna karşılık Swift 6.4 duyurusu embedded iyileştirmelerini sürümün parçası olarak listeliyor: "Embedded Swift grows more capable, with support for existential types and richer error handling for microcontroller-class targets." Yani dil yetenekleri sürüm notlarıyla geliyor, ama resmi kurulum yolu hâlâ snapshot toolchain'ini işaret ediyor — "üretime hazır mı" sorusuna mutlak bir evet/hayır yerine somut sınırları bilerek karar vermek daha doğru.

Swift 6.4 tabanında gerçekçi bir değerlendirme şöyle: dil sınırları büyük ölçüde kalktı (existential'lar, metatype'lar, throws), donanım desteği net ve genişliyor (ARM Cortex-M + RISC-V ailesi), ama iki şey hâlâ senin sorumluluğunda — (1) donanım seçiminde Xtensa/RISC-V ayrımını doğru yapmak, (2) iOS companion app köprüsünü resmi bir şablon olmadan kendi mimarinle kurmak. Küçük-orta ölçekli bir sensör/aktüatör firmware'i için gerçekçi bir seçenek; kritik-güvenlik (ör. medikal cihaz, otomotiv) sınıfı bir sistem için mevcut sertifikasyon/araç ekosistemi olgunluğunu ayrıca değerlendirmen gerekir — bu konuda resmi bir sertifikasyon beyanı bulunmuyor.

Donanım seçimini netleştirmek için aşağıdaki matrisi referans alabilirsin — resmi swift-embedded-examples deposunda örneklenen hedefler:

SSS

Embedded Swift hangi donanımlarda kullanılabiliyor?

Embedded Swift, ARM Cortex-M ve RISC-V mimarili birçok mikrodenetleyicide çalışır; STM32F746G-DISCO, Raspberry Pi Pico / Pico 2 / Pico W, Nordic nRF52840-DK ve Espressif'in RISC-V tabanlı ESP32-C6'sı resmi örnek deposunda kendi projeleriyle yer alıyor. Yine de resmi doküman "Embedded Swift is not a complete one-click solution to program all embedded boards and MCUs" diyor: linker, flash formatı ve yükleme aracı için donanım üreticisinin araç zincirine ihtiyacın var. Önemli istisna: klasik Xtensa mimarili ESP32/ESP32-S2/S3 upstream derleyicide desteklenmiyor, özel bir derleyici derlemesi gerektiriyor — bu ayrımı atlamak yaygın bir hata.

Embedded Swift ile normal Swift arasındaki kısıtlar neler?

Embedded Swift, tam Swift'in bir alt kümesi olacak şekilde tasarlandı: çalışma zamanı reflection (Mirror API'leri) ve ABI kararlılığı gibi özellikler devre dışı. Swift 6.4 öncesinde geniş any/existential kullanımı da kısıtlıydı, ancak 6.4 ile bu değişti — artık Any dahil tüm existential tipler ve metatype'lar destekleniyor. Genel ilke hâlâ geçerli: Embedded modda derlenen kod normal Swift'te de derlenir, tersi her zaman doğru değildir.

Swift 6.4 embedded tarafında ne getirdi?

Swift 6.4, 15 Eylül 2026'da yayınlandı ve Embedded Swift'e üç somut kazanım getirdi: (1) AnyObject kısıtı olmadan tüm existential/any tiplerinin desteklenmesi, (2) existential metatype'lar dahil metatype'ların tam desteklenmesi, (3) mikrodenetleyici sınıfı hedefler için untyped throws ve throwing concurrency dahil daha zengin hata yönetimi.

Embedded Swift firmware'i bir iOS uygulamasına nasıl bağlanır?

En olgun yöntem Bluetooth Low Energy üzerinden GATT servisleridir: firmware tarafı servisleri yayınlar, iOS tarafı Core Bluetooth ile bağlanıp veriyi okur/yazar. Resmi bir "eşleştirme mimarisi" dokümanı yayınlanmadığı için bu köprüyü kendi projenin gereksinimlerine göre tasarlaman gerekir.

Embedded Swift projeme hangi Swift sürümüyle başlamalıyım?

Swift 6.4, 15 Eylül 2026'da yayınlandı ve embedded existential/metatype iyileştirmelerini sürümün parçası olarak listeliyor; bu yüzden yeni bir projede 6.3 tabanına geri dönmek için sebep yok. Ancak resmi kurulum rehberi Embedded Swift için hâlâ "you'll need to use a development toolchain" diyor ve swiftly install main-snapshot ile geliştirme snapshot'ı kurmanı öneriyor — araç zincirini buna göre planla.

Sonuç

Embedded Swift, vision dokümanıyla çizilen hedeften Eylül 2026'ya kadar iki büyük sürümle (6.3, 6.4) olgunlaştı ve artık existential tipler, metatype'lar ve throwing concurrency gibi masaüstü Swift'ine has özellikleri mikrodenetleyici sınıfı donanımlara taşıyor. Donanım desteği net: ARM Cortex-M ve RISC-V ailesi güçlü, klasik Xtensa ESP32 varyantları ise dışarıda; resmi doküman ise modu hâlâ deneysel sayıyor ve geliştirme snapshot toolchain'i öneriyor. Bir sonraki adımın firmware'ini bir iOS uygulamasına bağlamaksa, Core Bluetooth ve BLE rehberimiz pratik başlangıç noktası; gerçek bir offline-first senkronizasyon mimarisi için ESP-Point vaka çalışmasını incelemeni öneririz.

Swift tarafında asenkron firmware kodu yazarken TaskGroup ve AsyncStream desenlerini Swift Structured Concurrency rehberimizde derinlemesine ele aldık; Swift 6'nın strict concurrency geçişinde actor isolation uyarılarıyla karşılaşırsan Swift 6.3 geçiş rehberimiz yol gösterici olacaktır. Firmware ve host uygulaman büyüdükçe kod tabanını modüllere ayırmak için Swift Package Manager ileri seviye rehberimize bakabilirsin, offline senaryoları iOS tarafında ele almak içinse iOS Offline-First Mimari yazımız tamamlayıcı bir kaynak.

Kaynaklar

• Swift 6.4 Released — Swift 6.4'ün resmi yayın duyurusu, 15 Eylül 2026 tarihli.
• Embedded Swift Improvements Coming in Swift 6.4 — existential, metatype ve throws iyileştirmelerinin ilk duyurusu, 20 Ağustos 2026.
• Swift 6.3 Released — @c attribute, module selector ve embedded iyileştirmeleri içeren 6.3 duyurusu.
• Get Started with Embedded Swift — resmi tanıtım sayfası; Playdate'te 788 baytlık Game of Life örneği dahil.
• Embedded Swift Documentation — resmi doküman; "Embedded Swift is experimental" notu ve binary/runtime boyut ifadeleri burada.
• Installing Embedded Swift — swiftly ile geliştirme snapshot toolchain'i kurulumu.
• Learning the basics of Embedded Swift — kanonik swiftc -target ... -enable-experimental-feature Embedded -wmo derleme biçimi.
• A Vision for Embedded Swift — Embedded Swift'in hedeflerini ve yaklaşımını tanımlayan resmi vision dokümanı.
• Embedded Swift support for ESP32-S3, ESP32-S2 and original ESP32 (Xtensa arch) — Xtensa varyantlarının özel derleyici derlemesi gerektirdiğini anlatan Swift Forums başlığı.
• swift-embedded-examples (GitHub) — ESP32, nRF52840, Raspberry Pi Pico ve QEMU/NuttX örnek projeleri.
• Xcode 27 Release Notes — "Xcode 27 includes Swift 6.4" ifadesinin resmi kaynağı.