Peter's Path - Development

Swift at scale: building the TelemetryDeck analytics service

hello@peterspath.net (Peter) — Fri, 06 Mar 2026 17:00:00 +0000

The decision to go with Swift brought a lot of unexpected advantages for us. We come from a world of iOS in the frontend, Python, Node, or Ruby in the backend for server-based applications. Compared to these languages and frameworks, Swift is just as easy to use, and its compiled nature allows us to catch a lot of possible errors at compile time instead of runtime, making it ideal for a hardened, high-performance web service. </blockquote>
→ swift.org/blog/building-privacy-first-analytics-with-swift/</a>
TelemetryDeck is an analytics service for app developers. It focuses on privacy. It anonymises data and makes tracking easy.
The service handles data from millions of users each month. It helps thousands of app makers improve their products. The backend uses Swift. They chose Swift and the Vapor framework for the server. This choice brought benefits. Swift catches errors at compile time. It performs well with many threads. It handles high loads with low costs.
They store metadata in Postgres and analytics data in Apache Druid. They use Swift tools to connect to these. At first, they picked Swift because they liked it. It led to a fast, stable system. They can develop quickly. Swift's Codable makes JSON handling safe and simple. It rejects bad data right away. This improves security. Development feels good in Xcode. They run tests, debug, and use local databases. This helps new team members start fast.
Lessons include: Structure code with Swift packages. Databases often cause slowdowns, not Swift code. Use Vapor's built-in tools. Version APIs from the start. Set cache timeouts. Monitor errors yourself.

E2EE Backend part 3: Passkeys with the PRF Extension

hello@peterspath.net (Peter) — Sun, 01 Mar 2026 17:00:00 +0000

This is the third post in a series on building a truly privacy-preserving, end-to-end encrypted backend and client.

The goal of this part is user-friendly key management. We do that by using Passkeys with the PRF extension to create a deterministic encryption key.

Why This Matters</h3>
End-to-end encryption needs a strong key on the client. The server must never see it. Old solutions either stored keys on the server or asked users to remember extra passwords. Both are bad.
Passkeys solve authentication. They use Face ID or Touch ID and work across devices.
The PRF extension (Pseudo-Random Function) adds the missing piece. It lets the client create a deterministic encryption key from the Passkey itself. The server stores only a salt. The key stays on the device and never leaves the Secure Enclave.

How Passkeys Improve Security</h3>
Passkeys use public key cryptography. The device holds the private key. The server holds only the matching public key. No shared secret travels across the internet.
This design stops phishing. A Passkey is bound to one exact domain. The browser and operating system check the website address before they allow the Passkey to work. If you land on a fake site, even a perfect copy, the Passkey will not activate. The private key never leaves your device. An attacker cannot steal it by tricking you into typing something. Passkeys also resist reuse. Each Passkey works only for its registered service. Attackers cannot take a Passkey from one site and use it on another.
Passkeys remove other common risks too. There is no password to guess, reuse, or leak in a breach. Biometric checks such as Face ID or Touch ID add another layer. The device must confirm it is really you before it signs the challenge.
The Demo: Passkey Login + Instant Encryption</h3>
Two ready-to-run projects:

Backend: Vapor server with full WebAuthn support
Repo: github.com/peterspath/PasskeyBackend</a> </li>

Client: macOS SwiftUI app
Repo: github.com/peterspath/PasskeyDemo</a> </li> </ul>
The user enters an email and clicks one button. The app decides whether to register or log in. After Face ID or Touch ID, an encryption key is ready.
Key client code:
// Unified flow (auto register or login) await authManager.authenticate( email: email, presentationAnchor: window ) // After success if let prfOutput = credential.prf { self.encryptionKey = prfOutput.first // AES-256 key ready } // Use it let encrypted = try authManager.encryptString( "My secret data" ) let decrypted = try authManager.decryptToString( encrypted ) </code></pre> How the PRF Extension Works and Helps with Key Management</h3> Registration Client creates a 512-bit salt and sends it to the backend. Passkey is created with the PRF extension. Client receives the first key output. </li> Login Backend returns the stored salt. Client performs Passkey login with the same salt. Device returns the exact same key. </li> </ol> The PRF extension helps key management in three important ways: the key stays on the device. It never reaches the server.</li> the key is deterministic. The same Passkey plus the same salt always gives the exact same key. You do not store the key anywhere. You derive it fresh each login.</li> rotation is simple. The server can issue a new salt. The client then derives a new key. Old encrypted data can stay safe while new data uses the fresh key.</li> </ol> Better User Experience Through Simple Key Management</h3> This way of managing keys makes the user experience much better. Users do not need to remember extra passwords or handle key files. Encryption becomes automatic. After login the app has the key ready. People can encrypt and decrypt data with one click. Encryption of data must be usable. Otherwise people will not use it. The PRF extension and seamless flow fix this problem. Strong security now comes with simple, natural steps. In our demo the encryption section appears right after login. Users see it works instantly. This is how we make privacy features something people actually enjoy. Security Guarantees</h3> No passwords</li> No server-side keys</li> Keys never leave the device</li> Full zero-knowledge encryption</li> Phishing resistant</li> </ul>

