Swift 6.3 veröffentlicht

 (swift.org)
2 Punkte von GN⁺ 2026-03-28 | 1 Kommentare | Auf WhatsApp teilen
  • Erweitert Sprache, Standardbibliothek, Build-System und Plattformunterstützung umfassend und verbessert die Developer Experience
  • Zu den wichtigsten Änderungen zählen stärkere C-Interoperabilität, ein offizielles Android-SDK, Verbesserungen für Embedded-Umgebungen und eine Erweiterung des Dokumentationstools DocC
  • Der Swift Package Manager erhöht mit einer integrierten Build-Engine und Unterstützung für vorgefertigtes Swift Syntax die Konsistenz plattformübergreifender Builds
  • Swift Testing ergänzt neue Funktionen wie die Protokollierung von Issues auf Warnstufe, Testabbruch und das Anhängen von Bildern und erhöht damit die Flexibilität beim Testen
  • Mit der offiziellen Veröffentlichung des Android SDK erweitert Swift seinen Bereich für plattformübergreifende Entwicklung und ermöglicht die Integration mit Kotlin-/Java-Apps

Wichtige Updates in Swift 6.3

  • Swift 6.3 bietet erweiterte Funktionen über Sprache, Standardbibliothek, Build-System und Plattformunterstützung hinweg
  • Stärkere C-Interoperabilität, ein offizielles Android-SDK, Verbesserungen für Embedded-Umgebungen und eine Erweiterung des Dokumentationstools DocC sind die zentralen Änderungen
  • Ziel sind eine bessere Developer Experience und eine stärkere Integration plattformübergreifender Entwicklung

Sprache und Standardbibliothek

  • C-Interoperabilität

    • Mit dem neuen Attribut @c lassen sich Swift-Funktionen oder Enums für C-Code verfügbar machen
    • In der Form @c(MyLibrary_callFromC) kann ein benutzerdefinierter C-Deklarationsname angegeben werden
    • Werden @c und @implementation zusammen verwendet, können in Swift Funktionen implementiert werden, die in C-Headern deklariert sind
    • In dieser Kombination prüft Swift, ob die bestehenden C-Deklarationen übereinstimmen

  • Modulnamensselektoren (Module Name Selectors)

    • Werden APIs mit demselben Namen aus mehreren Modulen importiert, ist mit ModuleA::getValue() ein modulspezifischer Aufruf möglich
    • Über die Syntax Swift::Task ist Zugriff auf Concurrency- und String-Processing-APIs möglich

  • Performance-Steuerung für Bibliotheks-APIs

    • @specialize: stellt vorab spezialisierte Implementierungen für bestimmte Typen generischer APIs bereit
    • @inline(always): erzwingt Inlining und erweitert den Funktionsrumpf an der Aufrufstelle
    • @export(implementation): legt in ABI-stabilen Bibliotheken Funktionsimplementierungen offen und erlaubt zusätzliche Optimierungen
    • Zugehörige Vorschläge sind im Swift-Evolution-Dashboard einsehbar

Verbesserungen bei Paketen und Builds

  • Der Swift Package Manager enthält eine integrierte Swift-Build-Vorschau und bietet damit auf allen Plattformen ein konsistentes Build-Erlebnis
    • Die integrierte Build-Engine stärkt die Konsistenz plattformübergreifender Entwicklung
    • Nutzer können direkt mit ihren Paketen testen und Probleme melden
  • Wichtige Verbesserungen in SwiftPM 6.3
    • Unterstützung für Prebuilt Swift Syntax: In Bibliotheken nur für Makros können vorgefertigte swift-syntax-Binärdateien verwendet werden
    • Flexible Steuerung geerbter Dokumentation: In Command-Plugins, die Symbol Graphs erzeugen, lässt sich steuern, ob geerbte Dokumentation einbezogen wird
    • Erkundung von Package Traits: Mit dem Befehl swift package show-traits lassen sich die vom Paket unterstützten Merkmale prüfen
    • Weitere Details finden sich in den Release Notes zu SwiftPM 6.3

Updates der Core Libraries

  • Swift Testing

    • Protokollierung von Issues auf Warnstufe: Mit Issue.record(..., severity: .warning) werden Warnungen angezeigt, ohne dass der Test fehlschlägt
    • Testabbruch: Mit try Test.cancel() können laufende Tests und Unteraufgaben gestoppt werden
    • Unterstützung für Bildanhänge: Auf Apple- und Windows-Plattformen können während des Testens Bilder angehängt werden
    • Zugehörige Vorschläge: ST-0012, ST-0013, ST-0014, ST-0015, ST-0016, ST-0017, ST-0020

  • DocC

    • Unterstützung für Markdown-Ausgabe: Mit der Option --enable-experimental-markdown-output lassen sich Markdown-Dokumente erzeugen
    • Statische HTML-Inhalte pro Seite: Durch das Einfügen von zusammenfassendem HTML in `` werden Suchmaschinenfreundlichkeit und Barrierefreiheit verbessert
    • Erweiterte Codeblock-Anmerkungen: Neue Formatoptionen wie nocopy, highlight, showLineNumbers, wrap wurden hinzugefügt
    • Aktivierbar mit der Option --enable-experimental-code-block-annotations

Plattformen und Umgebungen

  • Embedded Swift

    • Enthält zahlreiche Verbesserungen wie stärkere C-Interoperabilität, besseres Debugging und Fortschritte beim Abschluss des Linkage-Modells
    • Details finden sich im Blog “Embedded Swift Improvements coming in Swift 6.3”

  • Android

    • Erste offizielle Veröffentlichung des Swift SDK for Android
    • Ermöglicht die Entwicklung nativer Android-Apps mit Swift sowie Android-Build-Unterstützung für Swift-Pakete
    • Integration mit Kotlin-/Java-Apps ist über Swift Java und Swift Java JNI Core möglich
    • Gilt als wichtiger Meilenstein für den Ausbau von Swifts plattformübergreifender Entwicklung
    • Eine Einstiegshilfe bietet das Dokument “Getting Started with the Swift SDK for Android”

Nächste Schritte

  • Die Swift-6.3-Toolchain kann über die Seite Install Swift installiert werden
  • Entwickler können die neuen Funktionen sofort ausprobieren und Feedback geben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-28
Hacker-News-Kommentare

  • Es ist schön zu sehen, dass für Swift so ein großartiges Release erscheint.
    Ich habe es seit v3 nicht mehr benutzt, aber ungefähr 2015–17 hätte Swift Python ersetzen können.
    Es war einfach, schnell und passte gut zum C/C++-Ökosystem. Als IBM die Server-Seite vorantrieb, schien das wirklich möglich.
    Aber Apple hat die Community nicht ausreichend eingebunden, und am Ende blieb Swift eine Apple-exklusive Sprache. Inzwischen ist die Komplexität auch auf C++-Niveau angestiegen.

    • Als ich im Studium freiberuflich gearbeitet habe, habe ich ein Web-Backend in Swift gebaut. Ich habe es mit einem Heroku-Buildpack deployt, das war eine ziemlich spannende Zeit.
      Ich mag Swift, aber außerhalb des Apple-Ökosystems fühlt es sich immer noch so an, als hätte es die kritische Masse nicht erreicht. Am Ende bin ich letztes Jahr zu Typescript gewechselt.
    • Selbst mit dem aktuellen Swift 6.3 ist Entwicklung außerhalb der Apple-Plattformen immer noch schmerzhaft.
      Vor allem wollen wohl nur sehr wenige freiwillig Apple als Gatekeeper in ihren Stack holen.
    • Google wollte TensorFlow zeitweise auch von Python nach Swift verlagern.
      TensorFlow-Swift-Projekt
    • Selbst Python 3 hat lange gebraucht, um Python zu ersetzen.
    • Python ist dank des interaktiven Interpreters stark bei iterativer Entwicklung und in Jupyter Notebook.
      CircuitPython war auch für Embedded-Prototyping nützlich. Swift konnte diese Bereiche nie wirklich besetzen.
      Außerdem kam Swift erst 2016 auf Linux, 2020 auf Windows und sogar erst 2025 auf FreeBSD.
      Mitte der 2010er erschienen so viele neue Sprachen wie Go, Julia, Rust, TypeScript und Solidity, dass die meisten Leute nur Zeit hatten, ein oder zwei davon zu lernen.

  • Ich hatte gehofft, dass Swift zu einer Sprache für den gesamten Stack wird, aber die Realität sieht anders aus.
    Es fühlt sich an, als hätte Apple die Chance vertan.

    • Ich arbeite tatsächlich mit Swift über den gesamten Stack hinweg.
      Zum Beispiel ist ClearSurgery von Linux bis zu Echtzeit-Komponenten komplett in Swift geschrieben.

  • Letzte Woche habe ich das Betriebssystem xv6-riscv nach Zig, Nim, LISP und Swift portiert.
    Dank der Fortschritte bei Embedded Swift wirkte es wie eine produktive Sprache. Auch die Abstraktionen rund um Speicherzugriffe waren sauber.
    Aber die Kompiliergeschwindigkeit war so langsam, dass ich mich am Ende auf Nim konzentriert habe.

    • Nim ist ein Name, den man schon lange nicht mehr gehört hat; mich würde interessieren, warum du es gewählt hast.
    • Es wurde gefragt, ob damit McCarthy LISP gemeint ist.

  • Schade, dass Verbesserungen der Kompiliergeschwindigkeit nicht erwähnt wurden.
    Langsameres Kompilieren als bei Rust verschlechtert die Developer Experience erheblich.

    • Ich hatte auch kürzlich ein Swift-Projekt, und je mehr Abhängigkeiten es gab, desto erstaunlich langsam wurde das Kompilieren.
      Wenn man an die schnellen Builds von Go gewöhnt ist, ist Swift für iterative Entwicklung wirklich schmerzhaft. Die Sprache selbst ist großartig, aber die Feedback-Schleife ist viel zu langsam.

  • In Swift 6.3 wurde erstmals ein offizielles SDK für Android aufgenommen.

    • Ich frage mich, ob es auch welche für Windows und Linux gibt.
      Für Windows gibt es einen Blogpost von vor 5 Jahren,
      für Linux einen Guide für GNOME.
      Es wäre schön, wenn man wie früher bei OpenSTEP einmal entwickeln und dann auf mehreren Plattformen ausliefern könnte.
    • Es wird wohl noch weniger genutzt werden als Swift für Server.

  • Die Verbesserungen bei noncopyable-Typen sind der am meisten unterschätzte Teil dieses Releases.
    Damit wird es in Swift jetzt viel realistischer, eindeutige Ownership zu modellieren.

  • Mit dem Attribut @c in Swift 6.3 kann man Swift-Funktionen jetzt für C-Code exportieren.
    Ich frage mich allerdings, warum das erst jetzt hinzugefügt wurde. C++-Interoperabilität vorher einzubauen wirkt wie eine seltsame Priorisierung.

    • Tatsächlich existierte das früher schon als unterstrichenes Attribut.
    • C++-Interoperabilität war für Apple wichtig, um bestehende Low-Level-Codebasen einzubinden.
      Wenn man Swift dagegen nach C exportiert, entsteht leicht FFI-Spaghetti, und bei enum, Ownership und Null-Handling schleichen sich schnell ABI-Bugs ein.
      Vor allem wenn Closures dazukommen, kann eine falsche Calling Convention leicht einen ganzen Tag Debugging kosten.
    • Weil es bereits die Möglichkeit gab, nach ObjC zu exportieren, hatte das eine niedrigere Priorität.
    • Ich habe das schon früher experimentell genutzt; jetzt wurde es einfach offiziell gemacht.

  • Früher musste ich @cdecl verwenden, wenn ich in Swift eine dylib für ein C-Programm gebaut habe; deshalb freut mich die offizielle Unterstützung.

  • Die tatsächlichen Änderungen jenseits des Marketings kann man im CHANGELOG und in der
    Liste der Swift-Evolution-Vorschläge sehen.
    6.3 war vor allem ein Release mit Fokus auf Integrationsarbeit — stdlib, C/C++, swift-java-Interoperabilität, Build-System usw.
    SPM übernimmt nach und nach Funktionen von Xcode, und auch eine neue swift-build-Engine sowie prebuilt-Module werden experimentell erprobt.
    Aber das Zusammenspiel von SPM und Xcode ist weiterhin instabil, und die interne Komplexität wächst.
    Der Fortschritt der Sprache selbst ist leise, aber an tiefgreifender Strukturarbeit wie Lifetime-Kontrolle und Concurrency-Coloring wird weiter gearbeitet.
    Da mehrere Betriebssysteme, Geräte und CI-Umgebungen miteinander verflochten sind, befinden sich Swift-Entwickler ständig in einer Situation, in der sie im Wandel das Gleichgewicht halten müssen.

    • In Swift 6.4 soll swift-build zum Standard werden.
      Laut dem offiziellen Forenbeitrag
      wird es intern bereits von Xcode verwendet, aber die Performance-Probleme sind gravierend.
      Dazu gibt es auch eine zugehörige Diskussion.
      Wenn SPM und Xcode dieselbe Engine nutzen, könnte es besser werden, aber ich erwarte nicht zu viel.

  • Ich frage mich, wie die Toolchain in aktuellen Swift-Versionen aussieht. Mich würde interessieren, ob Swift Lint und Swift Format unterstützt werden.
    Bei einer modernen Sprache sollte es einen eingebauten Formatter und empfohlene Lint-Regeln geben. Nicht nur die Sprache, sondern das gesamte Ökosystem ist wichtig.

    • Beide Tools sind jetzt standardmäßig enthalten. Man kann sie ohne externe Abhängigkeiten direkt mit swift format und swift format lint verwenden.