The idea that stayed with me

The book argues that complexity is the real enemy, and that good design hides complexity behind deep modules. I like that framing because it moves the conversation away from style debates and toward the question that matters: does this boundary make the next change easier?

Why it maps well to iOS

Mobile apps accumulate complexity quickly: networking, cache, analytics, experiments, navigation, accessibility, design states and lifecycle behavior all meet in the same screen. The book's advice is useful because shallow abstractions are everywhere in app code. A wrapper that only forwards calls is not a design improvement.

Where I would be careful

I would not read the book as a command to create large abstract systems upfront. In product engineering, the wrong abstraction can slow the team down. For me, the practical version is: let the feature teach you where complexity repeats, then create a boundary that removes a real burden.

How I apply it in Swift

When reviewing Swift code, I ask whether the caller needs to know too much. If a view model must understand retry policy, cache freshness, transport errors and analytics naming, the module is probably too shallow. A better API lets the caller express intent and keeps operational detail behind the boundary.

protocol SessionRefreshing {
    func refreshIfNeeded() async throws -> Session
}

My take

It is a strong book for engineers who already know how to code and want better judgment around design. The most valuable habit is not memorizing rules; it is learning to notice when code makes every future change negotiate with too many details.