Selected work
Three problems from three codebases, and what each one needed from the person responsible for the architecture.
A CV lists roles. It does not show how someone thinks about a codebase they are responsible for. The three pieces of work below were chosen because each one is a different kind of architectural problem, each was shipped rather than prototyped, and each left something public that can be read.
A large retail app has several independent features that all want the screen at launch: a seasonal interstitial, a registration prompt, a background session request, a deep link to one specific product. Each was written by a different team and each is reasonable alone. A fixed priority list handles the easy case and none of the real ones, because the sequence has to survive interruption, cancellation, suspension and resumption, and new events arriving while it is already running.
The answer was a library that let those sequences be declared rather than coordinated by hand, so that safe cancellation and re-queuing became a property of the mechanism instead of something each feature team had to remember. It ran across three white-label iOS apps responsible for over £100M in monthly revenue. The open-source package is the same design rebuilt on Swift Concurrency, with an actor in place of OperationQueue and Combine.
Field software for fire safety and compliance teams, offline-first by necessity: technicians work in buildings with no signal and the app has to hold local edits until it can reconcile them. That rested on a legacy Objective-C API integration with a schema-driven design, mapped through a custom serialiser into a mirrored Core Data model, with licensing rules, permissions, feature flags and extensibility modules layered over it. The offline experience was only ever as good as the diffing and write-back underneath it.
Alongside that, Swift 6 adoption across the codebase, a CI pipeline covering build, test and release, and a move to a modular architecture for faster builds and parallel feature work. The constraint that shapes this kind of work is that none of it is allowed to stop feature delivery, which rules out the rewrite and leaves the harder, more incremental path.
Deep linking is where navigation architecture is tested, because the app is asked to arrive at an arbitrary screen in an arbitrary state, from outside, at a moment it did not choose. SwiftUI gives you the primitives and leaves the routing to you, which in practice means a new piece of hand-rolled plumbing for every screen that becomes a destination.
Iris routes incoming URLs into typed SwiftUI navigation instead. The case-study series works through the problem in public, including the parts that do not resolve cleanly, and a four-part internals track covers how the package itself is built.
Since January 2026 the same practice has run with AI agents doing a large share of the implementation, under a system that reviews the code, enforces the conventions and watches for drift. Audient is the clearest output: a macOS app on the Mac App Store that transcribes audio and video and searches what was said, built that way, with open-source models running on-device.
The findings are published as they happen, including the ones that did not work. The bottleneck turned out not to be typing, and not to be reviewing either. It is trust, and deciding whether to believe what comes back is the part that does not automate.