[izaankml]

Problem

#1790 fixed the HTTP 503 sign-in for AltServer and AltDaemon by sending com.apple.akd/1.0 in X-MMe-Client-Info, but on-device sign-in still fails. FetchAnisetteDataOperation copies the client identity from the anisette server, and every server in anisette-servers.json still reports the blocked Xcode identity (/v3/client_info, 2026-09-12):

Server	client_info
ani.sidestore.io, ani.sidestore.app, ani.sidestore.zip	<MacBookPro13,2> <macOS;13.1;22C65> <com.apple.AuthKit/1 (com.apple.dt.Xcode/3594.4.19)>
ani.846969.xyz	same
ani.npeg.us	same

Apple drops the request on the client token alone. The same request with com.apple.akd/1.0 returns 401 instead of 503, so it reaches the service.

Fix

AltStore sends its own client identity instead of the server's, the same way AltServer's AnisetteDataManager already does, using a fixed model and OS with com.apple.akd/1.0 as the client. A current OS instead of macOS;13.1 also fixes the repeated two-factor prompts from #1772.

Testing

On device from this branch on classic, sign-in with ani.sidestore.io completes and Delta and Aidoku install on a free account. After one verification code, later sign-ins and a refresh the next day needed no new code. Without the change the same device got 503 on every refresh for two days.

Related: #1776, #1782, #1772

[sshane]

Confirmed on device (iPhone 17 Pro, iOS 27 beta, AltStore Classic 2.3b2) with <Mac17,3> <macOS;27.0;26A428> <com.apple.AuthKit/1 (com.apple.akd/1.0)>: init, complete and apptokens all return 200, the Xcode token is issued with no second factor, and refresh works. The same request naming com.apple.dt.Xcode returns 503.

[catdkny]

Confirming the diagnosis independently, and +1 to merging this.

I re-checked all five servers in anisette-servers.json today (2026-09-14), two days after your table. Every one still reports the blocked identity:

ani.sidestore.io    <MacBookPro13,2> <macOS;13.1;22C65> <com.apple.AuthKit/1 (com.apple.dt.Xcode/3594.4.19)>
ani.sidestore.app   same
ani.sidestore.zip   same
ani.846969.xyz      same
ani.npeg.us         same

So the on-device path is still broken on classic. #1790 did flag this exposure — "Third-party anisette servers commonly serve this same stale Xcode string and are blocked for the same reason. They need the same change independently." — but it framed the remedy as something the operators would apply. Four days on, none of the five has redeployed. That framing was wrong, and this PR has the right read: the dependency on them is itself the bug. I also confirmed the identity this PR proposes works at the auth layer, not just at the edge: a well-formed SRP init plist carrying real anisette data and a nonexistent account returns HTTP 200 with ec=-20101 "Your account information was entered incorrectly.", versus a 190-byte HTML page from Server: Apple for the servers' current string.

Small correction to the description: the akd curl returns 401 here, not 404. It doesn't change the conclusion — both mean the request reached the service instead of being dropped at the edge.

One suggestion, as a follow-up rather than a blocker

This replaces a hardcoded identity that Apple blocked with another hardcoded identity, and pins a beta OS build while doing it. #1790 said the same of its own fix — "This treats the symptom. Apple could block com.apple.akd/1.0 next; the durable fix is to derive the identifier from the system instead of hardcoding it." — and that still stands. On iOS there is no system Mac identity to derive from, so the closest equivalent is making the value updatable without a release. Otherwise, when com.apple.akd/1.0 goes the way of the Xcode token, every user is stuck again until a new build ships and each of them sideloads it.

AnisetteServerManager already fetches https://cdn.altstore.io/file/altstore/altstore/anisette-servers.json, which AltStore controls. Carrying the identity there would turn the same incident into a one-file CDN edit instead of a release:

{
  "clientInfo": "<Mac15,7> <macOS;27.0;26A5378j> <com.apple.AuthKit/1 (com.apple.akd/1.0)>",
  "userAgent": "akd/1.0 CFNetwork/1568.100.1",
  "servers": [ ... ]
}

AnisetteServer.clientInfo from this PR becomes the fallback when that fetch fails, so nothing here is wasted — same constant, just with a remote override in front of it. Flagging it as an idea rather than claiming it — no expectation that it belongs in this PR.

Minor, while you're in there: userAgent is pinned to CFNetwork/808.1.4, which sits oddly beside the argument for keeping the OS current. It is harmless — I verified the User-Agent has no bearing on the edge block, testing akd/1.0 CFNetwork/808.1.4, /978.0.7, /1568.100.1, curl/8.7.1 and a browser UA, all 503 with the Xcode token — but it may be worth making consistent with the OS you're declaring.

[izaankml]

Good catch, the akd probe returns 401, fixed the description. Agree the remote override belongs in a follow-up PR so this one can land as is, and can align the User-Agent there too.

[izaankml]

Closing this. Riley's 7428029 fixed the Xcode-token 503 on classic, and since Oct 12 Apple rejects a Mac client identity paired with the Android anisette these servers generate (-80045), which is what this PR forces. #1835 takes the approach that works now.