0
Kai Detmers
← Project index
Product fork · Native iOS developer toolPrivate build

PocketEngineer— a remote workspace in your pocket.

A native iOS control plane for remote Linux development: projects, agent streams, files and terminal sessions over SSH. The phone stays the interaction layer; the repository, compilers and long-running agents stay on real infrastructure.

Origin & scope

PocketEngineer is a product fork and redesign, not a greenfield claim. The baseline is Eugene Pyvovarov's open-source CodeAgents Mobile. My branch uses that native SSH/agent client as a starting point and moves the product model toward remote workspaces (“Spaces”), explicit project creation and a first-class terminal. The screenshot set present in the fork tracks the upstream baseline, so I do not present those images here as evidence of my redesign.

Stack

ClientSwiftUI · @Observable · iOS 17+
PersistenceSwiftData · projects / servers / sessions
TransportSwiftNIO SSH · PTY / file / agent channels
SecurityKeychain · SSH keys · provider credentials
Provisioningcloud-init · DigitalOcean · Hetzner
ArchitectureMVVM · protocol-oriented services

How it evolved

Process reconstruction — based on the import history, subsequent commits and current source. It is a design narrative, not a literal diary of every decision.

01
Start from a working native SSH/agent client.

The first useful decision was not to rebuild SSH, streaming and remote file access for the sake of ownership. The upstream project provided a functioning technical baseline.

02
Change the mental model from server to Space.

“Server” describes infrastructure; “Space” describes where work lives. The UI terminology was pushed toward a developer workspace so host details become implementation detail rather than the main product object.

03
Add project lifecycle inside a workspace.

An AddProject flow makes the remote environment usable as more than a saved SSH endpoint. The user thinks in repositories/projects first and infrastructure second.

04
Make terminal a first-class surface.

Agent chat alone is too narrow for professional development. Terminal work was promoted alongside chat and files so escape hatches, diagnostics and ordinary shell workflows remain available.

05
Pull provisioning closer to the product.

Cloud-provider models, cloud-init resources and managed-server views reduce the gap between “I want a mobile dev space” and “I have prepared a Linux box correctly.”

UI / interaction rationale

Workspace, not infrastructure consoleHost, port and key configuration belong in setup/settings. The everyday surface should lead with the active project and what the agent is doing.
Three professional escape routesChat, Files and Terminal expose three different ways to understand or change the remote system. None is hidden behind the AI layer.
Progressive tool visibilityAgent output should show tool calls and results while they execute instead of collapsing everything into one polished assistant bubble; for coding work, provenance is part of trust.
Native density, not desktop cosplayThe iPhone cannot be a mini VS Code. Sheets, project switching, native navigation and focused task surfaces are more useful than reproducing desktop chrome at 390px width.

Architecture

iPhoneNative project, chat, file and terminal surfaces.
ServicesSSH, project, file and agent concerns sit behind service boundaries rather than inside views.
SSHPurpose-specific sessions prevent a long-running agent or terminal command from monopolising file operations.
LinuxRepository state, compilers, CLIs and agent processes remain on a machine designed to run them.

What I would validate next

Setuptime from install to first working remote project
Resumewhether users can recover a useful agent/terminal session after mobile interruptions
Trustwhether tool visibility is sufficient before users accept code changes from a phone