VS Code on iPad: What Works in 2026

VS Code on an iPad means opening vscode.dev in Safari. You get the actual VS Code editor: open a repo, edit files, commit. What you do not get is a terminal or a runtime. By Microsoft's own statement the browser version is "a very limited execution environment" where "the terminal and debugger are not available." So you can edit code on an iPad, but you cannot run, build, or debug it there — and a Magic Keyboard does not change that, because the limit is the browser sandbox, not the keyboard. If running code is what you came for, the honest answer is a native app plus a persistent cloud Linux box, which is what we build at Cosyra.

The iPad makes this question sharper than the phone version does. On a phone you can blame the small screen for vscode.dev feeling cramped. On an iPad, especially an iPad Pro with a Magic Keyboard, the screen is laptop-sized, the trackpad gives you a pointer and hover, and Stage Manager gives you windowing. The hardware excuse is gone. And yet the one thing that decides whether you can build software — a terminal — is still missing, for the same reason it is missing on the phone. This guide quotes Microsoft's docs and GitHub issue tracker directly so you are not taking our word for it, then shows the setup that actually gives you a terminal on an iPad. For the phone angle and the full four-surface breakdown, see our VS Code on your phone guide; for a head-to-head on the run-code question specifically, see Cosyra vs VS Code for the Web.

The iPad paradox: the hardware is there, the terminal is not

Apple sells the iPad Pro as a computer that can replace your laptop, and for a lot of work it can. So the natural assumption is that VS Code in a browser, which feels cramped on a phone, finally comes into its own on an iPad. The editor itself does feel better: more room for the file tree, a real pointer from the trackpad, keyboard shortcuts from a hardware keyboard. We opened a repo in vscode.dev on an iPad Pro with the Magic Keyboard and it was a genuinely pleasant place to read and edit code.

Then we reached for a terminal to run the project, and there wasn't one. That is the paradox in one sentence: the iPad fixes the input problem and the screen problem, but the thing that stops vscode.dev from being a dev environment is neither. It is the browser sandbox, and the sandbox is the same on a $1,300 iPad Pro as it is on a phone. A better keyboard cannot add a runtime that the browser does not expose.

What actually works in vscode.dev on an iPad

vscode.dev on an iPad is good at a specific, narrow job, and the iPad makes that job nicer than the phone does. Reading and editing code, and committing it, all work well. Fixing a config file, reviewing a pull request diff, editing docs, making a quick change while you are on the couch without the laptop — the iPad's screen and keyboard make this comfortable. The editor is the real Monaco editor with the command palette and keybindings you know, so there is no learning curve.

Language help is tiered, and Microsoft's docs lay it out: most languages get syntax coloring and text-based completions; TypeScript, JavaScript, and Python get richer single-file completions and syntax errors; and JSON, HTML, CSS, and Markdown are "nearly identical to the desktop." What you lose is project-wide IntelliSense for most languages, because there is no compute to run a language server. For a Markdown or JSON edit on the sofa, none of that matters. For building and running software, it is the whole game.

The load-bearing limit: no terminal, no runtime

This is the fact that decides whether vscode.dev is enough for you on an iPad. Straight from the official VS Code for the Web docs:

"the terminal and debugger are not available, which makes sense since you can't compile, run, and debug a Rust or Go application within the browser sandbox."

Microsoft is not hiding this, and it follows it with the recommended fix: "if you need access to a runtime to run, build, or debug your code, you want to use platform features such as a terminal … we recommend moving your work to the desktop application, GitHub Codespaces, or using Remote - Tunnels." Every one of those moves the compute to a real machine and reaches it over the network. On an iPad the editor in Safari is, by design, just the front end — the same front end you would get on a phone, only with more screen around it.

We will say the opinionated part plainly, because it is what an "vscode on iPad" search is really chasing: the iPad is good enough hardware to be a real coding machine, and the thing holding it back is not the device, it is the decision to run the editor inside a browser. The edit-and-commit workflow is fine for small fixes. But the reason people want to code on an iPad in 2026 is to run a dev server, run a test, or hand a task to an AI coding agent, and none of that happens in a browser sandbox. People who say vscode.dev is "basically a laptop on the iPad" usually mean they only ever edit, never run.

Safari on iPad cannot open a project folder

There is one more iPad-specific catch worth knowing before you build a workflow around vscode.dev. Opening a local project folder in the browser relies on the File System Access API, which is implemented in Chrome and Edge but not in Safari. On an iPad, where every browser ultimately runs on Safari's engine, vscode.dev can open single files but not a whole local folder. The practical path is to open a GitHub or Azure Repos URL instead — for example https://vscode.dev/github/your-org/your-repo — which loads the repo through the service's API rather than from local disk. It works, but it means your "local" project on the iPad is not really local; it is a repo loaded over the network, with no terminal to act on it.

Touch and iPad support has been in the Backlog since 2019

Even for editing, the iPad experience has rough edges, and it has been a known gap for years. The request, issue #85254, "Web: Mobile Safari support," was opened on 2019-11-21 and carries the ios-ipados label specifically. As of 2026-06-03 it is still open, in the Backlog milestone. A Microsoft maintainer documents the gaps in the thread: missing wheel-event support, the Escape key not reachable, function keys absent, and hover-triggered UI that is hard to reach without a pointer. The Magic Keyboard's trackpad helps the hover problem, but the wheel-event and key gaps remain, and the in-thread conclusion is that without an external keyboard and mouse the web UI is "difficult to use."

A newer request, issue #256181, "Mobile-Friendly Layout for vscode.dev" (opened 2025-07-16), asks for larger touch targets, resizable panels, and a minimal small-screen layout. It is also open and in the Backlog with no commitment to ship. So the realistic read after six-plus years, with the ios-ipados label sitting on an unstaffed issue: a touch-optimized VS Code on the web for iPad may simply not arrive. That is worth knowing before you plan your iPad coding setup around it.

github.dev: the same gap, even lighter

If you only need to edit a GitHub repo from the iPad, github.dev is the fastest path. GitHub calls it "a lightweight editing experience that runs entirely in your browser," where you "navigate files and source code repositories" and "make and commit code changes." Press the period key on a repo and you are in. It is excellent for a quick fix from the couch. It also has no terminal and no compute, so the same ceiling applies on iPad as everywhere else: edit and commit, do not run.

How to actually run code from an iPad

The pattern that works is the one vscode.dev is missing: a native app talking to a persistent cloud Linux environment, so the editor has a computer behind it. The iPad's job is to be a good client to a real Linux box — and with the big screen and Magic Keyboard, it is a very good client. That is what we build. You get a persistent Ubuntu 24.04 container on Azure AKS with Claude Code, Codex CLI, OpenCode, and Gemini CLI already installed, 30 GB of storage, and hibernation that resumes where you left off. The same container is reachable from iPad, iPhone, and the web, so we start a task on the iPad on the couch and pick it up on a laptop later without re-cloning anything. Here is the three-minute setup.

Step 1: Install Cosyra

Install Cosyra from the App Store (it runs on iPad and iPhone) or on Android from Google Play. Sign in with Apple, Google, or email, and the app provisions a fresh Ubuntu container on first launch. This is a native app, not a desktop editor squeezed into Safari, so it gets the full iPad keyboard and pointer.

Step 2: Add your model API key

Cosyra is bring-your-own-key, so you pay Anthropic, OpenAI, or Google directly rather than through us. In the terminal:

Step 3: Run your code or an agent

This is the step the browser cannot do. Clone a repo and run it, or hand the work to an AI agent on the iPad's big screen:

How the iPad coding options compare

Lined up against what matters when the device on your lap is an iPad — a real terminal, a native app, and whether you can actually run your code — the surfaces sort out clearly. The table covers the realistic paths as of 2026-06-03.

Where VS Code for the Web wins on iPad

A fair comparison names what the other tool does better, so here it is with no hedging. vscode.dev and github.dev beat Cosyra on these, and if they describe your situation you should use them:

• Truly free and zero-install. No account, no trial, no card. Open vscode.dev in Safari and edit. Cosyra is a paid container ($29.99/mo Pro after the free trial).
• Instant for quick repo edits. Press the period key on a GitHub repo and you are editing in a second. For a one-line fix or a PR review from the iPad, github.dev is faster than spinning up any container.
• The real VS Code editor UI. Familiar keybindings, command palette, the Monaco editor, no learning curve for existing VS Code users — and on the iPad's bigger screen it is comfortable to read.
• Microsoft-backed, not going anywhere. vscode.dev is actively shipping monthly. No vendor-longevity worry.

Who should pick which on an iPad?

Here is the decision framework we would give a friend, with the "can I run it" question front and center.

• Pick vscode.dev or github.dev if you only need to edit and commit (config tweaks, docs, a quick PR review), you want zero cost and zero setup, and you never compile or run from the iPad. They are purpose-built for exactly that, and they are free.
• Pick Cosyra if the device on your lap is an iPad and you need a real terminal: to run a dev server, run tests, or drive an AI coding agent. That is the part the browser sandbox cannot do, no matter how good your keyboard is, and it is the part we built for.
• Try vscode.dev first if you are not sure how much you actually need to run versus edit. Open a repo, make an edit, and the moment you reach for a terminal you will know which side of this line you are on.

Frequently asked questions

For the wider picture, our guide to AI coding agents on mobile maps every agent across phone and tablet, and the mobile coding terminal pillar covers the terminal-on-a-device decision end to end. If you are weighing the iPad specifically for AI coding, see our Claude Code on iPad walkthrough, and for other browser-only IDEs that hit the same wall on a tablet, our Firebase Studio on iPad and Coder on iPad guides. Zed has it even worse than the browser IDEs — no iPad app and no web build at all — which we cover in Zed on iPad. Kiro, AWS's agentic IDE built on Code OSS, sits in the same desktop-first bucket: its editor is desktop-only, and its browser surface (Kiro Web) is a paid autonomous-PR dashboard rather than an editor you would drive from a tablet, which we cover in Kiro on iPad.