Severe App Store bug: IAP Restore no longer working in live version

Hey there,


I've got a popular app that is taking a big hit by the sudden inability to restore purchases.

Customers are going crazy. Facing legal action by one of them. The issue has persisted for over a week now.


Apple Technical Support closed my case and asked me to file a bug report, which I have done under ID 34278255.


Hoping to reach the right people at Apple via the forum, because I am about to go out of business due to this issue.
1) IAP restoration worked flawlessly for many months since the last update to my app.


2) Suddenly, customers began emailing me about their inability to restore purchases, which persisted for a few days.

The problem then suddenly disappeared. No new version release.


3) Got curious, added some more NSLogs to my IAP code just in case this weird issue would resurface, and submitted an update. Which I deeply regret. This action must have triggered the issue again.


Immediately after releasing the new version, the ability to restore purchases broke down. This time much more severely. My inbox started to overflow rapidly with complaints. So I looked into the device's console, and what I found was this:


The first line says that the App Store (or StoreKit?) "couldn't parse protocol":

Sep 10 00:59:02 Dudes-iPhone itunesstored(iTunesStore)[4759] <Error>: DaemonProtocolDataProvider: Couldn't parse protocol: <private>


The second line comes straight out of StoreKit:

Sep 10 00:59:02 Dudes-iPhone itunesstored[4759] : StoreKitClient: Restore completed transactions failed for client: with error:


My app receives a call to -paymentQueue:restoreCompletedTransactionsFailedWithError:, and I'm NSLogging the error ("Cannot Connect to iTunes Store"):

Sep 10 00:59:02 Dudes-iPhone Xxxxxxx[5377] : Error: Couldn't restore completed transaction: Cannot connect to iTunes Store, (null), (null)


4) Meanwhile, restoration works flawlessly in TestFlight. My restoration logic is still the same one I used for many years.


I'd love to hear if any other developers are facing this issue, and I'd also love to see a sign from Apple that someone is working on this. Anyone?


Cheers,

- A developer whose app and business is getting killed by an App Store glitch.

Replies

One thing to check - are all your contracts signed?

I'm experiencing the same problem. After updating my app, it is no longer able to connect to iTunes store.


Did you get your problem solved? I hope you did, and I desperately hope you're able to share something on how to go about it.


Thank you in advance!

The problem hasn't been fixed on Apple's end.


Here's what's happening:


1) App sends restoration request via StoreKit's standard APIs.


2) Device log shows that iOS is unable to parse a proto col from the App Store:

error13:04:12.641399 +0100itunesstoredDaemonProtocolDataProvider: Couldn't parse protocol: Error Domain=NSCocoaErrorDomain Code=3840


3) StoreKit acknowledges that it is unable to fulfill the request:

default13:04:12.643606 +0100itunesstoredStoreKitClient: Restore completed transactions failed for client: <private> with error: Error Domain=SSErrorDomain


4) End result: Restoration of In-App purchases is impossible using StoreKit's APIs. I've had this problem some years ago and Apple had fixed it on their servers. The fix lasted a while, then the problem resurfaced. I reposted my initial bug report with technical documentation and logs, easily verifyable with any device.


IAP restoration remains broken for my app worldwide. Now since about a year it has not been fixed, although it is all easily verifyable and visible from any device's console logs. I've done my best to give them all the information they need, and pointed out several times that everything is available via any device in the world through looking at the console logs. The team responsible for that hasn't undertaken any efforts to solve the problem so far, and I'm no longer expecting that they're interested in fixing it, presumable because its a rare edge case. Only problem with that: It damaged my business, reputation and career severely!

ftium,


Do you have the incident tracking number or your original report? I'm also checking the bug report - 34278255. Is there a more recent bug report? Does this problem occur with every user? Something to consider as an alternative to using the restoreCompletedTransactions method is to implement Receipt Validation. The contents of the in_app array from a validated appStoreReceipt will show what in-app purchases have been charged against the user account by the App Store Server.


rich kubota - rkubota@apple.com


developer technical support CoreOS/Hardware/MFI

rich, 43462062 is the most recent one. The original report's incident tracking number is 34278255. Delighted to see that 43462062 has been reopened. The problem occurs with every user, to the best of my knowledge. Once someone gets a new device and needs to restore purchases, there seems no chance it will work. Signing in and out, rebooting, resetting, reinstalling... gone through all that with many customers. One hint I found is that the bug may come from the transition to Swift. My app is still Objective-C only. This Githup repository exhibits a similar bug that one developer claims could be solved by transitioning to Swift 3: https://github.com/bizz84/SwiftyStoreKit/issues/175


Yes, Receipt Validation via RMStore + OpenSSL is probably a solution to restore purchases. However, the use of cryptography, especially OpenSSL, comes with excessive risk exposure to hefty fines and penalties, as Apple warns us resource-constrained developers in iTunes Connect. As a bootstrapped one-man operation I lack the funds to implement this safely in compliance with all the cryptography-related regulations around the world, so I need a solution without embedding cryptographic methods.


It would be hugely beneficial to all of us if Apple added a cryptography-free way to let an app check the contents of the receipt, so that we app developers don't have to take on the burden of export compliance.
One other option I'm evaluating now is to send a receipt validation request to https://buy.itunes.apple.com/verifyReceipt and then just evaluate the already decrypted response. I just learned from one app developer doing exactly that, successfully.