Try using Safari with a Private Window. Fixed the issue for me.

Seeing the same issue now with my app. Did you find a solution?

Same here with Xcode 13.3.1 Lucky for me, I have another Mac with Xcode 13.3, which didn't yet update. Archiving from that Mac worked without any issue.

Note that with UITableView there is no scrolling issue, even with 10,000 rows (the sample project demonstrates that as well)

Unfortunately not. The issue of my other question is far more problematic and really puzzles me... Can you please help or guide me? I have no idea how to fix it...

@ChenJingFeng, did you have any progress with this issue?

Can anyone confirm this? Did anyone tested this behavior on iOS 15 beta?

I realize that long time has passed... But I am facing the exact same issue and wondering if you found a solution or workaround?

atomicbird, thank you for your reply. I wasn't sure if anyone also encountered this issue, so I guess I'm not alone here. I tried your workaround and it works very well on the demo project (thank you for this!). The problem is that my app uses a 3rd party library with deep Core Data integration. I have the source code of this library, however, there are hundreds of performBlockAndWait blocks in this library, so adding @autoreleasepool inside each of them is not very practical. Did you report this issue or got in touch with Apple about it? I submitted a report at https://feedbackassistant.apple.com/feedback/8761671 and also opened a ticket with Apple code level support in order to accelerate the process of fixing this. I am not sure how to move forward. I doubt it will be fixed soon by Apple. I consider to temporary change my app name to workaround this issue (e.g. from "Music Library" to "My Music Library") however I'm not sure that this is a good idea. Changing the PRODUCT_NAME build setting in my Xcode project might cause unpredicted runtime results as this variable is probably widely used across the high level and low level app code. Any suggestions?

Any updates on this topic? I am facing the exact same issue today. I can confirm that until recently I was getting a "Failed" event (SKPaymentTransactionStateFailed) with error code of SKErrorPaymentCancelled and I designed my code accordingly. Now it looks like the behavior is changed, and I can't tell if this is a glitch or change by design.  It's critical to know in order to target this use case correctly. Anyone has an idea? UPDATE: I just tested re-purchasing an auto renewable subscription in sandbox on both iOS 13 and iOS 14: On iOS 13, I encountered the same behavior as before where re-purchasing triggers SKPaymentTransactionStateFailed with SKErrorPaymentCancelled. On iOS 14, purchasing triggers SKPaymentTransactionStatePurchased. In both cases the "You are currently subscribed to this" alert is displayed, but the result is different as described above. Can anyone confirm that this is by design?

Any updates on this topic? I am facing the exact same issue today. I can confirm that until recently I was getting a "Failed" event (SKPaymentTransactionStateFailed) with error code of SKErrorPaymentCancelled and I designed my code accordingly. Now it looks like the behavior is changed, and I can't tell if this is a glitch or change by design. It's critical to know in order to target this use case correctly. Anyone has an idea?

Same issue here. Any suggestions so far?