PricingLoginStart free
Swift Academy · Lesson

Local Packages and Feature Modules

Extracting features into local Swift packages for faster builds and isolation.

Lesson 2 of 413 steps

Local Packages and Feature Modules is a free Swift Academy lesson on CoddyKit. This is lesson 2 of 4. Any 3 lessons of this learning path are free to read in full — after that, CoddyKit PRO unlocks every lesson, plus hands-on practice with a built-in code editor and a 24/7 AI tutor. It is part of the Swift Academy learning path, and your progress syncs across the web and the CoddyKit app. The Swift Academy course includes 4 lessons in total.

Why Feature Modules?

Splitting an app into local packages enforces encapsulation, speeds up incremental builds, and enables team parallel development.

// Without modules: one giant target recompiles everything
// With modules: changes to FeatureA only recompile FeatureA

Creating a Local Package

Create a directory beside your Xcode project and run swift package init inside it.

mkdir Features/UserProfile
cd Features/UserProfile
swift package init --name UserProfile --type library

Adding to Xcode Project

Drag the local package directory into Xcode's project navigator. Xcode detects it as an SPM package automatically.

// In Xcode:
// File → Add Package Dependencies → Add Local...
// Select the package directory

Referencing a Local Package

In your app's Package.swift (or via Xcode), reference local packages with .package(path:).

.package(path: "../Features/UserProfile"),
// In the target:
.product(name: "UserProfile", package: "UserProfile")

Public API Surface

Only public and open declarations in the local package are accessible from the app. Use access control to define the module boundary.

// UserProfile/Sources/UserProfile/ProfileView.swift
public struct ProfileView: View {
  public init() {}
  public var body: some View { Text("Profile") }
}

Internal Implementation

All internal types are invisible outside the module, enforcing encapsulation automatically.

// Only visible within UserProfile module:
final class ProfileCache { ... }
struct ProfileMapper { ... }

Feature Module Structure

Each feature module owns its own Domain, Data, and Presentation layers internally.

// UserProfile/
// ├── Sources/UserProfile/
// │   ├── Domain/         (entities, use cases, protocols)
// │   ├── Data/           (repositories)
// │   └── Presentation/   (views, view models)
// └── Tests/UserProfileTests/

Shared Core Module

Extract cross-cutting concerns (networking, analytics, design system) into a shared module imported by feature modules.

// CoreNetwork package
// CoreDesign package
// Both imported by FeatureA and FeatureB

Dependency Graph

Feature modules should not depend on each other directly. Shared dependencies flow through a Core module to avoid coupling.

// GOOD:
// FeatureA → CoreNetwork
// FeatureB → CoreNetwork
// BAD:
// FeatureA → FeatureB  (tight coupling)

Build Time Benefits

With clean module boundaries, Xcode rebuilds only affected modules when source files change.

// Change in UserProfile → only UserProfile recompiles
// App target links the new binary → fast incremental build

Testing Feature Modules

Each feature module has its own test target, enabling parallel test execution and faster CI.

// Run all tests:
swift test --package-path Features/UserProfile
// Or let Xcode run them as part of the main test plan

Quick Check

What access level is required for declarations in a local Swift package to be usable from the app target?

Answer it in the interactive lesson

Lesson Recap

Create local feature packages with swift package init, reference them via .package(path:), and expose only public types. Extract shared utilities into a Core module. Feature modules should not depend on each other. Clean module boundaries drastically reduce incremental build times.

Free to start

Learn Swift with an AI tutor — free

Write and run real code in your browser, get instant help from a 24/7 AI tutor, and pick up where you left off on the web or in the app.

Courses
122
Lessons
409
Start learning freeView the full course

Frequently Asked Questions

Is the “Local Packages and Feature Modules” lesson free?

Yes — any 3 lessons of the Swift Academy learning path, including “Local Packages and Feature Modules”, are free to read in full here on the web. After that, CoddyKit PRO unlocks every lesson, plus interactive practice with a built-in code editor and a 24/7 AI tutor. The Swift Academy course includes 4 lessons in total.

What will I learn in “Local Packages and Feature Modules”?

Extracting features into local Swift packages for faster builds and isolation. You practise Swift Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Swift Academy?

No prior experience is required. Swift Academy on CoddyKit is structured for beginners through advanced learners, so you can start here or from the beginning and move at your own pace. This is lesson 2 of 4.

How long does the “Local Packages and Feature Modules” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Swift Academy lesson?

Yes. Every Swift Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Package.swift: Targets, Products and Dependencies
  2. Local Packages and Feature Modules
  3. Binary Targets and XCFrameworks
  4. Versioning, Resolving Conflicts and Swift Plugins
← Back to Swift Academy