DEV Community: Serhii Didanov

Building CLI Apps on iPad using an AI Agent and a Remote VPS

Serhii Didanov — Tue, 14 Jul 2026 06:56:49 +0000

A command-line app isn't the most obvious thing to build on a tablet. No real terminal, no filesystem you're used to from a desktop, no proper multitasking - that's how it looked just a couple of years ago. But move the actual code execution to a remote Linux server and turn the iPad into a thin client for driving an AI agent and reviewing the result, and the picture changes completely. Below is the workflow I've settled on for building Python CLI tools: a VPS + an AI coding agent (Claude Code) in tmux + Remote IDE as a single entry point, all on an iPad with Stage Manager.

Why command-line apps specifically

CLI is a forgiving genre for this kind of workflow. A command-line app has no browser UI to poke at by hand, no visual design that's easier to assemble with a mouse on a big screen. There's code, tests, dependencies, and a command to run it - and the whole "write - run - check the output" loop fits inside a terminal. That's exactly what an AI agent handles best: it writes code, runs it itself, sees the output in the same terminal, and keeps iterating without a human in the loop at every step.

All that loop needs is SSH access to the server running the agent, and a way to look at files and diffs in parallel without losing the agent's session when switching windows. Here's how it plays out, step by step.

Step one: the server and the project

It all starts with describing a server - a plain form with an address, a port, and an authentication method (password or SSH key; keys and passwords go straight into the device Keychain and nowhere else). After that you create the project itself: a name, a path on the server, and a "Use remote filesystem" toggle.

That toggle decides how the project behaves from here on. If it's off, Remote IDE works the usual way - local files in iCloud Drive, manually synced to the server through SFTP buttons in the toolbar. But for a CLI that the agent is building directly on the server, it's far more convenient to turn it on: the project's file tree in the sidebar is then pulled straight from the server over SFTP, and opening or saving a file in the editor writes directly to the remote filesystem. No local copy, no manual syncing, and - importantly - no risk of drifting from what the agent sees and edits in the terminal: the editor and the agent look at the exact same filesystem in real time.

Step two: tmux - separate windows for the console and the agent

Next is the terminal. The connection settings have a "Use tmux" toggle: when it's on, the SSH session gets wrapped in tmux right on the server. The practical upside isn't just that the session survives a dropped connection (close the iPad's cover, lose Wi-Fi - reconnect and everything's still there, including whatever the agent was typing). Inside tmux I keep separate windows for the same project: one is a plain bash shell for git commands, running tests, manual checks; the second runs the CLI agent itself (Claude Code, Codex CLI, and the like). Every project gets its own named tmux session, so the agent and the console for my-pet-project never collide with a neighboring project on the same server, and switching between several simultaneous tasks is just switching a tmux window, not hunting for where a session went.

In practice it looks like this: the status bar at the bottom shows the active tmux window for the current project's session - you can keep both bash and the agent open, switching between them without losing context in either.

Step three: Stage Manager instead of tab-switching

Next comes iPadOS 26's multi-window support. The SSH console with the agent is just one stream of information; in parallel you want to see the code the agent just wrote, and what changed relative to the previous commit. Keeping all of that in one window with constant scrolling is awkward - spreading it across Stage Manager or Split View is exactly what it was built for.

The usual working set looks like this: on the left, a window with the agent's console (Remote IDE in SSH mode); on the right, a second window with the editor and the project's file tree; and, when needed, a third floating window for Git status. These are all independent native app windows that Stage Manager manages the same way it manages windows from different apps: dragging, resizing, remembering the layout between sessions. The agent writes code in the terminal on the left while you flip through files and diffs on the right - without a single context switch.

Working with files as if they were local

It's the remote filesystem toggle that makes this genuinely seamless. Open the README.md the agent just created on the server, and it opens in the editor exactly like a regular local file, with the project's directory tree in the sidebar: .claude, .git, .venv, src, tests, pyproject.toml, uv.lock. Edit by hand whatever you feel like fixing yourself, without waiting for the agent - the save goes straight to the server automatically, on every change. No "download, fix, upload back": the editor and the terminal work against the same copy of the files on the server at the same time.

