Project 2: Offline-First Task Manager

Welcome back, future iOS professionals! In our previous project, you built a foundational social app, touching on core UI and navigation. Now, we’re diving into a crucial aspect of modern app development: offline-first design.

In this chapter, we’ll embark on building an “Offline-First Task Manager” application. This project will teach you how to create an app that remains fully functional and responsive even when the user has no internet connection. We’ll leverage Apple’s modern frameworks, SwiftUI for the user interface and SwiftData for robust local data persistence, alongside the Network framework for connectivity monitoring.

By the end of this project, you’ll understand how to:

Design a data model for an offline-first application.
Implement local data persistence using SwiftData.
Build a SwiftUI interface that interacts seamlessly with your local data.
Monitor network connectivity and react to changes.
Lay the groundwork for future data synchronization strategies.

This builds directly on your SwiftUI and data persistence knowledge from previous chapters. Get ready to make your apps incredibly resilient and user-friendly!

Core Concepts: Embracing Offline-First

Imagine you’re on a subway, jotting down a critical task, and suddenly your internet drops. If your app relies solely on a live network connection, you’re out of luck. An offline-first approach solves this by prioritizing local data storage and functionality, ensuring a smooth user experience regardless of network availability.

What is Offline-First?

Offline-first is a development paradigm where your application assumes it will primarily operate without a network connection. All user interactions—creating, editing, deleting data—first happen against a local data store. When a network connection becomes available, the app then attempts to synchronize these local changes with a remote server.

Why is it important?

Reliability: Your app works anywhere, anytime.
Performance: Local data access is significantly faster than network requests, leading to a snappier UI.
User Experience: No frustrating “no internet connection” messages or lost work.
Reduced Server Load: Fewer constant requests, as data is fetched and stored locally.

Data Synchronization: The Challenge

While the core idea is simple, the real complexity in offline-first lies in data synchronization. When data exists both locally and remotely, you need a strategy to keep them consistent. This involves:

Conflict Resolution: What happens if a task is edited locally and remotely at the same time? Who wins?
Change Tracking: How do you know which local changes need to be sent to the server, and which server changes need to be pulled locally?
Eventual Consistency: Accepting that data might be temporarily out of sync, but will eventually converge.

For this project, we’ll focus on the foundations: robust local persistence and detecting connectivity. We’ll introduce a simple “sync status” to our local model as a placeholder, setting the stage for more advanced synchronization logic that you might implement with a backend in a real-world scenario.

Choosing a Persistence Layer: SwiftData

For modern iOS development (iOS 17+), SwiftData is Apple’s recommended framework for persisting structured data. Built on top of Core Data, it provides a more Swifty, intuitive API and integrates beautifully with SwiftUI. It handles all the complexities of saving and fetching data to and from a local database (SQLite) for you.

For our task manager, SwiftData is the perfect choice because:

It’s tightly integrated with the Apple ecosystem.
It’s performant for local data storage.
Its declarative nature aligns with SwiftUI development.

Connectivity Monitoring with Network Framework

To truly be “offline-first,” your app needs to know when it’s online or offline. Apple’s Network framework provides NWPathMonitor, a powerful tool to monitor network changes. It can tell you if a connection is available and even what type of connection it is (Wi-Fi, cellular, Ethernet). We’ll use this to update our UI and potentially trigger sync operations.

Offline-First Data Flow

Let’s visualize the basic offline-first data flow we’ll implement for our task manager:

flowchart TD User_Action["User Creates/Edits Task"] --> Local_Persistence["1. Store in SwiftData "] Local_Persistence --> UI_Update["2. Update UI Immediately"] Local_Persistence --> Mark_Dirty["3. Mark Task as 'Pending Sync'"] subgraph Connectivity_Monitoring["Network Connectivity Monitoring"] Start_Monitor[Start NWPathMonitor] --> Detect_Change{Network Status Changed?} Detect_Change -->|Online| Network_Online[Network Online] Detect_Change -->|Offline| Network_Offline[Network Offline] end Network_Online --> Check_Dirty[4. Check 'Pending Sync' Tasks] Check_Dirty -->|Tasks Found| Attempt_Sync["5. Attempt to Sync Server "] Attempt_Sync -->|Success| Clear_Dirty["6. Clear 'Pending Sync' Status"] Attempt_Sync -->|Failure| Keep_Dirty["7. Keep 'Pending Sync' Status"] Network_Offline --> Show_Offline_UI["8. Show Offline Indicator in UI"]

