Based on the number of problems reported in the In App Forum....absa****inglutely not!

It may be simpler than you think. Divide the task into two streams:1) On each device, rely on updatedTransactions to set the expires date based on the transaction.transactionDate and the transaction.payment.productIdentifier properties.2) Do whatever you must to verify the receipt and accept that value.Everything else is extra fluff. Even #2 above.

You must use IAP if required to by the guidelines. There are various 'packages' and 'code examples' out there for IAP.With the exception of verifying receipts, it's not that hard.If you have a server, even verifying receipts is not that hard.And you will discover that non-renewing subscriptions are much easier to implement than autorenewable subscriptions. The question is whether you want that autorenew feature.Finally, 30% is only the other side of 70%. 70% of X is larger than 100% of X/2.

I can't help with the uploading problems you are having.The difference between using hosted content versus placing the content in the originnal app bundle is that1) you can change the hosted content without needing all users to update the app2) you can add to the hosted content without needing all users to update the app3) if the hosted content is large, you don't burden all users with downloading it when they purchase the app from the app store.4) if the hosted content is very large you don't burden any user with downloading it inconveniently through the app store download

> reconcile between payment receipt which i am receiving after each purchase/renewal in my app in app store vs monthly reports generated in app store connect.Again - you can't. You can only reconcile between payment receipts you are receiving for all purchase/renewal in my app in app store vs monthly reports generated in app store connect.> If its not match then i will need to find where is the gap.You are supposed to verify the receipt each time an individual user makes a purchase. That reconciles the individual claim to the rights of an IAP with the receipt issued by Apple. Having done that, you can then check to be sure that Apple is paying you for the total number of validated purchases that you have recorded and complain to Apple if you feel you are being short-changed. You CANNOT reconcile Apple's report with any individual purchase.

A receipt contains all of the earlier purchases. Your receipt lists the following different purchases all from the same original subscription purchase (they all share the same original_transaction_id going back to April 2018):appadfree "purchase_date":"2020-05-05 13:52:49 Etc/GMT",appadfree "purchase_date":"2019-05-05 13:52:49 Etc/GMT", (different web_order_line_item_id)promontly "purchase_date":"2019-04-30 03:52:49 Etc/GMT", then cancelled on "cancellation_date":"2019-05-06 01:54:14 Etc/GMT",promonthly "purchase_date":"2019-03-30 03:52:49 Etc/GMT",On May 5 the promonthly was converted to appadfree and two ( ! ) transactions generated for an apadfree subscription. The next day, May 6, the current promonthly subscription was cancelled, I think becasue the subscription was converted to apadree.What may be unusual is that the system seems to have generated two purchase receipts that are renewals of the same original_transaction_id (with different web_order_line_item_id) at exactly the same time when the subscription was converted from promontly to appadfree.

> i want to reconcile those transaction with any transaction report generated by apple-store-connectIf by 'reconcile' you mean that a specific user's transaction is reflected in your apple payment - no.If by 'reconcile' you mean determine if the apple payment is consistent with the total number of transactions - yes. Count up your individual transactions over a period of time and see if that number is close to what Apple reports. - on a country-by-country basis and on a week-by-week basis. But there may be a time shift in when Apple reports revenue and the user reports payment. Another question is - what will you do if you discover that you are getting much more or much less than you expect?

If you have IAPs that were 'non-consumable' or 'autorenewable subscription' then those IAPs have to remain available for a restoreCompletedTransaction. In fact, I think if you ever had IAPs in an app you must always have the IAP functionality. You can certainly mark an IAP as no longer 'cleared for sale' and you can update the app so that a new IAP purchase option is not there - but you must retain 'restore' functionality if you had subscriptions or non-consumable IAPs.