Syntax highlighting that doesn't feel like a compromise

The editor itself deserves a mention on its own. It's built on Runestone with Tree-sitter grammars - so the highlighting isn't regex-based coloring, it's an actual syntax parse for the specific language. Python, TOML, Markdown, YAML, JSON, Shell, and a few dozen other languages are detected automatically from the file extension. Open a pyproject.toml the agent just edited, and you see properly highlighted sections and values instead of a wall of grey text - that "this is a real code editor" feeling, not a text field in a monospace font.

Git diffs without dropping into the console

One of the things that makes a dedicated Git window pay for itself the most, specifically paired with an agent, is a fast visual check of what it actually touched, without typing git diff by hand. The list of changed files - marked A (added) and similar - opens next to the editor; picking a file immediately shows a line-by-line diff, additions highlighted in green and deletions in red. The agent edited pyproject.toml, changing the description in the manifest - you see it line by line, without having to ask the agent to summarize what it changed, and without the risk of that summary drifting from the actual diff.

That's especially valuable when the agent finished a task in a few minutes "in the background": you come back not to a wall of chat text, but straight to a list of files and line-by-line changes.

The keyboard toolbar: a small thing that saves time every single minute

The iPadOS on-screen keyboard isn't built for code - brackets, the period, =, # are tucked away on secondary layouts, and there's no Tab key at all. Above the keyboard, Remote IDE's editor shows an extra quick-input bar with exactly these symbols: Tab, a pair of brackets with the cursor placed between them, a period, an equals sign, and a hash. It's always within reach whenever a text field is active - no need to dive into a third layer of the system keyboard for a single bracket. With a physical keyboard attached, the bar simply isn't needed and stays out of the way.

What it looks like end to end

Here's a scenario from actual use: I create a new remote project, my-pet-project, with the remote filesystem enabled, pointing at a path on the server. In the agent's tmux window I ask it to scaffold a Python CLI with typer and uv - the agent creates the structure, pyproject.toml, README.md, tests, runs uv run, and shows that the hello and version commands work. Then it edits pyproject.toml, tightening up the description - and I see it line by line in the Git window before the agent even reports it back. I ask the agent, "how do I run the app?" - I get the exact commands, cd, uv run my-pet-project hello --name World, uv run my-pet-project version - and try them right there, without leaving the console, in the neighboring tmux window with plain bash. I open README.md in the editor - it's already highlighted as Markdown and reads cleanly. All of this is three or four windows on screen at once, with not a single blind tab switch.

The bottom line

Building command-line apps is about as close to an ideal fit for this setup as it gets: an agent that doesn't need a graphical interface, a server it can actually run on, and an iPad that stops being an "almost workstation" and becomes a full-fledged remote control for the whole process - with syntax highlighting, line-by-line diffs, per-project tmux windows, and multi-window support that finally helps instead of getting in the way.

Remote IDE - to discuss a feature, suggest an idea, or report a problem, head to GitHub Issues.

Download Remote IDE on the App Store →

Canonical source: https://remote-ide.com/blog/remote-ide-cli-agent-en/

iPad as a Developer Tool in the Age of Agentic Programming

Serhii Didanov — Mon, 11 May 2026 08:44:12 +0000

Not long ago, talking about the iPad as a serious developer tool was met with scepticism. A Netflix machine, a sketching pad, a presentation device — but not a real environment for writing and deploying code. That scepticism had merit: iPadOS lacked proper multitasking for years, tools for working with remote servers barely existed, and the constant need to switch between apps made any serious workflow frustrating.

Today the picture has changed dramatically, and for two reasons that reinforce each other.

Agentic Programming Is Changing the Nature of Developer Work

