cd /news/developer-tools/swift-1-0-stable-apis-rust-1-95-lang… · home topics developer-tools article
[ARTICLE · art-33012] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=↑ positive

Swift 1.0 Stable APIs + Rust 1.95 Language Features

Swift's server ecosystem reached two 1.0 milestones with the release of Swift System Metrics, providing stable APIs for CPU, memory, and file descriptor monitoring. Rust 1.95 introduced new zeroed allocation APIs and iterator optimizations, while a new CLI tool called add-mcp solves MCP configuration fragmentation across multiple AI agents. Deno 2.7 stabilized the Temporal API and added native Windows ARM support.

read5 min views1 publishedJun 18, 2026

This week's releases are less about flashy new capabilities and more about the quieter, more valuable kind of progress: stable APIs that let you stop maintaining workarounds. Swift's server ecosystem crossed two 1.0 milestones simultaneously, Rust 1.95 landed language features that eliminate entire dependency categories, and a small CLI tool solved a genuinely annoying MCP configuration problem. Here's what's worth your attention.

Swift System Metrics gives you CPU usage, memory consumption, and file descriptor counts out of the box for any Swift service, wired into the backend-agnostic Swift Metrics API. That means it routes to Prometheus, OpenTelemetry, or whatever metrics sink you're already running—no vendor lock-in, no custom /proc

parsing.

Before this, Swift backend observability meant writing your own instrumentation layer or vendoring fragmented packages with no stability guarantees. The 1.0 tag changes that calculus: you get a stable, maintained API, a Grafana dashboard template included in the repo, and lifecycle integration via ServiceLifecycle so metrics collection starts and stops cleanly with your service.

Verdict: Ship now. Requires Swift 5.9+ and the Swift Metrics ecosystem. Drop it into any Swift backend and get production observability from first deploy. The Grafana template alone saves an hour of dashboard setup.

Temporal moves out of unstable in Deno 2.7, which means date arithmetic, timezone handling, and calendar operations that don't involve Date

hacks are now production-ready without flags. Native Windows ARM builds land as well, removing emulation overhead for that platform. Node.js compatibility gaps in worker threads, child_process

, and zlib

also close in this release, which matters if you're migrating existing Node projects.

The subprocess spawn APIs—Deno.spawn()

as a simpler alternative to Deno.Command()

—also appear in 2.7 but remain unstable. That's the one thing worth waiting on.

Verdict: Ship Temporal now, wait on spawn APIs. If you have any date/timezone logic in a Deno project, replace it with Temporal immediately—it's significantly cleaner and now carries a stability guarantee. Hold off on spawn()

until it stabilizes; Deno.Command() still works fine. Run deno upgrade

to get 2.7.

If you're running multiple AI agents—Claude Code, Cursor, VS Code with Copilot, Codex—and you've added even two or three MCP servers, you've already dealt with the configuration fragmentation problem. Each tool has its own config file format, its own location, its own schema. add-mcp is a single CLI that auto-detects which agents you have installed and writes the appropriate config for all of them in one pass.

The actual command is npx add-mcp

followed by an MCP server URL or npm package name. It supports 9 agents at v1. There's no daemon, no persistent process—it's a config file writer that knows where everyone keeps their configs.

Verdict: Adopt immediately if you manage MCPs across multiple tools. The only requirements are having a supported agent installed and knowing your MCP server's URL or package name. This is the kind of glue tooling that seems minor until you've spent 20 minutes hunting down why Claude Code picked up a server that Cursor didn't.

Rust's latest stable adds `Box::new_zeroed()`

, `Rc::new_zeroed()`

, and `Arc::new_zeroed()`

as first-class APIs, replacing the `vec![0; n]`

pattern or unsafe manual zeroing that previously handled this case. Iterator specialization for TrustedLen

also lands, letting Iterator::eq skip redundant work when the iterator length is statically known.

The more important change is a behavior fix: iter::Repeat::last() previously looped infinitely because Repeat

has no end. That silent hang is now a panic—breaking if you relied on the old behavior, but the old behavior was a correctness trap. If you hit this in production without realizing it, you now get a clear failure instead of a hung process.

Verdict: Ship now. These are additive stabilizations with no migration cost for the new APIs. The Repeat::last

change is technically breaking but fixes something that should never have worked. Update to latest stable Rust and grep your codebase for .last()

calls on Repeat

iterators if you have any doubt.

Two language features stabilize in Rust 1.95 that reduce real friction in day-to-day code. cfg_select!

is a standard library macro for compile-time configuration matching—it replaces the cfg-if

crate that most Rust projects have been pulling in for years to handle conditional compilation across platforms or feature flags. One fewer dependency, same functionality, now in stdlib. If-let guards extend match expressions to support if let

bindings inside guard position—match x { Some(v) if let Ok(n) = parse(v) => ... } is now valid syntax. This closes a real expressiveness gap where you'd previously need nested matches or awkward intermediate variables to combine pattern matching with fallible bindings.

Verdict: Ship both now. cfg_select!

is a direct drop-in for cfg-if —remove the crate dependency and update the macro call. If-let guards are opt-in syntax; nothing breaks, you adopt where it simplifies existing match arms. Both are stable, backward-compatible, and available on Rust 1.95.

Swift Configuration 1.0 gives you a single ConfigReader

abstraction that reads from environment variables, config files, command-line arguments, or any custom provider—with explicit precedence ordering between them. Libraries can accept a ConfigReader

without knowing or caring where the config comes from, which is the architectural property that matters here.

The practical additions on top of that abstraction are useful: hot-reload without refactoring read call sites, secret redaction for logging, and access logging to audit what your service actually reads at startup. The 40+ PRs merged since October give you a sense of how actively this was refined before the 1.0 tag.

Verdict: Ship now for server apps and CLI tools. Add the swift-configuration

package and refactor config access to go through ConfigReader . The upfront cost is the refactor; the payoff is never writing environment variable parsing boilerplate again and getting hot-reload essentially for free.

If this kind of technically grounded coverage of the tools actually shipping in production is useful to you, Dev Signal publishes it every week at thedevsignal.com. Worth subscribing if you'd rather spend your research time building.

── more in #developer-tools 4 stories · sorted by recency
── more on @swift 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/swift-1-0-stable-api…] indexed:0 read:5min 2026-06-18 ·