A native macOS app that gives non-technical site owners a visual, edit-in-place experience for their website.
Scaffolding, deploys, and design flows are deterministic Swift; generative features run on Apple Intelligence (on-device Foundation Models). Edits and content operations go through the Anglesite MCP sidecar (server/ in the sibling repo), which runs inside the app's container runtime. The former Claude Code dependency — the claude --print subprocess and the markdown-skill machinery — is fully retired (epic #459).
Pre-release. The v0 → v1 core is built (Phases 0–9): site plumbing, supervised subprocesses, the WKWebView live preview with the block editor (JS/wysiwyg-engine, edits routed through the MCP sidecar), deploy via wrangler (with the mandatory pre-deploy scan), Keychain/gh credentials, the per-site chat panel, multi-window, the deploy-readiness health badge, image-drop optimization, and per-edit undo.
In progress (Phase 10, v2 polish):
- Mac App Store build.
Anglesiteis the single sandboxed app target (io.dwk.anglesite). The old direct-download target has been retired. The host-side embedded Node runtime has been retired (#70); local Apple Containerization is the macOS runtime direction. - Apple Help Book — shipped. 15 hand-authored HTML pages with
hiutilsearch index, accessible via Help ▸ Anglesite Help.
Also landed since v1:
SiteRuntimeprotocol (#65) — abstracts the execution substrate soPreviewModelis decoupled from how a site runs (in-process subprocess vs. local container vs. Cloudflare).- HTTP/Streamable MCP transport (#64) —
MCPClientcan connect over HTTP in addition to stdio, enabling container-backed runtimes. - Containerization — Apple Containerization is the macOS runtime direction. The active app-bundled image source is
Containers/anglesite-dev/, exported byscripts/vendor-container-image.shintoResources/container-image/and booted by theAnglesiteContainertarget. Docker/buildx is only used to build that inert OCI root filesystem. The lowercasecontainer/directory is the Cloudflare Sandbox / remote-runtime image pipeline forRemoteSandboxSiteRuntimeand iOS work, not the macOS app image. - Xcode 27 migration (#108) — macOS 27+ deployment target,
@Statemacro audit, Swift 6.4 toolchain. - macOS 27 platform features — the first platform wave has shipped: system-wide MCP (#101), Spotlight/App Intents (#102), native chat on Foundation Models (#105), and more.
See docs/build-plan.md for the full phased status.
- Build plan — phased implementation roadmap
- High-level design — companion design doc in the sidecar repo
These are the requirements for building the macOS app — the primary development flow. For working on the portable core from a Linux machine, see Developing on Linux.
On either platform, scripts/setup-dev-env.sh checks the prerequisites below, fixes what it safely can (generating the Xcode project, enabling git hooks, the Linux libxml2 shim), and prints instructions for the rest.
- macOS 27+
- Xcode 27+ (Swift 6.4; required for the SwiftUI 27
@Statemacro semantics audited indocs/specs/2026-06-10-xcode27-state-macro-audit-notes.md) - XcodeGen (
brew install xcodegen) — the.xcodeprojis generated fromproject.yml - The host-side embedded Node runtime has been retired (#70) — dev-server, build, and deploy commands run in a container runtime instead, so users do not need Node installed.
# Clone alongside the sidecar repo
git clone https://github.com/Anglesite/Anglesite.git
cd Anglesite
# One-shot environment check/bootstrap (generates the Xcode project, enables the
# git hooks below, and reports anything missing) — or follow the steps manually:
scripts/setup-dev-env.sh
# Generate the Xcode project
xcodegen generate
# (Recommended) Enable git hooks: auto-regenerate the .xcodeproj after
# `git pull` / branch switches / rebases (keeps Xcode in sync with project.yml
# and Sources/ without manual `xcodegen generate` calls), and auto-restore the
# trailing newline Xcode's String Catalog build phase strips from *.xcstrings.
git config core.hooksPath scripts/git-hooks
# (Optional one-time verification) Confirm project.yml hasn't drifted from the
# source tree — regenerates the .xcodeproj and checks every app target compiles all
# of Sources/AnglesiteApp. CI runs this too, so it's not a required setup step.
scripts/check-xcodeproj-sync.sh
# Build via CLI (ad-hoc signed; no Apple account required). Use scripts/build-app.sh
# instead of a raw `xcodebuild` — it regenerates the project first, so a checkout
# that went stale without tripping the git hooks above never builds a stale one (#123).
scripts/build-app.sh -project Anglesite.xcodeproj -scheme Anglesite -configuration Debug build
# Or open in Xcode (note: `open Anglesite.xcodeproj`, NOT `xed .`)
open Anglesite.xcodeprojThere is one app target, ad-hoc-signed in Debug so it builds without an Apple account:
| Scheme | Bundle id | Distribution | Sandbox |
|---|---|---|---|
Anglesite |
io.dwk.anglesite |
Mac App Store | on (App Sandbox) |
Don't
xed .— this repo contains both aPackage.swiftand anAnglesite.xcodeproj.xed .opens the package, whose scheme picker only showsAnglesite-Package(libraries only, no runnable target). Open the.xcodeprojexplicitly; the scheme picker should then showAnglesite,AnglesiteCore,AnglesiteBridge,AnglesiteSiteModel,AnglesiteIntents, andAnglesiteContainer, and ⌘R should run the app.
The Debug configuration uses ad-hoc signing so contributors can build and run locally without any Apple Developer enrollment. App Store Release builds require a paid Apple Developer account and a provisioning profile with the app's restricted entitlements; see docs/release.md.
The app shell is macOS-only today, but Anglesite is going multi-platform — Linux first — per the cross-platform port design. On Linux, Package.swift exposes only the portable SwiftPM targets (currently AnglesiteSiteModel; the set grows as the "purity phase" lands seam by seam), and CI runs swift build && swift test on Ubuntu to enforce that boundary.
git clone https://github.com/Anglesite/Anglesite.git
cd Anglesite
# Checks for a Swift 6.3+ toolchain (installable via swiftly: https://www.swift.org/install/linux/),
# creates the libxml2 soname shim if your distro needs it (see below), enables git hooks,
# and runs a smoke build of the portable targets.
scripts/setup-dev-env.sh
swift build # portable targets only
swift testNotes:
- Toolchain: Swift 6.3+ (via swiftly). No Xcode, XcodeGen, or Node needed on Linux.
- libxml2 on newer distros: distros shipping libxml2 ≥ 2.15 (e.g. Ubuntu 26.04) provide
libxml2.so.16, but the swift.org toolchain linkslibxml2.so.2. The setup script creates a user-level symlink shim and prints theLD_LIBRARY_PATHexport to activate it; loader warnings about "no version information" are expected and harmless. (CI is unaffected — theswift:*container images ship a matching libxml2.) - Working on the port itself:
ANGLESITE_PORT_WIP=1 swift build --target AnglesiteCoreopts the not-yet-portable core into the manifest so in-flight seam work can be compile-checked locally. Apple-only targets (AnglesiteBridge,AnglesiteIntents,AnglesiteContainer, …) never build off-Darwin. - Containers:
podmanis not needed for the purity phase; it becomes relevant with the Linux MVP'sPodmanSiteRuntime.
Claude Code's cloud session containers (claude.ai/code) are Linux and ship no Swift toolchain, so agents there need the same swiftly install as any Linux contributor. Two pieces make that work, and both need a one-time tweak to the repo's cloud environment settings on claude.ai/code:
- Setup script (preferred): the setup script runs before the session's repo clone is in place, so it can't invoke
scripts/install-swift-linux.shby a repo-relative path (./scripts/install-swift-linux.shfails with "No such file or directory", exit 127) — fetch it from GitHub instead:#!/bin/bash curl -fsSL https://raw.githubusercontent.com/Anglesite/Anglesite/main/scripts/install-swift-linux.sh | bash || true
raw.githubusercontent.comis in Claude Code's default Trusted allowlist, so this works even with Custom network access as long as "Also include default list of common package managers" stays checked. The trailing|| truekeeps an intermittent install failure from blocking session startup (see "Script requirements" in Claude Code's cloud environment docs) — theSessionStarthook below retries idempotently if the toolchain didn't end up installed. The setup script runs once per environment and its result is cached, so every later session starts with Swift ready instead of re-downloading it. - Network access: the install also downloads the Swift toolchain itself from swift.org, which is not in the default package-registry allowlist. If the environment restricts network access, allowlist
swift.org,www.swift.org, anddownload.swift.org.
The checked-in SessionStart hook (.claude/hooks/session-start.sh) remains as a per-session fallback: it runs the same install script when no cached toolchain is present (needing the same allowlist), and persists the toolchain's PATH and the libxml2-shim LD_LIBRARY_PATH into each session via $CLAUDE_ENV_FILE — something a setup script can't do.
This repo expects a sibling checkout of the sidecar repo, Anglesite/anglesite-skills, in a directory named anglesite next to this one (both under the same parent directory) — or set ANGLESITE_SIDECAR_SRC to point elsewhere (ANGLESITE_PLUGIN_SRC remains a compatibility alias). The sibling repo supplies the MCP sidecar (server/), which the container-image scripts (scripts/vendor-container-image.sh, scripts/build-podman-image.sh) stage into the dev-server image; the MCP end-to-end tests also spawn it directly from the checkout (ANGLESITE_PLUGIN_PATH). Nothing from the sibling repo is bundled into the app itself anymore (#466).
Resources/container-image/ is a gitignored local build artifact, so it's never rebuilt automatically — if your sidecar checkout was already vendored before pulling an app change that bumps the required MCP protocol version, the image quietly keeps serving the old one. scripts/lib/stage-dev-image-context.sh guards against the current known case (the MCP 2026-07-28 stateless spec, #1277): both vendor scripts refuse to stage a sidecar checkout older than the pinned minimum version and tell you how to update it. When in doubt, git -C ../anglesite pull and re-run the vendor script before debugging an MCP failure.
Anglesite collects no telemetry, analytics, or crash reports, and contacts no tracking domains. This is declared, not just asserted: Resources/PrivacyInfo.xcprivacy sets NSPrivacyTracking to false with empty tracking-domain and collected-data-type lists, and lists the required-reason APIs the app does use (UserDefaults for its own settings, file timestamps for internal conflict detection and content indexing, and on-device elapsed-time measurement for the startup progress bar) with Apple's approved reason codes for each.
ISC. See LICENSE.