The rise of AI agents — Claude Code, GitHub Copilot Agent, Cursor and similar tools — has fundamentally changed what a developer's workflow looks like. A significant portion of actual code writing is now handled by the agent: you describe the task, the agent executes it, you review the result, steer the next step, check the diff again. It is more dialogue, direction, and navigation than intensive keyboard input.

This shift changes what you need from a device. Previously, a "powerful developer tool" meant above all a fast machine with a comfortable physical keyboard — because you spent most of your time typing code directly. Now other things matter more: a comfortable way to review changes, quick navigation between files, the ability to keep several contexts in view at once — code, terminal, documentation, agent chat. That is a job for a good display, a thoughtful interface, and flexible multitasking — not raw CPU speed.

In this model, an iPad with an external keyboard and Apple Pencil stops being a compromise. It becomes a deliberate choice: lightweight, with an excellent display and long battery life. Monitoring an agent's progress, reading code, reviewing diffs, making commits, deploying — all of this maps naturally onto a touch interface. The only missing piece was the right app.

Stage Manager: iPad Finally Has Real Windowing

The second key factor is Stage Manager, introduced in iPadOS and significantly expanded in iPadOS 26. This is genuine multi-window mode: multiple apps running simultaneously, overlapping windows of any size that can be freely moved and resized, and quick switching between sets of working windows.

For developers, this matters a great deal. Previously, working on an iPad looked something like this: open the editor and you can't see the terminal; switch to the terminal and you lose sight of the code; want to check the docs — another switch. Every context switch breaks the flow. Stage Manager removes that barrier: you can keep a code editor, an SSH console, a documentation browser, and an agent window side by side — exactly as you would on a Mac or PC.

iPadOS 26 takes Stage Manager even further: apps built against the new API get native support for multiple independent windows within a single application. This is not a hack or emulation — it is a full windowing system on a tablet.

There was, however, a gap: when these capabilities arrived, no app existed that took full advantage of them and brought all the essential developer tools together in one place. Existing SSH clients had no real code editor. Code editors had no terminal. And native multi-window support was barely mentioned in most of them.

Remote IDE: A Development Environment Built for iPadOS 26

Remote IDE was born from exactly that gap. It was built from scratch for iPadOS 26, written in Swift 6 with SwiftUI, with full Stage Manager and multi-window support from day one. No legacy code, no compromises for backwards compatibility — just what a modern developer or DevOps engineer actually needs when working from an iPad.

The app brings four core tools together in a single interface.

Code Editor with Syntax Highlighting

Remote IDE includes a full-featured code editor built on the Runestone library — the same foundation used in a number of professional iOS editors. It supports Swift, Python, JavaScript, TypeScript, Go, Rust, C, C++, Ruby, PHP, Shell, JSON, YAML, Markdown, HTML, CSS and dozens of other languages via Tree-sitter. The language is detected automatically from the file extension.

Practically important details: find and replace, undo/redo, configurable indentation (spaces or tabs), line numbers, word wrap. Above the on-screen keyboard an extra input bar appears with Tab, brackets, dot, equals sign, and hash — characters that are buried several screens deep on the standard iOS keyboard. Files are saved automatically on every change, so losing edits is impossible.

SSH Console and Server Management

The built-in terminal, powered by SwiftTerm, provides a full interactive session with a remote Linux server directly from the iPad. Both password and SSH key authentication are supported. All credentials — passwords and private keys — are stored exclusively in the device's Keychain and never leave it. The terminal handles ANSI/VT100 escape sequences correctly, meaning colour output, interactive programs like vim or htop, progress bars, and similar displays all work as expected.

A feature that anyone who spends time in the terminal will appreciate: a saved SSH commands library. Long commands like cd /Users/username/Projects/MyProject && npm run build:production can be saved with a descriptive name and triggered with a single tap. The most recently executed command is also available in the console toolbar — repeat it with one touch.

File Manager and SFTP Sync

