Most iOS apps do not rot because the code is bad. They rot because everything depends on everything, so no change is ever local. This intermediate course is about the structural decisions that keep an app changeable for years, and it teaches them the way they actually get used, on a real Swift codebase rather than on a diagram. You will start with SOLID applied concretely in Swift — what the single responsibility principle means when a type has three reasons to change, why the dependency inversion principle is about who owns the protocol rather than about having protocols at all, and how the dependency rule (source-code dependencies point inward, toward policy, never outward toward frameworks) is the one idea the whole architecture rests on. Then you will build a domain layer worth having: use cases that state what the app does in business language, entities and value types that make illegal states unrepresentable, and a pure core surrounded by an imperative shell that talks to the network, the database and the UI. The middle of the course is about boundaries, because that is where the design lives: MVC, MVVM and MVP treated as presentation details rather than architectures, and the patterns that let layers meet without leaking — Adapter, Decorator, Composite, Null Object, and a composition root where the graph is assembled once instead of scattered through the app. You will then split a monolith into Swift packages, choose between slicing horizontally by layer and vertically by feature, break the cyclic dependencies that appear the moment you try, and get build times and independent testability as the payoff. Finally, honesty: how to prove the dependency rule with tests rather than hope, how to refactor toward boundaries incrementally instead of rewriting, and how to recognise when this is genuinely over-engineering for the app in front of you. Assumes you already write Swift and have shipped something. By the end, you will be able to look at an app and see its seams.