Skip to main content
Question

RevenueCat getCustomerInfo taking ~6 seconds on fresh install, but less than or equal 1 second shortly after — why?

  • June 30, 2026
  • 1 reply
  • 0 views

Forum|alt.badge.img

I'm calling Purchases.shared.getCustomerInfo from my intro screen / AppDelegate on a fresh install to check if the user is premium before routing them to the correct screen. On fresh install, this call takes approximately 6 seconds to return. However, if I call getCustomerInfo again a few seconds later, it returns in under 1 second.

Because of this delay, I can't reliably validate whether the user is premium at the point my intro screen needs to make a routing decision.

Setup:

  • SDK version: 5.80.0
  • Platform: Swift, UIKit
  • Call site: intro screen / AppDelegate, on first launch after install

Questions:

  1. Why is the first getCustomerInfo call so much slower than subsequent calls on a fresh install?
  2. Is this expected behavior (e.g. due to receipt fetch/validation on first call, with caching afterward), or could this indicate a configuration issue on my end?
  3. What's the recommended pattern for gating UI on entitlement status during this initial slow fetch — is there a way to speed up the first call, or should I be designing around it with a loading state / timeout fallback?

Any guidance on best practices here would be appreciated.

1 reply

Forum|alt.badge.img+4
  • Member
  • June 30, 2026

Hey ​@mehedi-hasan-4d1ac0 ,

RevenueCat documents that CustomerInfo is automatically fetched and cached when the SDK is configured and throughout the app lifecycle. Their docs also mention that getCustomerInfo() is safe to call frequently because, in most cases, it can return from cache without needing a network request.

So the faster second call is consistent with the expected caching behavior.

On a fresh install there may simply be no cached CustomerInfo yet, so the SDK may need to fetch the latest status before returning.

For routing, the safest approach is to configure RevenueCat as early as possible and show a short loading state while the first entitlement check completes, rather than immediately routing the user as non-premium while the request is still pending.