It seems that this issue is resolved in Xcode 13 beta - https://bugs.swift.org/browse/SR-14715

Thanks for your feedback, I believe it works well for small rows of data. But, what about large number of rows? Isn't this solution will fire fault to ALL rows of data, which can take up a lot of device memory, if there is large number of rows in CoreData? I really do hope Apple provides some sort of "official" example on how to use FRC with Diffable Data Source, to achieve update/ insert/ delete/ reorder. This will save us countless of hour, from having to try-n-error to make basic thing works. Thanks.

I think I will give a pass on NSAsynchronousFetchRequest at this moment. As, it seems like not a very straightforward thing to apply correctly, in production app.

Thank you for your feedback. May I know, do we have access to 71832162 ticket? Can app developer take a look on 71832162 ticket to understand more? Thank you

Hi, the link https://github.com/ziqiaochen/CoreDataCloudKitShare is 404 not reachable. I am very interest to know, the detailed step 4 & 5 (detecting relevant changes by consuming store persistent history & removing duplicate data). Here's the my way, on how to re-produce the data duplication problem - https://stackoverflow.com/questions/72544804/what-are-some-reliable-mechanism-to-prevent-data-duplication-in-coredata-cloudki Thank you very much, for willing to share your solution.

Thank you. One of the advice is, we should purge history tracking transactions after certain time frame. However, if user has disabled cloudkit sync, does this mean we shouldn't perform such an operation? As, if we do so, and later user turn on cloudkit sync again, he might not able to catch up due to lack of enough history tracking transactions info. But, this is causing a dilemma. If we never clean the history tracking transactions, will it cause disk full issue? Thanks,

Currently, during development, we are able to test one-time in-app purchase using Products.storekit file. Is there a way for us to test on promo code redemption during development, without having to release the app to production? Thank you.

Sorry. Please ignore this answer as it is incorrect.

Hi, I find it behaves correctly after testing for Taiwan and Germany. Do you find a use case where it is not correct?

Thank you. This is one of the potential use cases: real-time font changing. The font selection option will be placed within the UISheetPresentationController. By omitting the dim effect, users can accurately view the results of their font selection.

Thank you for your valuable input. May I know, is while container.isNeedMigration() workaround risky? It seems there is a possibility that we might stuck at forever loop...

May I know, how does shouldAddStoreAsynchronously able to resolve this issue? Thank you.

I received a call from Apple this morning and appreciate the conversation, which clarified the rejection's root cause. My account is associated with a terminated account that owns a similar product. I have provided documents proving that the terminated account was impersonating and infringing on my original product. Thank you for your professionalism. I hope for a positive outcome.

I think this technique is a scalable way to this problem- https://observablehq.com/@dgreensp/implementing-fractional-indexing

Hi, thank you for your feedback! Here’s my latest response from App Review team: “Thank you for your response. We encourage you to consider ways to make your app stand out.” What I’ve done so far: Provided records showing our app’s genuine and original development since 2018, as it’s a port of our original Android app. Highlighted key features that differentiate our app within its category. Shared my phone number, inviting direct contact to clarify concerns regarding Design 4.3