purchases-ios icon indicating copy to clipboard operation
purchases-ios copied to clipboard

`enableAdServicesAttributionTokenCollection` blocking background threads

Open joaopdcgarcia opened this issue 8 months ago • 4 comments

Describe the bug

In the TestFlight environment, enabling RevenueCat’s enableAdServicesAttributionTokenCollection() (used to track Apple Search Ads attribution) was causing significant delays in presenting the push notification authorization prompt. This was particularly noticeable on devices with many past purchases and subscriptions (large receipts to process / to be used for attribution), likely due to expensive or blocking AdServices token fetches running concurrently with receipt processing.

Commenting out Purchases.shared.attribution.enableAdServicesAttributionTokenCollection() makes issues go away.

  1. Environment
    1. Platform: ios
    2. SDK version: 4.43.4
    3. StoreKit version:
      • [x] 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:
    5. Xcode version:
    6. Device and/or simulator:
      • [x] Device
      • [ ] Simulator
    7. Environment:
      • [ ] Sandbox
      • [x] TestFlight
      • [ ] Production
    8. How widespread is the issue. Percentage of devices affected.

Happens to users with a lot of purchases in a TF environment.

  1. Debug logs that reproduce the issue. Complete logs with Purchases.logLevel = .verbose will help us debug this issue.
Logs here
  1. Steps to reproduce, with a description of expected vs. actual behavior

With a device that has purchased a lot of times while testing, launch the app.

Expected Behavior: App should function normally.

Observed Behavior: UI is not blocked but we get some services calls and notification permission request not working (system prompt not displayed and data not coming through) for a few seconds / minutes.

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

To isolate the cause of the delay, I triggered a manual crash when the notification alert took too long to appear and examined the stack trace.

Image

  • We can see multiple threads (5+) were simultaneously waiting on AAAttributionTokenWithError via RevenueCat’s internal AdServicesToken logic

Each thread is stuck on

semaphore_timedwait_trap
dispatch_semaphore_wait
AAAttributionRequester.attributionTokenWithError
  • This indicated that multiple async tasks were accessing Apple’s AdServices API at the same time (likely through RevenueCat), all waiting on the same semaphore.
  • This overloaded the background thread pool and delayed system responsiveness — even though the main thread itself wasn’t technically blocked.
  1. Additional context Add any other context about the problem here.

joaopdcgarcia avatar Apr 14 '25 16:04 joaopdcgarcia

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

RCGitBot avatar Apr 14 '25 16:04 RCGitBot

Hi @joaopdcgarcia, Is this still happening in the latest version of the SDK? Thanks!

nyeu avatar Sep 29 '25 16:09 nyeu

Hi @joaopdcgarcia, Is this still happening in the latest version of the SDK? Thanks!

We ended up disabling this for TF users, which doesn't make a difference and in production it wouldn't happen.

joaopdcgarcia avatar Sep 29 '25 17:09 joaopdcgarcia

Hi @joaopdcgarcia, thanks for letting me know!

nyeu avatar Oct 09 '25 16:10 nyeu