When Apple dropped SwiftUI in 2019, the promise was hard to ignore: one declarative UI framework across iOS, macOS, watchOS, and tvOS. A lot of us jumped in early. Then reality hit. Missing APIs. Layout that didn’t behave. Performance gremlins. Plenty of teams shrugged and called it “not ready for production.” That take is stale.
SwiftUI landed in 2019 looking more like a prototyping toy than a framework you’d bet a business on. A few years later, that’s changed. It’s quietly running inside shipping apps everywhere—indie side projects and enterprise suites alike. But making it hum in production takes more than knowing your stacks from your spacers. You need opinions
The Subtle Art of Generic Thinking in Swift When you first stumble across generics in Swift, they feel like a neat shortcut. Write a function once, let it handle any type, and move on. But after building larger systems—libraries, frameworks, shared components—I’ve realized generics aren’t just a feature. They’re a design commitment. The choices you
Building Swift Packages That Stay Manageable Every time I kick off a new Swift project, the first real call I make is how to handle dependencies. Swift Package Manager has been the standard since Swift 3.0, and honestly, it pulls its weight across iOS apps, server-side stuff, command-line tools—pretty much everything. The snag is that
Swift protocol design on a development screen Every Swift developer hits a wall where a protocol gets too rigid. You start with a neat abstraction, then pile on requirements until conforming types crack. Yuki Tanaka spots this in code reviews all the time—protocols that demand way more than they actually need, twisting types into shapes
Swift protocols give us a clean way to describe what something should do without nailing down how it does it. That’s the promise, anyway. The reality can be messier. You start with a neat idea, then add one requirement, then another, and before you know it, the protocol is dictating storage details, threading assumptions, and
I still remember the first time I debugged a tangled mess of reference-type mutations in an iOS app. A simple screen update triggered changes across half a dozen view models, and tracing the source of truth felt like untangling a knot with one hand. That afternoon I rewrote the core model layer with structs, and
Writing Swift that runs is one thing. Writing Swift that screams is another. After years of building apps and fighting slow frame rates, I’ve come to see the compiler as a partner — one with a specific personality. Feed it code shaped a certain way, and it gives you tight, fast binaries. Ignore its preferences,
Getting Swift to run fast is less about clever algorithms and more about how you present your code to the compiler. The Swift compiler is hungry for predictable input — patterns it can recognize, tear apart, and rebuild into something lean. I’m Yuki Tanaka, and I’ve spent a career chasing performance at the OS layer.
Swift’s compiler can be a strong partner—if you feed it code that matches its optimization model. Getting to fast, lean machine instructions isn’t a puzzle to outsmart the optimizer. It’s about stripping away ambiguity and leaning into the guarantees the language already gives you. This piece walks through concrete, no-nonsense ways to help the Swift
