I get the same error. I'm not using any third party frameworks or static libraries. I have my project set to include DWARF with dSYM in the build and debugger. This is a MacOS C/Objective C XCode project. With some Swift. Most of the discussion about this for iOS projects. When I verify or upload my App I just ignore this. Is this OK? Is this an Apple bug?

Also: AppLogger.error("Couldn't get the app store transaction") won't build: "Cannot find 'AppLogger' in scope" It looks like AppLogger is a third-party API. Is this correct?

Xcode wants me to use guard appTransaction != nil for the guard statement. This does seem to be closer to what a guard wants. XCode won't build: return await inspectAppTransaction(appTransaction, verifiedByApple: false) error: Cannot find 'inspectAppTransaction' in scope Naturally I can't find anything about this method by searching the Developer Documentation

Apple released 15.4.1 Today. Maybe this fixed it? You would expect this to be a high-priority bug.

You don't want your users to have to refresh() the app because it will ask for YOUR Sandbox test user credentials.

If you sell your app from your site it could be a problem with your receipts and verification. If this is happening to users that buy it from the App Store then it's likely that there's a BIG problem with 15.5. I understand your frustration with Mac development - crappy documentation in Swift only, very weak developer support, etc.

It's hard to know exactly what happened to me. There was a valid receipt in my project that I was using for testing. This was loaded using the old API exit(173). After I upgraded to 15.4 It was either gone or invalid. In my post I added code toload a receipt if there isn't one. This posts a dialog asking me to enter my Sandbox user name and password and then gets a receipt. If you comment out the refresh() and run it again it will verify the receipt so I'm guessing that it is still in the build folder. I'm hoping that none of my users will report that they are getting this dialog. What you have going on sounds much worse. If your users are getting their app from the store, the store either didn't attach a valid receipt or their older receipt is invalid on 15.4. I'm leaning to the second option. Would they have to get a valid receipt from the store? Download the app again from the store? How could they do this? This sounds really bad.

I decided to use a different approach: @objc class MyAppTransaction: NSObject{ @objc class func checkReceipt() async -> String { var appTransaction: VerificationResult<AppTransaction>? do { appTransaction = try await AppTransaction.shared } catch { appTransaction = try? await AppTransaction.refresh() } do { switch appTransaction { case .verified(_): return "VERIFIED" case .unverified(_, _): return "NO RECEIPT" default: return "ERROR" } } } } When my program executes the refresh() method it prompts me for my Sandbox user name and password, using two-factor authentication on my phone. Then in subsequent executions of the application it doesn't. I assume that this means that the receipt stays in the application bundle. Also I assume that refresh() won't be executed when my end users launch the application because the App Store will already have attached a valid receipt. Is this correct? Couldn't I comment out the refresh() in the final build I send to the App Store?

And naturally Searching the Developer Documentation for AppTransaction.BackingValue yields no results.

XCode error: Failed to parse AppTransaction: missingValue(for: [StoreKit.AppTransaction.Key.appTransactionID], expected: StoreKit.BackingValue)( In the Developer Documentation for AppTransactionID the definition includes: @backDeployed(before: iOS 18.4, macOS 15.4, tvOS 18.4, watchOS 11.4, visionOS 2.4)) So Apple DID change something in how it verifies receipts with OS 15.4. Is there any way to verify that my verification code will parse receipts on 15.4? Searching for @backDeployed in the documentation of course I can find nothing.

According to the Developer Documentation: "Important Calling refresh() displays a system prompt that asks users to authenticate with their App Store credentials. Call this function only in response to an explicit user action, like tapping or clicking a button." Calling let verificationResult = await AppTransaction.refresh isn't doing this or refreshing the AppTransaction.

I spoke too soon. Refreshing the AppTransaction won't load a valid receipt.

I can get a receipt by putting code like this: let verificationResult = AppTransaction.refresh //do{}catch{} in the checkReceipt() function berore the do{}catch{} Then the program will run, verifying the refreshed receipt. This is OK for developing the application but you would want to delete this before building the app for submission to the App Store. Also it's possible that only doing this once during the development wouls leave a valid receipt in your build. I'll check this out.

Just to make sure that exit(173) is no longer working I added this code before I called my function verifyWithStoreKit(); void getReceiptData(void) { NSError *theError = nil; NSData *receiptData; NSURL *appStoreReceiptURL; NSBundle *mainBundle = [NSBundle mainBundle]; appStoreReceiptURL = [mainBundle appStoreReceiptURL]; if((receiptData = [NSData dataWithContentsOfURL: appStoreReceiptURL options: NSDataReadingMappedAlways error: &theError]) == nil) exit(173); } The first time you call exit(173), XCode will post an alert saying that exit(173) is no longer available but it actually WILL get a receipt. But then verification will fail to validate the receipt. This is happening with a built version of the app that worked fine for a long time as well because it had a receipt. This is worrying because this could happen to my users. Is there now no way to get a receipt to use while testing your application?

I solved the problem. I control-clicked on the archive in the organizer window to show it in the finder. It’s a .xarchive bundle. Control clicking on it shows a pop-up menu with the option to show the package contents. the package contains three things: a dSYMs folder, an Info.plist and a Products folder. The Products folder contains an Applications folder. This folder has a copy of the application and an app name.docarchive. Double clicking on the .docarchive opens the developer documentation with my application shown in the left side bar and a list of the Swift classes and functions that I implemented in my Objective-C application. So this looks like something that Xcode did when I added swift objects to the app with a bridging header. When there’s a .docarchive in the Application’s folder Xcode thinks it’s an type other. Setting the target build setting in Document Compiler - Options > Build Documentation During ‘Build’ to no fixes the problem.