Hello,
We are using the UPI device validation APIs on iOS 26+ in a production banking/UPI app, and we are seeing a recurring failure from CoreTelephony that we need guidance on.
API / entitlement
- Framework: CoreTelephony
- API: CTCellularPlanStatus.checkValidity(ofToken:)
- Related: CTCellularPlanStatus.token()
- Entitlement: com.apple.developer.upi-device-validation
- Availability: iOS 26.0+
Minimal call site do { let isValid = try await CTCellularPlanStatus.checkValidity(ofToken: token) // isValid == true/false -> expected outcomes } catch { // Unexpected: API throws instead of returning Bool print(error.localizedDescription) }
Error error.localizedDescription is:
- English: Couldn't communicate with a helper application.
- Same failure also appears with a localized Hindi message on Hindi-locale devices.
This is distinct from checkValidity(ofToken:) returning false (token/SIM mismatch). Here the API throws, so we cannot tell whether the token is valid.
In production we currently only have this localizedDescription from telemetry.
Production observations (large fleet, last few days)
- Observed only on production user devices so far; we have not reproduced it reliably on lab hardware.
- Occurs across multiple iOS 26.x builds (notably 26.5.2, 26.5, 26.6; also seen on 26.0-27.0). Not limited to a single patch.
- Seen on many iPhone models (not one SKU).
- Latency is bimodal for the same error string:
- large share fails in under 100 ms (immediate)
- another large share fails after about 2-10+ seconds (timeout-like)
- Observed under Wi-Fi, cellular (4G/5G), and No Connection / radio-not-ready conditions.
- Same device can emit many identical failures within about 1 second when validity is checked from multiple call sites concurrently.
- Token generation (CTCellularPlanStatus.token()) and successful checkValidity work for the vast majority of users; this throw is a smaller but material failure class.
Questions for Apple
- Is "Couldn't communicate with a helper application." an expected / documented failure mode of checkValidity(ofToken:) (for example CommCenter/XPC unavailable, radio not ready)?
- What conditions typically trigger this error from checkValidity(ofToken:)?
- Recommended client handling: retry (with backoff)? treat as transient and skip forcing re-binding? surface to user?
- Does validation require cellular registration / SIM ready state even when docs indicate internet is not required?
- Any known issues on specific iOS 26.x builds, dual-SIM, eSIM, or airplane-mode transitions?
- Is concurrent checkValidity from multiple tasks unsupported / unsafe?
Because this is currently production-only and not reliably reproducible on lab devices, we cannot attach a sysdiagnose or Instruments trace at this time. We can share aggregated production telemetry and API details via Feedback Assistant if helpful.
Thank you.