A changing SwiftUI list should keep selection, pending actions and saved state attached to the same logical item after sorting or filtering. Review that identity contract with deliberately similar records. An interface can look correct while an action unexpectedly affects the row that moved into the previous position.
Limelight appears in the SwiftUI product collection. Its official site describes movie watchlists, seen lists and a sorting interaction with undo. Those features suggest a useful evaluation scenario; they do not reveal the app's internal implementation.
Create records that challenge visual recognition
Use two titles with similar names, two editions of one title and a series alongside a film. Add different personal states such as saved, seen and rated. The sample should make it possible to identify the exact record without relying solely on its current row number.
Open one item, change the list order and return. Confirm that the detail view and any pending action still refer to the intended record. Repeat after a filter removes that item from the current list. Decide whether selection should clear, remain in a separate detail pane or return to a sensible parent view.
Define the scope of undo
An Undo action needs a precise meaning. Does it reverse the most recent classification, restore the item's former position or also restore a previous rating? Write the expected change in terms of fields and identity before testing the gesture.
Perform two different actions in sequence and undo the second. Then change the filter before attempting another reversal. Observe whether the application communicates which action is available and whether repeated activation causes an unintended duplicate.
These are acceptance checks for a workflow you control or are authorised to evaluate, not findings of defects in the listed product.
Separate view selection from saved preference
Apple's SwiftUI state documentation explains how views share owned state and cautions against using transient view state as persistent storage. A selected row, an open menu and a saved watchlist entry therefore deserve different lifecycle decisions.
Close and reopen the view, then relaunch the app where appropriate. Check that temporary controls reset sensibly while saved choices remain available according to the product's documented behaviour. A filter may reasonably persist as a preference, but that should be an intentional decision rather than an accidental consequence of where a variable lives.
Include synchronisation in the sample
For a product that offers cross-device sync, use an authorised test account and a small non-sensitive list. Change one record on one device, wait for the documented update behaviour and inspect the other. Preserve the observation time and connection state.
Try a conflicting edit only in a safe test context. The useful result is an understandable conflict policy, not an assumption that the last screen you opened must be correct. Record unavailable evidence as an open question rather than inventing a consistency guarantee.
Judge the complete interaction
Check that keyboard or assistive interactions can identify the same item and action as touch gestures. Long titles, increased text size and empty filtered results should leave the next available action clear.
Keep a short scenario record with starting items, action order and expected saved result. It can become a regression case when navigation or list rendering changes. For a related editing problem, the SwiftUI save and cancel guide explains how to separate a temporary form from its persistent record. Stable identity makes both kinds of interaction easier to reason about.
Snapkin