Skip to content

Apple is moving Xcode downloads to .aea — 27.3 announced as the last .xip release #499

Open

Description

@Ramanathan0310

Summary

Apple's download page for the Xcode 27.3 beta states that Xcode is now also offered as an Apple Encrypted Archive (.aea), and that 27.3 is the last release that will be distributed as .xip. If that holds, xcodes stops being able to install new Xcode releases from 27.4 onward.

I can't link the source: the notice is on the Xcode 27.3 beta entry in the developer downloads area, which is behind an Apple ID sign-in, so there's no public URL to point at. Reported here second-hand in case others have seen the same notice — happy to be corrected if someone reads it differently.

Current state

As far as I can tell there's nothing on this yet in either repo:

  • No issues or PRs matching aea in XcodesOrg/xcodes
  • No issues matching aea in XcodesOrg/XcodesApp
  • No mention of aea / Apple Encrypted Archive in any release notes back to 1.4.1 (latest: 2.1.0)

Filing so there's somewhere to collect information as the change lands.

Why it matters

xcodes install currently assumes a .xip and unarchives it (including the --experimental-unxip path). An .aea download would need a decrypt step before anything resembling the current unarchive flow. For anyone running xcodes unattended (CI, or a scheduled updater), this turns into a silent failure the first time Apple ships an .aea-only release.

Possible implementation note

macOS ships /usr/bin/aea, which may remove the need to implement the format directly — xcodes could shell out to it much as it already does for xip:

$ aea
Usage: aea command <options>

Commands:
  encrypt     Create a new encrypted archive `output_file` from the data in `input_file`
  decrypt     Decrypt the contents of encrypted archive `input_file` to `output_file`
  append      Append the contents of `input_file` to an existing encrypted archive `output_file`
  sign        Sign an existing encrypted archive `output_file`
  id          Print archive identifier for `input_file`
  remove-from-keychain  Remove credentials stored in Keychain for the input archive

The open question is key material. aea decrypt with no arguments fails at context creation, and the remove-from-keychain subcommand implies credentials get cached in the Keychain, so Apple's Xcode archives presumably carry a key tied to the signed-in developer session rather than being freely decryptable. Someone with access to an actual .aea Xcode download would need to confirm what aea id reports for it and what key the decrypt requires — that seems like the part that needs designing, rather than the unarchiving itself.

Environment

  • xcodes 2.1.0 (Homebrew)
  • macOS 27.3, Apple Silicon
  • Xcode 27.3 beta (27C5020n), installed via xcodes as a .xip — so the .xip path still works today

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions