pingdotgg · t3dotgg · Jul 30, 2026 · Jul 30, 2026 · Jul 30, 2026 · Jul 30, 2026
diff --git a/.agents/skills/ios-debugger-agent/SKILL.md b/.agents/skills/ios-debugger-agent/SKILL.md
@@ -1,12 +1,19 @@
 ---
 name: ios-debugger-agent
-description: Build, launch, inspect, and drive iOS apps with the repository-configured XcodeBuildMCP server. Use on macOS for iOS Simulator builds, focused native test runs, semantic UI automation, screenshots, logs, or debugging, including T3 Code Mobile verification.
+description: Build, launch, inspect, and drive iOS apps with the repository-configured XcodeBuildMCP server. Use on macOS for iOS Simulator builds, focused native test runs, semantic UI automation, screenshots, logs, or debugging, including either the React Native T3 client in apps/mobile or the separate native SwiftUI client in apps/swift-ios.
 ---
 
 # iOS Debugger Agent
 
 Use the repository-configured `xcodebuildmcp` tools instead of requiring a globally installed Codex plugin. Prefer MCP tools over raw `xcodebuild`, `xcrun`, or `simctl` when the client exposes them.
 
+T3 Code has two separate iOS clients. Identify the affected one before setting session defaults:
+
+- React Native mobile: `apps/mobile/ios/T3CodeDev.xcworkspace`, scheme `T3CodeDev`
+- Native SwiftUI mobile: `apps/swift-ios/T3Code.xcodeproj`, scheme `T3Code`
+
+Do not assume an installed React Native build verifies SwiftUI behavior, or vice versa. Use [`test-t3-mobile`](../test-t3-mobile/SKILL.md) for the full isolated-backend and pairing workflow.
+
 ## Confirm availability
 
 This workflow requires macOS 14.5 or newer, Xcode 16 or newer, and Node.js 18 or newer. The repository pins XcodeBuildMCP in both `.mcp.json` for Claude Code and `.codex/config.toml` for Codex. Project MCP servers may require one-time trust or approval followed by a new session.

diff --git a/.agents/skills/test-t3-app/SKILL.md b/.agents/skills/test-t3-app/SKILL.md
@@ -5,7 +5,7 @@ description: Launch, retain, and test the T3 Code web app in isolated developmen
 
 # Test T3 App
 
-Use this skill for the web client. For iOS Simulator, Android Emulator, or physical-device testing against an isolated T3 backend, use the sibling [`test-t3-mobile`](../test-t3-mobile/SKILL.md) skill.
+Use this skill for the web client. For iOS Simulator, Android Emulator, or physical-device testing against an isolated T3 backend, use the sibling [`test-t3-mobile`](../test-t3-mobile/SKILL.md) skill and select either the React Native client in `apps/mobile` or the separate native SwiftUI client in `apps/swift-ios` before building.
 
 ## Start an isolated web environment
 

diff --git a/.agents/skills/test-t3-mobile/SKILL.md b/.agents/skills/test-t3-mobile/SKILL.md
@@ -1,32 +1,42 @@
 ---
 name: test-t3-mobile
-description: Launch and test T3 Code Mobile on an iOS Simulator or Android Emulator against disposable local T3 environments, including Metro and dev-client reuse, native rebuild decisions, per-client pairing, seeded projects, semantic UI control, screenshots, and iOS serve-sim streaming. Use after mobile UI or native changes, when reproducing phone or tablet behavior, pairing an emulator to isolated state, or verifying mobile behavior on macOS, Linux, or Windows.
+description: "Launch and test either T3 Code mobile client against disposable local environments: the React Native iOS/Android app in apps/mobile or the separate native SwiftUI iOS app in apps/swift-ios. Covers client selection, native rebuild decisions, Metro and dev-client reuse for React Native only, per-client pairing, seeded projects, semantic UI control, screenshots, and iOS serve-sim streaming. Use after mobile UI or native changes, when reproducing phone or tablet behavior, pairing a device to isolated state, or verifying mobile behavior on macOS, Linux, or Windows."
 ---
 
 # Test T3 Mobile
 
 Run one focused, end-to-end mobile verification pass against disposable T3 state. Use the sibling [`test-t3-app`](../test-t3-app/SKILL.md) skill as the detailed reference for pairing-token semantics and SQLite fixtures.
 
