fix: report the client as akd, not Xcode, to stop Apple refusing sign-in with 503

[parawanderer]

Fixes #268 (and #269).

Problem

Every sign-in fails with Error response for GSA request: 503.

Apple's edge refuses any POST to gsa.apple.com/grandslam/GsService2 whose X-MMe-Client-Info names com.apple.dt.Xcode, before any credential is examined — it answers a 190-byte HTML page from Server: Apple in about 0.2s rather than a GSA plist. com.apple.akd is the daemon that actually performs this request on macOS, and is answered normally.

Reproducing it, without an account

curl -so /dev/null -w '%{http_code}\n' -X POST --data-binary t \
  -H 'X-MMe-Client-Info: <MacBookPro18,3> <Mac OS X;13.4.1;22F8> <com.apple.AOSKit/282 (com.apple.dt.Xcode/3594.4.19)>' \
  https://gsa.apple.com/grandslam/GsService2      # 503

curl -so /dev/null -w '%{http_code}\n' -X POST --data-binary t \
  -H 'X-MMe-Client-Info: <MacBookPro18,3> <Mac OS X;13.4.1;22F8> <com.apple.AuthKit/1 (com.apple.akd/1.0)>' \
  https://gsa.apple.com/grandslam/GsService2      # 401 — it reached the service

And with this library's own request shape and real anisette data, one variable changed:

X-MMe-Client-Info app token	Result
com.apple.dt.Xcode/3594.4.19	HTTP 503, 190-byte edge page
com.apple.akd/1.0	HTTP 200, a real GSA plist

Credit

The isolation is AltStore's, in altstoreio/AltStore#1790, shipped in AltServer 1.7.6. They established that only the app token matters — bumping the Xcode version does not help, and the user agent, the hardware/OS portion of the header, and which edge IP is used make no difference. Dadoum/anisette-v3-server#60 is the same one-token change. The same block took out SideStore, Macless Haystack and OpenBubbles.

Testing

Verified end to end against a real Apple ID: sign-in that had failed with 503 for days now completes. Done on a fork of this library where the GSA call site composes the header separately; on main that call site reads self._anisette.client, which this changes.

One thing worth checking if you patch further: client is also used by get_headers(with_client_info=True), so this changes that too. That appears correct — akd is the truthful claim for these requests — but you will know better than I do whether any endpoint expects the Xcode identity specifically.

Interactively co-authored by Claude Code and @parawanderer

[malmeloo]

Thanks, adjusting the anisette client info is definitely the right approach. The additional client info itself still identifies as Xcode for e.g. 2FA, but that doesn't appear to be causing any issues.