Plenty of people talk about Swift's Sendable protocol as if it's just a neat compiler toggle. Slap : Sendable on your struct, silence the warnings, and get back to building features. But if you've spent any time inside a large codebase with strict concurrency turned on, you already know that Sendable compliance isn't a simple
The Clean Code Trap Every Swift developer knows the feeling. You crack open a fresh project, and something in you wants to build it right—like, really right. You remember a meetup where someone swore by VIPER, or maybe you’ve been reading about Redux-like unidirectional data flows and how they make state predictable. So you lay
By Yuki Tanaka Every iOS developer remembers the first time they heard about VIPER. Or Clean Swift. Or some new coordinator pattern. The promise was always the same: clean separation, testability, scalability. But after a decade of building apps — everything from tiny utilities to sprawling financial platforms — I’ve tripped over the same failure
Moving a big iOS or macOS codebase into Swift’s modern concurrency model is not a light switch you flip over a weekend. The jump from completion handlers, DispatchQueue chains, and Operation subclasses to async/await, tasks, and actors takes a plan. I’m Yuki Tanaka, and I’ve walked several teams through this. You need a real inventory
Moving a big existing codebase to Swift’s modern concurrency model isn’t a weekend hackathon project. It asks for planning, solid discipline, and a real feel for both the old and new ways of doing things. I’ve walked several teams through this migration—sometimes kicking and screaming—and while the payoffs are tangible (fewer data races, code that
Swift’s access control often gets the checkbox treatment during code review—slap private on something, move along, and forget about it. That habit throws away a lot of design clarity. I’m Yuki Tanaka, and I want to show you why Swift’s five access levels aren’t just syntax decoration. They determine how your modules talk to each
