Skip to content
Prepare to Grow
Open navigation

iOS Architecture

Choosing an Architecture and Mini Project

Choose proportionate boundaries and integrate the complete module in a testable Learning Library feature.

Advanced7 min read2 guided activities

Before you begin

What you will understand

  • Select architecture from workflows, risks, team constraints, and expected change.
  • Recognize when Clean Architecture ideas help without copying every layer.
  • Build one complete vertical feature with explicit ownership.
  • Evaluate the result through change scenarios, tests, and an architecture decision record.
01

Learning stage

Concept Explanation

There is no universally best iOS architecture. Start with the feature's workflows, state, external effects, failure modes, team ownership, deployment target, and likely change. A small local screen may need a view and a dependency; a long-lived offline workflow may justify repositories, use cases, state machines, modules, and several test levels.

Clean Architecture contributes a useful direction: important policy should not depend on UI, storage, or network details. Apply that principle selectively. A use case should represent a meaningful product operation, not wrap every repository method. Boundaries should translate models when they protect independent change, not generate ceremonial layers and duplicate types automatically.

The final project is a Learning Library that lists courses, searches and filters, opens a detail, records completion offline, refreshes remotely, and restores navigation. Build it as vertical slices. Record why each boundary exists, demonstrate one UIKit or SwiftUI presentation, test the core workflows, and prove the design with changes rather than a diagram alone.

  • Architecture driver: workflow, risk, constraint, or expected change shaping the design.
  • Clean boundary: policy depends on abstractions rather than framework details.
  • Vertical slice: complete user value through UI, policy, and data.
  • Decision record: concise context, choice, alternatives, and consequences.
  • Fitness check: scenario used to verify architecture still serves its purpose.
  • Evolutionary design: structure adjusted as evidence and pressures change.
02

Learning stage

Syntax & Examples

The mini project uses a small dependency graph and explicit flow rather than applying every pattern to every file.

Learning Library architecturetext
LearningApp (composition root)
│
├── AppCoordinator
│   └── CourseLibraryFeature
│       ├── CourseLibraryView / ViewController
│       ├── CourseLibraryStore
│       │   ├── SearchCourses use case
│       │   └── CourseRepository protocol
│       └── Routes: course(id), lesson(courseID, lessonID)
│
├── LearningDomain
│   ├── Course, Lesson, Progress
│   └── CompleteLesson use case
│
└── LearningData
    ├── LiveCourseRepository
    ├── APICourseDataSource
    └── CourseCache

Dependency direction:
App → Feature → Domain
App → Data → Domain
Feature never imports concrete Data implementation.
The app assembles parallel feature and data implementations around stable domain capabilities, avoiding a dependency from policy toward infrastructure.
ADR-001-course-data.mdtext
# Decision: Offline-capable course repository

Context
- Learners must reopen downloaded courses without a connection.
- The API remains authoritative for course metadata.
- Completion created offline must synchronize later.

Decision
- CourseLibrary depends on a CourseRepository protocol in domain vocabulary.
- LiveCourseRepository coordinates API and local persistence.
- Completion is written locally first and queued for synchronization.

Consequences
- UI and use cases remain independent from storage technology.
- Conflict and freshness rules require explicit tests.
- The repository is more complex than direct API access, justified by offline behavior.
The decision record captures the pressure, chosen boundary, and cost so future developers can revisit it with evidence.
03

Learning stage

Real-World Usage

Connect the architectural concept to maintainable iOS features and real change scenarios.

  • Choose a simpler pattern for a read-only settings screen than for an offline editor.
  • Use an architecture decision record to explain a consequential boundary.
  • Demonstrate UIKit and SwiftUI replacement against the same domain capabilities.
  • Review the design when team size, build performance, data consistency, or product workflow changes.
04

Learning stage

Common Mistakes

Identify abstractions and dependencies that add coupling, ambiguity, or unnecessary ceremony.

  • Selecting architecture from popularity instead of feature pressure.
  • Implementing every Clean Architecture ring for a trivial flow.
  • Creating use cases that only rename repository methods.
  • Building horizontal layers for weeks before one vertical workflow works.
  • Treating the initial diagram as permanent and ignoring new evidence.
05

Learning stage

Practice Exercises

Apply the design to a small feature and evaluate it through observable change scenarios.

Activity 1

Build the Learning Library

Implement course list, search, detail, offline completion, refresh, and navigation restoration as vertical slices using only justified boundaries.

Hint: Begin with list → detail → complete, then add offline and restoration pressures one at a time.

Activity 2

Run an architecture fitness review

Test changes to the API, cache, presentation framework, completion rule, and feature ownership. Write an ADR for the most consequential decision and list one boundary you would remove or add.

Hint: A strong design explains both what changes and what deliberately stays untouched.

06

Learning stage

Knowledge Check

Answer each question before revealing the explanation.

QUESTION 1

What should primarily drive architecture selection?

  1. A.Feature workflows, risks, constraints, and likely change
  2. B.The most popular diagram
  3. C.The largest possible number of layers
  4. D.A framework name on a résumé
Reveal answer

Feature workflows, risks, constraints, and likely change

Architecture should solve concrete pressures at a proportionate cost.

QUESTION 2

What is the most useful Clean Architecture principle for an iOS feature?

Reveal answer

Important policy should not depend directly on UI, storage, networking, or other replaceable details.

Dependency direction protects decisions without requiring every project to reproduce the same number of layers.

07

Learning stage

Interview Preparation

Explain the decision, dependency direction, trade-offs, and evidence—not only the pattern name.

How would you choose and defend an architecture for a new iOS feature?

Short answer: I would map workflows, state, effects, risks, ownership, and expected change, then choose the smallest boundaries that address those pressures.

Explore the detailed answer

I start with one vertical slice, keep state ownership explicit, and isolate domain policy or external systems only where independent change or testing benefits justify it. I document major decisions and consequences, verify them through tests and change scenarios, and evolve the structure as evidence changes. I can explain why each abstraction exists and which simpler alternatives were rejected.

Possible follow-ups

  • • When would you remove a layer?
  • • How would your design change for offline-first behavior?
08

Learning stage

Key Takeaways

Architecture is a continuing design process. Choose proportionate boundaries, validate them through complete workflows and change scenarios, and retain only abstractions that protect real decisions.

  • Architecture follows pressures, not fashion.
  • Apply dependency direction selectively and deliberately.
  • Build vertical slices before broad infrastructure.
  • Document consequential choices and costs.
  • Use tests and change scenarios as architectural evidence.