Making Your Rork Max App Resilient to Dropped and Restored Connections: Offline Detection and Retry with NWPathMonitor

Translate the path's state into UX decisions

The value of NWPathMonitor lies in not being a mere online/offline boolean. Adding isExpensive and isConstrained lets you distinguish "connected, but we should hold back on large transfers." Mapped to UX, it looks like this.

What I came to appreciate is that respecting isConstrained improves how the app feels in reviews. People who enable Low Data Mode are sensitive to usage and dislike apps that reach for high-resolution images on their own. This small courtesy rarely shows up in metrics, but I did feel the edge come off the wording in low-star reviews.

Make the offline state visible in SwiftUI

The first step to preventing silent failure is not hiding state. When you're offline, show it. Rather than blocking the whole screen, a thin banner along the top stays out of the way.

import SwiftUI
 
struct OfflineBanner: View {
    @EnvironmentObject var monitor: NetworkMonitor
 
    var body: some View {
        if !monitor.isConnected {
            HStack(spacing: 8) {
                Image(systemName: "wifi.slash")
                Text("You're offline. Changes will send automatically once you reconnect.")
                    .font(.footnote)
            }
            .padding(.vertical, 8)
            .frame(maxWidth: .infinity)
            .background(.thinMaterial)
            .transition(.move(edge: .top).combined(with: .opacity))
        }
    }
}

Pass it near the root as an environmentObject and animate its appearance.

@main
struct MyApp: App {
    @StateObject private var monitor = NetworkMonitor.shared
 
    var body: some Scene {
        WindowGroup {
            ContentView()
                .environmentObject(monitor)
                .safeAreaInset(edge: .top) {
                    OfflineBanner()
                        .environmentObject(monitor)
                        .animation(.easeInOut, value: monitor.isConnected)
                }
        }
    }
}

The wording carries a lot of weight. Don't stop at "You're offline"; add "will send automatically once you reconnect" so the user doesn't abandon their action. Whether that sentence is there or not visibly changed my drop-off rate.

Flush failed sends the moment the connection returns

A banner alone is only half of it. You need machinery that actually keeps the promise of "sends automatically once you reconnect." Don't throw away sends made while offline — stack them in a queue and drain it, in order, the instant isConnected flips from false to true.

import Foundation
import Combine
 
actor SendQueue {
    struct Job: Codable, Identifiable {
        let id: UUID
        let endpoint: String
        let payload: Data
    }
 
    private var jobs: [Job] = []
    private var isFlushing = false
 
    func enqueue(_ job: Job) {
        jobs.append(job)
    }
 
    func flush(using send: @Sendable (Job) async throws -> Void) async {
        guard !isFlushing else { return }   // prevent double flush
        isFlushing = true
        defer { isFlushing = false }
 
        while let job = jobs.first {
            do {
                try await send(job)
                jobs.removeFirst()          // remove only what succeeded
            } catch {
                break                        // leave the rest and wait for the next recovery
            }
        }
    }
}

Tie the queue to connectivity changes. Observe NetworkMonitor's isConnected and call flush only on the false-to-true transition.

@MainActor
final class SyncCoordinator: ObservableObject {
    private let queue = SendQueue()
    private var cancellable: AnyCancellable?
    private var wasConnected = true
 
    init(monitor: NetworkMonitor) {
        cancellable = monitor.$isConnected
            .removeDuplicates()
            .sink { [weak self] connected in
                guard let self else { return }
                let recovered = connected && !self.wasConnected
                self.wasConnected = connected
                if recovered {
                    Task { await self.flush() }
                }
            }
    }
 
    func submit(endpoint: String, payload: Data) async {
        await queue.enqueue(.init(id: UUID(), endpoint: endpoint, payload: payload))
    }
 
    private func flush() async {
        await queue.flush { job in
            var request = URLRequest(url: URL(string: job.endpoint)!)
            request.httpMethod = "POST"
            request.httpBody = job.payload
            request.setValue(job.id.uuidString, forHTTPHeaderField: "Idempotency-Key")
            _ = try await URLSession.shared.data(for: request)
        }
    }
}

The thing that's easy to miss here is idempotency. Draining all at once on recovery can, over a flaky stretch of signal, deliver the same job twice. Putting the job's UUID in an Idempotency-Key header so the server can reject duplicates prevents double writes. I cover that pattern in depth in idempotent design for token refresh and retries, so take a look alongside this.

If you want the queue to survive app termination, persist jobs to a file or SwiftData and read it back on launch. For the broader offline picture, the thinking in offline-first persistence is a useful reference.

Pitfalls to close before shipping

Even when it runs, missing these will let it unravel in the field. Here they are in roughly the order I stumbled into them.

1. Touching the main thread inside pathUpdateHandler: the start(queue:) queue is a background one. Updating UI state directly there produces warnings and flicker. Always hop to the MainActor before applying.
2. Misreading .satisfied as "guaranteed to arrive": .satisfied means a path exists; it does not guarantee a successful request. On a captive portal (hotel Wi-Fi and the like) a path may exist while requests are blocked. Judge final success by the actual send.
3. The banner flickering on brief drops: when state jitters — stepping in and out of an elevator — the banner blinks restlessly. Waiting a few hundred milliseconds after it goes false before showing it settles things down.
4. Multiple flushes on recovery: add both removeDuplicates() and the double-flush guard flag. With only one, state jitter sends the same job in parallel.
5. The queue evaporating on termination: an in-memory queue is lost on quit. Once you've promised "I'll send it later," persistence is mandatory.

What changed after adopting it

After introducing this offline detection and resend queue, the "I saved it but it disappeared" inquiries — which had run to over a dozen a month — nearly stopped arriving. The number that mattered most was that previously failed sends now drain fully on recovery. Sends over unstable stretches used to be lost outright; since queuing them, I can recover almost all of them after reconnection.

The other surprise was a shift in the content of low-star reviews. I used to see complaints about "using data on its own" and "draining the battery," but after respecting isExpensive and isConstrained to hold back on large transfers, that kind of wording visibly declined. Choosing not to transmit, and doing so intelligently, turned out to be part of the experience too.

As a next step, move the queue's persistence onto SwiftData so unsent work survives even after the app is terminated. Only when the banner and the queue are both in place does the promise "will send automatically once you reconnect" become real. I hope this helps anyone wrestling with the same quiet loss of data.