+## Choose the mobile client first
+
+T3 Code has two independent mobile implementations:
+
+- **React Native mobile** lives in `apps/mobile` and targets iOS and Android. Its development workflow uses Expo, Metro, and the `T3 Code Dev` identity documented below.
+- **SwiftUI mobile** lives in `apps/swift-ios` and targets iOS. It is a native Xcode project and never uses Expo or Metro. Its Debug identity is `T3 Swift Dev`, bundle identifier `com.t3tools.t3code.swiftui.dev`, and URL scheme `t3code-swiftui-dev`.
+
+Inspect the affected paths and choose one before launching anything. Do not use one client as verification for the other. For SwiftUI, load [`ios-debugger-agent`](../ios-debugger-agent/SKILL.md), set the project to `<repo>/apps/swift-ios/T3Code.xcodeproj`, scheme `T3Code`, configuration `Debug`, and use the selected simulator. Then use this skill's disposable-backend, pairing, UI-driving, and cleanup guidance while skipping every Metro, Expo, and Android step.
+
 Command examples use POSIX shell syntax. On Windows, use PowerShell equivalents: set variables with `$env:NAME = "value"`, use an explicit temporary directory from `[System.IO.Path]::GetTempPath()`, and run multiline examples on one line or with PowerShell backticks. Use `$env:ANDROID_HOME\platform-tools\adb.exe` when `adb` is not already on `PATH`.
 
 ## Select a viable platform
 
 Inspect the host and the affected code before launching processes:
 
-- On macOS with Xcode, prefer one representative iOS Simulator when the change is cross-platform so the user can watch through serve-sim. Load and follow [`ios-debugger-agent`](../ios-debugger-agent/SKILL.md), and load [`ios-simulator-browser`](../ios-simulator-browser/SKILL.md) when live streaming is available.
+- On macOS with Xcode, prefer one representative iOS Simulator when the change is cross-platform so the user can watch through serve-sim. This can be either mobile client; use the project selected above. Load and follow [`ios-debugger-agent`](../ios-debugger-agent/SKILL.md), and load [`ios-simulator-browser`](../ios-simulator-browser/SKILL.md) when live streaming is available.
 - On macOS, Linux, or Windows with the Android SDK, use one Android Emulator when Android is the affected surface or iOS tooling is unavailable.
 - When the change is platform-specific, test that platform. When neither platform is viable, report the missing SDK, emulator, or dev-client prerequisite rather than claiming verification.
 
 Do not treat unavailable iOS tooling as a blocker when Android is a valid representative target.
 
 ## Choose the lightest valid launch path
 
-- For JavaScript, TypeScript, or asset-only changes, reuse a compatible installed development client and start Metro. Do not rebuild native code merely to load a new bundle.
+- For React Native JavaScript, TypeScript, or asset-only changes, reuse a compatible installed development client and start Metro. Do not rebuild native code merely to load a new bundle.
+- For SwiftUI changes, build or reuse the native `T3Code` scheme with `ios-debugger-agent`; Metro and Expo compatibility do not apply.
 - For native source, native dependencies, entitlements, config plugins, or generated project changes, rebuild the affected platform.
 - Use `vp run ios:dev` or `vp run android:dev` only when an Expo clean prebuild is actually required; both commands regenerate the native project.
 - If the user requested no native rebuild and no compatible app is installed, reuse an existing compatible `.app` or `.apk` artifact when available. Otherwise report the missing dev client instead of silently rebuilding.
 
-The development identity on both platforms is:
+The React Native development identity on both platforms is:
 
 - App: `T3 Code Dev`
 - Bundle/package identifier: `com.t3tools.t3code.dev`
@@ -70,7 +80,7 @@ Enter the complete `http://` origin to make the test transport explicit. Bare IP
 
 ## Start or reuse Metro safely
 
