{"id":50466,"date":"2025-12-16T15:39:35","date_gmt":"2025-12-16T20:39:35","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=50466"},"modified":"2025-12-18T11:31:11","modified_gmt":"2025-12-18T16:31:11","slug":"swift-configuration","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/12\/16\/swift-configuration\/","title":{"rendered":"Swift Configuration"},"content":{"rendered":"<p><a href=\"https:\/\/forums.swift.org\/t\/introducing-swift-configuration\/82368\">Honza Dvorsky<\/a>:<\/p>\n<blockquote cite=\"https:\/\/forums.swift.org\/t\/introducing-swift-configuration\/82368\">\n<p>Today, we&rsquo;re pleased to announce the initial release of <strong><a href=\"https:\/\/github.com\/apple\/swift-configuration\">Swift Configuration<\/a><\/strong>: a new library that provides a unified approach to reading configuration in your Swift applications.<\/p>\n<p>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:<\/p>\n<ul>\n<li>\n<p><strong>Read configuration the same way across your codebase<\/strong> using a single configuration reader API that&rsquo;s usable from both applications and libraries.<\/p>\n<\/li>\n<li>\n<p><strong>Quickly get started with a few lines of code<\/strong> using built-in providers for environment variables, command-line arguments, JSON and YAML files, and in-memory values.<\/p>\n<\/li>\n<li>\n<p><strong>Build and share custom configuration providers<\/strong> using a public <code>ConfigProvider<\/code> protocol that anyone can implement and share.<\/p><\/li><\/ul>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@helge\/115266424074068222\">Helge He&szlig;<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@helge\/115266424074068222\">\n<p>It actually makes me a little sad, because Foundation has a configuration management system already: <code>UserDefaults<\/code>. Is it really necessary to reinvent the wheel again and again?<\/p>\n<\/blockquote>\n\n<blockquote cite=\"https:\/\/mastodon.social\/@helge\/115266582136405207\">\n<p>My point is that instead of enhancing\/embracing the existing system (and defaults are really flexible, e.g. an environment domain is something that is conceptually supported), something completely new and separate is created. Yes, just like logging and metrics FWIW, desktop\/mobile and server are not really as different as some people tend to think either. &#x1F648;<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/www.swift.org\/blog\/swift-configuration-1.0-released\/\">Honza Dvorsky<\/a>:<\/p>\n<blockquote cite=\"https:\/\/www.swift.org\/blog\/swift-configuration-1.0-released\/\">\n<p><a href=\"https:\/\/github.com\/apple\/swift-configuration\"><strong>Swift Configuration<\/strong><\/a> brings a unified, type-safe approach to this problem for Swift applications and libraries. What makes this compelling isn&rsquo;t just that it reads configuration files: plenty of libraries do that. It&rsquo;s the clean abstraction that it introduces between <em>how<\/em> your code accesses configuration and <em>where<\/em> 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.<\/p>\n\n<p>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 <a href=\"https:\/\/forums.swift.org\/t\/introducing-swift-configuration\/82368\">initial release announcement<\/a> in October 2025 over <strong>40 pull requests<\/strong> have been merged, and its API stability provides a foundation to unlock community integrations.<\/p>\n<\/blockquote>\n\n<p>Update (2025-12-16): <a href=\"https:\/\/mastodon.social\/@lvalenta\/115731185694517006\">Lukas Valenta<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@lvalenta\/115731185694517006\">\n<p>At first, I asked myself why. Then I created a small Vapor application and I understood - the current ways to set environment are not great. Or more precisely, had not been. Looking forward to implementing it!<\/p>\n<\/blockquote>\n\n<p id=\"swift-configuration-update-2025-12-18\">Update (<a href=\"#swift-configuration-update-2025-12-18\">2025-12-18<\/a>): <a href=\"https:\/\/bsky.app\/profile\/czechboy0.dev\/post\/3ma5cfcfto225\">Honza Dvorsky<\/a>:<\/p>\n<blockquote cite=\"https:\/\/bsky.app\/profile\/czechboy0.dev\/post\/3ma5cfcfto225\">\n<p>The original motivation came from making Swift servers easier to operate, as switching between env vars, CLI flags, JSON\/YAML files, or even remote feature flagging services shouldn&rsquo;t require a large refactor. [&#8230;] Turns out, putting an abstraction layer between sources of config and the config reading API is pretty powerful as it lets libraries configure themselves from an opaque config container. Not just servers benefit from that.<\/p>\n<\/blockquote>","protected":false},"excerpt":{"rendered":"<p>Honza Dvorsky: Today, we&rsquo;re pleased to announce the initial release of 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, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"2025-12-16T20:39:39Z","apple_news_api_id":"54c1b601-d553-4cc6-a16e-851f9534f46e","apple_news_api_modified_at":"2025-12-18T16:31:14Z","apple_news_api_revision":"AAAAAAAAAAAAAAAAAAAAAQ==","apple_news_api_share_url":"https:\/\/apple.news\/AVMG2AdVTTMahboUflTT0bg","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[31,2741,30,2742,2868,74,71,901,1389],"class_list":["post-50466","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-ios","tag-ios-26","tag-mac","tag-macos-tahoe-26","tag-nsuserdefaults","tag-opensource","tag-programming","tag-swift-programming-language","tag-vapor"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/50466","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=50466"}],"version-history":[{"count":3,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/50466\/revisions"}],"predecessor-version":[{"id":50491,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/50466\/revisions\/50491"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=50466"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=50466"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=50466"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}