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?

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?

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?

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

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

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

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

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

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.

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

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