-Run Metro from `apps/mobile`.
+This section applies only to React Native mobile. Run Metro from `apps/mobile`. Skip it entirely for SwiftUI mobile.
 
 1. Inspect any process on the intended Metro port and its `/status` response. Reuse it only when it is healthy, belongs to this worktree, and matches `APP_VARIANT=development`, `--dev-client`, and scheme `t3code-dev`.
 2. Never kill another worktree's Metro. Use a free explicit port when necessary.
@@ -88,7 +98,7 @@ Run Metro from `apps/mobile`.
 
 4. Open the exact development-client URL for the selected device and confirm the loaded bundle belongs to this worktree and Metro port.
 
-### iOS launch
+### React Native iOS launch
 
 Use `ios-debugger-agent` to select one UDID and set these XcodeBuildMCP session defaults:
 
@@ -107,7 +117,7 @@ xcrun simctl openurl <simulator-udid> <printed-dev-client-url>
 
 Accept the iOS confirmation prompt and dismiss the developer menu when it obscures the app.
 
-### Android launch
+### React Native Android launch
 
 Select one running emulator serial from `adb devices` and check the installed client:
 
@@ -142,6 +152,8 @@ The helper opens this registered route:
 t3code-dev://connections/new?pairingUrl=<encoded-pairing-url>&autoConnect=1
 ```
 
+For SwiftUI, pass `t3code-swiftui-dev` as the helper's fifth argument. The default `t3code-dev` scheme selects the React Native development client.
+
 The Add Environment route owns the behavior: `pairingUrl` prefills its normal host and token inputs, while `autoConnect=1` submits once in development builds and returns to Home after success. Without `autoConnect`, the same route only prefills the form for manual inspection.
 
 Do not enter pairing hosts or tokens through simulator keyboard automation. Xcode's semantic typer sends HID-style key events through the simulator's active keyboard state, which can corrupt uppercase tokens and punctuation even when the host Mac uses a U.S. input source. The one-shot route is the deterministic pairing path. Use the visible form only as a fallback, and paste credentials rather than typing them character by character.

diff --git a/.agents/skills/test-t3-mobile/agents/openai.yaml b/.agents/skills/test-t3-mobile/agents/openai.yaml
@@ -1,4 +1,4 @@
 interface:
   display_name: "Test T3 Mobile"
-  short_description: "Test T3 Code on iOS or Android"
-  default_prompt: "Use $test-t3-mobile to launch T3 Code against an isolated backend and verify the affected flow on an available simulator or emulator."
+  short_description: "Test React Native or SwiftUI T3 clients"
+  default_prompt: "Use $test-t3-mobile to select the affected React Native or SwiftUI client, launch it against an isolated backend, and verify the flow on an available simulator or emulator."
diff --git a/.github/workflows/swift-ios.yml b/.github/workflows/swift-ios.yml
@@ -0,0 +1,58 @@
+name: SwiftUI iOS
+
+on:
+  pull_request:
+    paths:
+      - "apps/swift-ios/**"
+      - "packages/contracts/**"
+      - "scripts/generate-swift-wire-fixtures.ts"
+      - "scripts/package.json"
+      - ".github/workflows/swift-ios.yml"
+      - "package.json"
+      - "pnpm-lock.yaml"
+      - "pnpm-workspace.yaml"
+  push:
+    branches:
+      - main
+    paths:
+      - "apps/swift-ios/**"
+      - "packages/contracts/**"
+      - "scripts/generate-swift-wire-fixtures.ts"
+      - "scripts/package.json"
+      - ".github/workflows/swift-ios.yml"
+      - "package.json"
+      - "pnpm-lock.yaml"
+      - "pnpm-workspace.yaml"
+
+concurrency:
+  group: swift-ios-${{ github.event.pull_request.number || github.sha }}
+  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
+
+jobs:
+  test:
+    name: Contract fixtures and native tests
+    runs-on: blacksmith-12vcpu-macos-26
+    timeout-minutes: 25
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v6
+        with:
+          sparse-checkout: |
+            /*
+            !/.repos/
+          sparse-checkout-cone-mode: false
+
+      - name: Setup Vite+
+        uses: voidzero-dev/setup-vp@v1
+        with:
+          node-version-file: package.json
+          cache: true
+          run-install: |
+            args:
+              - --filter=@t3tools/scripts...
+
+      - name: Verify generated wire fixtures
+        run: node scripts/generate-swift-wire-fixtures.ts --check
+
+      - name: Test SwiftUI client
+        run: apps/swift-ios/Scripts/ci-test.sh
diff --git a/AGENTS.md b/AGENTS.md
@@ -28,7 +28,12 @@ T3 Code has 3 key app surfaces: **web**, **desktop**, and **mobile**.
 
 **Desktop** is the main surface most users install first. It's a full Electron app that bundles the server runner as well. The desktop app can also be used as the host server, allowing remote connections from app.t3.codes or the mobile app.
 
-**Mobile** is a React Native app for both iOS and Android, available on the App Store and Google Play. The mobile app allows for connecting to any T3 Code server to control work remotely.
+**Mobile** has two separate clients that connect to the same T3 servers:
+
+- `apps/mobile` is the React Native app for iOS and Android, available on the App Store and Google Play.
+- `apps/swift-ios` is the native SwiftUI app for iOS, with its own Xcode project, UI implementation, and app identities.
+
+Treat them as distinct clients. UI, navigation, persistence, and build changes in one do not automatically reach the other. When implementation details matter, say **React Native mobile** or **SwiftUI mobile** instead of referring ambiguously to “the mobile app.”
 
 ## A note from Theo
 
@@ -67,9 +72,9 @@ We need to be on the same page with terminology. When communicating, use this la
 The most common defect in this repo is a change that works on the path you tested and is missing everywhere else. Before calling frontend work done, walk this list and say which entries applied:
 
 - **Entry points.** A behavior reachable from the chat view is usually also reachable from Settings, the command palette, and a keybinding. Fixing one is not fixing the feature.
-- **Clients.** Web, desktop (wraps web, adds Electron shell/IPC), and mobile (React Native, separate navigation). Shared logic lives in `packages/client-runtime`
+- **Clients.** Web, desktop (wraps web, adds Electron shell/IPC), React Native mobile, and SwiftUI mobile. Decide explicitly which mobile clients a change applies to. Shared TypeScript client logic lives in `packages/client-runtime`; the SwiftUI client is a separate native implementation.
 - **Providers.** Codex, Claude, Cursor, Grok, OpenCode, and Antigravity each have an adapter. Provider-shaped features need a decision per adapter, even if the decision is "not supported here".
-- **Contracts.** Anything crossing the wire is typed in `packages/contracts`. Change the schema and the server, web, mobile, and desktop all follow.
+- **Contracts.** Anything crossing the wire is typed in `packages/contracts`. When a schema changes, update the server, web, desktop, React Native mobile, and SwiftUI mobile implementations as applicable.
 - **Reverse states.** If you added a way in, add the way out and the way to see it. Snooze needs unsnooze. Close needs reopen. A one-way door is a bug.
 - **Connection modes.** Local, remote/relay, and tunnel behave differently. Multi-device and multi-environment cases are real.
 - **Docs.** Check whether the change makes existing guidance inaccurate. Apply the [documentation rules](#documentation) before adding anything.
@@ -108,7 +113,7 @@ An empty database is a bad test. Seed your worktree's `.t3` with a copy of real
 - **Do not run repo-wide checks.** No `vp check`, no `vp run -r test`, no `vp run -r typecheck` unless I ask. CI owns the full suite.
 - Backend behavior changes ship with focused tests for that behavior.
 - The server is event-sourced and its async flows emit typed receipts. Wait on receipts and worker drains, never on sleeps or polling. A test that needs a timeout to pass is wrong.
-- Upon request, user-visible frontend changes should get one integrated pass in a real client: `test-t3-app` for web, `test-t3-mobile` for mobile. The primary agent does this once after integrating. Subagents do not launch their own dev servers. Ask permission before doing computer use or spinning up browsers.
+- Upon request, user-visible frontend changes should get one integrated pass in a real client: `test-t3-app` for web and `test-t3-mobile` for either mobile client. Select the React Native or SwiftUI path before building. The primary agent does this once after integrating. Subagents do not launch their own dev servers. Ask permission before doing computer use or spinning up browsers.
 
 ## Pull requests
 
@@ -147,10 +152,13 @@ Full glossary with file links: `docs/internals/glossary.md`
 ## Where code lives
 
 - `apps/server` - WebSocket, orchestration, providers, checkpointing. Effect-heavy: read `.repos/effect-smol/LLMS.md` before writing Effect code.
-- `apps/web` - React/Vite UI. `apps/desktop` wraps it, `apps/mobile` is React Native, `apps/marketing` is the site.
+- `apps/web` - React/Vite UI. `apps/desktop` wraps it and adds Electron behavior.
+- `apps/mobile` - React Native client for iOS and Android.
+- `apps/swift-ios` - Separate native SwiftUI client for iOS.
+- `apps/marketing` - Marketing site.
 - `packages/contracts` - Effect/Schema contracts plus small derived helpers. No heavy runtime logic.
 - `packages/shared` - shared runtime utils, subpath exports, no barrel.
-- `packages/client-runtime` - client code shared by web and mobile.
+- `packages/client-runtime` - TypeScript client code shared by web and React Native mobile. SwiftUI implements the corresponding native client behavior separately.
 - `.repos/` - vendored read-only references. Prefer their patterns over invented ones. Never edit or import from them. Sync with `vpr sync:repos` when bumping the matching dependency.
 
 ## Taste

diff --git a/apps/swift-ios/.gitignore b/apps/swift-ios/.gitignore
@@ -0,0 +1,4 @@
+.derivedData/
+DerivedData/
+*.xcuserstate
+xcuserdata/
diff --git a/apps/swift-ios/App/Cloud/T3ConnectAuth.swift b/apps/swift-ios/App/Cloud/T3ConnectAuth.swift
@@ -0,0 +1,74 @@
+import ClerkKit
+import Foundation
+
+public struct T3ConnectAccount: Equatable, Sendable {
+    public let id: String
+    public let email: String?
+    public let imageURL: URL?
+}
+
+public enum T3ConnectAuthError: LocalizedError, Sendable {
+    case noSession
+
+    public var errorDescription: String? {
+        switch self {
+        case .noSession:
+            "Sign in to your T3 account to use T3 Connect."
+        }
+    }
+}
+
+enum T3ConnectAuthCallback {
+    static let scheme = PlatformRoute.nativeScheme
+    static let redirectURL = "\(scheme)://clerk-callback"
+}
+
+/// Small ClerkKit boundary. Clerk owns encrypted session persistence and the
+/// ASWebAuthenticationSession callback; the app only asks for the relay JWT.
+@MainActor
+public final class T3ConnectClerkSession {
+    private let clerk: Clerk
+    private let jwtTemplate: String
+
+    public init(configuration: T3ConnectConfiguration) {
+        jwtTemplate = configuration.clerkJWTTemplate
+        clerk = Clerk.configure(
+            publishableKey: configuration.clerkPublishableKey,
+            options: .init(
+                redirectConfig: .init(
+                    redirectUrl: T3ConnectAuthCallback.redirectURL,
+                    callbackUrlScheme: T3ConnectAuthCallback.scheme
+                )
+            )
+        )
+    }
+
+    var client: Clerk { clerk }
+
+    public var account: T3ConnectAccount? {
+        guard let user = clerk.user else { return nil }
+        return T3ConnectAccount(
+            id: user.id,
+            email: user.primaryEmailAddress?.emailAddress,
+            imageURL: URL(string: user.imageUrl)
+        )
+    }
+
+    public var isLoaded: Bool { clerk.isLoaded }
+
+    public func refresh() async throws {
+        _ = try await clerk.refreshClient()
+    }
+
+    public func signOut() async throws {
+        try await clerk.auth.signOut()
+    }
+
+    public func relayToken() async throws -> String {
+        let token = try await clerk.auth.getToken(
+            .init(template: jwtTemplate, expirationBuffer: 20)
+        )
+        guard let token, !token.isEmpty else { throw T3ConnectAuthError.noSession }
+        return token
+    }
+}