So I found the answer after digging a bit... it turns out that functions that work with CoreData items should perform on the same thread as the one assigned to the CoreData context. To do this the view context has a perform method: the add, remove, duplicate and move functions must all do their stuff inside this. So, for example, the move method must be edited as such: func move(from oldIndex: IndexSet, to newIndex: Int) { // This guarantees that the edits are performed in the same thread as the CoreData context managedObjectContext.perform { var revisedItems: [Song] = songs.map({$0}) revisedItems.move(fromOffsets: oldIndex, toOffset: newIndex) for reverseIndex in stride(from: revisedItems.count-1, through: 0, by: -1) { revisedItems[reverseIndex].id = Int64(reverseIndex) } PersistenceController.shared.save() } } Probably the SetlistsView got to work on the same thread as CoreData and the SongsView on another, hence the reason for the different behaviour.

I see, this makes sense for the way it is implemented, too. i just thought it was strange at first as I was retrieving Apple Watch made routes and i expected that variable to be populated since GPS trackers usually hand out ellipsoidal, not geoid altitudes. Thank you for the library suggestion, very helpful!