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?

Up vote post of vaijab Down vote post of vaijab
1.6k views
Posted by
vaijab
Reply
Add a Comment

Replies

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.

Posted by
PBK
Up vote reply of PBK Down vote reply of PBK
Add a Comment

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.

Posted by
vaijab
Up vote reply of vaijab Down vote reply of vaijab
Add a Comment

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.

Posted by
PBK
Up vote reply of PBK Down vote reply of PBK
Add a Comment

>... 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

Posted by
KMT
Up vote reply of KMT Down vote reply of KMT
Add a Comment

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


FB7467964

Posted by
lesmond
Up vote reply of lesmond Down vote reply of lesmond
Add a Comment

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?

Posted by
f.goncalves
Up vote reply of f.goncalves Down vote reply of f.goncalves
Add a Comment

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.

Posted by
paweldd
Up vote reply of paweldd Down vote reply of paweldd
Add a Comment