Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Purchase methods do not support specifying the scene they should confirm in #4774

Open
11 of 12 tasks
marcpalmer opened this issue Feb 9, 2025 · 4 comments
Open
11 of 12 tasks
Labels

Comments

@marcpalmer
Copy link

Describe the bug

  1. Environment
    1. Platform: iOS, visionOS and macOS Catalyst
    2. SDK version: 5.14.5
    3. StoreKit version:
      • StoreKit 1 (default on versions <5.0.0. Can be enabled in versions >=5.0.0 with .with(storeKitVersion: .storeKit1))
      • StoreKit 2 (default on versions >=5.0.0)
    4. OS version: iOS 18.x, Catalyst 15.x
    5. Xcode version: 16.2+
    6. Device and/or simulator:
      • Device
      • Simulator
    7. Environment:
      • Sandbox
      • TestFlight
      • Production
    8. How widespread is the issue. Percentage of devices affected.
      Probably 100%
  2. Debug logs that reproduce the issue. Complete logs with Purchases.logLevel = .verbose will help us debug this issue.
N/A
  1. Steps to reproduce, with a description of expected vs. actual behavior

As noted in #4611 Apple have had issues in StoreKit with changes they made to have APIs support a confirmIn: parameter that takes a VC or scene that should be used to present the StoreKit UIs.

This is required because in modern apps multiple scenes can exist and we have to pass in the actual one we want to be handling the UI.

With SwiftUI we don't have to do this if we use Apple's modifiers for purchasing + showManagesSubscriptions etc. because they handle it internally as they know the current widow scene.

The "bug" or problem is that as a RevenueCat user I cannot do this, and RC does not offer the API for me to pass in a UIScene so that I can work it out myself and pass it in.

So I cannot work around problems where the StoreKit UI appears in the wrong window.

  1. Other information (e.g. stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc.)

See #4611

Apple's docs for the new showManageSubscriptions() https://developer.apple.com/documentation/storekit/appstore/showmanagesubscriptions(in:subscriptiongroupid:)

Apples docs for the new purchase() functions
https://developer.apple.com/documentation/storekit/product/purchase(confirmin:options:)-6dj6y

  1. Additional contextAdd any other context about the problem here.

We really need RC to allow us to pass in this visual context, and ideally also include its own view modifiers for purchase + showManageSubscriptions so that we don't have to do the hacky workarounds to get the UIScene ourselves.

@marcpalmer marcpalmer added the bug label Feb 9, 2025
@RCGitBot
Copy link
Contributor

RCGitBot commented Feb 9, 2025

👀 We've just linked this issue to our internal tracker and notified the team. Thank you for reporting, we're checking this out!

@marcpalmer
Copy link
Author

Note that as far as I am aware there is no workaround for this until RC adds the API. For example, I have a multi-window Catalyst app and the user can start a purchase from the Settings window, while the main window is also showing.

A lot of the time this results in the purchase sheet appearing in the main window instead of in the settings window, which is unexpected and problematic.

@MarkVillacampa
Copy link
Member

Hey @marcpalmer!

Thank you for filing this request, this is indeed a blind spot on the SDK for apps opening multiple windows. We're working to add support for passing a UIScene so the payment sheet can be opened in the right window.

@marcpalmer
Copy link
Author

Thanks @MarkVillacampa — is there a viable workaround to not call RC purchase calls and fetch the SK2 product and call purchase on that ourselves? Will RC do all the housekeeping properly or will we lose something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants