Swift Configuration 1.0 released

Swift Configuration brings a unified, type-safe approach to this problem for Swift applications and libraries. What makes this compelling isn’t just that it reads configuration files: plenty of libraries do that. It’s the clean abstraction that it introduces between how your code accesses configuration and where that configuration comes from. This separation unlocks something powerful: libraries can now accept configuration without dictating the source, making them genuinely composable across different deployment environments.

→ swift.org/blog/swift-configuration-1.0-released/

Swift Configuration is a new library for Swift. It handles settings in a unified way. You read values the same way no matter where they come from. Before, developers had to write code for each source. This included environment variables, files, or remote services. Code often mixed with how values were read. Swift Configuration fixes this. It separates code that uses settings from code that loads them. Libraries can now take a configuration reader. They do not need to know the source. This makes libraries work in more places.

You start with a few lines. Import the library. Create a reader with providers. Providers load from files, environment, or arguments. You can layer providers. First ones override later ones. Defaults fill in last. It supports synchronous or asynchronous access. It can watch for changes and reload. It has namespacing, logging, and secret hiding.

Many projects use it. Examples include Vapor, Hummingbird, and Swift Temporal SDK. Some apps like Peekaboo and swiftodon use it too. Custom providers exist for TOML or AWS. This library makes configuration clean and flexible. It suits servers, tools, and libraries.