Diagram: Offline-First Data Flow Overview

As you can see, the user experience is prioritized by always writing to the local database first and updating the UI instantly. The network synchronization happens in the background when connectivity is available.

Step-by-Step Implementation

Let’s start building our Offline-First Task Manager!

Step 1: Project Setup

First, create a new SwiftUI project and ensure SwiftData is enabled.

Open Xcode 17.x (or later). As of February 2026, Xcode 17.x is the expected stable release that fully supports Swift 6 and modern iOS 17+ features.
Choose “Create a new Xcode project”.
Select the “iOS” tab, then “App”, and click “Next”.
Configure your project:
- Product Name: OfflineTaskManager
- Interface: SwiftUI
- Language: Swift
- Storage: Select SwiftData from the dropdown. This automatically sets up the basic model container for you.
Click “Next” and choose a location to save your project.

Xcode will create a basic SwiftUI app with a Persistence.swift file (or similar) and a default Item model, which we’ll replace.

Step 2: Define the Data Model with SwiftData

We need a Task model. This model will represent our tasks and include a property to track its synchronization status.

Delete the default Item.swift file (if Xcode created one) or its contents if it’s within ContentView.swift.
Create a new Swift file named Task.swift (File > New > File… > Swift File).

Add the following code to Task.swift:

// Task.swift
import Foundation
import SwiftData

// 1. We mark our class with @Model to tell SwiftData it's a persistable object.
@Model
final class Task: Identifiable { // Identifiable is useful for SwiftUI lists
    // 2. Properties that will be stored in the database.
    var id: UUID // Unique identifier for each task
    var title: String
    var isCompleted: Bool
    var createdAt: Date
    var lastModifiedAt: Date
    var syncStatus: SyncStatus // New property for offline-first!

    // 3. Initializer to create new Task instances.
    init(id: UUID = UUID(), title: String, isCompleted: Bool = false, createdAt: Date = Date(), lastModifiedAt: Date = Date(), syncStatus: SyncStatus = .notSynced) {
        self.id = id
        self.title = title
        self.isCompleted = isCompleted
        self.createdAt = createdAt
        self.lastModifiedAt = lastModifiedAt
        self.syncStatus = syncStatus
    }
}

// 4. Define an Enum for our sync status.
// This will help us track if a task needs to be sent to a remote server.
enum SyncStatus: Int, Codable, CaseIterable, Identifiable {
    case notSynced = 0 // Created or updated locally, needs to be sent to server
    case syncing = 1   // Currently being sent to server
    case synced = 2    // Successfully synchronized with server
    case deletedLocally = 3 // Marked for deletion on server
    case syncError = 4 // Failed to sync

    var id: Int { self.rawValue } // Conformance to Identifiable

    var description: String {
        switch self {
        case .notSynced: return "Pending Sync"
        case .syncing: return "Syncing..."
        case .synced: return "Synced"
        case .deletedLocally: return "Pending Deletion"
        case .syncError: return "Sync Error"
        }
    }
}

Explanation:

@Model: This macro is the magic sauce from SwiftData. It automatically makes our Task class persistable. SwiftData handles the underlying database schema and object lifecycle.
Identifiable: Required for SwiftUI lists to uniquely identify rows. We use UUID for id.
title, isCompleted, createdAt, lastModifiedAt: Standard properties for a task.
syncStatus: This is key for our offline-first approach. It’s an enum that tells us the current synchronization state of a task. We’ll use Int as the raw value, making it easy to store in SwiftData, and Codable for potential future serialization.
init: A convenient initializer to create new Task objects, providing default values for most properties.

Step 3: Set Up the Model Container in the App Entry Point

For SwiftData to work, we need to tell our app about our Task model and provide a modelContainer. Xcode usually sets this up automatically when you select SwiftData during project creation.

Open OfflineTaskManagerApp.swift.

Ensure your App struct looks like this:

// OfflineTaskManagerApp.swift
import SwiftUI
import SwiftData

