I solved (after months) dropping all certificates and generates again. @Sam_Rowlands helped me with the Apple authority certificate and he’s near to release the new AppWrapper version that fix a privileges certificates on the newer MacOs.
Anyway keep in mind that the appstore validation code must be executed before all in the open event in the app…
Ciao Sergio,
I believe what (I at least) am seeing is different to the issue you experienced, which we solved together as I wouldn’t have gotten there without your help.
The “App corrupted” message is another problem - it has IMO nothing to do with the “libcrypto.dylib” changes. These are neccesary to prevent a rejection of the app in review process - due to a crash.
In summary I just want to clarify what the problem I am experiencing is.
App tries to read the receipt at the path given by NSBundle_appStoreReceiptURL( NSBundle_mainBundle( NSBundleClass ) )
Because there’s no file there, the app exits with code 173 (as it should).
The system is supposed to then generate the receipt at the location and re-launch the application.
but it doesn’t. It writes some error messages to the console, then displays the error message that the application is corrupted.
Re-launch the application and go to 1.
The application is already on the Mac App Store with the same bundle id, I have logged out and back in the sandbox user, I have validated that the application is in the "Applications’ folder. I have validated that the Sandbox tester is using the same locale as my main account. I have rebooted.
I couldn’t install Monterey until I changed the DNS on my computer. I know that this doesn’t make any sense, but I am not the only one who experienced this problem. Howard Oakley also documented problems with Apple’s servers until he changed his DNS. So today I’m going to try that.
The developer of pCalc has just released an update claiming that they’ve auto disabled iCloud features because of continued problems with Apple’s iCloud system. I’ve been told by Apple that Notarization requires access to iCloud, so maybe, just maybe receipt validation also requires access to iCloud and it is failing because of iCloud issues, I wonder if iCloud uses AWS? Perhaps it is susceptible to log4j and they’ve been trying to patch it, but left it broken to prevent hacking?
I’ve tried using a different DNS, no luck.
So far no response from Apple, I guess there’s no official word on what’s wrong with Receipt validation, just that it appears to be broken at the moment (this is with testing app store receipts, not actual apps downloaded from the App Store).
My honest advice is to spend some time working on an App Store exit plan. There’s a number of reasons as to why the App Store may not be viable for you (or even all of us) and so I’d recommend people take some time to think about what they’re going to do, if they can’t sell via the App Store any more?
As I was saying in the opening of this topic, when MAS rejected my app because it crashed at launch, I submitted one without Receipt Validation, and within a short time it was accepted.
Not arguing. Guess I was lucky.
I have the same problem since several days, unable to test a new version of my app without the error message that the app is corrupted. This happens under Catalina, Big Sur and Monterey (3 different mac) but works as expected under El Capitan (VM).
It seems that the _MASReceipt folder as well as the receipt file is not created after an Exit 173 (no AppleID authentication popup), but only when installing through the Mac Store.
By installing the pkg of the current version locally (which is currently on the App Store), I have the exact same problem (application is corrupted), but installing it through the App Store it works. Also, by copying the _MASReceipt folder of the version installed by the App Store to my new app installed via the pkg, the new version works for tests.
So, this is definitely not a signature or libcrypto issue but an issue that Apple needs to fix!
Maybe Trump can take Cook’s place to make Apple ‘great again’…
I’m seeing others complain in other forums about it not working, Apple’s “Services” page shows that it is, and I’ve yet to receive any response from Apple about the issue.
Yesterday’s Monterey Combo + SDK + Xcode fixes one problem:
Signing and Distribution
Resolved Issues
Resolved an issue where Xcode required every component of a Mac app to have a provisioning profile when uploading to App Store Connect. (83833905) (FB9677186)
Not sure if impacts positively Xojo and AppWrapper
Thanks Rick, I don’t think it does. I only have a couple of customers who were using Provision Profiles before the recent Testflight announcement.
My contact at Apple has been helping me to understand how it all works and to some degree what should and shouldn’t work (which doesn’t mean it will or will not work). I think I’m finally getting a grasp on things. I will need to be making changes to how App Wrapper works to accommodate this information.
Still no word from Apple on the receipt issue, meanwhile I’m seeing more and more developers complaining about this problem.
Apple is a 2.5 Trillion dollar company that wants a monopoly on where you can buy software for their devices, yet companies like FastSpring will answer support requests within 24 hours, Apple not a peep in almost twice that time frame.
Please, please read the read-me and understand that this replacement is asynchronous and therefore you should design your registration workflow around that principle. In the example project I have created a sample workflow from my understanding of Apple’s recommendations.
Notes:
THIS IS A PRERELEASE VERSION
It allows me to test my own App Store intended applications on my machines locally.
It has not yet gone through the Mac App Store.
It has been tested as far back as Mac OS X 10.13.6
It has been tested as far back as Xojo 2020r1.2.
It is self contained, meaning all the Ohanaware App Kit components have been included.
It is FREE with the source code included.
It includes the OWCallBackExpress design, I’ve been working over the year.
Thank you, Sam, for your efforts. I tested your #1 solution (the “I don’t care” one) and #3 solution (the full process): they work all right.
Nonetheless I’m still of the idea to submit to MAS without any Receipt Validation code. The main reason I used Validation was to allow my testers to test the app thru login; but since with Apple’s new procedure this won’t work anymore and testers are expected to use TestFlight, I don’t see the reason to carry on the exercise.
If anybody wants to carry on contributing to this topic, OK. Otherwise I guess it’s time for me to thank everybody to mark Sam’s answer as “Solution”.