Apple is open sourcing Swift Build

Original Article ↗ Hacker News Discussion ↗

Embedded Swift and Interoperability

  • Multiple commenters confirm Apple is actively investing in Embedded Swift (examples on ESP32, RP2040/RP2350, WWDC talks, docs).
  • Interop with C/Objective‑C/C++ is described as a core design goal; Embedded Swift produces ordinary object files that can link with C code.
  • FreeRTOS interop is considered feasible; one sample includes freertos/FreeRTOS.h. Biggest limitation noted: async support is rudimentary, currently single‑threaded.
  • Some speculate Apple wants Swift to replace internal “safe C” dialects (e.g., for iBoot, Secure Enclave, firmware, smart home devices).

Xcode, Tooling, and Developer Experience

  • Strong split: some say Xcode is “fine” if you avoid Interface Builder and keep SwiftUI simple; others describe it as crash‑prone, slow, and bug‑ridden (indexing issues, broken refactors, flaky tests, git confusion).
  • Several express desire to decouple Swift from Xcode; others note Swift has had CLI tools and a VS Code plugin for years, though VS Code support is still seen as weaker than Xcode.
  • Frustration that newer Swift versions often require newer Xcode/macOS, effectively forcing hardware/OS upgrades; others counter that standalone Swift toolchains can be installed, but that doesn’t solve iOS SDK/codesigning.

Apple Control, Trust, and Cross‑Platform Perception

  • Many argue Swift is “Apple‑tied” in branding and governance: Apple leads the project and prioritizes Apple platforms, which discourages non‑Apple adoption.
  • Others reply this is similar to Go, Rust, C#, Zig, etc., all of which have strong corporate or core‑team control, plus formal proposal processes.
  • Debate over whether Apple can be trusted as a long‑term steward; comparisons to .NET/Mono and other corporate‑controlled ecosystems recur.
  • Some emphasize Apache licensing and the ability to fork, while skeptics say the real risk is strategic control and priorities, not code access.

Linux, Foundation, and Ecosystem

  • Complaints that Swift still lacks first‑class distro packages; most Linux installs rely on tarballs, Docker images, or a Swift‑specific toolchain manager.
  • Others say distro toolchains are typically outdated anyway and prefer rustup‑style managers; one points out Swift provides such a tool.
  • New open‑source swift-foundation and swift-testing are highlighted as moves toward full, cross‑platform core libraries comparable to Apple’s proprietary Foundation/XCTest.
  • Some report modern Swift on Linux (with new Foundation) now feels close to macOS in practice for server‑side usage.

Swift Build and Build System Goals

  • The newly open‑sourced Swift Build is presented as a unified build engine that SwiftPM can delegate to on all platforms.
  • Apple‑specific behavior is being moved into plugins so the core build system can be shared by macOS, Linux, and Windows.
  • Commenters see benefits in easier debugging of build issues and faster access to fixes, without waiting for Xcode releases.
  • One link from the Swift forums claims this will improve SwiftPM and builds on all platforms, setting a foundation for more consistent multi‑platform tooling.

Comparisons to Other Languages and Ecosystems

  • Several compare Swift’s trajectory to C#/.NET: powerful language, originally platform‑tied, slowly opened, but still perceived as vendor‑owned.
  • Others argue .NET Core is now a strong, fully multi‑platform framework and suggest Swift would need similar depth in tooling, libraries, and governance to gain comparable trust.
  • Some prefer Kotlin, Rust, Go, or C# due to broader platform neutrality, more mature tooling, or richer ecosystems; others find Swift “comfy” and would like to use it beyond Apple platforms to avoid JVMs or Rust’s complexity.

Language Ergonomics, Error Reporting, and Compile Times

  • Swift is widely praised as a “really cool” and expressive language with strong safety and good C interop.
  • Criticisms include:
    • Poor crash messages for “index out of range” in non‑Xcode contexts: stack dumps require symbolication and can still be unhelpful; this contrasts with Go’s clear file/line panics.
    • Slow compile times, often attributed to complex type checking and overload resolution.
    • Perception of increasing complexity (many keywords, “too complex” types, extensive extensions) and a drift toward a Scala‑like feel.
  • Some note Swift is IDE‑first (Xcode) rather than CLI‑first, making non‑Mac workflows feel rougher than languages designed around simple tooling from the outset.

Adoption Prospects and “Dying Language” Debate

  • One camp asserts that without full early parity on non‑Apple platforms and more open tools (even Xcode), Swift will remain mostly confined to Apple ecosystems and be unattractive for general use.
  • Others strongly dispute claims that Swift is “dying,” pointing to its centrality for iOS/macOS/watchOS/visionOS apps and new uses (embedded, server‑side, projects like a Swift‑based browser).
  • Several argue Swift’s fate outside Apple depends on whether non‑Apple developers see enough long‑term neutrality and investment to justify choosing it over better‑established, less vendor‑tied alternatives.