@main
struct OfflineTaskManagerApp: App {
    // 1. This tells our app to create a model container for our Task model.
    // It will manage the database where our tasks are stored.
    var sharedModelContainer: ModelContainer = {
        let schema = Schema([
            Task.self, // Specify our Task model here
        ])
        let modelConfiguration = ModelConfiguration(schema: schema, is=(true))

        do {
            return try ModelContainer(for: schema, configurations: [modelConfiguration])
        } catch {
            // Handle the error gracefully in a real app.
            // For now, we'll just crash if the container can't be created.
            fatalError("Could not create ModelContainer: \(error)")
        }
    }()

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        // 2. Apply the modelContainer modifier to the WindowGroup.
        // This makes the model container available to all views within the window.
        .modelContainer(sharedModelContainer)
    }
}

Explanation:

sharedModelContainer: We create a ModelContainer instance. This is the entry point for SwiftData, telling it which models (Task.self in our case) it should manage.
.modelContainer(sharedModelContainer): This SwiftUI view modifier injects the ModelContainer into the environment, making it accessible to any child view that needs to interact with SwiftData.

Step 4: Build the Basic Task List UI

Now, let’s create the UI to display and manage our tasks. We’ll start with a simple list.

Open ContentView.swift.

Replace its content with the following:

// ContentView.swift
import SwiftUI
import SwiftData

struct ContentView: View {
    // 1. @Query fetches all Task objects from our SwiftData store.
    // It automatically updates the UI when tasks are added, deleted, or changed.
    @Query(sort: \Task.createdAt, order: .reverse) var tasks: [Task]
    // 2. @Environment property wrapper to access the SwiftData model context.
    // We'll use this to add, delete, and save tasks.
    @Environment(\.modelContext) var modelContext

    // 3. State to control the presentation of our "Add Task" sheet.
    @State private var showingAddTaskSheet = false

    var body: some View {
        NavigationView {
            List {
                // 4. Loop through our fetched tasks and display them.
                ForEach(tasks) { task in
                    TaskRow(task: task) // We'll create this custom row view next
                        .swipeActions {
                            // 5. Swipe action to delete a task.
                            Button(role: .destructive) {
                                deleteTask(task)
                            } label: {
                                Label("Delete", systemImage: "trash")
                            }
                        }
                }
            }
            .navigationTitle("My Tasks")
            .toolbar {
                // 6. Toolbar button to present the "Add Task" sheet.
                ToolbarItem(placement: .navigationBarTrailing) {
                    Button {
                        showingAddTaskSheet = true
                    } label: {
                        Label("Add Task", systemImage: "plus.circle.fill")
                    }
                }
            }
            // 7. Present the AddTaskView as a sheet when showingAddTaskSheet is true.
            .sheet(isPresented: $showingAddTaskSheet) {
                AddTaskView() // We'll create this view soon
            }
        }
    }

    // 8. Function to delete a task from the model context.
    private func deleteTask(_ task: Task) {
        modelContext.delete(task)
        // SwiftData automatically saves changes when the context is modified.
    }
}

// --- Preview ---
#Preview {
    ContentView()
        // 9. For previews, we need to provide a model container as well.
        // We create an in-memory container for testing purposes.
        .modelContainer(for: Task.self, inMemory: true)
}

Explanation:

@Query: This powerful property wrapper from SwiftData automatically fetches Task objects. We sort them by createdAt in descending order. Any changes to the underlying data store will automatically update this query and refresh the UI.
@Environment(\.modelContext): This grants us access to the ModelContext, which is SwiftData’s equivalent of a scratchpad for managing our model objects. We use it to perform operations like delete(task).
NavigationView: Provides the navigation bar and title.
List: Displays our tasks.
ForEach: Iterates over the tasks array.
TaskRow: A custom view we’ll create to display each task’s details.
swipeActions: Allows users to swipe left on a row to reveal a “Delete” button.
toolbar: Adds a “+” button to the navigation bar to add new tasks.
sheet(isPresented:): Presents AddTaskView modally.
deleteTask(_:): A helper function to delete a task using modelContext.delete().

Step 5: Create the TaskRow View

Now, let’s build the TaskRow to display each task’s details, including its completion status and, importantly, its syncStatus.

Create a new Swift file named TaskRow.swift.

Add the following code:

// TaskRow.swift
import SwiftUI
import SwiftData

