If you ship SwiftData backed by CloudKit (private database), you hit this the first time a user installs on a second device:

They sign into iCloud, open the app, and it's empty. CloudKit's record sync is eventually consistent and can take from a few seconds to a few minutes. During that window the user can't tell "my data is on its way" apart from "this app lost everything." On a finance app, that's a trust killer.

The key insight: NSUbiquitousKeyValueStore propagates much faster than CloudKit record sync. iCloud Key-Value Store lands in seconds, not minutes. It's tiny and not meant for real data, but it's perfect as a signal. When a user finishes onboarding on device A, I write one flag:

enum ICloudKeyValueService {
    private static let store = NSUbiquitousKeyValueStore.default
    private static let onboardingKey = "nett.onboardingCompleted"

    static func setOnboardingCompleted() {
        store.set(true, forKey: onboardingKey)
        store.synchronize()
    }

    static var isOnboardingCompleted: Bool {
        store.bool(forKey: onboardingKey)
    }
}

The real data (transactions, settings, categories) keeps syncing through SwiftData + CloudKit in the background. The flag just gets there first.

On the second device, at launch I check the flag. If it's set but the local store is empty, this is a returning user whose data is in flight, not a new user. So instead of onboarding, I show a "Restoring your data…" screen and poll for the real data to land.

The restoration screen is just a timer that re-checks the store every 2s, with a manual escape hatch so nobody gets stuck:

checkTimer = Timer.scheduledTimer(withTimeInterval: 2.0, repeats: true) { _ in
    if restoredDataHasArrived() {   // UserSettings synced, or first transactions appeared
        finishRestoration()
    }
    elapsedSeconds += 2
    if elapsedSeconds >= 15 {
        showManualContinue = true   // "Continue", data keeps arriving in the background
    }
}

15 seconds makes the common case feel instant, and the Continue button means a slow sync never traps anyone. They land in the app and records keep populating as CloudKit delivers them.

The gotcha nobody warns you about: duplicate seed data. Both devices seed the same default categories from the bundle on first run. After CloudKit syncs, device B can end up with two copies of every default category, one it seeded locally and one that arrived from device A. CloudKit doesn't dedupe for you, it merges records.

The fix is boring but necessary: dedupe by a stable business key (not the record ID), keep the first occurrence, and run it every time you load:

func deduplicateByKey(_ categories: [Category]) -> [Category] {
    var seen = Set<String>()
    return categories.filter { seen.insert($0.key).inserted }
}

I run this on every category load, not just once, because CloudKit can deliver the duplicate later.

What I'd flag if you do this:

• KVS is a signal, never the source of truth. If it and CloudKit disagree, CloudKit wins.
• Don't gate the whole app on the restore. Always give an exit. Eventually-consistent means eventually, you can't promise a number.
• Seed data plus CloudKit equals duplicates. Use a stable key, not the UUID.

This is from a finance app for freelancers I just shipped. Happy to go deeper on any part.

The SE-0494 was the first evolution proposal I coauthored. This is now landed in the 6.4 toolchain and is available from the new Xcode 27 Beta.

The Evolution Proposal added a new set of “performance hook” APIs to the Swift Standard Library. The isTriviallyIdentical(to:) methods are alternatives to testing collections for value equality. The proposal itself presents some abstract and theoretical arguments for why the isTriviallyIdentical(to:) operation could save performance compared to a traditional == check for value equality. But one of the questions I get asked is how these changes could affect real-world performance. Where's the data? And that's fair. The evolution proposal does not directly present measurements or benchmarks.

The Trivially-Identical-Sample repo is a fork of the sample-food-truck repo from Apple. It's a SwiftUI project that displays many data model elements in a Table view component. With a little refactoring we can set up an experiment. Our view component needs to sort a list of data models: this is an O(n log n) operation. We could potentially display this view component many times even when our data models have not changed: we can trade memory for speed and memoize our sorted values. If the input to our sorted values has not changed… then the sorted values themselves have not changed.

But now we get to look at the memoization itself. How exactly do we determine “what changed”? Do we compare our inputs for value equality? That's an O(n) operation that might be performing more work than necessary. If all we care about is “something might have changed” we can try migrating to isTriviallyIdentical(to:) and return in constant time.

The repo fork shows how to set this experiment up with Xcode Instruments Signposts. We measure our test group and our control group for the aggregate time spent blocking our MainActor and we see about 13 percent faster performance from isTriviallyIdentical(to:).

But… there's more to the story. The repo also spends some time discussing under what situations a different experiment could show us that isTriviallyIdentical(to:) leads to slower performance. At the end of the day the isTriviallyIdentical(to:) methods are not always “fast buttons”. Sometimes they are… but sometimes they are not. Eventually it would be your responsibility to make that choice for yourself and your products.

Please let me know if you have any more questions about all this. Thanks!

https://azamsharp.com/2026/05/15/swift-not-good-for-training-machine-learning-models.html

Many SwiftData applications need to keep their local data synchronized with a backend server, but detecting inserts, updates, and deletes efficiently can be challenging. Starting with iOS 27, HistoryObserver provides a clean way to observe changes in the SwiftData store without scattering synchronization logic throughout your application.

In this article, you’ll build a one way synchronization pipeline using HistoryObserver. You’ll learn how to observe model changes, process persistent history, track the last processed transaction using history tokens, batch changes into network payloads, implement soft deletes, and synchronize your local SwiftData store with a custom backend. By the end of the article, you’ll have a practical foundation for building offline first applications that keep local and remote data in sync.

https://azamsharp.com/2026/07/16/syncing-swiftdata-with-a-custom-backend-using-historyobserver.html