E2EE Backend part 2: Private Information Retrieval hello@peterspath.net (Peter) — Mon, 23 Feb 2026 17:00:00 +0000 This is the second post in a series that explores a truly privacy-preserving, end-to-end encrypted backend and client. The goal of this part: a demo that can look up data in an encrypted database without telling the server what you search for. Why This Matters</h3> Homomorphic encryption lets servers compute on encrypted data. But often you need to fetch specific records first. Normal queries show the server your search terms. That breaks privacy. Private Information Retrieval (PIR) fixes this: The client asks for a value by keyword. The server sends back the match in encrypted form. But the server does not know which keyword you asked for. This pairs well with homomorphic encryption for full zero-knowledge operations. The Demo: Private Lookup of Contacts</h3> Here is a complete, runnable Swift example using Apple’s open-source HomomorphicEncryption and PrivateInformationRetrieval frameworks (KeywordPIR with MulPir). // Key parts let encryptionParams = try EncryptionParameters<Bfv<UInt32>>( from: .n_4096_logq_27_28_28_logt_5 ) let context = try Context( encryptionParameters: encryptionParams ) let secretKey = try context.generateSecretKey() // Setup database with 999 entries let (keyPam, pirPam, processed, _, _, evKey) = try setupKeywordPirDatabase( keywordValues: keywordDatabase ) // Client: Generate query let query = try generateQuery( keyword: "Bob12", keywordParameter: keyPam, pirParameter: pirPam, context: context, secretKey: secretKey ) // Server: Compute response let response = try computeResponse( query: query, keywordParameter: keyPam, pirParameter: pirPam, processed: processed, context: context, evaluationKey: evKey ) // Client: Decrypt let result = try decryptResponse( response: response, keyword: "Bob12", keywordParameter: keyPam, pirParameter: pirPam, context: context, secretKey: secretKey ) print("Result: \(result ?? "Not found")") </code></pre> Output Result for 'Bob12': Contact: +1-555-0589 | Email: bob12@example.com </code></pre> Repo: github.com/peterspath/HomomorphicLookup</a> Why These Parameters?</h3> Polynomial degree N = 4096 → good for demos; use 8192+ in production for more security</li> Plaintext modulus logt_5 → fits small values like contact info</li> Coefficient modulus [27, 28, 28] → controls noise for multiplications</li> Cuckoo hashing with 2 functions → maps keywords to indices privately The setup takes seconds. Each query processes in under 10 seconds on typical hardware.</li> </ul> How Lookup Works Under the Hood (KeywordPIR)</h3> KeywordPIR uses homomorphic encryption to hide the query. Client hashes the keyword and encrypts a query vector. Server multiplies this by the database matrix homomorphically. Result is the encrypted value at that index. Server sees only ciphertexts. It cannot tell the keyword. We use MulPir for efficient multi-query support and BFV for the encryption scheme. This handles missing keys by returning nil. Further Reading</h3> Apple's Swift Homomorphic Encryption</a></li> Apple's PIR Announcement</a></li> Apple's ML + HE Research</a></li> </ul> Announcing Swift System Metrics 1.0 hello@peterspath.net (Peter) — Fri, 20 Feb 2026 17:00:00 +0000 We are excited to announce the 1.0 release of Swift System Metrics, a Swift package that collects process-level system metrics like CPU utilization time and memory usage. Swift System Metrics runs on both Linux and macOS, providing a common API across platforms. </blockquote> → swift.org/blog/swift-system-metrics-1.0-released/</a> Apple released Swift System Metrics 1.0. It is a Swift package that collects system metrics from a process. It works on Linux and macOS with the same API. It tracks: CPU use time</li> Virtual and resident memory use</li> Open file descriptors and the maximum allowed</li> Process start time</li> </ul> You add it with a few lines of code. It sends data to Swift Metrics, which works with Prometheus and OpenTelemetry. It uses Swift Service Lifecycle for start-up and clean-up. Version 1.0 has a stable API. The package was once called swift-metrics-extras. It includes an example Grafana dashboard. E2EE Backend part 1: Homomorphic Encryption hello@peterspath.net (Peter) — Mon, 09 Feb 2026 17:00:00 +0000 This is the first post in a series exploring a truly privacy-preserving, end-to-end encrypted backend and client. The goal of this part: a demo that can calculate totals on encrypted user data without ever seeing the plaintext. Why This Matters</h3> Traditional E2EE protects data at rest and in transit, but the moment the server needs to do anything useful (e.g., compute total revenue, average score, or aggregate telemetry), it must decrypt. That defeats the purpose of zero-trust architecture. Homomorphic encryption changes the game: Encrypt(a) + Encrypt(b) = Encrypt(a + b)</code> The server adds (or multiplies) ciphertexts directly. The result decrypts to the correct plaintext on the client. The Demo: Homomorphic Sum of 72 Encrypted Numbers</h3> Here’s a complete, runnable Swift example using Apple’s excellent open-source HomomorphicEncryption framework (BFV scheme with UInt64</code>). // Key parts let params = try EncryptionParameters<Bfv<UInt64>>( from: .n_8192_logq_40_60_60_logt_26 ) let context = try Context(encryptionParameters: params) let secretKey = try context.generateSecretKey() // Encrypt each value separately // coefficient encoding // one value per ciphertext let (ciphertexts, plaintexts) = try encryptRandomNumbers( numberOfValues: 72, context: context, secretKey: secretKey ) let encryptedSum = try calculateEncryptedSum( ciphertexts: ciphertexts ) // Decrypt & verify let decrypted = try encryptedSum.decrypt( using: secretKey ) let result = try decrypted.decode( format: .coefficient )[0] print("Expected: \(plaintexts.reduce(0, +)) | Actual: \(result)") </code></pre> Output Expected sum: 41869 Result from homomorphic operation: 41869 Match: ✓ Success! </code></pre> Repo: github.com/peterspath/HomomorphicSum</a> Why These Parameters?</h3> Polynomial degree N = 8192 → supports up to ~8192 operations before noise becomes critical</li> Plaintext modulus t ≈ 2²⁶ → plenty of room for the sum of 72 numbers (each ≤999) without modular wrap-around</li> logq_40_60_60</code> gives sufficient ciphertext modulus bits to keep noise growth manageable during addition</li> </ul> Addition of ciphertexts is extremely cheap compared to multiplication (no relinearization needed). How Addition Works Under the Hood (BFV)</h3> In BFV, a ciphertext encrypts a plaintext polynomial in the ring R_t = Z_t[X]/(X^N + 1)</code>. When you add two ciphertexts: ct₁ + ct₂ = (c0₁ + c0₂, c1₁ + c1₂) mod q</code> Decrypting this recovers exactly m₁ + m₂ mod t</code>. Because we used coefficient encoding with one value per ciphertext, each ciphertext holds a single scalar. This is the simplest way to demonstrate correctness before moving to packed/SIMD encoding. Announcing the Windows Workgroup hello@peterspath.net (Peter) — Mon, 26 Jan 2026 17:00:00 +0000 The new Windows workgroup joins a growing list of Swift workgroups, including the Android workgroup, Build and Packaging workgroup, and Testing workgroup which were all added in the past year. Swift workgroups are community-led efforts, formally recognized by the project, to help move forward key areas. </blockquote> → swift.org/blog/announcing-windows-workgroup/</a> The Swift project has launched a Windows workgroup. Its main goal is to maintain and improve Swift support on Windows. This lets developers build Windows apps with Swift and its tools. The workgroup will: Keep the official Swift release reliable on Windows.</li> Suggest improvements to core packages like Foundation and Dispatch for better Windows fit.</li> Advise the Swift project on future Windows direction.</li> Share best practices for linking Swift to Windows APIs and shipping Swift libraries in Windows apps.</li> </ol> Improving the usability of C libraries in Swift hello@peterspath.net (Peter) — Thu, 22 Jan 2026 17:00:00 +0000 There are many interesting, useful, and fun C libraries in the software ecosystem. While one could go and rewrite these libraries in Swift, usually there is no need, because Swift provides direct interoperability with C. With a little setup, you can directly use existing C libraries from your Swift code. When you use a C library directly from Swift, it will look and feel similar to using it from C. That can be useful if you’re following sample code or a tutorial written in C, but it can also feel out of place. </blockquote> → swift.org/blog/improving-usability-of-c-libraries-in-swift/</a> Swift can call C libraries directly, but the result feels like C code: unsafe pointers, manual reference counting, and long function names. Use a module map and an API notes file (YAML) to fix this without touching the C header. This turns C enums into real Swift enums, objects into classes with automatic memory management, functions into methods with labels, bit flags into OptionSets, and more. Fucking Approachable Swift Concurrency hello@peterspath.net (Peter) — Tue, 30 Dec 2025 15:00:00 +0000 Swift Concurrency can feel like a lot of concepts: async/await</code>, Task</code>, actors, MainActor</code>, Sendable</code>, isolation domains. But there's really just one idea at the center of it all: isolation is inherited by default. With Approachable Concurrency</a> enabled, your app starts on MainActor</code>. That's your starting point. From there: Every function you call inherits that isolation</li> Every closure you create captures that isolation</li> Every Task { }</code> you spawn inherits that isolation</li> </ul> You don't have to annotate anything. You don't have to think about threads. Your code runs on MainActor</code>, and the isolation just propagates through your program automatically. When you need to break out of that inheritance, you do it explicitly: @concurrent</code> says "run this on a background thread"</li> actor</code> says "this type has its own isolation domain"</li> Task.detached { }</code> says "start fresh, inherit nothing"</li> </ul> And when you pass data between isolation domains, Swift checks that it's safe. That's what Sendable</code> is for: marking types that can safely cross boundaries. That's it. That's the whole model: Isolation propagates from MainActor</code> through your code</li> You opt out explicitly when you need background work or separate state</li> Sendable guards the boundaries when data crosses between domains</li> </ol> When the compiler complains, it's telling you one of these rules was violated. Trace the inheritance: where did the isolation come from? Where is the code trying to run? What data is crossing a boundary? The answer is usually obvious once you ask the right question. </blockquote> → fuckingapproachableswiftconcurrency.com</a> This is an excellent explanation of Swift Concurrency. It covers key ideas like async and await, actors, tasks, and structured ways to handle work in the background. The text makes hard topics clear and easy to follow. People who build apps with Swift will find it helpful. It is worth the time to read. Keep it as a bookmark for later use. Share it with others who code in Swift so they can learn too. Swift Configuration 1.0 released hello@peterspath.net (Peter) — Fri, 12 Dec 2025 16:00:00 +0000 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. </blockquote> → swift.org/blog/swift-configuration-1.0-released/</a> 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. Embedded Swift Improvements Coming in Swift 6.3 hello@peterspath.net (Peter) — Tue, 18 Nov 2025 17:00:00 +0000 Embedded Swift is a subset of Swift that’s designed for low resource usage, making it capable of running on constrained environments like microcontrollers. Using a special compilation mode, Embedded Swift produces significantly smaller binaries than regular Swift. While a subset of the full language, the vast majority of the Swift language works exactly the same in Embedded Swift. Additional information is described in the Embedded Swift vision document. Embedded Swift is evolving rapidly. This post describes a number of improvements made in the last few months, covering everything from improved C interoperability to better debugging and steps toward a complete linkage model for Embedded Swift. </blockquote> → swift.org/blog/embedded-swift-improvements-coming-in-swift-6.3</a> Swift 6.3 advances Embedded Swift, a subset for microcontrollers, with key improvements in libraries, diagnostics, C interoperability, debugging, and linking. Floating-point types now support description</code> and debugDescription</code> via a Swift implementation, while new EmbeddedRestrictions</code> warnings flag unavailable constructs like untyped throws. The Swift MMIO package 0.1.x adds bug fixes, documentation, and svd2swift</code> code generation from SVD files, with SVD2LLDB enhancing register inspection in LLDB. C interoperability gains @c</code> functions and enums for C-compatible declarations, better tolerance for signature mismatches, and @section</code>/@used</code> attributes for linker control. Debugging improves with value printing, core dump inspection of standard library types like Dictionary</code>, and reliable ARMv7m exception unwinding. Linking progresses with weak symbol definitions to avoid duplicates and @export</code> for controlling function visibility, moving toward a formalized Embedded Swift linkage model. These features, available in nightly toolchains, enhance safety, performance, and usability on constrained devices. Instrumenting Vapor 4 with Swift OTel hello@peterspath.net (Peter) — Wed, 12 Nov 2025 17:00:00 +0000 In complex systems it's often a good thing to be able to figure out why the system is behaving in a certain way without having to look into the code. When we want to be able to have a more high level view of what happens in the application without opening up the black box, we're looking for observability. Observability is the concept of collecting information about a system's execution and internal state, based on the data it generates. </blockquote> → blog.vapor.codes/posts/otel-integration</a> The tutorial guides developers through instrumenting a Vapor 4 application with OpenTelemetry for metrics collection, visualised in Grafana, emphasising observability’s role in understanding system behaviour without code inspection. Observability comprises logs for event details, metrics for instantaneous measurements like HTTP requests per second, and traces for data flow across components. The process uses Vapor’s built-in swift-metrics support to emit metrics, with swift-otel sending them to an OpenTelemetry Collector via OTLP, configured in configure.swift</code> with a OTelLifecycleHandler</code>. A Docker Compose setup runs the Collector, exporting to Prometheus, with Grafana for visualisation, using a provided dashboard JSON. Deployment on AWS ECS Fargate involves a sidecar Collector, AWS Managed Prometheus for storage, and Managed Grafana for dashboards, ensuring scalable monitoring. This setup enables real-time performance insights, leveraging Swift’s ecosystem for robust server-side observability. Introducing Temporal Swift SDK: Building durable and reliable workflows hello@peterspath.net (Peter) — Tue, 11 Nov 2025 17:00:00 +0000 Building reliable distributed systems requires handling failures gracefully, coordinating complex actions across multiple services, and ensuring long-running processes complete successfully. Rather than develop these resiliency features into every application or service you develop, an alternative approach is to use workflows. Workflows encapsulate your code so it runs durably and handles many common failure scenarios. Temporal is widely used for workflow orchestration across many languages. With the release of the SDK, Temporal is now available for Swift developers building production cloud services. </blockquote> → swift.org/blog/swift-temporal-sdk</a> The Temporal Swift SDK is now open source, bringing Temporal's durable workflow orchestration to Swift developers for reliable distributed systems. Temporal handles failures gracefully by resuming workflows automatically after crashes, using a separation of deterministic workflows (defining logic) and idempotent activities (performing work). The SDK leverages Swift’s async/await, structured concurrency, strong typing, and macros for a seamless, low-boilerplate experience. It enables building resilient applications like data pipelines and payment processing without custom retry or state management code. Developers can explore documentation, example projects, and the repository to implement workflows and activities efficiently. Announcing the Swift SDK for Android hello@peterspath.net (Peter) — Sat, 25 Oct 2025 15:00:00 +0000 The Android workgroup is an open group, free for anyone to join, that aims to expand Swift to Android. Today, we are pleased to announce nightly preview releases of the Swift SDK for Android. This milestone reflects months of effort by the Android workgroup, building on many years of grassroots community effort. With the SDK, developers can begin developing Android applications in Swift, opening new avenues for cross-platform development and accelerating innovation across the mobile ecosystem. </blockquote> → swift.org/blog/nightly-swift-sdk-for-android</a> Swift has grown over the last ten years to run on many platforms, from cloud services to Windows, browsers, and small devices. It lets developers share code between these platforms. The Android workgroup has now released preview toolchains that let you build Swift code for Android phones and tablets. You can download the Swift SDK for Android today, either with the Windows installer or on its own for Linux or macOS. A guide shows how to set up your first Swift app on Android. Example projects help you see full apps working. Over a quarter of packages on the Swift17 Package Index already build for Android. You can start moving your Swift packages to Android now. The swift-java project helps mix Swift and Java code safely. The workgroup is writing a plan for the future of Swift on Android. You can read it and give ideas. A project board shows what work is happening. Talk about your ideas or share apps on the Swift forums in the Android section. Introducing Swift Profile Recorder hello@peterspath.net (Peter) — Tue, 07 Oct 2025 15:00:00 +0000 Profiling enables you to understand where your Swift application spends its time, whether it’s computing, waiting for a lock acquisition, or blocked in file I/O. Profiling is achieved by collecting samples of activity, which provide insight into how it’s being used. Modern operating systems have tooling available to profile your applications or even the whole system. Examples include Apple’s Instruments, sample, and Linux’s perf. Furthermore, there are kernel systems like DTrace or eBPF that can be used to profile your applications. </blockquote> → swift.org/blog/swift-profile-recorder</a> Apple has open-sourced Swift Profile Recorder, an in-process sampling profiler for Swift services, enabling easy performance analysis without external tools or special privileges. It runs within the application process, supporting macOS and Linux, and integrates via a Swift package with a simple HTTP endpoint for collecting samples using curl</code>. Profiles output in industry-standard formats like Linux perf, pprof, and collapsed stacks, compatible with tools like Speedscope, Firefox Profiler, and FlameGraph for visualisation. Used at Apple for years to debug latency-sensitive services, it addresses challenges in sandboxed or restricted environments where tools like eBPF are unavailable. The package supports continuous profiling and can feed data to systems like Parca or Pyroscope, complementing swift-parca</code> for broader ecosystem use. Developers can add it to projects with minimal setup, start the server via environment variables, and collect samples for analysis, with community feedback welcomed on GitHub. This tool lowers barriers to profiling Swift server applications, enhancing performance insights across deployment environments. The Growth of the Swift Server Ecosystem hello@peterspath.net (Peter) — Wed, 24 Sep 2025 17:00:00 +0000 Nearly ten years ago, Swift was open sourced and an official runtime for Linux was released. I’ve been involved with Swift on the server since almost the very beginning, originally picking it up as a way to use a language I really enjoyed for backend development. In that time Swift has come a long way, with stability across platforms, a burgeoning ecosystem and many success stories. It’s matured into a great option for highly-scalable server applications, websites, and lambdas. In this post, I’ll cover how Swift: is seeing a number of success stories of running critical production workloads</li> has evolved to be a powerful language for server development</li> has a thriving ecosystem of frameworks and libraries</li> has a growing and passionate community - including a dedicated server conference coming up in October!</li> </ul> </blockquote> → swift.org/blog/swift-on-the-server-ecosystem/</a> This post reflects on a decade of Swift’s evolution as a robust server-side language since its open-sourcing and Linux runtime release. Highlighting success stories, it notes the Things app’s backend migration from Python to Swift, achieving a 4x performance boost and cost reduction, and Apple’s Password Monitoring Service, which saw a 40% throughput increase and 90% memory usage drop after switching from Java. Swift’s language advancements, including UTF-8 strings, Codable, keypaths, property wrappers, and Swift Concurrency with Sendable, have eliminated data race issues, as evidenced by Vapor’s crash-free record. The ecosystem thrives with frameworks like Vapor and Hummingbird, supported by the Swift Package Index and observability packages for logging, metrics, and tracing, ensuring compatibility with tools like Prometheus. Swift’s interoperability with C, C++, and Java, enhanced by cross-compilation SDKs and the Swiftly CLI, facilitates integration and migration. The growing community, driven by the Swift Server Workgroup, culminates in the annual ServerSide.swift conference, featuring talks on gRPC, concurrency, and success stories, with workshops for newcomers, fostering a vibrant future for Swift server development. Meet Vapor for VS Code hello@peterspath.net (Peter) — Wed, 24 Sep 2025 16:00:00 +0000 The extension offers a variety of features related to Vapor, Fluent, and Leaf. It supports all platforms supported by Vapor, including macOS and Linux. It can also be used with VS Code in the browser, but only for some Leaf-related features. </blockquote> → blog.vapor.codes/posts/vapor-for-vscode/</a> The "Vapor for VS Code" extension, developed over six months to enhance Vapor application development, supporting macOS, Linux, and limited Leaf features in browser-based VS Code. It enables project creation via the Welcome page or Command Palette’s Vapor: Create New Project... command, using Vapor’s default template or custom ones via URL, requiring the Vapor Toolbox for setup. The extension provides robust Leaf language support, including syntax highlighting for Leaf tags atop HTML, formatting for consistent indentation with Format Document or Format Selection, and Emmet support for quick HTML generation. It also offers IntelliSense snippets for Vapor endpoints, Fluent models, migrations, and Leaf constructs, accessible via typing or the Insert Snippet command. Swift 6.2 Released hello@peterspath.net (Peter) — Tue, 16 Sep 2025 17:00:00 +0000 We’re excited to announce Swift 6.2, a release aimed at making every Swift developer more productive, regardless of where or how you write code. From improved tooling and libraries to enhancements in concurrency and performance, Swift 6.2 delivers a broad set of features designed for real-world development at every layer of the software stack. </blockquote> → swift.org/blog/swift-6.2-released/</a> Swift 6.2 focuses on developer productivity with approachable concurrency features like single-threaded defaults on the main actor, intuitive async functions that run in the caller’s context, and the @concurrent</code> attribute for explicit parallelism. It advances safe systems programming with InlineArray</code> for stack-allocated fixed-size arrays, Span</code> for safe contiguous memory access, and opt-in strict memory safety to flag unsafe constructs. The VS Code Swift extension gains background indexing, LLDB debugging, a project panel, and live DocC previews for seamless editing. Swift 6.2 introduces Subprocess</code> for streamlined external process management and enhances Foundation’s NotificationCenter</code> with concrete notification types and async support. Swift Testing</code> adds exit testing, attachments for test results, and raw identifier names, while WebAssembly support enables client/server apps for browsers and runtimes. Migration tooling aids upcoming feature adoption, and the community is thanked for shaping these enhancements. Memory Integrity Enforcement hello@peterspath.net (Peter) — Mon, 15 Sep 2025 17:00:00 +0000 Memory Integrity Enforcement (MIE) is the culmination of an unprecedented design and engineering effort, spanning half a decade, that combines the unique strengths of Apple silicon hardware with our advanced operating system security to provide industry-first, always-on memory safety protection across our devices, without compromising our best-in-class device performance. We believe Memory Integrity Enforcement represents the most significant upgrade to memory safety in the history of consumer operating systems. </blockquote> → security.apple.com/blog/memory-integrity-enforcement/</a> Apple introduced Memory Integrity Enforcement (MIE) as a new memory safety feature for iPhone 17 and iPhone Air devices. MIE combines Apple silicon hardware with operating system security to block memory corruption attacks. It works always and protects key areas like the kernel without slowing down the device. Apple spent five years on this design. No common malware has ever attacked iPhone at the system level. Only rare spyware from state actors uses memory bugs. These bugs let attackers change data or take control. Apple fights this with safe tools like the Swift language. They also built secure memory allocators called kalloc_type</code> and xzone</code> malloc. In 2018, Apple added Pointer Authentication Codes (PAC) to chips. This stops attacks on code flow. Then Apple looked at Arm's Memory Tagging Extension (MTE). MTE tags memory to find errors. Apple worked with Arm to improve it into Enhanced Memory Tagging Extension (EMTE). EMTE checks tags in real time to block bad access. MIE uses secure allocators plus EMTE to stop buffer overflows and use-after-free bugs. It tags small memory blocks that allocators miss. MIE also guards non-tagged memory and fights attacks from wrong guesses in the chip. Apple put extra chip space and speed into MIE for strong protection. Tests show MIE stops real spyware chains early. Apple lets developers test MIE with Xcode's Enhanced Security setting. MIE makes attacks much harder and costlier. It changes memory safety for consumer devices forever. How we approach releases at Vapor hello@peterspath.net (Peter) — Fri, 15 Aug 2025 17:00:00 +0000 See how we approach releases in Vapor, so we can release quickly and often to save time and provide a better experience for users and contributors. </blockquote> → blog.vapor.codes/posts/how-we-do-vapor-releases/</a> The Vapor framework’s release process, outlined by Tim on August 14, 2025, treats each pull request (PR) as a potential release, streamlining development for its 30+ packages. PRs are labeled as no-release-needed</code>, semver-patch</code> (bug fixes), or semver-minor</code> (new APIs), reviewed by maintainers, and merged with automated releases via Penny, Vapor’s bot, which tags and announces releases on GitHub and Discord. This automation, initially met with skepticism, saves time, ensures quick bug detection by isolating changes to individual PRs, and benefits contributors by rapidly deploying their code. Despite robust testing, occasional bugs, like Swift 6.1 compilation issues, are quickly identified and reverted due to the granular release strategy. Beta testing is avoided for minor releases, as it delays feedback without significant user testing, aligning with Vapor’s continuous delivery ethos for faster, reliable updates. @isolated(any) hello@peterspath.net (Peter) — Tue, 05 Aug 2025 17:00:00 +0000 Ahh, @isolated(any). It’s an attribute of contradictions. You might see it a lot, but it’s ok to ignore it. You don’t need to use it, but I think it should be used more. It must always take an argument, but that argument cannot vary. Confusing? Definitely. But we’ll get to it all. </blockquote> → nshipster.com/isolated-any/</a> The Swift 6.0 release introduced the @isolated(any)</code> attribute to address the challenge of tracking function isolation in async contexts, enabling inspection of a function’s isolation (e.g., MainActor or nonisolated) via a special isolation</code> property of type (any Actor)?</code>. This attribute is crucial for APIs like Task</code> and TaskGroup</code>, ensuring predictable scheduling, particularly for MainActor-bound tasks, by preserving execution order. While it requires await</code> even for synchronous functions, its primary role is to provide scheduling information for API producers, not callers, who can largely ignore it. The any</code> argument anticipates future constraints, like specific actor types, enhancing flexibility without impacting source compatibility. Developers are encouraged to use @isolated(any)</code> when passing isolated functions to such APIs to leverage its scheduling benefits, though it’s not essential for most use cases. Uncertain hello@peterspath.net (Peter) — Sat, 26 Jul 2025 17:00:00 +0000 You know what’s wrong with people? They’re too sure of themselves. Better to be wrong and own it than be right with caveats. Hard to build a personal brand out of nuance these days. People are attracted to confidence, however misplaced. But can you blame them? (People, that is) Working in software, the most annoying part of reaching Senior level is having to say “it depends” all the time. Much more fun getting to say “let’s ship it and iterate” as Staff or “that won’t scale” as a Principal. </blockquote> → nshipster.com/uncertainty/</a> The provided text critiques the oversimplification in programming that ignores real-world uncertainties, particularly in handling noisy data like GPS coordinates, proposing a probabilistic approach using the Uncertain<T></code> type inspired by a 2014 research paper. Implemented in Swift, Uncertain<T></code> models uncertainty with probability distributions (e.g., Rayleigh for GPS, normal for sensor data) and uses Monte Carlo sampling with Sequential Probability Ratio Testing for efficient computation, allowing operations like comparisons to return probabilistic results (Uncertain<Bool></code>) rather than definitive Booleans. Examples include calculating running speed with uncertain time inputs and modelling slot machine payouts, with a companion project showcasing Swift Charts visualisations. The approach encourages acknowledging uncertainty in code to avoid misleading outcomes, advocating for gradual adoption in critical paths and performance profiling to manage computational costs. It emphasises Swift’s suitability for such abstractions due to its generics and type safety, urging developers to integrate probabilistic modelling to enhance reliability in applications like location-based services. Redesigned Swift.org is now live hello@peterspath.net (Peter) — Thu, 05 Jun 2025 17:00:00 +0000 Our goal with the site redesign has been to make Swift.org more approachable for newcomers to Swift, highlight the language’s technical strengths, and make it easy to get started. That led to a focus on the website’s appearance, improving the user experience, and emphasizing important features such as Swift’s multiplatform support. </blockquote> → swift.org/blog/redesigned-swift-org-is-now-live/</a> The Swift.org website has been redesigned by the website workgroup to be more approachable for newcomers, highlight Swift’s technical strengths, and emphasise its multi-platform support. The initial release includes updated home and install pages, plus new pages showcasing use cases like cloud services, command-line tools, and embedded software, with curated content, code examples, and resource links. The redesign features a fresh look with an orange splash and bird animation, reflecting Swift’s creativity. The workgroup plans to iteratively improve the site and invites community feedback through Swift Forums, GitHub issues, and contributions to the open-source swiftlang/swift-org-website repository. The Swift Information Architecture Project supports these changes, and thanks are extended to contributors for their efforts. Swift at Apple: Migrating the Password Monitoring service from Java hello@peterspath.net (Peter) — Tue, 03 Jun 2025 17:00:00 +0000 Swift is heavily used in production for building cloud services at Apple, with incredible results. Last year, the Password Monitoring service was rewritten in Swift, handling multiple billions of requests per day from devices all over the world. In comparison with the previous Java service, the updated backend delivers a 40% increase in performance, along with improved scalability, security, and availability. </blockquote> → swift.org/blog/swift-at-apple-migrating-the-password-monitoring-service-from-java/</a> The Password Monitoring service for Apple’s Passwords app, introduced in 2024, was rewritten from Java to Swift, achieving a 40% performance increase, better scalability, and lower resource usage. Previously built on Python 2 and Google App Engine, the Java-based service faced slow response times and high memory demands, prompting a full rewrite using Swift’s Vapor framework, leveraging its protocols, async/await, and safety features like optionals. The Swift version reduced the codebase by 85%, improved latency to under 1 ms for 99.9% of requests, and cut memory usage significantly, running efficiently on Kubernetes with 50% less capacity. Custom Swift packages for cryptography and middleware, combined with a robust ecosystem, supported the rewrite, demonstrating Swift’s suitability for high-performance, privacy-preserving cloud services. ICYMI: Memory Safety, Ecosystem Talks, and Java Interoperability at FOSDEM 2025 hello@peterspath.net (Peter) — Tue, 06 May 2025 16:00:00 +0000 The Swift community had a strong presence at FOSDEM 2025, the world’s largest independently run open source conference, held every year in Brussels, Belgium. FOSDEM highlighted a range of Swift-related talks related to memory safety, a broad ecosystem around Swift including using it to develop web services and embedded projects, and new areas of the project including Java interoperability. </blockquote> → swift.org/blog/memory-safety-ecosystem-talks-java-interoperability-fosdem-2025/</a> The Swift community showcased a robust presence at FOSDEM 2025, Europe's largest open-source conference in Brussels, with talks emphasising memory safety, a diverse ecosystem for web services and embedded projects, and Java interoperability. Doug Gregor's main track presentation on "Incremental Memory Safety in an Established Software Stack: Lessons Learned from Swift" highlighted Swift's memory-safe features and adoption lessons, with resources available in Swift's documentation. The inaugural Swift DevRoom, organised by Steven Van Impe, featured 12 talks including embedded applications like a ferrofluidic music visualiser, container image building, and distributed tracing in server-side Swift. Konrad Malawski's session in the Free Java DevRoom delved into Swift/Java bindings for high-performance integration without full rewrites. This event underscores Swift's growing role in open-source innovation, encouraging broader adoption of Swift 6's data-race safety features across the ecosystem. Swift 6.1 Released hello@peterspath.net (Peter) — Tue, 01 Apr 2025 17:00:00 +0000 This release includes new language enhancements to improve productivity, diagnostics improvements, package traits, and ongoing work to improve data-race safety usability and compile times. </blockquote> → swift.org/blog/swift-6.1-released/</a> Swift 6.1 introduces enhancements to improve productivity and data-race safety, extending the nonisolated keyword to types and extensions for better concurrency control and improving task group type inference. It adds the @objc @implementation attribute for porting Objective-C implementations to Swift, supports trailing commas in various syntactic contexts, and introduces package traits for conditional compilation in SwiftPM. Swift Testing now supports custom traits for setup/teardown logic, and Swift-DocC offers a more readable symbol link disambiguation method using parameter and return types. The release also enables background indexing for SwiftPM projects in SourceKit-LSP, enhancing editing features, and is available via Xcode 16.3 or the swiftly version manager for macOS and Linux.