struct TaskRow: View {
    // 1. Each row receives a Task object.
    @Bindable var task: Task // Use @Bindable for two-way binding to model properties
    @Environment(\.modelContext) var modelContext // To save changes

    var body: some View {
        HStack {
            // 2. Checkmark for completion status. Tapping it toggles completion.
            Button {
                task.isCompleted.toggle()
                task.lastModifiedAt = Date() // Update modification date
                // SwiftData automatically saves changes to @Bindable properties
            } label: {
                Image(systemName: task.isCompleted ? "checkmark.circle.fill" : "circle")
                    .font(.title2)
                    .foregroundStyle(task.isCompleted ? .green : .secondary)
            }
            .buttonStyle(.plain) // Prevent button from highlighting

            VStack(alignment: .leading) {
                // 3. Task title.
                Text(task.title)
                    .font(.headline)
                    .strikethrough(task.isCompleted, pattern: .solid, color: .gray)

                // 4. Display the sync status.
                Text("Status: \(task.syncStatus.description)")
                    .font(.caption)
                    .foregroundStyle(.secondary)
            }

            Spacer()
        }
        .padding(.vertical, 4)
    }
}

// --- Preview ---
#Preview {
    // For preview, we need a Task instance and a model container.
    let config = ModelConfiguration(isStoredInMemoryOnly: true)
    let container = try! ModelContainer(for: Task.self, configurations: config)
    let sampleTask = Task(title: "Buy groceries", syncStatus: .notSynced)
    container.mainContext.insert(sampleTask)

    return TaskRow(task: sampleTask)
        .modelContainer(container)
}

Explanation:

@Bindable var task: Task: This is a new property wrapper introduced with iOS 17/SwiftData. It allows for two-way binding directly to properties of a SwiftData model object without needing @State on individual properties. When task.isCompleted is toggled, SwiftData automatically tracks and saves this change to the database.
Button for completion: Toggles isCompleted and updates lastModifiedAt.
Text("Status: \(task.syncStatus.description)"): Clearly shows the synchronization status of each task.

Step 6: Create the AddTaskView

Now, let’s build the view where users can input a new task.

Create a new Swift file named AddTaskView.swift.

Add the following code:

// AddTaskView.swift
import SwiftUI
import SwiftData

struct AddTaskView: View {
    @Environment(\.modelContext) var modelContext
    @Environment(\.dismiss) var dismiss // To close the sheet

    @State private var newTaskTitle: String = ""

    var body: some View {
        NavigationView {
            Form {
                TextField("Enter new task title", text: $newTaskTitle)
            }
            .navigationTitle("Add New Task")
            .navigationBarTitleDisplayMode(.inline)
            .toolbar {
                ToolbarItem(placement: .navigationBarLeading) {
                    Button("Cancel") {
                        dismiss() // Close the sheet without adding
                    }
                }
                ToolbarItem(placement: .navigationBarTrailing) {
                    Button("Save") {
                        saveTask()
                        dismiss() // Close the sheet after saving
                    }
                    .disabled(newTaskTitle.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty)
                }
            }
        }
    }

    private func saveTask() {
        // 1. Create a new Task instance.
        // By default, its syncStatus will be .notSynced.
        let newTask = Task(title: newTaskTitle.trimmingCharacters(in: .whitespacesAndNewlines))
        // 2. Insert the new task into the model context.
        modelContext.insert(newTask)
        // SwiftData handles the saving to the database.
    }
}

// --- Preview ---
#Preview {
    AddTaskView()
        .modelContainer(for: Task.self, inMemory: true)
}

Explanation:

@Environment(\.dismiss): Allows us to programmatically close the sheet.
@State private var newTaskTitle: Holds the text input for the new task.
Form and TextField: Standard SwiftUI elements for data input.
saveTask(): Creates a Task object and inserts it into the modelContext. Since we created the Task with a default syncStatus of .notSynced, this new task is automatically marked as needing synchronization.
disabled(): The “Save” button is disabled if the text field is empty or contains only whitespace.

At this point, you should be able to run your app, add tasks, mark them complete, and delete them. All these operations are happening locally using SwiftData! Even if you kill the app and restart it, your tasks will persist. This is the first crucial step of offline-first.

Step 7: Monitor Network Connectivity

