Skip to content

Commit fd4c23e

Browse files
authored
[Blog] Swift Configuration 1.0 released (#1264)
1 parent 227ee03 commit fd4c23e

File tree

2 files changed

+107
-1
lines changed

2 files changed

+107
-1
lines changed

_data/authors.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -341,7 +341,7 @@ honzadvorsky:
341341
name: Honza Dvorsky
342342
343343
github: czechboy0
344-
about: "Honza Dvorsky is a member of a team working on developer tools and services as part of Apple’s Services Engineering division, and is a core developer on Swift OpenAPI Generator."
344+
about: "Honza Dvorsky works on foundational Swift server libraries at Apple, and is a maintainer of Swift OpenAPI Generator and Swift Configuration."
345345

346346
simonjbeaumont:
347347
name: Si Beaumont
Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
---
2+
layout: new-layouts/post
3+
published: true
4+
date: 2025-12-11 10:00:00
5+
title: "Swift Configuration 1.0 released"
6+
author: [honzadvorsky]
7+
category: "Developer Tools"
8+
---
9+
10+
Every application has configuration: in environment variables, configuration files, values from remote services, command-line flags, or repositories for stored secrets like API keys. But until now, Swift developers have had to wire up each source individually, with scattered parsing logic and application code that is tightly coupled to specific configuration providers.
11+
12+
[**Swift Configuration**](https://github.com/apple/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.
13+
14+
With the release of Swift Configuration 1.0, the library is production-ready to serve as a common API for reading configuration across the Swift ecosystem. Since the [initial release announcement](https://forums.swift.org/t/introducing-swift-configuration/82368) in October 2025 over **40 pull requests** have been merged, and its API stability provides a foundation to unlock community integrations.
15+
16+
## Why it exists
17+
18+
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:
19+
- **Read configuration the same way across your codebase** using a single configuration reader API that's usable from both applications and libraries.
20+
- **Quickly get started with a few lines of code** using simple built-in providers for environment variables, command-line arguments, JSON and YAML files. Later, when your configuration needs require a more sophisticated provider, swap it in easily, without refactoring your existing code.
21+
- **Build and share custom configuration providers** using a public ConfigProvider protocol that anyone can implement and share. This allows domain experts to create integrations with external systems like secret stores and feature flagging services.
22+
23+
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.
24+
25+
For a step-by-step evolution of an example service, from hardcoded values all the way to a flexible provider hierarchy, check out the [video of my talk](https://www.youtube.com/watch?v=I3lYW6OEyIs) from the [ServerSide.swift conference](https://www.serversideswift.info/) in London.
26+
27+
## Getting started
28+
29+
After adding a package dependency to your project, reading configuration values requires just a couple of lines of code. For example:
30+
31+
```swift
32+
import Configuration
33+
34+
let config = ConfigReader(provider: EnvironmentVariablesProvider())
35+
let timeout = config.int(forKey: "http.timeout", default: 60)
36+
```
37+
38+
However, Swift Configuration's core strength is its ability to combine _multiple_ configuration providers into a clear, predictable hierarchy, allowing you to establish sensible defaults while providing clean override mechanisms for different deployment scenarios.
39+
40+
For example, if you have default configuration in JSON:
41+
42+
```json
43+
{
44+
"http": {
45+
"timeout": 30
46+
}
47+
}
48+
```
49+
50+
And want to be able to provide an override using an environment variable:
51+
52+
```bash
53+
# Environment variables:
54+
HTTP_TIMEOUT=15
55+
```
56+
57+
Then what we have are two Swift Configuration "providers", and we can layer them:
58+
59+
```swift
60+
let config = ConfigReader(providers: [
61+
EnvironmentVariablesProvider(),
62+
try await FileProvider<JSONSnapshot>(filePath: "/etc/config.json")
63+
])
64+
let timeout = config.int(forKey: "http.timeout", default: 60)
65+
print(timeout) // 15
66+
```
67+
68+
Providers are checked in the order you specify: earlier providers override later ones, followed by your fallback defaults. This removes ambiguity about which configuration source is actually being used.
69+
70+
## Advanced capabilities
71+
72+
Beyond basic lookups, the library includes features for production environments:
73+
74+
* [Multiple access patterns](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration#Three-access-patterns) – choose between the synchronous, asynchronous, and watching patterns.
75+
* [Hot reloading](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration#Hot-reloading) – apply configuration updates without restarting your service.
76+
* [Namespacing and scoped readers](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration#Namespacing-and-scoped-readers) – organize configuration values through nesting.
77+
* [Access logging](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration#Debugging-and-troubleshooting) – easily debug configuration issues through detailed observability.
78+
* [Secret redaction](https://swiftpackageindex.com/apple/swift-configuration/documentation/configuration/handling-secrets-correctly) – avoid accidental exposure of sensitive configuration values.
79+
80+
The [documentation](https://swiftpackageindex.com/apple/swift-configuration/documentation) covers these features in detail.
81+
82+
## Community adoption
83+
84+
With 1.0, the API is now stable. Projects can depend on Swift Configuration knowing only backward-compatible changes are expected going forward. API stability allows libraries and tools to rely on Swift Configuration as a common integration point for reading configuration.
85+
86+
Prior to the 1.0 release, a number of ecosystem projects have begun experimenting with and adopting Swift Configuration. Here are some examples of efforts in progress:
87+
88+
* [**In libraries**](https://swiftpackageindex.com/apple/swift-configuration/main/documentation/configuration/configuring-libraries): Expose configuration entry points built on [`ConfigReader`](https://swiftpackageindex.com/apple/swift-configuration/main/documentation/configuration/configreader), making your library easier to integrate. Projects experimenting with Swift Configuration include:
89+
* [Vapor](https://github.com/vapor/vapor/pull/3403)
90+
* [Hummingbird](https://github.com/hummingbird-project/hummingbird/pull/743)
91+
* [Swift Temporal SDK](https://github.com/apple/swift-temporal-sdk)
92+
* [**In applications**](https://swiftpackageindex.com/apple/swift-configuration/main/documentation/configuration/configuring-applications): Instantiate a [`ConfigReader`](https://swiftpackageindex.com/apple/swift-configuration/main/documentation/configuration/configreader) and pass it to your dependencies. Use any combination of [`ConfigProvider`](https://swiftpackageindex.com/apple/swift-configuration/main/documentation/configuration/configprovider) types - JSON/YAML files, environment variables, or remote systems.
93+
* [Peekaboo](https://github.com/steipete/Peekaboo)
94+
* [swiftodon](https://github.com/JonPulfer/swiftodon)
95+
* [**By implementing custom providers**](https://swiftpackageindex.com/apple/swift-configuration/main/documentation/configuration/configprovider): Extend the ecosystem with new formats or external sources by implementing a [`ConfigProvider`](https://swiftpackageindex.com/apple/swift-configuration/main/documentation/configuration/configprovider). Examples of experimental providers:
96+
* [Swift Configuration TOML](https://github.com/finnvoor/swift-configuration-toml)
97+
* [Vault Courier](https://github.com/vault-courier/vault-courier)
98+
* [Swift Configuration AWS](https://github.com/SongShift/swift-configuration-aws)
99+
100+
## Next steps
101+
102+
With a stable foundation in place, libraries and applications can begin finalizing their own integrations and releasing API-stable versions built on Swift Configuration.
103+
104+
Try integrating Swift Configuration into your applications, tools, and libraries, check out the project's [documentation](https://swiftpackageindex.com/apple/swift-configuration/documentation), and continue sharing feedback from your real-world experience on the [GitHub repository](https://github.com/apple/swift-configuration) through issues, pull requests, or [Swift Forums](https://forums.swift.org/c/related-projects/swift-configuration/123) discussions.
105+
106+
Happy configuring! ⚙️

0 commit comments

Comments
 (0)