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

macOS App hanging for at least 2000 ms because of check for macOS app running on the main thread. #3871

Open
8 of 12 tasks
jb-apps opened this issue May 6, 2024 · 3 comments
Labels

Comments

@jb-apps
Copy link

jb-apps commented May 6, 2024

Describe the bug
A clear and concise description of what the bug is. The more detail you can provide the faster our team will be able to triage and resolve the issue. Do not remove any of the steps from the template below. If a step is not applicable to your issue, please leave that step empty.

  1. Environment
    1. Platform: macOS
    2. SDK version: 4.40.1
    3. StoreKit version:
      • StoreKit 1
      • StoreKit 2 (enabled with usesStoreKit2IfAvailable(true))
    4. OS version: Sonoma 14.1.1
    5. Xcode version: 15.3
    6. Device and/or simulator:
      • Device
      • Simulator
    7. Environment:
      • Sandbox
      • TestFight
      • Production
    8. How widespread is the issue. Percentage of devices affected. 100% users.
  2. Debug logs that reproduce the issue. Complete logs with Purchases.logLevel = .verbose will help us debug this issue.
All good in debug, it only happens in production and in the App Store.
  1. Steps to reproduce, with a description of expected vs. actual behavior
  • Create a new macOS project.
  • Add revenueCat framework.
  • Set environment to prod.
  • Need to fiddle a little bit with the revenueCat SDK to make sure MapAppStoreDetector is called.

App hangs at status = SecStaticCodeCheckValidity
Screenshot 2024-05-06 at 22 28 15

It throws the following warning when running locally:
Screenshot 2024-04-22 at 15 37 56

  1. Other information (e.g. stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc.)
    Problem seems to be related to this code status = SecStaticCodeCheckValidity running on the main thread.

  2. Additional context
    It only happens on the App Store.

@jb-apps jb-apps added the bug label May 6, 2024
@RCGitBot
Copy link
Contributor

RCGitBot commented May 6, 2024

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

@aboedo
Copy link
Member

aboedo commented May 7, 2024

@jb-apps thanks for reporting! We'll get it fixed

aboedo added a commit that referenced this issue Aug 23, 2024
Alternative approach to #3875, also meant to address
#3871

We're currently looking at a field called Environment in the local
receipt to check whether the app is running in sandbox on macOS.

However, since it's an undocumented field, we can't trust that it will
always be there, so if the value is production then we check the
bundle's signature, which can be slow to run.

This PR changes that behavior so that we only perform that check if the
value for that variable isn't available, which would cause a receipt
parsing failure since it's marked as non-optional.

Still need to write tests for this, but it should be significantly
easier than for the other PR.
@aboedo
Copy link
Member

aboedo commented Aug 23, 2024

Sorry it took so long, but the fix is merged and will be a part of next release!

nyeu pushed a commit that referenced this issue Oct 2, 2024
Alternative approach to #3875, also meant to address
#3871

We're currently looking at a field called Environment in the local
receipt to check whether the app is running in sandbox on macOS.

However, since it's an undocumented field, we can't trust that it will
always be there, so if the value is production then we check the
bundle's signature, which can be slow to run.

This PR changes that behavior so that we only perform that check if the
value for that variable isn't available, which would cause a receipt
parsing failure since it's marked as non-optional.

Still need to write tests for this, but it should be significantly
easier than for the other PR.
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