Now, let’s add the logic to detect when our app is online or offline.

Create a new Swift file named NetworkMonitor.swift. This will be an ObservableObject so our SwiftUI views can react to its changes.

// NetworkMonitor.swift
import Foundation
import Network // Import the Network framework

// 1. NetworkMonitor will be an ObservableObject, allowing SwiftUI views to subscribe to its changes.
class NetworkMonitor: ObservableObject {
    private let monitor = NWPathMonitor() // The core object for monitoring network paths.
    private let queue = DispatchQueue(label: "NetworkMonitor") // A dedicated queue for the monitor.

    // 2. Published property to notify views when connectivity changes.
    @Published var isConnected: Bool = false
    @Published var connectionType: ConnectionType = .unknown

    // 3. Enum to represent different connection types.
    enum ConnectionType {
        case wifi
        case cellular
        case ethernet
        case unknown
    }

    init() {
        // 4. Set the path update handler. This closure is called whenever the network path changes.
        monitor.pathUpdateHandler = { path in
            // 5. Update published properties on the main thread to ensure UI updates are safe.
            DispatchQueue.main.async {
                self.isConnected = path.status == .satisfied // .satisfied means a connection is available
                self.connectionType = self.getConnectionType(path)

                if self.isConnected {
                    print("Network Status: Online (\(self.connectionType))")
                    // In a real app, this is where you might trigger a sync operation.
                } else {
                    print("Network Status: Offline")
                }
            }
        }
        // 6. Start monitoring network changes.
        monitor.start(queue: queue)
    }

    // 7. Helper to determine the specific connection type.
    private func getConnectionType(_ path: NWPath) -> ConnectionType {
        if path.usesInterfaceType(.wifi) {
            return .wifi
        } else if path.usesInterfaceType(.cellular) {
            return .cellular
        } else if path.usesInterfaceType(.ethernet) {
            return .ethernet
        }
        return .unknown
    }

    // 8. Deinitializer to stop the monitor when the object is no longer needed.
    deinit {
        monitor.cancel()
    }
}

Explanation:

NWPathMonitor: The class from Apple’s Network framework that detects network changes.
DispatchQueue(label: "NetworkMonitor"): It’s good practice to run network monitoring on a dedicated background queue to avoid blocking the main thread.
@Published var isConnected: Bool: This property will hold the current network status. Because it’s @Published, any SwiftUI view observing NetworkMonitor will re-render when isConnected changes.
monitor.pathUpdateHandler: This closure is called by the NWPathMonitor whenever the network status changes.
path.status == .satisfied: This is the key condition to check if a network connection is currently available.
DispatchQueue.main.async: Crucial for updating @Published properties (and thus the UI) from a background thread.
monitor.start(queue: queue): Starts the monitoring process.
monitor.cancel(): Stops monitoring when the NetworkMonitor object is deallocated.

Step 8: Integrate Network Monitor into the App and UI

Now, let’s make our ContentView aware of the network status and display it.

Open OfflineTaskManagerApp.swift.

Add an instance of NetworkMonitor to your app’s environment:

// OfflineTaskManagerApp.swift (updated)
import SwiftUI
import SwiftData
import Network // Import Network framework here too

@main
struct OfflineTaskManagerApp: App {
    // ... (sharedModelContainer as before) ...

    // 1. Create an instance of our NetworkMonitor.
    @StateObject var networkMonitor = NetworkMonitor()

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .modelContainer(sharedModelContainer)
        // 2. Inject the NetworkMonitor into the environment.
        // Now, any child view can access it using @EnvironmentObject.
        .environmentObject(networkMonitor)
    }
}

Explanation:

@StateObject var networkMonitor = NetworkMonitor(): We create a single instance of NetworkMonitor at the app’s root. @StateObject ensures this instance lives for the lifetime of the OfflineTaskManagerApp and is not recreated.
.environmentObject(networkMonitor): This makes our networkMonitor instance available to all views in the view hierarchy.

Open ContentView.swift.

Modify ContentView to display the network status:

// ContentView.swift (updated)
import SwiftUI
import SwiftData
import Network // Required for NetworkMonitor

struct ContentView: View {
    @Query(sort: \Task.createdAt, order: .reverse) var tasks: [Task]
    @Environment(\.modelContext) var modelContext
    @State private var showingAddTaskSheet = false

    // 1. Access the NetworkMonitor from the environment.
    @EnvironmentObject var networkMonitor: NetworkMonitor

    var body: some View {
        NavigationView {
            VStack(spacing: 0) { // Use VStack to layer the banner
                // 2. Display an offline banner if not connected.
                if !networkMonitor.isConnected {
                    OfflineBanner() // Custom view for the banner
                }

                List {
                    ForEach(tasks) { task in
                        TaskRow(task: task)
                            .swipeActions {
                                Button(role: .destructive) {
                                    deleteTask(task)
                                } label: {
                                    Label("Delete", systemImage: "trash")
                                }
                            }
                    }
                }
            }
            .navigationTitle("My Tasks")
            .toolbar {
                ToolbarItem(placement: .navigationBarTrailing) {
                    Button {
                        showingAddTaskSheet = true
                    } label: {
                        Label("Add Task", systemImage: "plus.circle.fill")
                    }
                }
            }
            .sheet(isPresented: $showingAddTaskSheet) {
                AddTaskView()
            }
        }
    }

    private func deleteTask(_ task: Task) {
        modelContext.delete(task)
        // In a real offline-first app, you'd mark this task for deletion on the server.
        // For now, it's just locally deleted.
    }
}

// --- Custom Offline Banner View ---
struct OfflineBanner: View {
    var body: some View {
        HStack {
            Image(systemName: "wifi.slash")
            Text("You are offline. Changes will sync when connected.")
        }
        .font(.caption)
        .padding(.vertical, 8)
        .frame(maxWidth: .infinity)
        .background(Color.orange.opacity(0.8))
        .foregroundStyle(.white)
        .transition(.move(edge: .top)) // Nice animation for the banner
    }
}

// --- Preview ---
#Preview {
    ContentView()
        .modelContainer(for: Task.self, inMemory: true)
        // 3. Provide a dummy NetworkMonitor for the preview.
        .environmentObject(NetworkMonitor())
}

Explanation:

@EnvironmentObject var networkMonitor: NetworkMonitor: This property wrapper allows ContentView to receive the NetworkMonitor instance from the environment.
if !networkMonitor.isConnected: We conditionally show an OfflineBanner if isConnected is false.
OfflineBanner: A simple custom View to display a message to the user when they are offline. It includes a transition for a smooth appearance/disappearance.
VStack(spacing: 0): Used to stack the banner above the list without any gaps.
#Preview update: We must provide a NetworkMonitor instance for the preview to work, even if it’s just a default one.

Run your app now! Try turning off Wi-Fi and cellular data on your device or simulator. You should see the “You are offline” banner appear at the top. When you reconnect, it should disappear. This is a huge step towards a robust offline-first experience!

Step 9: Conceptual Sync Trigger

While a full sync implementation with a backend is beyond the scope of this chapter, we can simulate the trigger for synchronization when the network comes online.

Open NetworkMonitor.swift.

Modify the pathUpdateHandler to include a conceptual sync trigger:

// NetworkMonitor.swift (updated pathUpdateHandler)
// ... (imports and class definition as before) ...

    init() {
        monitor.pathUpdateHandler = { path in
            DispatchQueue.main.async {
                let wasConnected = self.isConnected
                self.isConnected = path.status == .satisfied
                self.connectionType = self.getConnectionType(path)

                if self.isConnected {
                    print("Network Status: Online (\(self.connectionType))")
                    // 1. If we just came online (wasConnected was false, now true)
                    // This is the ideal place to trigger a synchronization process.
                    if !wasConnected {
                        print("Network just came online. Triggering conceptual sync...")
                        // In a real app, you would call a service here:
                        // self.syncService.startSync()
                    }
                } else {
                    print("Network Status: Offline")
                }
            }
        }
        monitor.start(queue: queue)
    }

// ... (getConnectionType and deinit as before) ...

Explanation:

let wasConnected = self.isConnected: We capture the previous isConnected state.
if !wasConnected: This condition ensures our “conceptual sync” message (or real sync trigger) only fires once when the device transitions from offline to online, not every time the pathUpdateHandler is called while already online.

This lays the foundation for a real synchronization service. When you build a backend, you would inject a SyncService into NetworkMonitor or ContentView and call its startSync() method here, passing the modelContext to it.

