A notarization stuck “In Progress” for 60 hours. A returning developer’s app failing validation with error 90286 because Automatic Signing prefixed the bundle ID with a 15-year-old Developer ID instead of a Team ID. A Canadian VoIP startup rejected under guideline 3.1.1 with no clear test for whether prepaid calling credits count as “intermediary currency.” These are three live forum threads from the past week, and they share one thing: there is no documented escalation path. The Developer System Status page is green. Feedback Assistant is not the right tool. You are alone with the tooling.

Stuck notarization: the diagnostic ladder

The pain in this thread: three notarytool submit jobs sit in In Progress for over 60 hours, notarytool log returns nothing, and the status page is green. Your queue can be stuck while everyone else’s flows.

1. Verify from the CLI, not the GUI

xcrun notarytool history \
    --apple-id you@example.com \
    --team-id ABCDE12345 \
    --keychain-profile "AC_NOTARY"

xcrun notarytool info <submission-uuid> \
    --keychain-profile "AC_NOTARY"

xcrun notarytool log <submission-uuid> \
    --keychain-profile "AC_NOTARY" log.json

If notarytool info shows status: In Progress and log returns nothing for more than four hours, that is abnormal.

2. Re-submit, don’t wait

A stuck submission cannot be cancelled. Bump the build number and resubmit:

agvtool next-version -all
xcrun notarytool submit MyApp.dmg \
    --keychain-profile "AC_NOTARY" \
    --wait

3. Open a DTS incident

Once you’ve confirmed the stall is account-specific and re-submission also stalls, open a paid DTS technical incident. Indie accounts get two incidents per membership year. Burn one.

4. File a Feedback Assistant report in parallel

Title it precisely: “notarytool submissions stuck In Progress >60h, account-level stall, status page green.” Include all submission UUIDs.

Validation errors 90286 and 91130: the Team ID prefix trap

The pattern in forum thread 835497: a developer updating an app for the first time since 2011 hits error 90286. Automatic Signing prefixed the bundle identifier with their personal Developer ID instead of their Team ID.

Rule: every bundle identifier in the application-identifier entitlement must be prefixed with your Team ID, not your old individual Developer ID.

How to confirm what you’re shipping

# Dump the embedded provisioning profile
security cms -D -i MyApp.app/embedded.provisionprofile

# Dump the entitlements baked into the binary
codesign -d --entitlements - --xml MyApp.app | plutil -convert xml1 -o - -

Look for the application-identifier key. It must read TEAMID.com.your.bundle.id.

How to fix it

1. In Signing & Capabilities, set Team to the Team ID-bearing entry.
2. Delete the project’s *.entitlements file references to the old identifier prefix. Re-add capabilities one at a time.
3. In App Store Connect, confirm the Bundle ID uses the Team ID prefix. If it doesn’t, open a DTS incident to correct it — App Store Connect won’t let you create a new record with the same display name.

Guideline 3.1.1 for VoIP and “intermediary currency”

The 3.1.1 rejection thread hits a real ambiguity. Prepaid calling credits are real-world services, but Apple’s review team can read them as “intermediary currency” and reject under 3.1.1.1.

Apple’s Review Guidelines section 3.1.3 explicitly exempts physical goods and services consumed outside the app — VoIP minutes to the PSTN qualify.

Concrete tactics

• Strip the in-app webview for credit purchases. Send users to Safari via a plain link.
• Submit a written appeal via Resolution Center. Cite section 3.1.3 directly. Reference competitor apps (Rebtel, Dingtone) that are approved.
• Request a phone call with App Review via the Resolution Center’s “Request a Call” affordance.

Appeal template

Our app sells prepaid telephony minutes for use on the global PSTN. Calls terminate on third-party carrier networks and are not consumed within the app. Per Review Guideline 3.1.3, “physical goods or services consumed outside the app” are exempt from in-app purchase requirements. Comparable approved apps include [list 2–3]. We have removed the in-app webview purchase flow. Please reconsider the rejection under 3.1.3 rather than 3.1.1.1.

What none of this fixes

Apple’s review and infrastructure operate on a queue model with no SLA for indie accounts. Build your launch timeline around that reality.

• Notarize a release candidate at least one week before launch.
• Validate signing on every CI build with codesign -d --entitlements -.
• Pre-validate against 3.1.1 ambiguity by emailing App Review pre-submission for niche categories.

---