Show Notes
In this episode, we break down Feature-Oriented Architecture on iOS and how it scales real-world apps by slicing them into modular, independent features. We’ll talk about how FOA complements patterns like MVVM, TCA, and Clean Architecture, so you get both vertical feature modules and clean horizontal layers for testability and maintainability, and we'll demonstrate the concept using an example To-Do app that manages to-do "task" objects. By the end, you’ll have a mental model you can apply directly to your own production codebases.
More from Real World Swift
The central question for this episode sounds simple but exposes one of SwiftUI’s deepest conceptual traps: When you write MyView(), when its body runs, when onAppear fires, when it becomes visible, and when its state is alive, are those all the same moment? They are not. A SwiftUI View is a value that describes part of an interface. SwiftUI can create that value repeatedly, evaluate its body repeatedly, preserve the corresponding identity and state across those evaluations, evaluate future content before it is visible, remove content from the screen without immediately destroying its persistent state, and cancel asynchronous work according to a lifecycle that is related to—but not identical to—visibility. Apple has described identity, lifetime, and dependencies as the three concepts SwiftUI uses to understand an interface, and Apple’s current View declaration remains a value-oriented protocol whose body provides the content and behavior of the view.
The goal of this episode is to replace one of the most common beginner mental models for SwiftUI... “Modifiers are properties I’m setting on a view.” ...with the much more useful model: A modifier changes the view description at the point where it is applied. The result becomes the input to whatever modifier comes next.
"State doesn't belong to the View struct. It belongs to an identity SwiftUI maintains in its view graph." That one sentence unlocks a tremendous amount of SwiftUI. This episode explains why.
We kick off our ten-part series on real-world SwiftUI, discussing why SwiftUI sometimes seems “magical” to UIKit developers, and why that behavior is actually fundamental to its design.
In Part 2, we look beyond Apple’s new visual language to the deeper philosophy guiding its future interfaces. We unpack Apple’s principles of purpose, agency, familiarity, flexibility, simplicity, responsibility, craft, and delight, then connect them to accessibility, brand identity, search, widgets, Live Activities, Siri, Spotlight, and AI-assisted prototyping in Xcode. The episode explores Apple’s shift from apps as isolated destinations to adaptable collections of content and capabilities that can appear throughout the system—while asking where human judgment, product identity, and thoughtful design fit into an increasingly intelligent platform.