Skip to main content
Solved

Previously non-occurring errors now occurring during non-consumable purchase in sandbox testing of Mac Catalyst app

C
Forum|alt.badge.img+4

The issue:

When testing a Mac Catalyst app built and run from Xcode, I now receive the following Xcode-console-logged errors, in the order listed here, upon attempting a non-consumable in-app purchase using a sandbox user account:

  1. No UI context available for payment sheet request.
  2. Received error that does not have a corresponding StoreKit Error: Error Domain=SKInternalErrorDomain Code=4 "An unknown error occurred. Please try again."
  3. Purchase did not return a transaction: Error Domain=SKInternalErrorDomain Code=4 "An unknown error occurred. Please try again."
  4. There was a problem with the App Store. This could also indicate the purchase dialog was cancelled.

Potentially relevant additional info:

  • The errors have occurred consistently over a 24-hour period, suggesting that it is not just a temporary problem with Apple’s sandbox server.
  • The errors only occur during sandbox testing of the Mac Catalyst version of the app; they do not occur during sandbox testing of the iOS and iPadOS versions of the app.
  • The errors only recently started occurring with the Mac Catalyst version of the app; previously, purchases made on the Mac using a sandbox user account were successful.
  • The only change in the purchasing code I’ve made recently was to update the RevenueCat SDK yesterday from version 4 to version 5 (specifically, version 5.28.1), but the errors above occurred *both* before *and* after the update.  In fact, it was the occurrence of the errors before the update that made me think I should update the RevenueCat SDK version being used.
  • The version of macOS being used for the sandbox testing is macOS 15.5 Sequoia.  The version of Xcode being used to build the app is Xcode 16.4.
  • I have tried the following sequence of troubleshooting steps: clearing my sandbox user accounts’ purchase history via App Store Connect, logging out of the current sandbox user account via the App Store app on the Mac, deleting the app’s preference and cache files, rebooting the Mac, signing into another sandbox user account via the App Store app, doing a clean build of the app via Xcode, and then retrying the in-app purchase.  The errors above still result.
  • I have also tried archiving the app in Xcode, and then exporting it with the direct distribution option in Xcode that outputs a notarized version of the app.  Running that version of the app has the same result as the version run directly from Xcode: failure to complete the purchase.
  • Given error message (1) above, I wondered whether perhaps the error is a version of the UI-involving iOS 18.2 error documented here: https://www.revenuecat.com/docs/known-store-issues/storekit/ios-18-2-purchase-sheet-may-fail-to-appear.  I confirmed, though, that the purchasing viewController is being presented by the rootViewController of the scene’s key window, so it doesn’t appear to be a version of the iOS 18.2 error.  I still wonder, though, what the “No UI context available for payment sheet request” error means.
  • Error messages (2) and (3) above contain other info, including the following additional initial part of an AMSServerPayload dictionary: 

    “customerMessage = "Sign in with Apple\U00a0Account";
        dialog =     {
            cancelButtonString = Cancel;
            defaultButton = Buy;
            explanation = "Enter the password for %%appleId%% to authorize this transaction.\n\n[Environment: Sandbox]."         

    That part of the AMSServerPayload dictionary still appears in the Xcode console log even after I am prompted to log in to a sandbox account (and do successfully log in) while attempting the app’s in-app purchase (having previously logged out of the sandbox account in order to force the log-in prompt).

 

Perhaps the in-app purchase failures occur only in sandbox testing (and in its direct distribution notarized app counterpart described above), and not in the release build that will ultimately be made available via the Mac App Store.  Still, though, I’m uncomfortable submitting this version of the app for review without first knowing whether the in-app purchase mechanism will work in production, especially since I have no way of testing the in-app purchase mechanism once the app is released on the Mac App Store.

Does anyone have any ideas what the problem might be that prevents the sandbox in-app purchase attempt from going through?  Alternatively, does anyone have any ideas about how otherwise to test the in-app purchase mechanism on the Mac?  Thanks for any suggestions you have.

Best answer by Chad Mohler

​@chris_perriam and I have had productive correspondence on this issue, and I have also done additional investigation of my own.  What I have discovered is that particularly for Mac Catalyst apps, Apple’s StoreKit is especially sensitive to the view / viewController / window context for the proper presentation of its payment sheet.

Just to give an example of that presentation context sensitivity: I was able to eliminate the purchase failures described above by presenting the UIViewController responsible for managing the purchase with a modalPresentationStyle of .formSheet rather than .fullScreen.  The fullScreen presentation of the purchasing viewController from the window’s rootViewController hid/obscured that rootViewController and was apparently enough to prevent the proper presentation of the StoreKit payment sheet.

The payment sheet’s sensitivity to the conditions of presentation seems somewhat similar to the problem, noted in my original post above and its reference to an earlier RevenueCat information item that iOS 18.2 users were experiencing.  As noted in the RevenueCat item, for those iOS 18.2 users, the payment sheet was not being displayed if the current scene's key window root view controller was not a part of the view hierarchy.

So the ultimate lesson here, for fellow Mac Catalyst developers, is that if you are experiencing instances where a purchase failure occurs, examine carefully your app’s view hierarchy and ensure there is as direct and visible as possible a path between your purchasing viewController and the rootViewController of the current scene’s key window.

Before I close here, I have one final comment that might prove helpful to Mac Catalyst developers.  My app is a document-based app, so I use a subclass of the UIDocumentBrowserViewController that presents the relevant document using a custom viewController.  I have found that for the Mac Catalyst version of my app, the system is not as good as I would like it to be at clearing from memory a documentBrowserViewController once the user closes the window of their accompanying document.  Merely destroying the documentBrowserViewController’s scene, for instance, is insufficient for that clearing to occur.  Among other reasons why destroying the scene isn’t enough: my Instruments-based analysis of memory leaks involving the documentBrowserViewControllers suggests that there are retain cycles involved in Apple’s underlying implementation of the setting of certain ones of the UIDocumentBrowserViewController properties— for instance, allowsPickingMultipleItems and allowsDocumentCreation— that prevent the documentBrowserViewControllers from being released when their accompanying windows are closed.  (In my app, not explicitly setting those properties resulted in the proper release of the UIDocumentBrowserViewControllers.)

The reason I am mentioning here the tendency for UIDocumentBrowserViewControllers to invisibly “hang around” in Mac Catalyst apps is that StoreKit purchase failures can also result if StoreKit associates itself with one of the lingering, invisible documentBrowserViewControllers instead of your UI’s purchasing viewController.  The moral here is to be especially vigilant about ensuring, in Mac Catalyst apps, that there are no UIDocumentBrowserViewControllers lingering in the background that might be silently interfering with StoreKit’s presentation of its payment sheet.

View original
Did this post help you find an answer to your question?

4 replies

C
Forum|alt.badge.img+4
  • Chad Mohler
  • Author
  • Helper
  • 9 replies
  • June 17, 2025

As a follow-up to my initial post above, I thought I would note that the errors described in my initial post have now consistently occurred over a three-day period, providing more evidence that the problem is not just a temporary one with Apple’s sandbox server.

C
Forum|alt.badge.img+4
  • Chad Mohler
  • Author
  • Helper
  • 9 replies
  • June 18, 2025

A second follow-up: I have now tried sandbox testing of the app’s in-app purchasing on three separate macOS versions: 13 (Ventura), 14 (Sonoma), and 15 (Sequoia).  The in-app purchasing still works perfectly well on 13 and 14; it’s only on 15 (Sequoia) that it fails.  So it appears that the in-app purchase failure described above is a problem unique to macOS Sequoia.

(I have not yet tried the in-app purchase on macOS 26 Tahoe, since, for other reasons, the app is not yet compatible with macOS 26.)

chris_perriam
RevenueCat Staff
Forum|alt.badge.img+4
  • chris_perriam
  • RevenueCat Staff
  • 56 replies
  • June 20, 2025

​@Chad Mohler and I are working together in a private conversation to determine the root cause of this. We’ll report back here with the findings.

C
Forum|alt.badge.img+4
  • Chad Mohler
  • Author
  • Helper
  • 9 replies
  • Answer
  • June 24, 2025

​@chris_perriam and I have had productive correspondence on this issue, and I have also done additional investigation of my own.  What I have discovered is that particularly for Mac Catalyst apps, Apple’s StoreKit is especially sensitive to the view / viewController / window context for the proper presentation of its payment sheet.

Just to give an example of that presentation context sensitivity: I was able to eliminate the purchase failures described above by presenting the UIViewController responsible for managing the purchase with a modalPresentationStyle of .formSheet rather than .fullScreen.  The fullScreen presentation of the purchasing viewController from the window’s rootViewController hid/obscured that rootViewController and was apparently enough to prevent the proper presentation of the StoreKit payment sheet.

The payment sheet’s sensitivity to the conditions of presentation seems somewhat similar to the problem, noted in my original post above and its reference to an earlier RevenueCat information item that iOS 18.2 users were experiencing.  As noted in the RevenueCat item, for those iOS 18.2 users, the payment sheet was not being displayed if the current scene's key window root view controller was not a part of the view hierarchy.

So the ultimate lesson here, for fellow Mac Catalyst developers, is that if you are experiencing instances where a purchase failure occurs, examine carefully your app’s view hierarchy and ensure there is as direct and visible as possible a path between your purchasing viewController and the rootViewController of the current scene’s key window.

Before I close here, I have one final comment that might prove helpful to Mac Catalyst developers.  My app is a document-based app, so I use a subclass of the UIDocumentBrowserViewController that presents the relevant document using a custom viewController.  I have found that for the Mac Catalyst version of my app, the system is not as good as I would like it to be at clearing from memory a documentBrowserViewController once the user closes the window of their accompanying document.  Merely destroying the documentBrowserViewController’s scene, for instance, is insufficient for that clearing to occur.  Among other reasons why destroying the scene isn’t enough: my Instruments-based analysis of memory leaks involving the documentBrowserViewControllers suggests that there are retain cycles involved in Apple’s underlying implementation of the setting of certain ones of the UIDocumentBrowserViewController properties— for instance, allowsPickingMultipleItems and allowsDocumentCreation— that prevent the documentBrowserViewControllers from being released when their accompanying windows are closed.  (In my app, not explicitly setting those properties resulted in the proper release of the UIDocumentBrowserViewControllers.)

The reason I am mentioning here the tendency for UIDocumentBrowserViewControllers to invisibly “hang around” in Mac Catalyst apps is that StoreKit purchase failures can also result if StoreKit associates itself with one of the lingering, invisible documentBrowserViewControllers instead of your UI’s purchasing viewController.  The moral here is to be especially vigilant about ensuring, in Mac Catalyst apps, that there are no UIDocumentBrowserViewControllers lingering in the background that might be silently interfering with StoreKit’s presentation of its payment sheet.

chris_perriam
1 person likes this
  • chris_perriam
    chris_perriam

Reply


Most helpful members this week

Terms & ConditionsCookie settingsAccessibility statement

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings