docs: feasibility study for Swift-native on-device agentic IDE - #5
Closed
ThyFriendlyFox wants to merge 1 commit into
Closed
docs: feasibility study for Swift-native on-device agentic IDE#5ThyFriendlyFox wants to merge 1 commit into
ThyFriendlyFox wants to merge 1 commit into
Conversation
Co-authored-by: ThyFriendlyFox <thyfriendlyfox@gmail.com>
ThyFriendlyFox
added a commit
that referenced
this pull request
Aug 5, 2026
Phase T's pure-logic layer in Kotlin, from swift/Mouse/TerminalScreen.swift, TerminalWidth.swift and the contract half of TerminalPrograms.swift. Faithful re-implementation, not a bridge (invariant #5): the grid, the alt-screen save/RESTORE pair, scroll regions, DECCKM, bracketed paste, the 103-range UAX#11 width table, the byte-at-a-time ANSI parser with its query replies, TerminalKey's xterm encodings, and the TerminalProgram/TerminalProgramIO contract. It is its own Gradle module — pure Kotlin/JVM, no Compose, no android.*, no dependency but kotlin-stdlib — for the reason phase T learned on iOS: logic that shares a file with UI is logic no harness can reach. :app depends on it and dexes it (verified: com/reagentsystems/mouse/terminal/TerminalScreen is in classes2.dex). The gate is :screencheck, a main() with no JUnit (invariant #4), shaped like the Swift harnesses in verify/. Its corpus is the iOS corpus ported assertion for assertion — verify/main.swift, altscreen, widechars, widetui and the screen-level half of tty — reading the SAME checked-in fixtures rather than copies, because two platforms gated by different corpora is a parity claim nobody can falsify. That includes the strongest one: the captured claude-code frame rendered against pyte's own output. ./gradlew :screencheck:run SCREEN CORPUS: 182 checks — grid, parser, widths, keys, program contract, pyte frame — MATCH (width table: all 199 agree with Python's unicodedata) Proven able to fail, twice, before it was believed: making TerminalTty.onlcr a pass-through reddened the pyte cross-check with the exact diagonal shear the iOS comment describes ("2 of 182 ... MISMATCH", exit 1), and a bogus width for U+2014 reddened the table ("unicodedata=1 ours=9"). ANDROID_HOME=~/Library/Android/sdk ./gradlew clean :screencheck:run assembleDebug — BUILD SUCCESSFUL. Deliberately deferred, not forgotten: NodeProgram (the Node layer, milestone 3) and the less/top programs. Only TerminalTty.onlcr is lifted out of NodeProgram, because it is tty truth the screen's own gate needs — the iOS comment says as much where it sits. Adaptations where the languages differ, semantics unchanged: a Swift Character (grapheme cluster) is a String, since a Kotlin Char cannot hold an emoji; the parser walks code points for the same reason; value-type array copies are explicit deep copies; CellStyle/TerminalCell are immutable data classes; Sendable and @mainactor have no equivalent and the main-thread discipline is documented instead. One assertion had to be spelled differently: Swift compares Strings by canonical equivalence, so its "combined glyph" expectation is "é"; Kotlin compares code units, so it names what the cell holds, "é". Same grid, stricter comparison. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a research/scoping document assessing the feasibility of the proposed Swift-native, fully on-device agentic IDE (iOS-first) architecture, grounded in the realities of iOS, the App Store, and the existing Mouse codebase.
File:
docs/feasibility-swift-native-on-device-ide.mdVerdict
Mostly feasible, with App Store precedents (Pythonista, Pyto, a-Shell, Swift Playgrounds, Working Copy) — but it is a new ground-up native product, not an evolution of the current Capacitor/Codespaces client. Three proposal claims do not hold on iOS and drive most of the risk:
pip/npmof native modules anddlopenof downloaded binaries are blocked by code-signing + Guideline 2.5.2; ship a pre-built bundled package catalog instead.Other key corrections: the "terminal" is a curated command dispatcher (no real shell/
fork/exec); Python has nosubprocess/fork; security-scoped bookmarks are only needed for external URLs; local LLMs are limited to small mmap'd quantized models (1B–4B Q4) by per-app memory ceilings.Contents
Documentation only — no code or build changes.