Test iOS List Differences on a Cloud Mac

When a list update combines deletions, insertions, and reordering, the hardest bugs to reproduce often come not from incorrect data, but from treating an old position as a new one. On an OSXFlow cloud Mac, you can first run a standalone Swift validation script—without launching a simulator—to check that differences round-trip correctly. Then connect the verified structural changes to your UI update layer.

Define the Two Snapshots the Difference Describes

Call the array of stable IDs before the update the old snapshot, and the array after the update the new snapshot. The call is new.difference(from: old), not the other way around. Removal offsets refer to the old snapshot; insertion offsets refer to the new snapshot. Do not interpret both within a single, continuously changing coordinate system.

For example, suppose the old list is [a,b,c] and the new list is [c,a,d]. If you insert at the new positions first and then remove at the old positions, you may delete an element you just inserted. When using the standard library to apply the difference, call old.applying(diff) rather than adjusting each offset yourself.

Establish three ground rules first: IDs must be unique within each snapshot; content changes must not change an ID; and the source snapshot must not be mutated in place while the difference is being computed in the background. Duplicate IDs do not necessarily cause the standard library to report an error, but they make UI row identity ambiguous.

A difference is not a patch you can apply to any list. It belongs to a specific pair of snapshots. Successful application does not mean the source data is at the correct version.

Verify Round Trips with an Executable Script

In the remote terminal, confirm that xcrun --find swift can locate the compiler. Save the following code as /tmp/list-diff-check.swift, then run xcrun swift /tmp/list-diff-check.swift. This example uses only the standard library: no project, dependency downloads, or signing configuration is required.

func hasUniqueIDs(_ values: [String]) -> Bool {
    Set(values).count == values.count
}

func verify(_ old: [String], _ new: [String]) {
    precondition(hasUniqueIDs(old))
    precondition(hasUniqueIDs(new))

    let raw = new.difference(from: old)
    let moved = raw.inferringMoves()

    precondition(old.applying(raw) == new)
    precondition(old.applying(moved) == new)
    precondition(new.applying(moved.inverse()) == old)
}

verify([], [])
verify([], ["a"])
verify(["a"], [])
verify(["a", "b", "c"], ["c", "a", "d"])
verify(["a", "b", "c"], ["c", "b", "a"])
precondition(!hasUniqueIDs(["a", "a"]))

On success, the script produces no output and exits with a zero status code. Any failed precondition terminates execution, causing the pipeline to fail. Do not use the -Ounchecked compilation mode, which removes these checks.

This verifies the raw difference, the difference with inferred moves, and the inverse transformation. They answer three distinct questions: “Can we reach the target?”, “Do the move associations preserve the transformation’s semantics?”, and “Can we return to the source state?” Checking only the element count will not catch misplaced elements; compare the complete arrays.

Exhaust Small Input Sets Instead of Testing Only Convenient Examples

Fixed examples help explain failures, but they can easily miss combinations such as deleting the first item while moving the last item into the middle. Four distinct IDs have 65 ordered subsets without repetition, giving 4225 pairwise transformations. That is small enough to test exhaustively, with no random seed required.

Append the following code to the same file and run it again:

func snapshots(
    prefix: [String],
    remaining: [String]
) -> [[String]] {
    var result = [prefix]
    for index in remaining.indices {
        var rest = remaining
        let next = rest.remove(at: index)
        result += snapshots(
            prefix: prefix + [next],
            remaining: rest
        )
    }
    return result
}

let cases = snapshots(
    prefix: [],
    remaining: ["a", "b", "c", "d"]
)
precondition(cases.count == 65)

for old in cases {
    for new in cases {
        verify(old, new)
    }
}

This covers empty lists, insertion-only updates, deletion-only updates, complete reversals, and mixed edits, but it does not prove correctness for arbitrary lengths. During integration, reduce production failures to minimal input pairs and add them to the fixed test cases. Measure execution time and memory use separately for large lists; do not treat the results here as a performance guarantee.

Move Associations Are Not UI Move Instructions

inferringMoves() adds associations between identifiable removals and insertions; it does not turn them into a new enum case. Pass the complete difference to applying(_:). Do not skip one side just because it has an association.

If your UI uses its own batch-update API, implement a separate adapter and check its requirements for source positions, destination positions, and when the data source must be updated. Passing the standard-library difference checks proves only that the array transformation is correct—not that an arbitrary sequence of UI calls is correct.

Handle Content Refreshes Separately

Suppose the row with ID a changes only its title. The ID array remains identical, so the difference is empty. You still need to compare the visible fields in the old and new models and collect the IDs that require a refresh. Do not generate a temporary new ID to trigger a refresh: that turns a content change into a deletion and insertion, losing selection or expansion state.

Reject Stale Differences with a Version Check

When background computation begins, capture both the old snapshot and a monotonically increasing version number. Once the result returns to the UI isolation domain, check that the current version still matches the captured version before updating the model and UI. There must be no asynchronous suspension between the check and the commit.

If the version has changed, discard the result and recompute from the current snapshot. Do not treat “the standard library returned a non-nil result” as a version check: duplicate values or coincidentally compatible positions may allow a stale difference to produce an array.

Before shipping, check four things: duplicate IDs are explicitly rejected; structural changes and content refreshes are handled separately; stale versions cannot be committed; and the UI adapter has at least one test covering a combination of deletion, movement, and insertion. Retain the input snapshots, version number, and failed assertion to diagnose issues; there is no need to log sensitive row content.

Frequently asked questions