Mini-Challenge: Task Priority

Let’s enhance our task manager by adding a priority level to each task.

Challenge:

Add an Int property named priority to the Task model, with a default value of 0.
Modify the AddTaskView to include a Picker that allows the user to select a priority (e.g., Low, Medium, High). You can map 0 to Low, 1 to Medium, 2 to High.
Display the priority in the TaskRow (e.g., using a small text label or an icon).

Hint:

For the Picker, you’ll need a @State variable in AddTaskView to bind to the selected priority value.
You might want to define a small helper enum for Priority (e.g., enum Priority: Int, CaseIterable, Identifiable, Comparable) within your Task file to make the Picker and display logic cleaner. Remember to make it Comparable if you want to sort by it later!
Update Task’s initializer to accept the new priority.

What to observe/learn:

How to extend a SwiftData model.
Integrating new data points into SwiftUI forms (Picker).
Updating existing views (TaskRow) to display new model properties.

Common Pitfalls & Troubleshooting

“No modelContainer found in environment” error:
- Issue: You forgot to add .modelContainer(sharedModelContainer) to your WindowGroup in OfflineTaskManagerApp.swift, or you didn’t add .modelContainer(for: Task.self, inMemory: true) to your #Preview provider.
- Fix: Ensure the modelContainer modifier is applied at the appropriate level.
UI not updating after Task changes:
- Issue: You might be observing a Task object that isn’t wrapped correctly.
- Fix: Ensure TaskRow receives its Task object as @Bindable var task: Task. For lists, @Query handles updates automatically. If you’re passing a Task to another view for editing, make sure that view also uses @Bindable if it’s directly modifying properties, or passes a binding to the property if using @Binding.
NWPathMonitor not working or not updating:
- Issue: The Network framework requires a dedicated background queue. If you forget monitor.start(queue: queue) or don’t use DispatchQueue.main.async for @Published updates, you might see issues.
- Fix: Double-check that monitor.start(queue: queue) is called in init() and that all @Published updates happen on the main queue. Also, ensure your NetworkMonitor instance is created as an @StateObject and passed as an @EnvironmentObject to ensure it lives for the app’s duration.
SyncStatus enum not storing correctly:
- Issue: If you initially defined SyncStatus without Int raw values or Codable, SwiftData might have trouble persisting it.
- Fix: Ensure your SyncStatus enum conforms to Int, Codable. If you change the enum definition after running the app, you might need to delete the app from your simulator/device to clear the old database schema, as SwiftData might not automatically migrate enum changes perfectly without explicit migration plans (an advanced topic).

Summary

Congratulations! You’ve just built the foundations of an offline-first task manager. This project has equipped you with critical skills for creating robust and user-friendly iOS applications:

SwiftData Mastery: You’ve learned to define, persist, fetch, update, and delete structured data locally using Apple’s modern persistence framework.
Offline-First Principles: You understand the importance of local data storage for reliability and performance.
Network Connectivity: You can now monitor network status using the Network framework and react to changes in your UI.
Seamless UI with SwiftUI: You integrated data persistence and network monitoring into a responsive SwiftUI interface.

This offline-first approach is invaluable for any app that deals with user-generated content or needs to be reliable in varying network conditions. In future advanced topics, we’ll explore how to build out the full synchronization logic with a backend.

Next up, we’ll dive deeper into more complex application architecture patterns, preparing you to build even larger and more maintainable projects!

References

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.

Project 2: Offline-First Task Manager

Table of Contents

Core Concepts: Embracing Offline-First

What is Offline-First?

Data Synchronization: The Challenge

Choosing a Persistence Layer: SwiftData

Connectivity Monitoring with Network Framework

Offline-First Data Flow

Step-by-Step Implementation

Step 1: Project Setup

Step 2: Define the Data Model with SwiftData

Step 3: Set Up the Model Container in the App Entry Point

Step 4: Build the Basic Task List UI

Step 5: Create the TaskRow View

Step 6: Create the AddTaskView

Step 7: Monitor Network Connectivity

Step 8: Integrate Network Monitor into the App and UI

Step 9: Conceptual Sync Trigger

Mini-Challenge: Task Priority

Common Pitfalls & Troubleshooting

Summary

References