A big problem is that the Identifiable Swift protocol on Core Data objects commandeers id as a property. Unfortunately, this means it uses the existing id attribute for our Core Data objects. That tends to be String?, because only items associated with a server have an ID, not local items. This unfortunately massively fowls the semantics of Identifiable for the sake of SwiftUI, where a String? is going to confuse things, especially if it can be nil.
We need to either:
Rename id, at least in Swift, maybe in Objective-C (no @objc(id)) and in the Core Data model (rename attribute, new model version)
Trickery to point Identifiable somewhere else and have Identifiable.id not mess with the existing id.
A big problem is that the
IdentifiableSwift protocol on Core Data objects commandeersidas a property. Unfortunately, this means it uses the existingidattribute for our Core Data objects. That tends to beString?, because only items associated with a server have an ID, not local items. This unfortunately massively fowls the semantics ofIdentifiablefor the sake of SwiftUI, where aString?is going to confuse things, especially if it can be nil.We need to either:
id, at least in Swift, maybe in Objective-C (no@objc(id)) and in the Core Data model (rename attribute, new model version)Identifiablesomewhere else and haveIdentifiable.idnot mess with the existingid.SBMusicItemandSBPlaylistare affected.