> we don't want to change all the code of our backend in order to fix with a workaround that behaviour.Any ideas on how to proceed with this issue?Cancellations are rare. And usually a cancellation means the user is no longer trying to use the subscription anyway. If you don't want to change your code, ignore them, take a risk that some users may be stealing, and move on to something more important. It is unlikely that Apple will let them steal more than once or twice.

There are many ways of comparing dates. You can use an NSDateFormatter to convert a string to an NSDate and then compare that to 'now' or use another NSDateFormatter to display that NSDate in your local time zone. Or, just err on the side of the user and give them an extra day.

When you write 'Apple doesn't send transaction to our system' do you mean that they did not send a call to StoreKit's updatedTransaction, they did not send a Notification Alert to your server, or they didn't send the money to your bank?

Seems like if you keep Firebase in the app you have to leave Kid's Category. You could try to convince App Review that [quoting from your original post before you edited it] "we have taken the recommended measures to completely disable all Firebase Analytics data collection activities in the application"has succeeded in making the app satisfy the guideline requirements for Kid's Apps.

1) when you write '(u)ser cancels the subscription' - you mean the user turns autorenew off - they do not request a refund from Apple and Apple does not generate a new receipt with a cancellation_date field. Correct? It is hard to turn off a subscription in the sandbox. 2) I am surprised that you got a .restored transaction state in updatedTranscations without getting a call to paymentQueueRestoreCompletedTransactionsFinished - check that that is actually happening. If it is, please report it as a bug. I do not think that is the expected behavior and it might be just a sandbox bug. 3) I am surprised that you got a restore rather than a purchase after a purchase request

Here's another perspective:> AFAIK Apple charges 30% for any digital good.The guidelines are here: https://developer.apple.com/app-store/review/guidelines/#goods-and-servicesYou seem to be saying 'AFAIK Apple requires the use of IAP for any digital good'. They do not. They require the use of IAP for any item used in an app (3.1.1) - with certain exceptions ( 3.1.3a, 3.1.3b and 3.1.5a ). If your digital good is not used in an app then there is no requirement of using IAP.On the other hand, if your digital good is used in an app then IAP may be appropriate - but for what? The service of actually creating the digital good is 'consumed' outside the app. But then if you bring that into the app what fraction of the total charge is assignable to the creation (no IAP) and what fraction is assignable to the app-based distribution (IAP). That's a tough call that would be made simpler if you divided the product into two streams - music creation and music distribution. It might be $100 to create a song and $3 to mail a CD or $1 to distribute through the app. Only the $1 would be IAP. If 50 people then bought the same song, 30 by CD and 20 by app then it's one charge of $100, 30 of $3 and 20 of $1 - only those 20 of $1 via IAP.

You wrote >allowing the user to choose an option to register with Facebook or Google,I respond: because you do this you must satisfy the guideline 4.8 which requires you to add a sign in with Apple. You wrote >but it's not 100% true.I ask: How is it not 100% true? What differs between that guideline and what you are doing? You might be aware that this guideline was changed over the past few months. It used to refer only to apps that 'exclusively' use use a third party log in but it no longer says that. So, IMHO, you must use Apple sign in if you are using some other third party log in 'to set up or authenticate the user's primary account.' You are - you must.

Yes, I know. I was just reflecting on how prescient my answer was.... "One difference between iOS13 and iOS12 is that the returns for product and purchase requests are being returned off the main thread and so those methods must regain the main thread before using any UI like an alert:

Do you call that exit within the app somewhere or is the system doing it?> I am using verifyReceipt (https://buy.itunes.apple.com/verifyReceipt), alough it is not used on the initial launch.When App Review tests an IAP they do it in the sandbox. The procedure is to first send to this website and if you get a 21007 error to test against the sandbox.

Interesting. Many apps are having that problem. Thanks for marking my correct answer as correct!

I can't read the crash log. One difference between iOS13 and iOS12 is that the returns for product and purchase requests are being returned off the main thread and so those methods must regain the main thread before using any UI like an alert:-(void) productsRequest: (SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response{ dispatch_async(dispatch_get_main_queue(), ^{ //code here }); }This however would not be relevant if, as you wrote, the crash occurs after the IAP is completed.

>allowing the user to choose an option to register with Facebook or Google,Triggers:4.8 Apps that ** use a third-party or social login service (such as Facebook Login, Google Sign-In,.....) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option. .... Sign in with Apple is not required if:...>but it's not 100% true.How so? It no longer has the word "exclusively" where the " ** " is so you can't argue being in a grey zone as others did before.

Unclear what caused the earlier problem. A side issue - the order of renewals in the IAP receipt is no longer first-to-last. That means you have to sort the various renewal receipts and pick the latest expiration date.

This is now way beyond me.I think KMT's suggestion of DTS may have been prescient - but the question is not 'how to force a complete reinstall' but rather 'why is the system blacklisting me'.That said - I think you need to respond sooner than 20 seconds with a completion handler and I'm not sure you always want to indicate .newData if there was no new data.

So this is then the issue behind your position....".. my app might be getting blacklisted. I need a way to check that and more importantly to reset it when a new build is installed"You are focusing on 'resetting it' - your 'position'. And you have found one means of resetting it - a full reinstall. And you are therefore trying to force a full reinstall. That might be the solution. Or it might be a rabbit hole that pits you against the system.Perhaps there is a reason why the system is objecting to your fetches - the 'issue' behind the position. Perhaps multiple 'no data' fetches raises a flag. Perhaps too many 'full data' fetches is raising a flag. Maybe your app could detect those circumstances and change the fetch rate. Then you would not get blacklisted in the first place. Is there something unusual or different about the data these affected users are downloading?