I believe the alert already contains something like "Allow the application to access the camera:" so all you would need is: "to chat or to upload payment receipt"

Apple wants you to go to Zoom to get written permission "to request, display, or distribute account information". Apple believes this information, not the SDK, may be proprietary to Zoom. It is possible that Zoom has on their website a policy stating what the public (you) can do regarding such information (and the SDK) and you could copy that website and send it - but I suspect what they have is 'you can't do what you are doing'. One thing you could try is to have your app reviewed by an intellectual property attorney and have them issue an opinion on what you are doing. If the account information is actually coming from the Zoom user, not Zoom, it is possible that there are no intellectual property issues. And the attorney can tell you why your app is, or is not, violating Zoom's rights or terms. It is also possible that App Review imprecisely stated their objection by limiting it to 'account information'. It is possible that your app is interacting with the Zoom service in a manner that Zoom might not approve and might violate Zoom's copyright or trademarks or terms of service. For example, an app that places Zoom's front facing interface in the background, parses their display and shows only certain images may be unacceptable to Zoom. After all, Zoom put a lot of effort into developing their platform; what right do you have to freely incorporate it into yours?

I believe you have to have the app function at some level before all IAPs. It can be a 'lite' level - essentially advertising all the wonderful things the app will do once the IAP is made. Even better, have it function enough to draw users into it the functionality and entice them to make the IAP.

> dialog controller not showingIf that is your "dialog controller", have you checked your productRequest and paymentRequest methods to be sure you return to the main thread as indicated in https://forums.developer.apple.com/thread/130793

App Review should notice the similarity and reject the second app as Spam.

Accumulate the receipts that come into your server on a day-by-day basis starting with a particular calendar date. Note each receipt and the revenue you expect on that date. When you get the Apple report, compare the numbers on that report with your daily totals. Try to detrmine the approximate time frame that Apple is reporting. Use that time frame in all subsequent Apple reporting periods. After a few reporting periods you should be able to align the delay in Apple's reports with your day-by-day numbers.

P.S. - see problems reported here:https://forums.developer.apple.com/message/424608?et=watches.email.thread#424608

> Do you know if hosted content is automatically downloaded to the device when purchased or whether the app needs to make some kind of call for it?The process is described here:https://developer.apple.com/documentation/storekit/in-app_purchase/unlocking_purchased_content?language=objc

Yes, you would have two IAPs for the same subscription; 4 IAPs in all. Therse would be in two different groups and every user, in one or the other group, could upgrade and downgrade within their group. Unfortunately, you need to maintain two groups because you alreaday have two groups.

By adding an item to Group A and also adding an item to Group B you allow all current subscribers to upgrade and downgrade from their current subscriptions.

I do not know if you can move an item from one group into the other. But here is another solution:Maintain two groups. Group A already has item 1 with duraction 1 Create a new IAP with duration 2 and add it to Group A Group B has item 2 with duration 2 Create a new IAP with duration 1 and add it to Group BIn the updated app, offer only Group A to anyone who does not already have a Group B subscription.If someone already has a Group B subscription, offer only Group B subscriptions.

I am not familar with Revenue Cat. And I generally avoid using such services/code, I prefer coding it myself.

Cute.I was writing that there are alternatives to using server-to-server notifications to maintain and verify an autorenewable subscription. Use those alternatives. Don't chose server-to-server notifications because there are more problems reported for them than for those other methods. It is unclear if there are similar alternatives with fewer problems to: notarize software, use dylibs, submit apps, purchase apple developer accounts.

You are correct - #3 and #4 do not apply to ODR. I misread your original post and focused on:Is ......hosted content ... dowloaded .... at purchase time? Also, is there any difference between having the IAP content on Apple's servers and downloaded/downloadable when purchased versus having it on the app bundle,Like IAP, ODR is not downloaded in the original in the app bundle. When you asked the question this way I assumed you were placing the content directly in the app binary not in ODR. The way IAP hosted content is downloaded into an app gives the app a bit more control, but that control may not be needed. Also, once downloaded the app must retain hosted content as a file on the device - I think ODR can be swapped in and out of memory as determined by the system. There appears to be little difference as far as the IAP is concerned if you place the ODR tag behind a wall in your app that is opened with a simple IAP. I think #1 and #2 may be different for hosted content than ODR.

>I make sure to include 'exclude-old-transactions'.Unclear what this means. But see change #2.There are two recent changes in IAPs. 1) The calls to productRequests and purchaseRequests are off the main queue so you need to add dispatch_async(dispatch_get_main_queue(), ^{ //code here });to display any UI element like a UIAlertViewController. 2) The order of the IAP receipts in the receipt is no longer in time order - you need to check expires_date and select the latest one.>Sandbox purchases only last a few minutes!This is a feature not a bug. Subscription times in the sandbox are all shortened so that they can be tested.