Summary
Our Live Caller ID Lookup deployment works end-to-end from an Xcode-signed build but fails on the App Store build of the same app, on the same device, same network, same Apple ID. On the production build every authenticated request fails locally in ~47 ms, before any packet leaves the device.
Our Identity & Trust configuration in CloudKit Console has read "Approved" since 2026-08-08.
Device log at the moment of failure
nw_endpoint_proxy_handler_should_use_proxy: "Proxies not present, but required to fail closed"
ciphermld(CipherML) <Error>: queryStatus(for:options:) threw an error:
Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline."
NSErrorFailingURLKey=https://<our-issuer-host>/token-key-for-user-token
_NSURLErrorPrivacyProxyFailureKey=true
NSUnderlyingError={NSPOSIXErrorDomain Code=50 "Network is down"}
(_NSURLErrorNWPathKey=satisfied, Wi-Fi up, LQM: good)
Control experiment: the device's privacy proxy stack is healthy at that exact moment
0.93 seconds before our extension is refused, the same device attaches a proxy to another connection without any problem:
11:51:59.417 mDNSResponder nw_endpoint_proxy_add_config_if_applicable
Adding proxy masque Proxy: https://mask.icloud.com:443
11:52:00.337 ciphermld [C15 ... bundle id: <our extension>, proxy fail closed] start
11:52:00.346 ciphermld Proxies not present, but required to fail closed
System state in the same capture:
Privacy Proxy Service Status: 1
Privacy Proxy User Tier: 1
Privacy Proxy Networks: (<Cellular, Active>, <WiFi, Active>)
Counts across the capture: nw_endpoint_proxy_add_config_if_applicable appears twice (mDNSResponder and Safari SafeBrowsing), while Proxies not present appears 16 times, all from ciphermld, all for our extension's bundle id. No connection made on behalf of our extension is ever given a proxy configuration. Reproduced on two networks and after a device restart, with the device charging and Low Power Mode off.
Apple's own endpoint already recognises our issuer
11:51:59.405 ciphermld(CipherML) Fetching token issuer directory from
https://gateway.icloud.com/pat-issuer-directory?issuer=<our-issuer-host>
11:52:00.332 200, 1511 bytes, 928 ms
Our validation Bearer token from the onboarding submission also returns 200 on /token-key-for-user-token when Apple's validator calls it, which we observe on our server several times a day.
A second observation that may be the key
In apple/pir-service-example issue #139 an Apple engineer stated that once onboarding is complete, "all requests ... will automatically use OHTTP even when it is a development build".
We captured our development build today with full device logging. Every one of its connections goes directly to our PIR host over QUIC, with no proxy fail closed stamp, and the words ohttp, oblivious, mask.icloud and our OHTTP gateway hostname appear zero times in the capture:
16 connections, all: Hostname#<our-pir-host>:443, attribution: developer
"proxy fail closed": 0
"Proxies not present": 0
If a completed onboarding forces OHTTP even for development builds, then our development build going direct indicates the relay configuration was never distributed for our extension's bundle id, despite the console showing "Approved".
Fleet-level data, not a single device
On the day of release, 40 distinct premium accounts on the current App Store build fetched their user tier token from our backend. Across that entire day our PIR service saw zero Privacy Pass issuances and zero queries from App Store builds. For contrast, a single development-signed device produced 144 /issue requests in one day earlier in the month.
What we already checked and fixed on our side
- HTTP/2 ALPN negotiates on all three hosts (service, issuer, gateway).
- The DNS TXT ownership record is in place.
- The OHTTP gateway serves a valid key config (X25519 / HKDF-SHA256 / AES-128-GCM).
- The PIR use case names match the required
<extension bundle id>.block/.identityformat exactly. - The validation identity +1 408 555 1212 "Johnny Appleseed" is present in the live corpus.
- We found and fixed a real defect of our own: our OHTTP gateway's allowed target origin list was missing the issuer host. We corrected it and restarted the gateway (its HPKE key config was byte-identical afterwards, so no key rotation occurred). The failure reproduced with an identical signature seven minutes later, and the device log confirms these hops never touch our gateway anyway.
Questions
- Is relay / privacy proxy provisioning for a production bundle id a separate step after the Identity & Trust configuration is approved, and what is the expected propagation time?
- Is there any way for a developer to check provisioning status? Right now an "Approved" badge and a completely non-functional production build look identical from our side.
- Is there a supported way to exercise the production privacy proxy path before shipping to the App Store? Development builds bypass it by design, so the first real test of the production path was made by paying customers. This seems likely to affect other adopters.
- Is provisioning keyed on the extension bundle id, the app bundle id, or the team id? Other system consumers on the same device receive proxy configurations normally.
- We accidentally submitted two identical configurations three minutes apart on 2026-08-08 and both show "Approved". Can a duplicate block or confuse provisioning, and should one be revoked?
Environment: iPhone 17 Pro Max, iOS 26.6.1, Xcode 26.5 (17F42). App Store build version 14 (36).
Feedback Assistant report with full device logs: FB24501570 GitHub issue with the same detail: https://github.com/apple/pir-service-example/issues/162
Configuration ID: 693155e2-b8ba-4b47-9b6c-64fd97677386 and a1959377-8069-4225-87b9-c1ff81016611