Yes. Songs do not need to be in the library in order to play them. To ensure what is played does not appear at all to the user in the Music app, use the ApplicationMusicPlayer.

Yes use CatalogSearchRequest and pass in the search term as "(title)+(artist)"

its a simulator, not an emulator, so yes you definitely need to code and test this on device.

fwiw, I still can't see enough of your code to determine the issue, but… One reason that your code may not be seeing changes is that all three views are probably using the same view (main thread managed object) context, and you're saving changes on that same context, so there's no signaling that changes are being made. If you're going to invest time into Core Data, I highly recommend mastering NSFetchedResultsControllers and using background contexts to change data (adds, edits, deletes). I even wrote an article about it! Hope it helps. https://medium.com/@deeje/practical-ios-architecture-coredata-cloudkit-lists-and-editors-638c87d382d3

The fundamental challenge with using Codable with Core Data entities is that, when you instantiate an entity, it must be within a current managed object context (and its thread). I have seen lots of articles written by others who tackled the challenge. e.g. https://medium.com/swlh/core-data-using-codable-68660dfb5ce8 https://medium.com/@andrea.prearo/working-with-codable-and-core-data-83983e77198e https://www.hackingwithswift.com/forums/100-days-of-swiftui/day-61-my-solution-to-make-core-data-conform-to-codable/2434

The stuttering is likely the allocation of new TextViews. fwiw, SwiftUI is still rather new compared to UIKit. UIKit includes TableView and CollectionView, which are designed to display, and scroll thru, large lists and grids of lots of things very efficiently. It does this by re-using a limited pool of "cell" views. SwiftUI currently does not expose this. It does have LazyH and LazyV, which means that the lazy views aren't instantiated until they are displayed, but they are not re-used.

the documentation may be archived, but CloudKit itself is not deprecated.

You can re-enable web access to iCloud, but you'll have to sign into iCloud alongside using an existing iCloud-connected device to generate temporary access keys for your web session. Unclear to me so far if this extends to all/any CloudKit JS clients.

Have you pushed your schema (changes) from Development to Production in CloudKit?

Are you pushing your schema (changes) from Development to Production in CloudKit?

to determine if a user is signed into iCloud, use CKContainer.accountStatus { … } https://developer.apple.com/documentation/cloudkit/ckcontainer/1399180-accountstatuswithcompletionhandl Going further, record types in CloudKit can have various read and write permissions using security roles. CloudKit Security Roles are not well documented. See this thread for more https://stackoverflow.com/questions/31369181/how-do-the-cloudkit-security-roles-and-permissions-work

How important is user privacy? How important is security? How are you planning to pay for cloud services like FireBase or AppWrite? I choose CloudKit (and CoreData), time and again, because, user data is private and secure by default, the capability to share between users is built in on top of that privacy and security, and users pay for their own cloud storage, not me. In 2019, Apple introduced a sync system between the CloudKit and CoreData, called NSPersistentCloudKitContainer, which might server you well. If you want more control, check out CloudCore. And for Android, check out cloudkit_flutter. fwiw

check the creatorUserRecordID field of the CKRecord https://developer.apple.com/documentation/cloudkit/ckrecord/1462208-creatoruserrecordid

not sure of this, but what thread does Auth.auth().addStateDidChangeListener {} call into? Inside that, you're using the viewContext, which must used be on the main thread.

I suggest turning on all the debugging capabilities of Core Data, this article does a great job summarizing them https://useyourloaf.com/blog/debugging-core-data/