Server-to-server notifications inconsistent docs

Hello,


This is my first post in Apple dev forums.


If you have integrated with appstore for renewable subscriptions, you probably know by now how bad the overall experience is. A couple of weeks ago I noticed that Apple updated their server-to-server notifications docs.


They are going to deprecate certain notification types and introduced new/changed objects. One object in particular is `unified_receipt` https://developer.apple.com/documentation/appstoreservernotifications/unified_receipt


Bedides many other inconsistencies in the docs and what their API actually returns, I want to focus on unified_receipt. In Sandbox, Appstore still returns an old payload (no unified_receipt), but I noticed that in Production unified_receipt is there. How does that make any sense? Why cannot Apple get such an important, yet very simple thing get right?

The sandbox environment is for developing code. Since this feature will be deprecated there is no reason to develop code that relies on it. The Production environment is for apps that were developed in the past and now are being used by many users. In the past this feature wasn't deprecated so apps may be relying on it. Therefore it must remain in Production until all apps have had a chance to replace the deprecated feature.

Sorry if I wasn't clear enough.


My point is that Production server-to-server notifications seem to contain a new unified_receipt object within the payload, whille Sandbox does not. It's supposed to be the other way around, right? Usually people would want to test in Sandbox first, then move on to Production.


PBK, I agree with what you're saying, however the reality is that Apple does exact opposite.

I see now what you mean. The unified_receipt is NOT being deprecated, it is coming into existence and will contain other fields that will be deprecated....

"The following top-level objects are scheduled for deprecation:

latest_receipt
,
latest_receipt_info
,
latest_expired_receipt
, and
latest_expired_receipt_info
. Update any existing code to rely on the following objects in unified_receipt instead:
latest_receipt
and
latest_receipt_info
.."



Therefore Apple will need to place this in the sandbox long before they deprecate the pre-existing fields. As long as they do that, we will have enough time to convert to the new fields. You are correct, they could have placed it in both sandbox and production at the same time. By placing it in production first, they prevent anyone from 'jumping the gun' by implementing it in sandbox and prematurely pushing it into production before production was ready for it.

>... you probably know by now how bad the overall experience is ~ Why cannot Apple


Feel free to file suggest enhancements/file bugs against the tools/docs/processes using the Feedback Assistant, adding your FB # to your thread for ref., thanks and Happy Holidays!


Ken

I filed a feedback back in December for this as saw the same..


FB7467964

Did you find any new information regarding this?


It's not like IAP is a minor feature that has little significance. After all it's the monetization of ones work and one should be able to process them reliably. But that's impossible with this poorly implemented system.

Apple always emphasizes how important a good user experience is, especially for IAP, but how am I supposed to provide a good experience, when I have to run my tests in production, to be sure it's implemented correctly?

Hi guys, I know that sometimes an API change missed is a big pain. Have you also experienced this?

I know I have. The docs are sometimes not enough and you need to test it manually to see what you'll get.

I'm attempting to create a changelog dashboard so that team can mark them as "seen" or "acted upon", do you think this makes sense? Thanks. Pawel from https://ApiPatrol.tech

Would love your feedback.

Server-to-server notifications inconsistent docs
 
 
Q