# Introducing Swift Configuration **URL:** \ **Category:** Swift Configuration\ **Tags:** configuration\ **Created:** [September 25, 2025, 6:23pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368 "2025-09-25T18:23:03Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [September 25, 2025, 6:23pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/1 "2025-09-25T18:23:04Z")
Hi Swift Community! Today, we’re pleased to announce the initial release of **[Swift Configuration](https://github.com/apple/swift-configuration)**: a new library that provides a unified approach to reading configuration in your Swift applications. Configuration management has long been a challenge across different sources and environments. Previously, configuration in Swift had to be manually stitched together from environment variables, command-line arguments, JSON files, and external systems. Swift Configuration creates a common interface for configuration, enabling you to: - **Read configuration the same way across your codebase** using a single configuration reader API that’s usable from both applications and libraries. - **Quickly get started with a few lines of code** using built-in providers for environment variables, command-line arguments, JSON and YAML files, and in-memory values. - **Build and share custom configuration providers** using a public `ConfigProvider` protocol that anyone can implement and share. Swift Configuration excels in the Swift server ecosystem, where configuration is often read from multiple systems and tools. The library is equally useful in command-line tools, GUI applications, and libraries wherever flexible configuration management is needed. ## Getting started Swift Configuration's key strength lies in its ability to combine multiple configuration providers into a coherent hierarchy. This allows you to establish sensible defaults while providing clean override mechanisms for different deployment scenarios. For example, if you have default configuration in JSON: ```json { "http": { "timeout": 30 } } ``` And want to be able to provide an override using an environment variable: ```bash # Environment variables: HTTP_TIMEOUT=15 ``` The example below creates the two relevant providers, and uses them to resolve a value for the HTTP timeout: ```swift let config = ConfigReader(providers: [ EnvironmentVariablesProvider(), try await JSONProvider(filePath: "/etc/config.json") ]) let httpTimeout = config.int(forKey: "http.timeout", default: 60) print(httpTimeout) // prints 15 ``` The resolver checks providers in the order you specify, so environment variables take precedence over JSON configuration, which in turn overrides your fallback defaults. This eliminates ambiguity about which configuration source is actually being used. As your configuration needs evolve, enable [access logging](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration/troubleshooting) to track where values are accessed in your code and which providers are responding. This transparency helps maintain confidence even in complex configuration hierarchies. ## Advanced capabilities While the library prioritizes simplicity for basic use cases, it includes powerful features for production environments: - [Multiple access patterns](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration#Three-access-patterns) – synchronous, asynchronous, and reactive watching patterns. - [Hot reloading](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration#Hot-reloading) – configuration updates without service restarts. - [Namespacing and scoped readers](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration#Namespacing-and-scoped-readers) – organized configuration management through nesting. - [Access logging](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration#Debugging-and-troubleshooting) – comprehensive debugging and troubleshooting support. - [Secret redaction](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration/handling-secrets-correctly) – built-in protection for sensitive configuration values. The [complete documentation](https://swiftpackageindex.com/apple/swift-configuration/documentation) covers these features in detail. ## Community feedback welcome With version 0.1.0 now available, we're eager to see how the community integrates Swift Configuration into real-world projects. Your experience with different use cases, configuration patterns, and deployment scenarios will help shape the library's evolution. Please try integrating Swift Configuration into your applications, tools, and libraries, and share your feedback through GitHub issues, pull requests, or Swift Forums discussions. ### Stability note Since this is a pre-1.0 release, libraries that need API stability may want to wait for the 1.0 release, which we expect to ship in the next few months. However, we encourage experimentation and integration testing on development branches – your feedback ensures the 1.0 API meets your requirements. ## Links - GitHub repo: [https://github.com/apple/swift-configuration](https://github.com/apple/swift-configuration) - Documentation: [https://swiftpackageindex.com/apple/swift-configuration/documentation](https://swiftpackageindex.com/apple/swift-configuration/documentation) ---
**Author:** ![xtremekforever](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/xtremekforever/32/43018_2.png) [@xtremekforever](https://forums.swift.org/u/xtremekforever)\ **Post date:** [September 25, 2025, 6:49pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/2 "2025-09-25T18:49:20Z")
Okay now this is awesome. We spun up our own configuration reader “library” but maybe this could be a thing to look at! ---
**Author:** ![karenchu](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/karenchu/32/39557_2.png) [@karenchu](https://forums.swift.org/u/karenchu)\ **Post date:** [September 25, 2025, 6:49pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/3 "2025-09-25T18:49:30Z")
👀 If anyone’s headed to ServerSide.swift next week, check out Honza’s talk on Friday at 16:15 on Swift Configuration – [Schedule | ServerSide.swift Conference](https://www.serversideswift.info/schedule/) ! PRO TIP: if you still need a ticket, use “COMMUNITY15“ for 15% off 😉 ---
**Author:** ![Andreas.Bauer](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andreas.bauer/32/42960_2.png) [@Andreas.Bauer](https://forums.swift.org/u/Andreas.Bauer)\ **Post date:** [September 25, 2025, 7:04pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/4 "2025-09-25T19:04:01Z")
Awesome work 🎉 ---
**Author:** ![jeudesprits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jeudesprits/32/27705_2.png) [@jeudesprits](https://forums.swift.org/u/jeudesprits)\ **Post date:** [September 25, 2025, 8:12pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/5 "2025-09-25T20:12:17Z")
And yet the choice of the abbreviation **Config** instead of the full **Configuration** is unclear. In Swift, full names without abbreviations seem to be preferred; the package itself is called **swift-configuration,** and even the folders in the sources start with **Configuration**. It almost makes you want to write a typealias when importing this library. ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [September 25, 2025, 8:30pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/6 "2025-09-25T20:30:34Z")
“Config" is only ever used as a type prefix, never a standalone term. ---
**Author:** ![jeudesprits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jeudesprits/32/27705_2.png) [@jeudesprits](https://forums.swift.org/u/jeudesprits)\ **Post date:** [September 25, 2025, 8:32pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/7 "2025-09-25T20:32:54Z")
That’s exactly what worries me: choosing an abbreviation for the type prefix instead of using the full word. ---
**Author:** ![pavm035](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/pavm035/32/18274_2.png) [@pavm035](https://forums.swift.org/u/pavm035)\ **Post date:** [September 26, 2025, 12:19am UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/8 "2025-09-26T00:19:43Z")
Can we use this for ios applications? If so do you have any use case or some doc? ---
**Author:** ![inductor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/inductor/32/42387_2.png) [@inductor](https://forums.swift.org/u/inductor)\ **Post date:** [September 26, 2025, 1:41am UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/9 "2025-09-26T01:41:01Z")
Hi! Yes you can. This is just an initial release announcement but we will add more examples to cover difference use cases in the future. ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [September 26, 2025, 6:02am UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/10 "2025-09-26T06:02:29Z")
Yes, can be used in iOS apps. I filed an issue for us to add an example, but the idea is that you create a ConfigReader at the top level, eg in your SwiftUI.App struct and then pass it down to the views as a parameter. > ---
**Author:** ![mamouneyya](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mamouneyya/32/22085_2.png) [@mamouneyya](https://forums.swift.org/u/mamouneyya)\ **Post date:** [September 26, 2025, 11:59am UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/11 "2025-09-26T11:59:53Z")
Can you access this in a SwiftPM’s Package.swift? That would be incredibly useful! ---
**Author:** ![FranzBusch](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/franzbusch/32/19447_2.png) [@FranzBusch](https://forums.swift.org/u/FranzBusch)\ **Post date:** [September 26, 2025, 1:10pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/12 "2025-09-26T13:10:35Z")
You can't and in general dynamic configuration based on external sources should be avoided in `Package.swift` manifest files. The package manager and build system can't reason about what is driving the dynamic configuration of the package. Usage of env variables inside the package manifest can easily lead to caching problems. If you need more dynamism in the manifest prefer to use [package traits](https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/packagetraits/). ---
**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\ **Post date:** [September 26, 2025, 7:24pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/13 "2025-09-26T19:24:47Z")
Can this interoperate with Argument Parser for command line arguments? How do the two interact? ---
**Author:** ![jacubit](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jacubit/32/27365_2.png) [@jacubit](https://forums.swift.org/u/jacubit)\ **Post date:** [September 26, 2025, 7:51pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/14 "2025-09-26T19:51:05Z")
I'm really excited about this, fantastic work! 🎉 I'm eager to try out to implement a Vault/OpenbaoProvider with `swift-configuration` and `vault-courier`. ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [September 26, 2025, 9:39pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/15 "2025-09-26T21:39:56Z")
Awesome! When you do, we can link to the repo from Swift Configuration's README. I'm excited to see community providers pop up. ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [September 26, 2025, 9:49pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/16 "2025-09-26T21:49:03Z")
ConfigReader is appropriate when using multiple sources or you need to read configuration from libraries. If you _only_ need CLI arguments and are reading from an application/tool, I recommend using Swift Argument Parser - it's a better, more optimized experience for the CLI use case. @nnnnnnnn and I discussed ideas of how, with some additional APIs, Swift Argument Parser could actually power the CommandLineArgumentsProvider under the hood. We can still do that, the public API of CommandLineArgumentsProvider wouldn't be affected. So we can do this before or after 1.0. ---
**Author:** ![apayne](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/apayne/32/22519_2.png) [@apayne](https://forums.swift.org/u/apayne)\ **Post date:** [September 29, 2025, 9:39pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/17 "2025-09-29T21:39:39Z")
I too am excited about this! Any chance we could get the yaml provider moved to a separate repo for a future stable release? I like the idea of having minimal dependencies around the providers, especially for a non-SSWG or non-Apple dependency. ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [September 29, 2025, 9:54pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/18 "2025-09-29T21:54:24Z")
With package traits, you control which providers you get. The YAML provider is opt-in, so unless you explicitly enable it, you won't get it and the Yams dependency won't be pulled in. ---
**Author:** ![apayne](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/apayne/32/22519_2.png) [@apayne](https://forums.swift.org/u/apayne)\ **Post date:** [September 29, 2025, 9:57pm UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/19 "2025-09-29T21:57:44Z")
Oh very cool, I missed that detail. Thanks! ---
**Author:** ![Malien](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/malien/32/34270_2.png) [@Malien](https://forums.swift.org/u/Malien)\ **Post date:** [October 1, 2025, 7:33am UTC](https://forums.swift.org/t/introducing-swift-configuration/82368/20 "2025-10-01T07:33:56Z")
This is super exciting news! I love this development! I guess the stringly-keyed API is a lot more flexible. Although I’d really be interested in a typesafe reader variant. Instead of relying on documentation and manual enforcement to keep key names, key types, and their defaults consistent. Although that would probably need to employ a macro. * * * I have a small exploration on this subject here: > [Next page](https://forums.swift.org/t/introducing-swift-configuration/82368.md?page=2)