ios – Why we have to use NSPersistentHistoryTransaction if NSFetchedResultController capable of replace UI accurately?

I nonetheless fail to know, what’s the downside NSPersistentHistoryTransaction is attempting to resolve, within the CoreDataCloudKitDemo WWDC 2019 “Utilizing Core Information with CloudKit”

https://github.com/software123inc/CoreDataCloudKitDemo/blob/grasp/CoreDataCloudKitDemo/DataProvider/CoreDataStack.swift#L161

I wish to see, what downside will happen, if processPersistentHistory is just not executed.

By making the processPersistentHistory empty, I attempt to do the next testing.

1. Run 2 simulators concurrently in the identical machine.
2. Add an merchandise to simulator A.
3. Since, there is no such thing as a means for simulator B to obtain push notification, I press the house button for simulator B.
4. In simulator B, I faucet on the app icon to launch the app once more.
5. In simulator B, I can observe controllerDidChangeContent is being known as. My guess is that, as a result of the backed SQLite is seamlessly up to date by CloudKit background activity, NSFetchedResultController will probably be notified the SQLite DB change, and subsequently replace the UI. Examine the “Obtain CloudKit Modifications into Core Information” of https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/syncing_a_core_data_store_with_cloudkit
6. In simulator B, on account of controllerDidChangeContent is being triggered accurately, I can observe the UI change carry out by NSFetchResultController with out concern.

Therefore, I’m not clear, on what downside processPersistentHistory is attempting to resolve within the demo code. Might I do know what sort of check case I can carry out, to know the issue solved by processPersistentHistory?

Primarily based on “Combine Retailer Modifications Related to the Present View”

https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/syncing_a_core_data_store_with_cloudkit

Your app receives distant change notifications when the native retailer
updates from CloudKit. Nevertheless, it’s pointless to replace your UI in
response to each notification, as a result of some adjustments is probably not
related to the present view.

Analyze the persistent historical past to find out whether or not the adjustments are
related to the present view earlier than consuming them within the consumer
interface. Examine the small print of every transaction, such because the entity
identify, its up to date properties, and the kind of change, to resolve
whether or not to behave.

For extra details about persistent historical past monitoring, see Consuming
Related Retailer Modifications.

This half is getting complicated. Our NSFetchedResultController is receiving related entity change occasion on account of SQLite, and subsequently capable of replace the UI appropriate. If this is so, why can we nonetheless want persistent historical past?