Settings ▸ Remote gains a "Connect via" picker — LAN (default), Tailscale (tailnet), or Relay (disabled, coming soon). On Tailnet, both devices run an embedded tsnet node via TailscaleKit (tailscale/libtailscale) and sync frames flow over the user's tailnet, so the phone can connect from anywhere the tailnet reaches; Noise E2EE runs above the transport unchanged. - NucleicTailnet (new target, macOS + iOS): TailnetNode wraps TailscaleKit's node lifecycle (auth-key login, generation-fenced start/stop since up() is un-cancellable) and drops to the framework's public C API for the data path — tailscale_dial/listen/accept hand back full-duplex socketpair fds, wrapped by FDFrameChannel (DispatchIO) into the shared FrameChannel seam. The Swift wrapper's one-way connection actors can't carry a bidirectional stream. - Host: TailnetListener adopts SyncListener; startSyncServer is single-flight and honors toggle-off/picker changes at the commit point; pairing QRs carry transport + tailnet IP/port hints (PairingPayload additive optional fields, forward/backward compatible over CBOR). - iPhone: pair/reconnect dial over whichever transport the pairing recorded; Settings gains a Tailscale auth-key field (Keychain, committed on editing end); connectivity chip shows "Connected · Tailnet". - TailscaleKit has no SwiftPM distribution: scripts/build-tailscalekit.sh builds a pinned libtailscale commit into an untracked local xcframework; Package.swift links it only when present (everything builds without it, the picker then reports Tailscale support as not built in), and the script clears SwiftPM's content-keyed manifest cache so the toggle is picked up. - iOS floor 17.0 → 18.1 (TailscaleKit requires the iOS 18 Swift runtime); package-app.sh embeds the framework in the .app like Sparkle. 703-test suite: no new failures (the 7 fake-claude/fake-grok staging issues reproduce identically on an untouched checkout — pre-existing, tracked separately). New coverage: FDFrameChannel over socketpairs, pairing-payload version-skew both directions, transport-setting resolution. Co-Authored-By: Claude Fable 5 <[email protected]>
NucleicRemote (iPhone client)
The thin iOS remote client for Nucleic (PLAN milestone M4). It's a pure projection of the
Mac host over LAN: monitor sessions, read transcripts/diffs, answer approvals, and send
follow-up input — scope approve. No local git or CLI; the Mac is the single authority
(see docs/UX_IOS.md and docs/SYNC_PROTOCOL.md).
Architecture
All wire/crypto logic is shared with the Mac via the NucleicProtocol SwiftPM library
(this Xcode project links it as a local package at ../..):
- Transport —
NWFrameChannel(NWConnection) +LANDiscovery(Bonjour_nucleic._tcp). - Engine —
NucleicProtocol.SyncClientruns the Noise handshake (XXpsk0 to pair, IK to reconnect), exchanges hello/welcome, and turnsHostMsgs into aSyncClient.Eventstream. - State —
RemoteStore(ObservableObject) is the single on-device UI state, a pure projection of the host. Identity + pinned host live inIdentityStore(Keychain + UserDefaults). - UI — SwiftUI:
SessionsView(attention-first list),SessionDetailView(transcript/diff + status-driven action area),ApprovalCardView(Face ID gate on high-risk),PairingScannerView(QR),SettingsView.
Build & run
# Resolves the local NucleicProtocol package automatically.
xcodebuild -project ios/NucleicRemote/NucleicRemote.xcodeproj \
-scheme NucleicRemote \
-destination 'platform=iOS Simulator,name=iPhone 17 Pro' build
Or open NucleicRemote.xcodeproj in Xcode and run. To pair, start the sync server on the Mac
(Nucleic ▸ Settings ▸ Add iPhone shows the QR), then scan it. On a real device, both must be
on the same Wi‑Fi.
Status
The full pair → list → subscribe → approve → reconnect path is implemented and the protocol/
server side is covered by tests in Tests/NucleicProtocolTests and Tests/NucleicCoreTests.
Push notifications / Live Activity (UX_IOS §5.1/§5.3) are the M5 follow-up (needs the relay).