feat(cli): create APNs keys with a native Apple sign-in instead of Node.js

[ArnabChatterjee20k]

Stacked on #1989. Draft until it has signed in to a real Apple account.

What

appwrite init apns --create-key no longer needs Node.js or @expo/apple-utils. The CLI signs in to Apple and calls the Developer portal itself, in Go.

How

Apple has no public API for creating APNs keys, so this does what the portal's web pages do. The sign-in follows fastlane's spaceship (readable, MIT, kept current), and the key calls follow @expo/apple-utils 2.2.1.

Sign-in (internal/apple/auth.go, srp.go)

1. Widget key from HEAD appstoreconnect.apple.com/logout (the widgetKey in the redirect), sent without cookies and without following the redirect. Falls back to the copy saved by an earlier run, then the old olympus/v1/app/config (removed by Apple in September 2026).
2. SRP-6a: POST idmsa.apple.com/appleauth/auth/signin/init, then PBKDF2-SHA256 over the password's SHA-256 (hex-encoded first for s2k_fo), then signin/complete with m1/m2. The password never leaves the machine.
3. Hashcash from GET /appleauth/auth/signin?widgetKey=… (X-Apple-HC-Bits / X-Apple-HC-Challenge), sent as X-Apple-HC.
4. On 409, two-factor: GET /appleauth/auth for the options, then the code pushed to trusted devices, or a text message (typing sms, or automatically when the account has no trusted devices), POST …/verify/{trusteddevice|phone}/securitycode. A wrong code is asked again up to three times. Then GET /appleauth/auth/2sv/trust.
5. GET olympus/v1/session confirms the session. Cookies are saved to ~/.appwrite/apple/session.json (0600), so later runs skip the sign-in. A saved session for a different Apple ID than the one in the environment is not reused.

Keys (portal.go), under developer.apple.com/services-account/QH65B2/:

• account/listTeams.action: one team is used directly, several are offered as a choice.
• account/auth/key/list: also hands out the csrf / csrf_ts tokens the create needs.
• account/auth/key/v2/create with scope: team, serviceConfigurations: {U27F4V844T: []} and one APNs request for environment: all.
• account/auth/key/download returns the .p8.
• "maximum allowed number of Keys" maps to the existing MaxKeysError, which lists the team's keys.

Credentials: APPWRITE_APPLE_ID / APPWRITE_APPLE_PASSWORD only, so a variable set up for another tool never signs in by accident. The CLI prints which variable it used, never the value. Otherwise it asks through the CLI's prompts, with the password hidden.

Environment: --environment production|sandbox|all (default all) decides which Appwrite APNs providers are set up and must exist for "already set up", and, with --create-key, the environment the Apple key works in. spaceship and apple-utils only ever send "all"; "production" and "sandbox" are unconfirmed until a real run.

Failures: with --create-key, a failed sign-in or key creation stops the command with the reason instead of falling back to a .p8 in the project folder. Choosing the Apple sign-in from the prompt still falls back to the other options. The session is saved as soon as Apple accepts the code, and an expired session's trust cookie is kept so signing in again skips two-factor.

Correctness

• srp_test.go checks the PBKDF2 key, A, m1 and m2 for both s2k and s2k_fo against values computed by fastlane-sirp (the gem spaceship uses), and hashcash against spaceship's. These include the non-obvious parts: x has no username; A, S and m2 drop leading zero bytes; k and u pad to 256 bytes.
• apple_test.go runs the whole flow against a fake Apple that does the server side of SRP: two-factor with a wrong code first, session reuse with no questions or sign-in requests, credentials from the environment (password never logged), wrong password (no session saved), full team, team choice and an unknown team, and widget-key fallback.
• The init apns tests are unchanged apart from the fake no longer being a Node error.

Not yet verified

• A real sign-in against Apple. The protocol was cross-checked against spaceship's and apple-utils' current code, but only a real account proves it.
• Accounts with security keys or Managed Apple IDs, which this sign-in can't handle (neither can spaceship's). Those users keep the browser and file options.

Notes against the reverse-engineering doc

Checked against the sources, a few details differ from the first write-up:

• Cookie portal calls use services-account/QH65B2/. services-account/v1/ is for the token client.
• The hashcash challenge comes from GET /appleauth/auth/signin?widgetKey=, not from the signin/init response.
• Codes are verified with POST, not PUT.
• Key fields are keyId / keyName.

[ArnabChatterjee20k]

Closing in favour of the adapter split. Everything here is carried over:

• feat(cli): adapter-based APNs key setup for init apns --create-key #1992 (base): the apns adapter contract, --provider / APPWRITE_APNS_SETUP, APPWRITE_APPLE_ID / APPWRITE_APPLE_PASSWORD, --environment, and stopping when --create-key fails.
• feat(cli): appwrite APNs key setup (native Go Apple sign-in) #1993: this native Go sign-in and key creation (SRP, hashcash, two-factor, the saved and trusted session, portal key calls), as the default appwrite setup.

The branch is kept.