PassKit silently rejects every .pkpass from one Team ID — client-side ruled out, DTS silent 5 weeks — how to escalate?

Looking for guidance on how to escalate a PassKit issue that appears to be at the team-account level, after two months of exhausting every client-side variable.

SYMPTOM

Every .pkpass I sign under team XMJKFS3D66 (Mesh Community AS, Norway) is silently rejected on install with:

"Sorry, your Pass cannot be installed to Passbook at this time."

The rejection is silent — no user-facing hint at what iOS objects to.

WHAT I'VE RULED OUT

Reproduced across:

  • 3 separate Pass Type IDs (pass.com.meshcommunity.membership original, .membership after re-issue, brand-new pass.com.meshcommunity.kiosk)
  • 2 independently-issued signing certs on the same identifier
  • 3 iPhone testers on 3 different iOS builds with different Apple IDs

Paris Pinkney (WWDR DTS) sent me the standard 6-item team-wide checklist on Aug 5, and I'm verifiably clean on all six:

  1. Cert not expired — notBefore 2026-07-08, notAfter 2027-08-07
  2. Cert not revoked — OCSP status "good" from ocsp.apple.com/ocsp03-wwdrg404
  3. WWDR G4 intermediate matches cert issuer OU
  4. Program membership active, latest PLA accepted
  5. Both Pass Type IDs Active in Portal
  6. Team ID XMJKFS3D66 matches everywhere (pass.json.teamIdentifier + cert OU)

Also verified:

  • openssl smime -verify -in signature -inform DER -content manifest.json -noverify → "Verification successful"
  • Full chain in signature: Pass Type ID cert → WWDR G4 → Apple Root CA
  • PKCS#7 detached, DER, SHA-256, -noattr
  • CDN serves application/vnd.apple.pkpass

THE DEFINITIVE TEST

To rule out the last remaining plausible client-side hypothesis (missing primaryFields causing a silent layout rejection, suggested by an independent review), I built a minimal known-good pass:

{ "formatVersion": 1, "passTypeIdentifier": "pass.com.meshcommunity.kiosk", "teamIdentifier": "XMJKFS3D66", "organizationName": "Mesh Community", "serialNumber": "10001", "description": "Mesh Kiosk Pass", "logoText": "Mesh Community", "foregroundColor": "rgb(255, 255, 255)", "backgroundColor": "rgb(25, 25, 25)", "barcodes": [ { "format": "PKBarcodeFormatQR", "message": "10001", "messageEncoding": "iso-8859-1" } ], "generic": { "primaryFields": [ { "key": "name", "label": "MEMBER", "value": "Test User" } ] } }

  • ASCII-only, no emoji, no hyphenated serial, includes primaryFields, minimal fields
  • Same signing recipe, same G4 chain, verify clean
  • Same 6 standard PNG assets (icon + logo, 1x/2x/3x)

Result on a fresh iPhone: identical silent rejection. Same "Sorry, your Pass cannot be installed to Passbook at this time." dialog.

At this point every plausible client-side variable has been isolated and eliminated. The block appears to be at team level inside Apple's PassKit backend — invisible from the Developer Portal.

WHAT APPLE HAS DONE SO FAR

  • DTS Case-ID: 21008005 — opened 2026-07-13, reproducer.zip attached same day
  • Assigned engineer: Paris Pinkney (WWDR, DTS) since 2026-08-05
  • Sysdiagnose: filed via Feedback Assistant as FB24516356 on 2026-08-26 (device Serial HWT3HQ2F9F, SEID captured, iOS 23G71, reproduction timestamp 2026-08-13 11:02:15 +0200) with Wallet debug profile installed on the device before reproduction
  • Radio silence since 2026-08-17 — 5 weeks and counting, including no reply to a polite check-in on 2026-09-08

WHAT I'M ASKING

  1. Anyone at Apple engineering seeing this: is there a way to accelerate the Case-ID 21008005 / FB24516356 log review? The PassbookUIService / PassKit / PassKitCore entries around the timestamp above would settle this in minutes on your end.

  2. Any developer who's hit team-wide PassKit rejection before: what unblocked it? Was it a PLA re-acceptance, a Developer Program Support ticket (separate from DTS), a re-provisioning request, something else?

  3. Any way to inspect a team's backend PassKit entitlement state from outside (a Portal page, an endpoint, an xcrun command), so I can either confirm my suspicion or eliminate it myself?

  4. Any known-good published .pkpass from a Norwegian-registered (C=NO) Developer Team I can diff against, just to eliminate country-registration as a factor?

Working Apple Wallet is a launch-blocker for the Mesh Community Workbar Kiosk rollout — we're currently shipping Google Wallet + QR-in-email as a full fallback and it works everywhere including iPhone, so no user is being turned away. But we'd like to close the Apple Wallet loop, and after 2 months I've run out of things to try from my side.

Any pointer welcome. Happy to share the full evidence bundle privately with anyone at Apple who can help.

Thanks, Mesh Community AS · Team ID: XMJKFS3D66

Hi @MeshCommunity,

I apologize for the lengthy delay while we prepared for the launch of iPhone Duo and iPhone 18 Pro.

You wrote:

Anyone at Apple engineering seeing this: is there a way to accelerate the Case-ID 21008005 / FB24516356 log review? The PassbookUIService / PassKit / PassKitCore entries around the timestamp above would settle this in minutes on your end.

Yes, your bug report is with the Wallet engineering team. However, the sysdiagnose logs provided don't contain the actual rejection moment reported—specifically, the SecTrustResultType and the SecTrustCopyFailureDescription explaining the underlying cause of the trust error.

Please install the Wallet logging profile, then reproduce the issue again, write down the timestamp of when the issue occurs, and then attach new sysdiagnose logs to your existing bug report (FB24516356).

Next, we need to rule out a cert / Apple Extension OID mismatch by doing the following:

  1. Dump the leaf cert's OIDs directly (openssl x509 -text on the signing cert, looking at the custom extensions, not just CN) and diff those byte-for-byte against pass.json's fields — including for the specific Pass Type ID cert used, not just the portal's UI display of it.
  2. Re-download a fresh cert from the portal for the diagnostic Pass Type ID created 2026-07-08 and re-sign with that, to rule out a stale/corrupted local cert.

Important: Your pass construction, hashing, and signing process appear to be correct. I've already escalated this issue to the engineering team that handles certificates and profiles, and will respond here (as well in your existing bug report) once I have more information to share with you. You do not need to change your build pipeline.

Again, please provide an updated sysdiagnose and timestamp so the investigating team can map the exact trust error with our internal configuration and certificates.

Cheers,

Paris X Pinkney |  WWDR | DTS Engineer

PassKit silently rejects every .pkpass from one Team ID — client-side ruled out, DTS silent 5 weeks — how to escalate?
 
 
Q