Can Swift run without the standard library?
Built-ins, compiler internals, and the limits of “bare Swift”
The short answer
Yes — Swift can run without the standard library.
But once you remove it, you quickly realize that most of what you think of as “Swift” isn’t the language itself, but the standard library layered on top of compiler primitives.
To understand why, you need to understand Swift built-in types.
What “built-in types” actually are in Swift
Swift built-in types are compiler-internal primitives exposed under a special namespace called Builtin. They exist below the standard library and are used by the compiler to model memory, values, and operations before anything becomes Int, Bool, or Optional.
Examples include:
Builtin.Int1,Builtin.Int64Builtin.WordBuiltin.RawPointerBuiltin.NativeObjectBuiltin.BridgeObjectBuiltin.FPIEEE64SIL-only token and vector types
Key facts:
You cannot import them
They do not appear in autocomplete
They are not stable APIs
They are meant for the compiler and standard library only
These types exist so Swift can lower high-level code into LLVM IR efficiently and predictably.
Built-ins vs the standard library
Int, Bool, Optional, Array, and even String are not built-in types. They are standard library abstractions built on top of built-ins.
For example, Int is effectively a wrapper around a compiler-known integer representation backed by a Builtin.Int* type. Arithmetic, comparisons, overflow behavior, and literals are implemented via compiler intrinsics operating on built-ins.
The actual layering looks like this:
LLVM IR
↑
Swift Built-in Types (Builtin.*)
↑
Swift Standard Library (Int, Bool, Optional…)
↑
Your Swift code
Once you remove the standard library, you lose everything above the Builtin layer.
Where built-in types live in the source
You won’t find built-in types in Xcode documentation. You need the Swift compiler source maintained by the Swift Project.
Important locations:
swift/include/swift/AST/Builtins.defswift/include/swift/AST/BuiltinTypes.def
These files define what built-ins exist and how the compiler understands them.
To see how they’re used:
swift/lib/SIL/— Swift Intermediate Languageswift/lib/IRGen/— lowering to LLVM IR
To see how the standard library wraps them:
swift/stdlib/public/core/Builtin.swiftswift/stdlib/public/core/Int.swiftswift/stdlib/public/core/Optional.swift
This is where compiler magic turns into user-facing APIs.
So… can Swift really run without the standard library?
This exact question is discussed in depth on the Swift Forums in the thread “Swift with no standard library”. The conclusion is consistent and blunt:
You can compile Swift with
-nostdlibYou can execute code using only built-ins
You lose literals, collections, strings, ARC helpers, and most conveniences
Writing meaningful programs becomes extremely low-level very quickly
That discussion also points to an interesting experiment: μSwift, available as the compnerd/uswift repository on GitHub. It provides a minimal stdlib-like core designed for constrained or experimental environments. It’s not a replacement for the real standard library, but it demonstrates that built-in types are sufficient to bootstrap higher-level abstractions — at a significant engineering cost.
Takeaways
It is technically possible to write and execute Swift code without the standard library.
Swift built-in types are thin compiler-level primitives that map directly onto LLVM representations.
A public GitHub repository compnerd/uswift demonstrates that this approach works in practice, not just in theory.
There is a thoughtful and technical discussion on the Swift Forums “Swift with no standard library“ that explores the limits, trade-offs, and motivations behind running Swift without its standard library.