This PR integrates Ghostty on macOS with the [App
Intents](https://developer.apple.com/documentation/appintents) system.
The focus of this initial work was on enabling [Apple
Shortcuts](https://support.apple.com/guide/shortcuts/welcome/ios) on
macOS, but App Intents are the same underlying system that powers a
number of other Apple features such as Spotlight, Siri, Widgets, and
more. We don't do much with these latter ones yet, though.
Additionally, this PR begins to refactor and untangle some of our
libghostty API calls from macOS views. Presently, macOS views and view
controllers directly call into the libghostty API and own libghostty
data models. This tight coupling is kind of nasty because it tends to
also couple libghostty API calls to the main GUI thread when they don't
really have to be (they just have to not be concurrently accessed). This
becomes an issue because App Intents run on background threads. This PR
starts to extract out some of this business logic into standalone
classes, but we still force all execution onto the main thread during
the transition.
**Version requirement:** Most of the shortcuts will work on macOS 13,
but there are some that require macOS 14, and some functionality will
require macOS 26. We gracefully degrade in all scenarios (the
capabilities that are unavailable just don't show up on older systems).
> [!IMPORTANT]
>
> This bumps our build requirements on macOS to Xcode 26 and the macOS
26 SDK. **You can still build on macOS 15,** but you must be using the
Xcode 26 beta. This includes a README update about that.
## Why?
Apple Shortcuts is an extremely powerful scripting tool on Apple
platforms. It comes with a number of built-in capabilities such as
moving windows, taking screenshots, fetching secrets, and more. By
integrating with Apple Shortcuts, it allows Ghostty to become scriptable
to a certain extent while also being able to take advantage of this
large ecosystem.
It is a huge downside that Shortcuts is Apple-only and I still would
like to make Ghostty scriptable to some extent on Linux and other
platforms as well. This work doesn't preclude that goal, but gives us an
answer to a large subset of users (macOS users), which is great.
Beyond this, no terminals integrate with Apple Shortcuts except the
built-in Terminal. And even then, the built-in Terminal only exposes two
actions (run script and run script over SSH). I think there's a lot that
can be done by exposing more functionality and I'm excited to see what
people do with this.
Finally, I think Shortcuts is possibly a way we can do some GUI testing
on macOS. That remains to be explored but it seems promising.
## Capability
The initial set of Shortcut actions is shown in the screenshot below:
These can be combined with the built-in shortcuts to do some pretty
interesting things.
### Future
There are more capabilities I'd like to expose, but they require
changing core parts of Ghostty that I didn't want to mix into this PR.
## Security
Scripting Ghostty can be considered a security risk, since it allows
arbitrary command execution, reading terminal output, etc. Therefore,
Ghostty will ask for permission prior to allowing any Shortcut to remote
control it:
<img width="859" alt="image"
src="https://github.com/user-attachments/assets/62344248-9c2c-402d-80f6-3fe3910d23fd"
/>
This can be directly overridden using the new `macos-shortcuts`
configuration, which defaults to `ask` but can also be set to `deny` or
`allow` with self-explanatory behaviors.
This PR makes the build script use the correct SDK and version flag for
the iOS Simulator.
Without this PR, the terminal fails to initialize on the iOS Simulator:
```
Compiler failed to build request
metal error=Target OS is incompatible: library was not compiled for the simulator
error initializing surface err=error.MetalFailed
```
<details>
<summary>With the PR</summary>
</details>
Fixes#7635.
This wasn't working before but it just requires a restart of the machine
for the changes to take effect. The namespace runners have this prebuilt
so this should work now.
The other workaround was flaky for unknown reasons so I'd prefer to go
back to this.
This fixes an issue where pressing the red close button in a window or
the "x" button on a tab couldn't differentiate and would always close
the tab or close the window (depending on tab counts).
It seems like in both cases, AppKit triggers the `windowShouldClose`
delegate method on the controller, but for the close window case it
triggers this on ALL the windows in the group, not just the one that was
clicked.
I implemented a kind of silly coordinator that debounces
`windowShouldClose` calls over 100ms and uses that to differentiate
between the two cases.
This wasn't working before but it just requires a restart of the machine
for the changes to take effect. The namespace runners have this prebuilt
so this should work now.
The other workaround was flaky for unknown reasons so I'd prefer to go
back to this.
