xtool

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

b9d726ca1c

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

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

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: 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

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

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

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

Use swift-subprocess (#225 )

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

5c4f3bcb05

Update dependencies (#222 )

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

756a867854

Handle static xcframeworks not being unpacked (#156 )

SwiftPM may not unpack static xcframeworks. Handle this gracefully, if
SwiftPM doesn't need the framework we don't either.

Fixes #155.

Kabir Oberai · 2025-08-10 18:05:28 -04:00

0710653cd0

Improve tmpdir management (#147 )

- We now have a single tmpdir "root" that can be recreated at launch to
clean up old stragglers
- The location of this tmpdir root can be controlled by `XTL_TMPDIR` or
`TMPDIR`. In general the path is `$TMPDIR/sh.xtool`.

With this change it should be possible to `export XTL_TMPDIR=/var/tmp`
if `/tmp` doesn't have enough space, which fixes #23.

Kabir Oberai · 2025-08-10 01:43:09 -04:00

836fca8daf

Add support for App Extensions (#97 )

This pull request adds support for Apple's [App
Extensions](https://developer.apple.com/app-extensions/).

Closes: #45

---------

Co-authored-by: ErrorErrorError <16653389+ErrorErrorError@users.noreply.github.com>
Co-authored-by: Kabir Oberai <oberai.kabir@gmail.com>

Erik Bautista Santibanez · 2025-07-13 23:47:47 -04:00

edd6b90f53

Add SwiftLint (#104 )

Closes #72

Kabir Oberai · 2025-05-31 19:38:57 +05:30

0425f9edeb

Support entitlements with XcodePacker (#88 )

Kabir Oberai · 2025-05-24 02:28:17 +05:30

693e60faef

Add support for custom entitlements (#82 )

Closes #46

Kabir Oberai · 2025-05-24 00:35:46 +05:30

3b17975fe7

Support building for iOS simulator (#74 )

Closes #68

## On any platform

You can now do

```bash
xtool dev build --triple arm64-apple-ios-simulator [--ipa]
```

To build a .app/.ipa that works on the simulator.

## On macOS

You can do

```bash
xtool dev --simulator
```

To one-shot build-and-install on the booted simulator.

Kabir Oberai · 2025-05-22 19:35:51 +05:30

3a4290c85e

Improve macOS SDK handling

Kabir Oberai · 2025-05-07 18:03:37 +05:30

e5eb0d3c4f

Rename main product

Kabir Oberai · 2025-05-06 11:30:59 +05:30

6778e66e55

Support app icon, root resources

Kabir Oberai · 2025-05-05 18:12:23 +05:30

1a44e86613

Merge infoPath instead of overwriting

Kabir Oberai · 2025-05-05 16:51:53 +05:30

88886e9ae4

Update sdk install + dev setup to use builder

Kabir Oberai · 2025-04-24 19:26:09 -04:00

9d90f84168

Update dependencies

Kabir Oberai · 2025-04-23 17:43:57 -04:00

3c5fe13244

Pacify type checker

Swift 6.1’s type checker couldn’t resolve the original expr in reasonable time yada yada

Kabir Oberai · 2025-04-23 17:28:42 -04:00

468cd39ad0

Integrate swiftpack

Kabir Oberai · 2024-12-31 17:39:57 +05:30

dd04f66cb6

30 Commits