Local project files are stored in iCloud Drive, which means they are available across all your devices and backed up automatically. The file manager in the sidebar shows the project hierarchy and supports creating, renaming, and deleting files and folders, as well as opening any file in the editor with a single tap.

Synchronisation with the remote server uses SFTP. Dedicated buttons in the console toolbar let you copy the entire project to the server — or pull files back from the server — recursively, preserving the directory structure. A progress indicator is shown during the transfer, and you can cancel at any time. Everything happens without leaving the app or switching to a separate SFTP client.

Git Integration

Change tracking is available in a dedicated Git window — and this is where Stage Manager really shines. You can open the list of modified files alongside the editor, select a file, and immediately see the diff with added lines highlighted in green and removed lines in red. No switching between screens — everything is visible at the same time.

Native Multi-Window Support

Remote IDE uses the iPadOS 26 multi-window API directly. The Git status window, the AI agent window, and the main working window each launch as separate native app windows that Stage Manager manages independently. You decide how to arrange them on screen, how large to make each one, and whether you need them open simultaneously or one at a time.

What This Looks Like in Practice

To move beyond abstractions, here is a concrete scenario.

You are working on a Python backend service. The iPad is on the desk with a Magic Keyboard attached. Stage Manager holds two windows: Remote IDE takes up the larger part of the screen; Safari with the FastAPI docs sits to the right, narrower.

Inside Remote IDE you see three areas at once: the file manager on the left, the code editor at the top, the SSH console at the bottom. In the console, Claude Code is running on the remote server. You type to the agent: "Add an endpoint for exporting data to CSV, use the existing User model." The agent gets to work — creates a file, edits the router, updates dependencies.

While the agent is running, you switch to the Git window (floating separately in Stage Manager) and check what has changed since the last commit. You return to the main window — the agent is done. You open the new file in the editor, review the code, notice that the date format needs adjusting. You edit it directly in the editor — the file saves automatically. You press "copy to server" — the SFTP operation runs in the background, the toolbar indicator shows progress. A few seconds later, a checkmark confirms success. You type the command to restart the service — it is already saved in your command library, so you trigger it with one tap.

This is not "almost like a computer." This is real development.

Security and Credential Handling

The way Remote IDE handles sensitive data deserves specific attention. SSH passwords and private keys are never stored in plain text, never written to the file system, and never placed in UserDefaults. Storage uses exclusively the device's Keychain — Apple's system-level secure store. Private keys are not exposed through the ShareSheet, are not included in any logs, and are never transmitted beyond the app. SSH connections are not established or re-established automatically without an explicit user action.

For a developer working with production servers, this is not a minor detail — it is the basic standard any tool in that context should meet.

Who This App Is For

Remote IDE is aimed at several types of users. Developers who already use the iPad as their primary or secondary device and are tired of the compromises in existing tools. DevOps engineers who need quick server access with as few steps as possible. Technical professionals who value mobility and want a capable tool at hand — on the road, in a café, between meetings.

The app supports both portrait and landscape orientation, adapts to Slide Over and Split View, and works with external keyboards. The interface is localised into English, Russian, Ukrainian, and German. Light and dark themes follow the system setting automatically.

Open Development

Remote IDE is a living project that evolves with feedback from its users. You can discuss the current feature set, propose new capabilities, or report issues directly in GitHub Issues. That is where the app's roadmap is shaped — every user's input directly influences development priorities.

It is also worth noting that the app handles failures gracefully: if the connection drops during a file transfer, the operation is cleanly interrupted without leaving partial data behind; all network operations run asynchronously with a visible loading indicator; and when something goes wrong, the user sees a clear description of the problem and the available actions.

The iPad has long deserved a tool that treats it as a serious working platform rather than a port of a cut-down desktop experience. With Stage Manager in iPadOS 26 and the spread of agentic programming, the moment for that tool has arrived. Remote IDE is built for exactly this moment.

Try Remote IDE on your iPad:

Download on the App Store →

Requires iPadOS 26 or later.