How I prove a from-scratch SwiftUI engine is correct by holding it against real SwiftUI in 125 differential tests, with the actual code, the harness, the firewall, and the floating-point floor that makes agreement mean identical
SwiftUI is the thin graph sitting above 40+ years of engineering. Measured against the real framework and read against Apple's own patent, it is a single demand-driven graph, and the least remarkable engine in the stack it rests on. Here is SwiftUI laid bare, with a hint of the far more interesting machines underneath.
Apple's new frameworks and sample code read like a brief, and Cupertino v1.4.0 puts the whole signal offline
How a pile of repeated corrections became the rulebook I load into every coding agent, and what writing it down taught me about my own code
Most validation code is one giant function that walks a tree and appends to an error array through a forest of if statements. OpenAPIKit showed me a better way, a validation is a small composable value, the description states the correct state, and every error already knows where it lives
Four of my Swift projects run right now on macOS, Linux, Windows, and inside the browser. A static site generator, a Markdown to PDF engine, a YAML parser, and a 2D vector graphics engine, all pure Swift, all with CI proving every platform on every push.
A pure-Swift Markdown to PDF engine compiled to WebAssembly, with a live in-browser playground
A first compiler-grounded check of whether OpenAPIDoctor can become a local-first browser tool.
OpenAPIKit's strict parser meets real-world specs. A typed diagnosis CLI with auto-repair, proven across 594 YAML files.
A Swift daemon that turns iMessage into a remote terminal for Claude Code
Elegant, Thread-Safe Authentication for OpenAPI Runtime
Building a Full OpenAPI Workflow on Top of the Extreme Packaging Architecture
Elegant, Structured Request Logging for OpenAPI-Driven Swift Servers
Example of Extreme Packaging in Swift
A Swift package for building and rendering CVs in multiple formats