Post not yet marked as solved
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?
Post not yet marked as solved
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?
Post not yet marked as solved
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?
Post not yet marked as solved
Same issue here. Any suggestions so far?
Post not yet marked as solved
Can you please indicate if there is any update on the deployment date for getting email for follow up authorizations?
Post not yet marked as solved
Having email provided for follow up authorizations is great. However, if you are considering to add the authorized user's email of follow up authorizations into ASAuthorizationAppleIDCredentialidentityToken > identityToken, please consider to add it into ASAuthorizationAppleIDCredentialidentityToken > email as well. I am developing a native iOS app, and parsing the email from identityToken is not straight forward in a native iOS app. It will require adding a 3rd party JSON Web Token Parser to my project (as there is no native iOS API for parsing JWT), instead of simply getting it from ASAuthorizationAppleIDCredentialidentityToken > email. This is an extra work that I (and probably many other iOS developers) would much prefer to avoid. Any thoughts?
Post not yet marked as solved
Same question here. Looks pretty odd that this control doesn't adapt automatically to dark/light mode
Post not yet marked as solved
I'm also looking for a way to disable this warning.
Post not yet marked as solved
Yes, I think that this is a new behavior of iOS 10 since it doesn't reproduce with iOS 8 and iOS 9.I assume that this is a new bug in iOS 10 not yet fixed by Apple. Could any one tell if a related bug was submitted to Apple bug report system? Also, it would be greatly appreciated if an Apple engineer can reply with some feedback...
Post not yet marked as solved
I just encountered exactly the same issue and not sure how to proceed... Did you find more info on this issue?
Post not yet marked as solved
UPDATE 1:after adding -com.apple.CoreData.SQLDebug 1 I figured the following:Following the added model version, there is a lightweight migration that rebuilds the image table and re-generate all indexes.On the first save this what happens:
BEGIN EXCLUSIVEfew UPDATECOMMIT (very fast!)pragma page_countpragma freelist_countpragma incremental_vacuum(4055) (very slow, almost 4 seconds!)pragma incremental_vacuum is taking almost 4 seconds on iPhone 6 device and much more time on slower devices (more than 10 seconds).Note that on the first save, no matter which app you develop, steps 1-5 will always take place after app loaded.Unique for my case is that I get incremental_vacuum in addition. I can see why it's invoked (I guess because there are too many unused pages due to rebuilding the large image table in the lightweight migration phase), however, I can't see why it's invoked later on subsequent app loads.Shouldn't the first invokation of incremental_vacuum fix the issue of unused page and update the sqlite file accordingly? It just seems that the result of incremental_vacuum is kept in memory and not saved to the file (although file is indeed saved)