TMI.In the scenario you describe StoreKit will send your updatedTransactions method two transactions, one immediately after the other. The first will have a state of 'failed' because the user's credit card information needed to be updated. The second will have the state 'purchased' because the user decided to go ahead with the purchase after updating their credit card information. Your code needs to handle both.A common problem is code that removes the transaction observer and the class that handles the IAP immediately after getting the failed transaction. One solution is to leave the observer and class in memory permanently (Apple recommends this solution!). Another solution is to delay removing them for a few seconds after a failed transaction.Usually the code allows the user to 'restore' their purchases. That will 'fix' this problem should it occur in a production app.

I am more surprised by "receipt" rather than "in_app".It is unclear how your print-out displays a JSON array with only one object. Perhaps it is an error in the printing process because the array has only one object in it. Note that the "in_app" (in your case "receipt") field should also be an array of one object.There is supposed to be a field called expires_date and your receipt has it. Your receipt is missing expires_date_ms.The receipt striucture has changed with time. The best and most reliable document is, surprisingly, the oldest document. It is hard to find and no longer maintained - and that may be a good thing. Treasure this link:https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html

What you describe sounds like a bug in "React-Native-Contacts" - they are the best ones to handle it.Wild Speculation: It is either with the button not responding or with the delegate not being assigned. The code needs to do a: myCNContactViewController.delegate=self; // or whatever class the delegate isbut if any functions of the delegate work, then it is not the delegate not being assigned. If other functions of the delegate work then look at the code in the method (theBadMethod:) in the IBAction called by the button in something like: [theBottomMostButton addTarget:self action:@selector(theBadMethod:) forControlEvents:UIControlEventTouchUpInside];It may dismiss the class before calling the delegate function that you expect to be called.

1) please use the " <> " button above to post code.2) you are posting lots of MCSession code and asking a question only about "notification tab" - and you are asking that question in the title of the post rather than in the post itself. Use the title as a title not a textfield. And what is "notification tab"?3) assuming that your question relates to this line of code: [[NSNotificationCenter defaultCenter] postNotificationName:@"MCDidChangeStateNotification" object:nil userInfo:dict];all you need to do to receive a notification is to add this line of code in any class in your project: [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(ReceivedSomeNotification:) name:@"MCDidChangeStateNotification" object:nil]; // and then receive it here in the same class as the addObserver above: -(void)ReceivedSomeNotification:(NSNotification *)notification{ }

So there are a few confusing things here. You can't replicate the problem so it doesn't crash in your hands - got it. The crash is happening at App Review. Got it.What did you do to fix the problem App Review sent about crashing at launch? Nothing? Why are you telling us you verify at buy.itunes.apple.com? Have you ever tried to verify anything but a sandbox receipt?

Apple has made provisions where users can purchase content outside of the app, not using IAP, and still use the content inside an app - they are called multiplatform apps and reader apps. There are various restrictions to each. I think you are not asking about those but about a more flexible autorenewable subscription.Here are four ways of creating the flexibility that you want:1) use a non-renewing subscription. Each renewal period ask the user what they want to renew - publisher 1 or 2 or 3. And if they want more than one, let them purchase more than one 'non-renewing subscription'. 2) Use generic products for the autorenewable subscriptions. Call them 'Subscription A' and 'Subscription B', etc. A user starts out with just one subscription - A. They can apply their A to any publisher and they can switch from one publisher to another. Your system handles which content the user gets given their one subscription. Apple will charge them for one subscription. If a user wants two publishers, they expand and purchase B. Apple will charge them for two subscriptions because they have purchased two different products. Again, your system decides which content stream they get given, now, that they have 2 streams available to them. If they decide to cancel one of the two subscriptions you cancel B. You can charge less for a B than an A. 3) There are 'groups' and 'levels' in autorenewable subscriptions. You could allow the user to upgrade within a group from '1 content stream' to '2 content streams'. 4) Create a different autorenewable subscription IAP product for each publisher.

Be sure you checked that the app should be released when approved not 'hold for developer release' somewhere in App Store Connect.