MAS: app rejected because of faulty receipt-validation

MAS rejected an app of mine (BigSur, Xojo 2021v3, App Wrapper 4.4) because it crashes as soon as it opens.
They made available two crash reports, but I somehow already knew that the problem was the receipt-validation code called in the open event of app.
In fact, after removing such code the app was allowed to reach the Store.

When the receipt-validation code fails, it calls
declare sub exit_ lib “System” alias “exit” (code as Integer)
exit_ ( 173 )

According to Apple docs, 173 makes the app quit and starts a process asking the user login and pw etc. etc. In fact, from 2011 to last December, this code by Thomas Tempelman and later Sam worked as espected.

But now the app crashes with a message “App corrupted etc. etc.”.
Yep, even removing all the tests and keeping the above snippet only.

I’d appreciate if some guru could look at the full receipt validation process and help me out of this situation; or share equivalent code if it does not make use of plugins.

Needless to add that all my apps are in the same situation.
BTW, if necessary I can also make the crash reports available.


I tripped over the exit(173), too, a while back.

Why do you still use libcrypto directly? Since BS this is verboten. Check out the forum. Jürg Otter made a project so that you can do BYOL with the lib. The following code works fine without libcrypto:

dim AppFolderitem as FolderItem = LaunchServicesFindApplicationForInfoMBS("", LiteBundleID,"")
if AppFolderitem = Nil then Return False

dim theReceipt as FolderItem = AppFolderitem.Child("Contents")
if theReceipt = Nil or not theReceipt.Exists then Return False
theReceipt = theReceipt.Child("_MASReceipt")
if theReceipt = Nil or not theReceipt.Exists then Return False
theReceipt = theReceipt.Child("receipt")
if theReceipt = Nil or not theReceipt.Exists then Return False
dim r as AppReceiptMBS = AppReceiptMBS.receiptForFile(theReceipt)

dim a as new AppReceiptVerificatorMBS
a.bundleIdentifier = LiteBundleID
a.bundleVersion = getBundleVersion(AppFolderitem)

dim theResult as Boolean = a.verifyReceipt(r)
if not theResult then
  declare sub exit_ lib "System" alias "exit" (code as Integer)
  exit_ (173)
end if
Return theResult

I’m glad you encountered the problem ans solved it. It gives me some hope.

Actually I dont even know what libcrypto is. I just copy/pasted some good fellow’s module, which, as I said, goes back to 2016.

According to your advise, I’ll look for Jürg Otter’s topic on the forum.

Thank you.

According to a couple of App Wrapper customers, receipt validation hasn’t been working for over a week. I’m investigating it right now and have initiated another support request with Apple, because I’m unable to verify any receipts at the moment, unlike a couple of weeks ago.

The problem appears to be that the various App Store mechanics are not working together well and are NOT creating the “receipt” file. This could be something I’m doing wrong that Apple has finally decided they’re no longer allowing.

Normally I’d say don’t do this in case Apple change the path of the receipt and break your application. They have API for obtaining the receipt file path.

Dim receiptURL as integer = NSBundle_appStoreReceiptURL( NSBundle_mainBundle( NSBundleClass ) )

The problem I have today is that the file doesn’t exist, so I exit (173) which should trigger the OS to create it and relaunch the application, but it doesn’t, it just says my app is damaged. In the console it complains about an App Store internal object failing with NIL.

Encouraging. Exactly what I see.

See How to build OpenSSL (libcrypto) and include it in a Xojo built app for libcrypto.

What is the result of receipt validation not working?

When you fail to validate the receipt you are supposed to exit the application with exitCode 173. This informs the macOS that receipt validation failed and it should then force a refresh of the receipt.

What I am seeing is that it is NOT refreshing the receipt, but App Store frameworks are writing a message to the console with a NIL parameter.

I can’t be sure with customers code, but in my own tests it is failing because there is no receipt file. Requesting the OS to refresh the receipt simply results in a onscreen message from the macOS that the application is corrupted and must be re-downloaded.

My code doesn’t even get to the point where it tries to read the receipt as it doesn’t even exist. :frowning:

Edit: It will be at least tomorrow before I hear back from Cupertino and I don’t expect to get a result that day.

Thank you for supplying the link.

Unfortunatelly the link does not work.

Jürg Otter, please…

Works fine for me: Xojo - some pieces 4u -

Hi Sam,

did you know when these problems started? My last (successful) submission to the MAS was on Dec., 3rd (and yet no complaints from customers about crashes), but at the end of November some customers had problems with corrupted receipt files (not missing, but corrupted). A re-download from MAS solved their problem.

At that time local testing a MAS App before submission to Apple started to fail (see: Unable to pre-test app for MAS)

Maybe the whole process at Apple is undergoing some significant changes under the hood…

1 Like

I don’t know the exact date sorry. What I do know if that 3 or 4 weeks ago, I submitted two apps to the App Store and had no problem testing the receipt, as it’s part of my process before I submit for review.

Back in spring 2020 I bought a 16" MBP and couldn’t use it to test my App Store apps. After about two weeks, DTS confirmed there was a bug but not sure if it was within the macOS or the machine, so I sent it back and gave it a few months before buying again.

You can simply exchange




in AppStoreReceipt constructor. “/usr/lib/libcrypto.35.dylib” is fine for all current systems (from macOS 10.11 up to macOS 12).

No, this doesn’t work. There is no libcrypto in the folder on Monterey:

1 Like

A lot of the libraries are there in the system, but for “security” they’re concleaded from prying eyes. I think it was Jeff Johnson who figured out how to see 'em.

I am still hopeful that Xojo will expose the functions we need from their own library, so we don’t need yet another copy of libcrypto in our apps.

Even if you don’t see the library, it is working fine - I am working on Monterey :wink:

Well, the library didn’t work for me. I don’t remember the exact error. It was like “don’t talk to me”.


I am using it in all of my apps, MAS and non-MAS, supporting macOS 10.11 up to macOS 12 without any problems.
Maybe you use functions not present in this version - .35 is not really “up-to-date” :wink:

Hi Thomas,
I made the changes in constructor (5 instances), but unfortunatelly I still get the funcky message (app corrupted etc.).
Using BugSur.