I would recommend that you file an appeal listing the other apps that you have on the App Store and telling Apple that if they believe that their objections to this one app is justified then surely they should remove all of your apps from the App Store.Note guideline #5: 5. Legal.........We know this stuff is complicated, but it is your responsibility to understand and make sure your app conforms with all local laws, not just the guidelines below.

> Schema? Security Rules? What? Where are these things?Xcode, select the target app, Signing & Capabilities,CloudKit DashboardSelect the container for the app on CloudKitThis gets you to the CloudKit Dashboard.Select Development. (this may be a drop down menu at the top labelled Production)Select Schema. (this may be a drop down menu at the top labeled Data)Select Security Roles (This may be on a drop down menu at the top labelled Record Types)Select the permissions for World, Authenticated and Creator. Then you may need to deploy to production.

Still unclear.You wrote: "payment deducted from my account"What account? Are you testing in the sandbox or in production? You wrote: "when I check the purchase history it shows purchase pending"What purchase history are you checking?You wrote: "I do not know when it is going to be a success"It will be a success when your updatedTransactions method is called with a state of 'purchased'.

Your app should get a call to updatedTransactions with state 'purchased' immediately after Apple has taken money from your user's account. Can you get your user to get your app to execute an 'addTransactionObserver'?A user can falsely claim that they have purchased an IAP but the app did not give them credit for it. You should ask the user to send you their email receipt from Apple indicating they made the purchase.

Ok. That makes sense. See my response below...copied here: The app can access the CloudKit container (of A) because the App ID and the app's entitlements file contains the CloudKit container (of A). That was done when Developer A created the CloudKit container or used an existing CloudKit container to which they had access. That CloudKit container is still Developer A's. It did not transfer when the app ownership transfered. Developer A can access that CloudKit container from their dashboard. That may be a security issue. Developer B cannot access that CloudKit container from their dashboard. That might be an access issue. You can add Developer B to the team (of Developer A) that has access to the container in the dashboard.And you now wish to move everything to Developer B and terminate Developer A. But the app is pointing to a container of Developer A so I don't think you can terminate Developer A. If you did, you would not be able to monitor CloudKit Dashboard even if Developer B became a member of Developer A's team. And it is unclear if the container would remain 'alive' - i.e. if it exceeded 'free' usage. You might be able to revise the app to point to a different container owned by B. That would require transitioning the data which could be complicated.

When the user changes their iTunes account they are a 'different' user. The different user did not make the original purchase (of the IAP or the app) and therefore can't change their subscription (or restore their IAPs). This inability prevents a user from purchasing a non-consumable IAP and going from device to device (of all their friends), logging into their iTunes Account, restoring the purchase and then logging out of their iTunes Account. How does it know the account has been changed? Is it because the receipt of the new purchase does not agree with the previous receipt? It is because StoreKit has access to the iTunes Apple ID of the user and recognizes that it is different.I would like to prevent the error by blocking users from changing subscription plans if a different account is used. How can I know that a different account is used? I don't think you can. That is Apple's information and I think you can't get it from the system. But the user usually knows exactly what is causing the problem. A user changes their iTunes ID only because they are trying to 'share' their purchase.

> Does anyone know if this permission (a permission asking the user whether or not they consent to their personal data being collected) is required if we decide to store the data locally instead of uploading it to our servers? We don't want to scare users with a messag, especially since we're collecting data that is not really even that "personal".You certainly need permission to 'transmit' personal data. You also need permission to 'collect' personal data according to 5.1.1 ii. If the message to the user indicates what data being collected "is not really even that 'personal'" it may not scare the user.

> let users who come through certain channels customize their experience in the app.Apple is concerned that those 'certain channels' involve a cash payment and are being used to get around IAP. But apps are allowed to unlock functionality using, for example, geolocation sensors. You might appeal explaining the nature of the certain channels.

In CloudKit a notification based on a subscription is not sent to the one iPhone that posted the change in CloudKit that generates the notification. Therefore it will not be passed from that iPhone to the Apple Watch. If you use any other iPhone to cause the subscription to trigger a notification then it will be sent to that iPhone and passed to the Apple Watch.

> I was really expecting the CloudKit container to be migrated over along with the rest of the app transfer.This may be the source of the assertion that: ".....devs can only transfer apps that aren’t iCloud enabled. No version of the app being transferred can use an iCloud entitlement."It's not so much that 'they can't use' but that 'they can't transfer ownership rights' hence the problems you encounter.

>If I keep the current receipt on a server, can I check by comparing with the receipt I get from current iTunes user?I cannot understand what you are asking. Please try to be more precise. What current receipt; check what; what current iTunes user?Different iTunes Accounts are different users. Issue an error message; the user knows exactly what they are doing when they change iTunes Account.

Complicated.You can offer promo codes issued by Apple. You cannot offer promo codes issued by yourself. In your case you would create a non-renewing subscription and try to use promo codes for that IAP. Promo codes for IAPs were buggy - I don't know if they have been fixed.You can offer all users (not selected users) a free period to try something in your app and have it expire at the end of that free period. Simply write the start date to the users iCloud key-value file or keychain.Autorenewing subscriptions are complicated - they must be used as prescribed. You can offer an autorenewable subscription with an initial free trial period that flows automatically into the paid subscription.

What is " the app's receipt in the iTunes account"?If you mean the receipt located in [[NSBundle mainBundle] appStoreReceiptURL] then say that rather than use a term that has a clear meaning only to you.That receipt ([[NSBundle mainBundle] appStoreReceiptURL]) does not contain any information that reflects the purchaser's App Store account. The fields of that receipt are described here:https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html#//apple_ref/doc/uid/TP40010573-CH106-SW1But if there were to be a difference, that difference would show up only after the user got the error message you are trying to avoid.Again, don't worry about this error message. The user, who changed the App Store login username, knows exactly why they got it.

Is it possible that someone accidently added an autorenewable subscription to the app on App Store Connect - not in the app?

Apple does not charge for any receipt verification services they provide. They charge 30% of the revenue when there is a transaction before distributing the 70% to the user. I believe this is net of taxes and VAT.