iOS Architecture
Use Swift package targets and access control to enforce valuable boundaries without creating an expensive module graph.
Before you begin
Learning stage
A Swift package groups modules developed together. Each target is compiled as a module or test suite, and library products expose selected targets to clients. A local package can remain in the application repository while giving Xcode and the compiler a real dependency boundary.
Modules enforce visibility and dependency direction. Keep APIs small: internal remains the default inside a module, package access can share implementation across targets in the same package, and public exposes declarations to importing modules. A public API creates compatibility and maintenance obligations even when every module lives in one repository.
Design the graph so feature modules depend on stable lower-level capabilities or feature APIs rather than one another's implementation. Avoid cycles and umbrella modules that import everything. Measure incremental build behavior, test startup, preview ergonomics, resource handling, and developer navigation before and after modularization; more modules are not automatically faster or cleaner.
Learning stage
A local package can expose a small feature API while keeping implementation and tests in separate targets.
// swift-tools-version: 6.1
import PackageDescription
let package = Package(
name: "LearningFeatures",
platforms: [.iOS(.v17)],
products: [
.library(name: "CourseLibrary", targets: ["CourseLibrary"])
],
targets: [
.target(
name: "LearningModels"
),
.target(
name: "CourseLibrary",
dependencies: ["LearningModels"],
resources: [.process("Resources")]
),
.testTarget(
name: "CourseLibraryTests",
dependencies: ["CourseLibrary"]
)
]
)import UIKit
public struct CourseLibraryFeature {
private let repository: any CourseRepository
package init(repository: any CourseRepository) {
self.repository = repository
}
@MainActor
public func makeViewController() -> UIViewController {
CourseLibraryViewController(repository: repository)
}
}
package struct CourseLibraryDiagnostics {
// Shared by targets in this package, hidden from package clients.
}Learning stage
Connect the architectural concept to maintainable iOS features and real change scenarios.
Learning stage
Identify abstractions and dependencies that add coupling, ambiguity, or unnecessary ceremony.
Learning stage
Apply the design to a small feature and evaluate it through observable change scenarios.
Activity 1
Draw App, CourseLibrary, LessonPlayer, LearningModels, Networking, Persistence, and DesignSystem targets. Add arrows and remove any cycle.
Hint: Features should usually meet through stable domain or feature APIs, not import each other's internals.
Activity 2
Move a stable design-system or domain boundary into a local Swift package with a library product, focused target, resources if needed, and a test target.
Hint: Start with the smallest public API the app actually requires.
Learning stage
Answer each question before revealing the explanation.
QUESTION 1
A module or test suite
Targets are the package's build units and may depend on other targets or external products.
QUESTION 2
Every public declaration increases coupling, compatibility obligations, and the surface clients can depend on.
Internal and package access let implementation evolve without becoming part of the supported external contract.
Learning stage
Explain the decision, dependency direction, trade-offs, and evidence—not only the pattern name.
Short answer: When a real boundary benefits from dependency enforcement, ownership, reuse, focused tests, or measured build improvements.
I map the desired acyclic graph, extract a stable boundary into a local package, and expose the smallest useful product API. I keep most declarations internal or package-scoped, add target-specific tests and resources, and measure developer workflows. I avoid module count as a goal because graph complexity and public API maintenance carry real cost.
Possible follow-ups
Learning stage
Swift packages turn logical boundaries into compiler-enforced modules. They are most effective when the dependency graph is intentional and APIs remain small.