Peter's Path - Development

Swift at scale: building the TelemetryDeck analytics service

E2EE Backend part 3: Passkeys with the PRF Extension

The Demo: Passkey Login + Instant Encryption</h3> Two ready-to-run projects:</p>

Security Guarantees</h3> No passwords</li> No server-side keys</li> Keys never leave the device</li> Full zero-knowledge encryption</li> Phishing resistant</li> </ul>

E2EE Backend part 2: Private Information Retrieval

Why These Parameters?</h3> Polynomial degree N = 4096</strong> → good for demos; use 8192+ in production for more security</li> Plaintext modulus logt_5</strong> → fits small values like contact info</li> Coefficient modulus [27, 28, 28]</strong> → controls noise for multiplications</li>

Further Reading</h3> Apple's Swift Homomorphic Encryption</a></li> Apple's PIR Announcement</a></li> Apple's ML + HE Research</a></li> </ul>

Announcing Swift System Metrics 1.0

E2EE Backend part 1: Homomorphic Encryption

Announcing the Windows Workgroup

Improving the usability of C libraries in Swift

Fucking Approachable Swift Concurrency

Swift Configuration 1.0 released

Embedded Swift Improvements Coming in Swift 6.3

Instrumenting Vapor 4 with Swift OTel

Introducing Temporal Swift SDK: Building durable and reliable workflows

Announcing the Swift SDK for Android

Introducing Swift Profile Recorder

The Growth of the Swift Server Ecosystem

Meet Vapor for VS Code

Swift 6.2 Released

Memory Integrity Enforcement

How we approach releases at Vapor

@isolated(any)

Uncertain

Redesigned Swift.org is now live

Swift at Apple: Migrating the Password Monitoring service from Java

ICYMI: Memory Safety, Ecosystem Talks, and Java Interoperability at FOSDEM 2025

Swift 6.1 Released

Security Guarantees</h3>

No passwords</li>
No server-side keys</li>
Keys never leave the device</li>
Full zero-knowledge encryption</li>
Phishing resistant</li> </ul>

Further Reading</h3>
Apple's Swift Homomorphic Encryption</a></li>
Apple's PIR Announcement</a></li>
Apple's ML + HE Research</a></li> </ul>