xtool

xcode: tweaks to XcodeProjects API

Kabir Oberai · 2026-10-28 18:15:02 -04:00

b9d726ca1c

utils: better XToolCache location

Kabir Oberai · 2026-10-28 18:15:02 -04:00

e61a4a1cc6

utils: light refactoring

Undo

Kabir Oberai · 2026-10-28 18:14:52 -04:00

723d61902d

cli: better IO (#375 )

## What does this PR do?

Adds `Dependency`s for console IO. Also fixes #268 by explicitly
handling non-pipe input.

## How was it tested?

Ran on macOS + Linux in Docker. I have a future PR that overrides the
dependencies in certain cases, which also appears to work correctly.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

Did not scrutinize the tests too much tbh but they look reasonable. Easy
enough to update/remove them in the future if needed.

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
<!-- coderabbit-ai-generated:v1 -->

## Summary by CodeRabbit

* **New Features**
* Added support for reading command-line input, including asynchronous
prompts, line-based responses, and graceful handling of end-of-input.
  * Added coordinated cleanup when commands finish.
* **Improvements**
* Command messages across authentication, device management,
installation, SDK, and other workflows now use consistent output
handling; displayed messages and command behavior remain unchanged.
* Improved handling of complete output when the system temporarily
cannot accept more data.
* **Tests**
* Added coverage for command input and output, including stream
behavior, cancellation, and shutdown.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-28 17:48:38 -04:00

3e0c11d967

gsa: update user agent (#406 )

## What does this PR do?

Fixes the latest source of HTTP 503s during Apple ID login

## How was it tested?

- [x] `xtool auth login`

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

<!-- coderabbit-ai-generated:v1 -->

## Summary by CodeRabbit

* **Improvements**
* Requests now use the user-agent value provided with device
information, rather than a fixed value.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-25 19:54:57 -04:00

70e1568fdf

pack: link edited dependencies into the builder package (#390 )

## What does this PR do?

SwiftPM looks for edited dependencies in the root package's Packages
directory. The builder package becomes the root when building, so
dependencies edited with `swift package edit` were ignored and SwiftPM
fetched them again instead.

<!-- Focus on *what* the PR does in essence. The *how* should come
second, if it's relevant. -->

## How was it tested?

Without this change, the build of `xtool/.xtool-tmp` tries to clone all
15 dependencies and fails.

* With `Packages` linked into `.xtool-tmp`, it builds without fetching
anything and produces `DemoTCA.app`
* `Examples/DemoSimple`, which has no `Packages` directory, still builds
* `swift test` passes

<!-- e.g. Ran locally on macOS and added unit tests -->

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

<!-- coderabbit-ai-generated:v1 -->

## Summary by CodeRabbit

* **Build Improvements**
* Builds now include access to the working directory’s `Packages` folder
when it exists. If the folder is absent, builds proceed without it. This
can make packages in that folder available during the build.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Signed-off-by: Anish Pallati <i@anish.land>

Anish Pallati · 2026-10-23 17:48:49 -04:00

7f7d5b7e44

sdk: accept directories for tarball overrides (#385 )

## What does this PR do?

XTL_TOOLSET_TARBALL and XTL_OAM_TARBALL can now point at an unpacked
directory, so package managers can use tools they already provide
without repacking them into tarballs.

<!-- Focus on *what* the PR does in essence. The *how* should come
second, if it's relevant. -->

## How was it tested?

Tested on Linux with Swift 6.2.4: 
* `xtool sdk build` with both overrides set to directories in the Nix
store
* `xtool dev` flags the SDK as out of date after an override path
changes

<!-- e.g. Ran locally on macOS and added unit tests -->

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
<!-- coderabbit-ai-generated:v1 -->

## Summary by CodeRabbit

* **New Features**
* SDK setup now accepts a directory as a package source, recursively
copying its contents and adding owner write permission.
* Archive files continue to be supported as package sources and are
extracted as before.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Signed-off-by: Anish Pallati <i@anish.land>

Anish Pallati · 2026-10-23 18:24:11 +00:00

f1eca85cf4

entitlements: support Sign in with Apple (#377 )

## What does this PR do?

Hi! xtool didn't know about the `com.apple.developer.applesignin`
entitlement, so every time I installed my app, the capability sync
removed Sign in with Apple from the App ID. The new provisioning profile
didn't have it, and the device refused the app ("A valid provisioning
profile for this executable was not found").

This maps the entitlement to the `APPLE_ID_AUTH` capability, as a
primary App ID, so the capability stays and the profile includes it.

## How was it tested?

I built xtool from this branch on macOS and installed my app (a SwiftPM
app with `entitlementsPath` and the Sign in with Apple entitlement) on
an iPhone with a paid team. The App ID kept the capability, the install
worked, and native Sign in with Apple works in the app. Before the
change the same install failed every time.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

<!-- coderabbit-ai-generated:v1 -->

## Summary by CodeRabbit

* **New Features**
  * Added support for configuring the Apple Sign In entitlement.
* Apple Sign In is now available as a supported entitlement type,
including serialization and configuration support.
  * Configures Apple ID app consent as the primary app consent option.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Víctor Agudo Gonzalez · 2026-10-22 22:25:37 -04:00

952a7ffd43

gsa: use macOS Omnisette (#380 )

## What does this PR do?

Fixes #378, solving error -80046. Seems Apple now blocks
Android-identifying clients from using gsa (at least the 2fa bits). Use
Mac Anisette instead. cf
https://github.com/nab138/iloader/commit/902597564315442f00ab299dcc758ee0e13b8fa8

Alas, this does mean we have to retire xadi and switch back to
Omnisette.

## How was it tested?

- [x] Ran locally on macOS

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
<!-- coderabbit-ai-generated:v1 -->

## Summary by CodeRabbit

* **Bug Fixes**
  * Two-factor requests now use the device’s configured User-Agent.
* **Updates**
* Anisette requests now use the Omnisette provider and a new default
server. The optional server URL override remains available.
* The password-login warning now explains the virtual Mac and
third-party service involved, clarifies that credentials are sent only
to Apple, and recommends considering a secondary Apple ID.
* **Behavior Changes**
  * The Android-specific ADI provider is no longer available.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-22 17:04:16 -04:00

e3ce2c402e

sdk: support env overrides for tarballs (#372 )

## What does this PR do?

When building the sdk, allows you to set
`XTL_TOOLSET_TARBALL`/`XTL_OAM_TARBALL` to use local tarballs instead of
fetching them remotely. Supersedes
https://github.com/xtool-org/xtool/pull/319.

## How was it tested?

Honestly didn't bother but I think it works. Fairly safe to land.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **New Features**
- Added support for installing the Toolset and OpenAppleMacros from
locally provided tarball files.
- Existing HTTP download behavior remains available when local tarballs
are not configured.

- **Chores**
  - Improved handling of lengthy installation logic.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Mathieu Post <mathieupost@gmail.com>

Kabir Oberai · 2026-10-20 01:00:51 -04:00

aa6ba75e7d

sdk: update OpenAppleMacros to v1.4.1 (#371 )

## What does this PR do?

Updates OpenAppleMacros to v1.4.1. It now includes an info.json that
lists supported modules, so we don't need to hardcode them.

## How was it tested?

Built a project that uses `@State` on Linux

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **New Features**
- Updated the DemoSimple example with a SwiftUI app window, interactive
counter, and button-based incrementing.
- The example now runs its demonstration action when the content view
loads.

- **Bug Fixes**
- Improved SDK component downloads with clearer progress reporting and
validation.
- Improved plugin setup across supported platforms for more consistent
availability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-20 01:00:50 -04:00

ef7ce5b30d

gsa: fall back to a trusted-device code when SMS 2FA fails (#349 )

`secondaryAuth` can't finish logging in: GSA rejects POST
/auth/verify/phone/put?mode=sms with HTTP 403 ("Could not connect to
iCloud"). The JSON flavor of those endpoints (GET /auth, PUT
/auth/verify/phone/) answers 401 as well.

GsService2/validate still accepts a code generated on a trusted device
(Settings > Sign-In & Security > Get Verification Code), so ask for one
instead of failing. Tested on WSL (Ubuntu 26.04) with an iOS 27 device.

## What does this PR do?

<!-- Focus on *what* the PR does in essence. The *how* should come
second, if it's relevant. -->

## How was it tested?

<!-- e.g. Ran locally on macOS and added unit tests -->

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Two-factor authentication can fall back to a trusted device when an
SMS request returns HTTP 403.
* If trusted-device authentication also returns HTTP 403, users receive
instructions for manually generating a verification code, and code
validation can continue. Other errors are still reported.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Kabir Oberai <oberai.kabir@gmail.com>

javiertrejoyam · 2026-10-19 00:55:16 +00:00

8c46156e27

auth: clean up Anisette handling (#367 )

## What does this PR do?

Simplifies the Anisette handling code. Removes some unnecessary fields
(including hard-coded Mac serial numbers, cf #348) from our http
requests amongst other things.

## How was it tested?

Tested on macOS:

- [x] Can log in after resetting provisioning
- [x] Can run `xtool ds teams`
- [x] Can run `xtool ds certificates`

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Updates**
* Anisette-backed requests now use device information provided with
Anisette data, including an Android 14 device identity.
* Developer service requests no longer include client-information and
device-ID headers.
* The Anisette command now displays fetched details in sorted order and
uses the configured Anisette provider instead of prompting for
provisioning data.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-18 19:49:24 -04:00

2afd5307a4

sdk: fix cross-import overlays with SwiftBuild (#361 )

## What does this PR do?

Fixes #360 cross-import overlays on Linux for builds with swift 6.4+. 

This PR adds "-Xfrontend", "-enable-cross-import-overlays" to
`toolchan-swb.json` as it was added to `toolchan.json`.
Also bumps sdkEpoch so SDK will rebuild after update.

## How was it tested?

Build was tested locally with branch built from sources.

`xtool new example`, then replace the app file

Fix was tested on this example:
```Swift
import SwiftUI
import PhotosUI

@main
struct exampleApp: App {
    @State private var item: PhotosPickerItem?

    var body: some Scene {
        WindowGroup {
            PhotosPicker("Pick a photo", selection: $item)
        }
    }
}
```

It fails on version 1.22.2, but builds normally when xtool built from
this branch.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Configuration Updates**
* Generated Swift toolchain settings no longer explicitly select the LLD
linker. Existing frontend and cross-import overlay options remain
unchanged. This affects linker selection for generated toolsets; no
public API changes are included.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Sergey Grechishnikov · 2026-10-18 01:36:45 -04:00

c3c958d760

certs: match certificates whose serial starts with 0 (#306 )

## What does this PR do?

Fixes #305 (thanks @0x53 for the detailed diagnosis).

`Certificate.serialNumber()` stripped leading `0` *characters* from the
hex string, so a serial like `0337…` became `337…` and never matched the
`serialNumber` returned by the API. xtool then treated its stored
certificate as missing: free teams are prompted to revoke a valid
certificate on every run, and paid teams take the same path and try to
create another certificate, which @McoreD confirmed fails with `409 …
You already have a current Development certificate or a pending
certificate request.`

The character-level `drop` predates b6a40ca, which switched to
fixed-width `%02hhX` formatting; since then it removes the significant
zero of any first byte below `0x10`. swift-certificates already strips
leading zero bytes (including DER sign padding) when parsing, so the
`drop` isn't needed for padding.

- `serialNumber()` now drops only leading zero *bytes*, matching the API
and `openssl x509 -serial`.
- The stored-certificate lookup uses a new
`Certificate.hasSerialNumber(_:)`, which compares serials numerically
(ignoring case and leading zeros), so it doesn't depend on Apple's exact
formatting.
- Profile creation no longer finds the signing certificate with
`filter[serialNumber]`. The API lists serials with the leading zero
(`0E41…`), but the filter only matches them without it (`E41…`), so once
`serialNumber()` kept the zero the filter matched nothing and profile
creation failed with a 409
([details](https://github.com/xtool-org/xtool/pull/306#issuecomment-6181157860)).
It now fetches all pages of certificates and matches them with
`hasSerialNumber(_:)`. Fix by @McoreD, with pagination added so a
certificate on a later page isn't missed.

## How was it tested?

- Added `Tests/XToolTests/CertificateTests.swift`: builds a cert with
the serial from #305, round-trips it through DER, and checks
`serialNumber()` and `hasSerialNumber(_:)`, plus a high-bit serial so
DER sign padding doesn't leak into the string. The leading-zero test
fails on `main` (returns `33742570D6F9684A23311711956A084`) and passes
with this change.
- `swift test` (17 tests) and `make lint` pass on macOS (Xcode 27, Swift
6.4, `XTL_CI=1`).
- @McoreD tested on Linux (Arch, Swift 6.4.1, Xcode 27 SDK, on top of
1.22.2) with a paid team whose certificate serial starts with `0`: the
stored certificate is reused, and provisioning, signing and install to
an iPhone (iOS 27) succeed end to end (tested before pagination was
added). `CertificateTests` also pass on Linux.
- Not tested with a free team.

To generate test certificates, the test target now depends on `Crypto`
and `X509`, which XKit already uses.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Certificate serial numbers now preserve leading zero nibbles while
omitting unnecessary padding.
* Certificate matching now ignores letter case and leading zeros, and
profile lookups find matching certificates even when the API’s
serial-number filter treats leading-zero values differently.
* Certificate lookups continue to use the existing fallback when no
matching certificate is found.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: McoreD <McoreD@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

Chintan Patel · 2026-10-15 16:44:32 -04:00

316a11e523

fix: strip trailing carriage return in console prompt on crlf terminals (#328 )

### Summary
In `Console.prompt`, incoming line input from standard input is split on
`\n` without stripping any preceding carriage return (`\r`). On Windows
environments or CRLF terminals, user input terminates with `\r\n`,
leaving a trailing `\r` on decoded input strings.

When downstream helper methods such as `Console.chooseNumber` attempt to
parse numerical selections using `Int(prompt(...))`, the trailing `\r`
(e.g., `"1\r"`) causes the conversion to return `nil`, trapping the
terminal in an infinite prompt loop.

### Changes
- In `Console.prompt` (`Sources/XToolSupport/Console.swift`), stripped
any trailing `\r` from the decoded string before returning.
- Verified that all interactive helper methods (`promptRequired`,
`getPassword`, `chooseNumber`, `choose`, and `confirm`) delegate their
standard input reading to `Console.prompt`, ensuring all input paths are
protected against CRLF leakages.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Console input no longer includes a trailing carriage return; all other
input remains unchanged.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Bit Wolf · 2026-10-14 00:44:37 -04:00

b50173f7b1

http: add newer Apple Root CAs (#340 )

## What does this PR do?

Adds Apple G2 & G3 Root CAs to Linux trust root. Fixes #339.

Apple now uses gsd.apple.com for part of the auth flow, which uses the
G3 root.

## How was it tested?

Tried to log in on Linux. Failed before, works after.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Improved TLS certificate trust on Linux by recognizing Apple Root CA,
G2, and G3 certificates when verifying secure connections. Existing TLS
validation behavior remains unchanged.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-13 20:11:18 -04:00

65bf3cc5a1

gsa: fix login using mismatched client-info (#337 )

## What does this PR do?

Fixes #329 (error `-80045` on gsa login).

We were sending client info generated from Android Anisette, but
claiming to be a Mac. Seems like GrandSlam no longer likes this
mismatch.

## How was it tested?

- [x] Run `xtool ds certificates` after updating -> logged out,
provisioning reset
- [x] Re-auth works

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Updates**
* Authentication now identifies the client as a Pixel 7 running Android
14 rather than using a macOS-style client description.
* The provider ID is now consistent across platforms. Existing
provisioning may be reset if its saved provider ID differs.
* Before password login, a notice explains the emulated device and
environment, recommends considering a secondary Apple ID, and says
credentials are sent only to Apple.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-13 18:06:11 -04:00

fae1981275

packer: custom SwiftVersion parser (#303 )

## What does this PR do?

Drops `mxcl/Version` in favour of a lighter parser that's specifically
designed to parse the Swift version.

## How was it tested?

- [x] Unit tests
- [x] CI

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* Swift versions can now be compared by major, minor, and patch number,
and displayed in a consistent three-part format.
* Version parsing now accepts two- or three-number versions, including
supported compiler-output formats with optional prefixes or a `-dev`
suffix.
* Versions with an omitted patch number are treated as equivalent to the
same version with patch `0`.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-06 18:54:38 -04:00

d802c719e4

packer: use XcodeProjectFormat for generate-xcode-project (#300 )

## What does this PR do?

Improves `xtool dev generate-xcode-project`. Instead of constructing an
XcodeGen project, we directly construct an xcodeproj (with the new
xcproj format) using
[apple/xcode-project-format](https://github.com/apple/xcode-project-format).
For now, we still rely on
[Tuist/XcodeProj](https://github.com/tuist/XcodeProj) to translate it
back into a pbxproj for maximal compatibility, but this is treated as an
implementation detail.

Also adds support for resources and icons in the generated Xcode project

## How was it tested?

- [x] Generated a simple project, opened it, and ran the app

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added support for creating and saving Xcode projects and workspaces in
`.pbxproj` and `.xcproj` formats.
* Added tools for opening, converting, and writing project and workspace
files, including workspace contents.
* Project generation can target a specified directory, and the command
reports where the project was created.
  * Project generation is available on non-macOS platforms.
* Generated projects include product settings and references for
packages, resources, icons, and app extensions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-06 18:19:30 -04:00

8f0cc0adf1

planner: skip macro targets (#208 )

Currently, when using a package with macros like TCA the build fails
with the following message.
```
Error: Could not find package containing product 'SwiftSyntaxMacros'
```

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Package planning now skips macro targets when collecting resources and
resolving dependencies. This prevents dependencies belonging to macro
targets from being traversed as part of planning, while leaving
dependency handling for other target types unchanged.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Kabir Oberai <oberai.kabir@gmail.com>

Alex Pawlowski · 2026-10-06 03:14:43 +00:00

491fe2fc2a

deps: update swiftlint (#299 )

## What does this PR do?

Updates SwiftLint to v0.65.1

## How was it tested?

CI

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Chores**
* Removed inactive legacy networking implementations; active app
behavior and user-facing capabilities are unchanged.
* Updated the configured SwiftLint version and improved selection of its
Linux download for supported processor architectures. macOS continues to
use its existing download.
* No changes to app features or user workflows are included in this
update.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-10-06 02:15:13 +00:00

6f87f8f39b

tests: derive CFBundleSupportedPlatforms from the build triple (#289 )

## What does this PR do?

Application packing now sets CFBundleSupportedPlatforms from
Packer.cfBundleSupportedPlatforms(for:). The helper splits the triple on
hyphens, takes the OS token after apple with any numeric version
stripped, and returns iPhoneSimulator for an ios triple that also
contains simulator, iPhoneOS for other ios triples, MacOSX for macos or
macosx, and iPhoneOS when the triple is missing or unrecognized.
PackerTests covers those triples. Package.resolved drops the
swift-issue-reporting pin and adds xctest-dynamic-overlay 1.13.1.

Application builds aimed at the iOS simulator still ship an Info.plist
whose CFBundleSupportedPlatforms value is iPhoneOS. Hosts that read that
key treat the archive as a physical-device build and refuse to launch it
on a simulator. While packing an application, Packer assigns
CFBundleSupportedPlatforms the fixed array iPhoneOS. The build triple is
already available on buildSettings, but that assignment never reads it,
so a simulator triple is packed the same way as a device triple.

Fixes #191

## How was it tested?

The package builds successfully.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

AI was used for assistance.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Application metadata now reports the supported platform based on the
build target, including iOS devices, iOS simulators, and macOS. Unknown
targets retain the iOS device platform as a fallback.
* **Tests**
* Added coverage for platform metadata across supported and unknown
build targets.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>

Matt Van Horn · 2026-10-04 19:33:04 +00:00

8041b9286b

package: bump deps (#281 )

## What does this PR do?

Bumps pointfree deps and explicitly disables OpenCombine so that we
don't have different dependency graphs when building xtool on Darwin vs
Linux hosts.

## How was it tested?

A bunch of `swift package resolve`s

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Chores**
* Updated supporting package versions and refreshed command-line and
file-operation handling.
* These changes do not add or remove app features or alter its public
interface. No action is needed to continue using the app.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-09-25 02:11:36 -04:00

720618701c

sdk: prune Xcode when installing from xip (#280 )

## What does this PR do?

We only need `Xcode.app/Contents/{Info.plist,version.plist,Developer}`
for the SDK (and expect that to continue being the case). We already
delete other directories when using `xtool sdk install Xcode.app` but we
weren't doing this on `xtool sdk install Xcode.xip`. Prune on the xip
path as well.

Also prune on update (and bump the SDK epoch) so that existing users
benefit from this.

## How was it tested?

- [x] Install SDK from xip, confirm `Xcode.app/Contents` only contains
those three things
- [x] Install SDK from app, confirm `Xcode.app/Contents` only contains
those three things + we don't modify the original app
- [x] Build SDK from app (`xtool sdk build Xcode.app`), confirm we don't
clobber the input Xcode app
- [x] Update SDK, confirm that extra contents are removed
- [x] SDK auto-updates after updating xtool binary

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* SDK builds from Xcode app and XIP inputs now check for required Xcode
components before installation. Missing components produce an error.
* Extra direct items in Xcode’s `Contents` folder are removed during XIP
builds and app updates. Slim builds remain unchanged.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-09-23 01:14:56 -04:00

f9706d900b

sdk: get clang resources from swift toolchain (#274 )

## What does this PR do?

When building the SDK, derives the clang resource dir from the installed
Swift toolchain (`swiftc -print-target-info`) instead of `clang
-print-resource-dir`.

Speculatively fixes #273.

## How was it tested?

Validated that I can still build on Linux

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Improved detection of the host Clang resource directory by using Swift
compiler target information, helping ensure more reliable compiler setup
across supported environments.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-09-21 20:01:02 -04:00

df1b6fa5e9

sdk: update darwin-tools and OAM (#270 )

## What does this PR do?

Bumps darwin-tools and OpenAppleMacros

- Updates LLD to support arm64e.x1 to fix #269
- Adds FoundationModelsMacros to fix #213

## How was it tested?

- [x] Confirm that we can build with an Xcode 27 release SDK on Linux
- [x] Confirm that FoundationModels APIs work

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Improved Darwin SDK tool discovery during Swift builds, including
support for locating `dsymutil`.

* **Updates**
  * Updated bundled Darwin tool dependencies.
* Added Foundation Models macros support to the OpenAppleMacros library
set.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-09-21 01:37:14 -04:00

916cdffba8

anisette: use XADI on macOS (#259 )

## What does this PR do?

Updates macOS build to use the fully-local XADI as the Anisette provider
instead of Omnisette. Includes a one-time migration, logging the user
out on macOS when they upgrade.

## How was it tested?

General:

- [x] Log in and confirm that there's no calls to omnisette
- [x] `xtool dev` works

Migration:

- [x] Log into Apple ID using an old version of xtool
- [x] Migrate to new xtool, run `xtool dev build -s` and confirm it
fails due to being logged out
- [x] Log in on new xtool, confirm that we stay logged in

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Authentication now supports tracking the anisette provider used to
create Xcode tokens.
* Xcode authentication tokens are automatically cleared when the
provider changes, helping ensure users sign in again with current
credentials.
* Anisette provider identification is supported across macOS and Linux.

* **Bug Fixes**
* Improved authentication error messages, including clearer messaging
for logout-related errors.
* Prevented outdated Xcode authentication tokens from being reused after
a provider change.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-09-20 03:04:52 -04:00

eacc35da98

sdk: SwiftBuild support (#229 )

## What does this PR do?

Adds support for SwiftBuild on Swift 6.4.

We now point SwiftBuild to iPhoneOS.platform and rely on the real
[SWBApplePlatform](https://github.com/swiftlang/swift-build/tree/b30ee3c00abf34857084c26bb873c3da06348134/Sources/SWBApplePlatform).
We also do a little futzing to convince SWB to use our Darwin-compatible
toolset (lld, librarian, resource dirs). We explicitly _don't_ pass in a
Swift SDK because that would downgrade SWB to using one of the generic
platform plugins instead of ApplePlatform.

This also gets us a lot closer to parity with Xcode's behavior when
building for Apple platforms; we get the same build flags and
everything. We can probably achieve identical bundling too, if we take
control of the PIF.

One other change: since we need to pass custom env vars and such, we
can't rely on sourcekit-lsp's built-in SwiftPM integration anymore. We
thus create a custom BSP server that trampolines to SwiftPM's build
server with the right flags set. This effectively makes SwiftPM an
implementation detail, so we can start messing with the PIF.

## How was it tested?

- [x] Build with Swift 6.3 on macOS
- [x] Build with Swift 6.4 on macOS
- [x] Build with Swift 6.3 on Linux
- [x] Build with Swift 6.4 on Linux
- [x] BSP/LSP file creation works
- [x] LSP support works in VSCode

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

## Summary by CodeRabbit

- **New Features**
- Added a `dev build-server` command for Build Server Protocol
integration.
- Projects automatically select the appropriate Swift build system when
supported.
- Packaging supports output layouts for Swift Package Manager and Swift
Build.
- Added options to skip language-server configuration when needed.

- **Documentation**
- Updated project templates and tutorials to use `.bsp/xtool.json` for
IDE features such as syntax highlighting and documentation lookup.

- **Improvements**
- Enhanced SDK generation and compatibility across supported toolchains
and platforms.
- Improved automatic language-server configuration while preserving
existing configuration files.

Kabir Oberai · 2026-09-20 02:47:12 -04:00

0108899e04

sdk: integrate OpenAppleMacros (#101 )

## What does this PR do?

Adds support for proprietary Apple macros (like SwiftUI's `@Entry` and
`@State`) via
[OpenAppleMacros](https://github.com/xtool-org/OpenAppleMacros).

We have to re-implement these because the macros need to run on the
_host_, and the Apple SDKs include them as macOS-only dylibs.

## How was it tested?

- [x] Extensive integration tests in OpenAppleMacros that compare
Apple's expansions against ours
- [x] Confirmed that `@Entry`, `#Preview`, and `@State` work in Swift
6.3 and 6.4 (State is a PW in the former, macro in the latter)
- [x] Confirmed that OSS toolchain macros continue to work (tested
`@Observable`, `#bundle`)

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->

Kabir Oberai · 2026-09-19 04:28:51 -04:00

317e018f2b

packer: keep swift build stdout on stdout (#261 )

per #260 discussion.

Anton · 2026-09-19 03:28:58 -04:00

7b97cdd4dd

sdk: self-updating darwin tools (#110 )

## What does this PR do?

Allows xtool to auto-update the Darwin SDK format when there's a new
Darwin toolset, or when we change the SDK format. Downstream this also
allows us to auto-update when there's changes to OpenAppleMacros (#101).

One callout: the disk footprint of `darwin.artifactbundle` is now ~7 GB
instead of ~3 GB.

Reason: `xtool sdk install /path/to/Xcode.[app|xip]` now performs a
"normal" install by default, which preserves the entirety of
`Xcode.app/Contents/Developer` — even the bits we don't currently use,
like `AppleTVOS.platform`. This makes it so if we start using more
components in the future, the user doesn't need to download Xcode again
and rebuild the SDK themselves.

You can still build an old-style SDK (containing just the components we
need) using `xtool sdk install --slim` or the dedicated `xtool sdk
build`.

## How was it tested?

Tested all of the install modes. Confirmed that auto-updating works.
Added integration tests in #252.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **New Features**
- Added SDK flavor reporting for slim, normal, and legacy installations.
- Added `sdk update` support to rebuild and install SDKs from an
installed Xcode bundle.
  - Added a `--slim` option for SDK installation.
  - SDK status now displays installation path, flavor, and version.
- SDK setup and build operations now ensure a suitable SDK is available
automatically.

- **Bug Fixes**
- Improved temporary SDK bundle handling, validation, replacement, and
cross-filesystem copying.
  - Copy failures now provide detailed diagnostic information.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Kabir Oberai · 2026-09-18 23:26:10 -04:00

6efd77fc0e

anisette: use XADI Swift Package (#258 )

## What does this PR do?

The xadi repo (https://github.com/xtool-org/xadi) now vends an
artifactbundle for xadi, so we don't need to separately build/install it
during the xtool build. This also makes it super easy to support macOS
later (#259).

## How was it tested?

- [x] Confirmed I can sign in (including provisioning)

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->

Kabir Oberai · 2026-09-14 19:45:41 -04:00

c4d8c42f9a

sdk: move DarwinSDK into PackLib (#256 )

## What does this PR do?

Mechanical move of DarwinSDK from XToolSupport -> PackLib. Needed for
https://github.com/xtool-org/xtool/pull/229.

## How was it tested?

Compiled + CI

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->

Kabir Oberai · 2026-09-10 18:37:51 -04:00

4208c77c81

gsa: fix auth again (#257 )

## What does this PR do?

Fixes HTTP 503 on GsService… again (followup from #244)

Seems like GSA has stopped accepting `com.apple.dt.Xcode` in the client
info string. Use `akd` instead.

## How was it tested?

- [x] Logging in before failed
- [x] Logging in after succeeds

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [x] **0** - No AI was used to write code
- [ ] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->

Kabir Oberai · 2026-09-10 18:37:31 -04:00

450223eb07

sdk: fix permission issue when copying clang resources (#255 )

## What does this PR do?

Fixes #254 by using `cp -R` instead of `FileManager.copyItem`. The
latter tries to preserve the original owner of files instead of using
the caller, which fails if you're non-root and the original files are
root-owned.

## How was it tested?

I was able to repro the original issue by installing an SDK as a
non-root user in an xtool Docker container.

Applied this patch, tried `xtool sdk install` again, and it worked.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->

Kabir Oberai · 2026-09-10 17:23:15 -04:00

d4f6443f55

http: add some debugging knobs (#249 )

## What does this PR do?

Improves support for HTTP MITM

## How was it tested?

Did some MITMing on macOS + Linux via Docker, using Proxyman and
mitmproxy. Didn't test `XTL_HTTP_PROXY` but Sol pinkie promises me that
it's correct.

## AI tool usage

How much of this PR was AI-assisted? (check one)

- [ ] **0** - No AI was used to write code
- [x] **1** - I was assisted by AI. I reviewed the finished result.
- [ ] **2** - I set the AI going and left it to it; nobody has read the
result - no review, or AI review only

<!-- If an AI agent is filling this in: declare the level honestly, and
open as a draft if it is #2. Do not lower the declared level to get the
PR reviewed. -->

Kabir Oberai · 2026-09-09 06:50:47 +00:00

b49941a62a

ci: enable warnings as errors (#248 )

Kabir Oberai · 2026-09-09 01:49:00 -04:00

189654c235

gsa: disregard keepalive (#247 )

GSA seems to, sometimes, reject HTTP requests made on a kept-alive
connection with a 503. This was either the real root cause, or a second
root cause, for #243. Fix this by creating a new HTTP connection for
each GSA request.

See also: https://github.com/rileytestut/AltSign/pull/52 and
https://github.com/rileytestut/AltSign/pull/47

Speculatively fixes #232

Kabir Oberai · 2026-09-08 21:23:04 -04:00

8c77ca7f0b

http: throw on unsuccessful responses (#246 )

Ref #243. `makeRequest` never inspected `response.status`, so a non-2xx
body was
returned as if it had succeeded. Every caller decodes that body as a
property list
or JSON, so Apple answering with an HTML error page surfaced as:

```
Error: DecodingError.dataCorrupted: Data was corrupted. Debug description: The given
data was not a valid property list.. Underlying error: ... Encountered unknown tag
html on line 1
```

which says nothing about what actually happened. In the case that
prompted #243, GSA
was returning `503 Service Temporarily Unavailable` for the `apptokens`
operation. It
now reads:

```
Error: POST https://gsa.apple.com/grandslam/GsService2 failed: HTTP 503 Service
Unavailable (text/html): <html> <head><title>503 Service Temporarily
Unavailable</title></head> ...
```

### Notes

- The response body is only included in the message for `text/html` and
`text/plain`,
i.e. gateway error pages. Bodies from the auth endpoints can carry
account details
(the 2FA requests use `Accept: application/x-buddyml`), and errors get
printed
verbatim in places such as `DevCommand.swift:164`, so those are left
out. It also
  avoids emitting replacement characters for binary bodies.
- The non-2xx path does not report progress, so `XADIProvider`'s
download no longer
  prints `100%` immediately before failing.
- Body collection moved to `collect(_:onProgress:)` so there is a single
exit point.
  Buffer pre-sizing and progress reporting are unchanged.
- `SDKBuilder` already does this check by hand on `send()`, so it is
unaffected.

### Behaviour changes worth a look

- `XADIProvider` writes the Apple Music APK download straight to disk; a
failed
  download now throws instead of leaving a corrupt `applemusic.apk`.
- The 2FA requests (`GrandSlamTrustedDeviceRequest`,
`GrandSlamSMSAuthRequest`,
`GrandSlamValidateRequest`) use no-op decoders, so a rejected request is
currently
discarded and xtool goes on to prompt for a code that was never sent —
the symptom
  in #235. Those now fail loudly.

### Two things I left alone

- `GrandSlamTwoFactorAuthenticateOperation.swift:47` catches
`GrandSlamOperationError`
with code `-21669` to report an incorrect verification code, but that
error is only
thrown by `GrandSlamOperationDecoder`, which the validate requests do
not use, so the
catch is unreachable. With this change a wrong code surfaces as a raw
HTTP error
instead. Mapping the status back to `incorrectVerificationCode` seemed
like your call,
  since I do not know what GSA returns for a bad code.
- If any endpoint reports errors in a decodable body under a non-2xx
status, this guard
would pre-empt it. I could not find one — `developerservices2` returns
HTTP 200 with
  `resultCode`/`userString` in the body, which is untouched here.

Built and linted on Linux (`swift build --product xtool`, `make lint`: 0
violations).

---------

Co-authored-by: Robetronica <noreply@Robetronica.com>
Co-authored-by: Kabir Oberai <oberai.kabir@gmail.com>

Rob · 2026-09-08 16:48:11 -04:00

76b005f6d8

gsa: update user agent to fix auth (#244 )

Fixes #243. GrandSlam seems to be rejecting clients that self-report as
really old.

Kabir Oberai · 2026-09-04 18:22:53 -04:00

893cf4f8f9

Support wifi-aware entitlement (#240 )

SuperKenVery · 2026-09-01 14:10:54 -04:00

8f11844553

Use swift-subprocess (#225 )

Kabir Oberai · 2026-07-12 16:36:24 -04:00

5c4f3bcb05

Fix tmpdir reentrancy (#234 )

Previously, we would clear xtool's temporary directory on startup. This
(practically) meant you couldn't have multiple instances running in
parallel, because the second instance could delete the first instance's
temp resources while the first instance still needed them. Fix this by
having xtool instances declare locks on their temporary directories.

Kabir Oberai · 2026-06-22 02:22:42 -04:00

7f151a9c66

Fix DarwinSDK legacy compat (#230 )

Kabir Oberai · 2026-05-28 01:50:58 -04:00

e49934c1fe

Fix clang headers (#228 )

A slightly different approach to #215.

---------

Co-authored-by: sfusco <slf@stevenfusco.com>

Kabir Oberai · 2026-05-28 01:43:22 -04:00

9c4772d64f

Add build --sign option (#224 )

Running `xtool dev build --sign [--ipa]` will produce a codesigned
app/ipa, without installing

Kabir Oberai · 2026-05-16 22:40:45 -04:00

4077e1a0b8

Update dependencies (#222 )

Kabir Oberai · 2026-05-16 20:57:29 -04:00

756a867854

Fix capability creation via public API (#220 )

Ref #216: the public API seems to now complain when passing in
`capabilities`, but the field is still required when using the private
API.

Co-authored-by: sfusco <slf@stevenfusco.com>

Kabir Oberai · 2026-05-16 20:04:51 -04:00

8edb54fb71

fix(linux): use home cache dir to avoid tmpfs→ext4 EINVAL on SDK install (#211 )

## Problem

`xtool setup` fails on Linux Mint (and other distros) with:

```
Error: Error Domain=NSCocoaErrorDomain Code=512 "(null)" UserInfo={
  NSUserStringVariant=["Copy"],
  NSSourceFilePathErrorKey=/tmp/sh.xtool/tmp-DarwinSDKBuild-.../darwin.artifactbundle/...,
  NSDestinationFilePath=/home/<user>/.swiftpm/swift-sdks/darwin.artifactbundle/...,
  NSUnderlyingError=Error Domain=NSPOSIXErrorDomain Code=22 "Invalid argument"
}
```

## Root Cause

On Linux Mint (and Ubuntu-based distros), `/tmp` is mounted as **tmpfs**
while the home directory is on **ext4**. Foundation's
`FileManager.copyItem` uses `sendfile(2)` internally, which returns
`EINVAL (22)` when copying between different filesystem types.

`TemporaryDirectoryRoot` defaults to
`FileManager.default.temporaryDirectory` → `/tmp` on Linux. When `swift
sdk install` copies the built SDK from `/tmp/sh.xtool/...` to
`~/.swiftpm/swift-sdks/`, it crosses filesystem boundaries and fails.

## Fix

On Linux, default the temp directory root to `$XDG_CACHE_HOME/xtool`
(falling back to `~/.cache/xtool`) instead of `/tmp`. This keeps the
build directory and install destination on the same filesystem, so the
copy always succeeds.

- `$XTL_TMPDIR` and `$TMPDIR` overrides continue to work as before
- macOS behaviour is unchanged
- Follows XDG Base Directory Specification

## Changes

One file, `Sources/XUtils/TemporaryDirectory.swift` — 11 lines added
inside a `#if os(Linux)` block.

Fixes #181

Swapnil Nakate · 2026-04-18 17:25:10 +05:30

c65d45ba60

221 Commits