Move beyond copying MVVM diagrams.
Learn how state, dependencies, navigation,
data flow, business logic and testing fit
together in real SwiftUI applications.
The goal is not to force every app into the same pattern.
Good architecture makes it easier to understand
where state lives, where side effects happen,
how dependencies enter the system and how features
can change without turning the whole application
into a fragile web of references.
This hub focuses on those decisions — not just
acronyms and folder structures.
Strong architecture is less about complexity
and more about making responsibilities clear.
Keep presentation, business rules,
networking and persistence from becoming
tightly coupled.
Pass services into features intentionally
instead of hiding them behind globals
and hard-coded implementations.
Know who owns state, who can change it
and how changes move through the application.
Make features easier to test, replace
and extend without rewriting unrelated code.
MVVM, coordinators, repositories and dependency
injection are tools. The more important question
is what problem each tool is solving.
If you can explain the responsibility,
boundary and trade-off, the architecture
is easier to defend and evolve.
Practical guides for structuring SwiftUI
applications that are easier to reason about,
test and extend.
Use the sections on this page to understand
responsibilities, dependencies, state and
testing, then apply them inside a complete
SwiftUI application.
Learn the ideas in context instead of treating
every architecture pattern as a rule.
Complexity becomes expensive when it is added
without a clear responsibility or trade-off.
A large ViewModel can become just as difficult
to understand as a large View.
Global access makes dependencies convenient
but harder to reason about, replace and test.
Abstraction is useful when it protects a boundary,
not when every concrete type gets an interface by default.
Screens become harder to reuse when every feature
owns unrelated app-flow decisions.
Premature architecture can create ceremony
before the application has real complexity.
Build flexibility around likely change,
not every possible requirement the app may never have.
Start with responsibilities and state,
then add boundaries only when they solve
a real problem.
Decide what belongs in the view,
feature logic and data layer.
Know who creates state, who observes it
and who is allowed to mutate it.
Inject services so features are easier
to replace and test.
Keep app flow from becoming tightly coupled
to individual screens.
Keep business behaviour testable without
depending on the entire UI.
Use architecture where multiple features,
services and screens have to work together.
What responsibility should a ViewModel have in a SwiftUI app?
How do you decide where state should live?
What problem is dependency injection actually solving?
When is a repository useful, and when is it unnecessary abstraction?
How should navigation responsibilities be divided in a growing app?
What would need to change if the networking implementation were replaced?
How can you tell when an architecture is becoming more complicated than the problem?
I'm Kevin Reid, an iOS developer with more than
seven years of professional experience, including
work at Apple, J.P. Morgan and LexisNexis.
iOS Insights focuses on helping you understand
why code is structured a certain way, how the pieces
fit together and how to explain the trade-offs.
Move from architecture diagrams to real applications
where state, navigation, dependencies and data flow
all have to work together.
Structure Better iOS Apps.
Understand Why the Pieces Belong Where They Do.
Architecture Is About Responsibilities and Boundaries
Design Apps That Are Easier to Change and Explain
Separate the Right Things
Make Dependencies Explicit
Keep State Understandable
Design for Change
Start With Decisions, Not Patterns
iOS Architecture Articles
Build the Architecture Mental Model First
Architecture Through the Problems It Solves
More Layers Do Not Automatically Mean Better Architecture
Turning MVVM Into “Put Everything in the ViewModel”
Hiding Dependencies Behind Singletons
Adding Protocols Without a Reason
Letting Navigation Leak Everywhere
Splitting the App Into Too Many Layers Too Early
Designing for a Hypothetical Future
Learn Architecture in the Order It Becomes Useful
Architecture Questions You Should Be Able to Explain
Learn Architecture as a Decision-Making Skill
Structure a Complete iOS App You Can Explain
IOS ARCHITECTURE
Build
·
Understand
·
Explain
BEYOND PATTERN NAMES
CORE ARCHITECTURE SKILLS
A BETTER WAY TO THINK ABOUT ARCHITECTURE
01
What owns this state?
02
Which layer is responsible for this decision?
03
Where should this dependency enter the feature?
04
What changes if the data source changes?
05
Can this logic be tested without the UI?
LATEST GUIDES
START WITH THE PRINCIPLES
EXPLORE THE TOPICS
MVVM
Separate presentation state and UI behaviour
without turning ViewModels into dumping grounds.
Dependency Injection
Make services explicit, replaceable and easier to test.
State Ownership
Decide where state should live and who is allowed to change it.
Navigation
Keep app flow understandable as the number of screens grows.
Repositories & Services
Add boundaries where they provide real flexibility.
Feature Boundaries
Keep unrelated concerns from leaking across the application.
Testing
Make business logic testable without booting the whole app.
Modularity
Split code when it improves ownership and changeability — not just for folders.
COMMON ARCHITECTURE MISTAKES
A PRACTICAL LEARNING PATH
01
Understand responsibilities
THINK LIKE AN IOS ENGINEER
01
02
03
04
05
06
07
PROFESSIONAL IOS EXPERIENCE
7+ Years
·
Apple
·
J.P. Morgan
·
LexisNexis
READY TO APPLY IT?