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

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.

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

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...

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.

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

Sorry. Please ignore this answer as it is incorrect.

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.

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,

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 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

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.

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.

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