Mobile app maker software, listed by pinned version

What other "mobile app maker software" guides skip

Open the first ten guides about mobile app maker software and count how many name the actual programs that run to produce your finished app. The answer is roughly zero. Every guide is a curated table of vendors with a Pricing column, a Templates column, and a Drag and Drop column. The Stack column never appears, because most of those vendors do not publish theirs.

That gap matters more in 2026 than it did five years ago. AI app makers are not closed binaries with a paint-and-publish UI. They are orchestrations of well-known open-source pieces (Vite, Chromium, Playwright, an LLM agent loop). The interesting question is no longer "which vendor has the right templates," it is "which orchestration does what I want and lets me see how."

This page is the version of that table the listicles never publish: the actual software, by name, by pinned version, and where each piece runs.

Where each piece lives in the Dockerfile

The Dockerfile is short. It is one apt-get for the OS-level packages, one curl-pipe-bash for Node 20 from NodeSource, one global npm install for the agent and MCP packages (with their versions pinned), and one npm create vite@latest for the React scaffold at /app. Then a handful of COPY lines drop the small in-VM scripts (proxy.js, acp-bridge.js, brd-proxy.js, startup.sh, scheduler-mcp.js) into /opt.

The interesting line is the global npm install. It explicitly pins the two packages whose wire formats the editor depends on:

RUN npm install -g \
      @playwright/mcp@0.0.70 \
      ws \
      @agentclientprotocol/claude-agent-acp@0.25.0 \
      @anthropic-ai/claude-code \
      social-autoposter \
 && ln -sf /usr/lib/node_modules /node_modules

The trailing symlink is there because Node ESM resolution does not honor NODE_PATH. Putting node_modules at the filesystem root lets ESM imports from files outside any node_modules tree (like /opt/patched-acp-entry.mjs) walk up and find the global packages. That detail will only matter to you if you ever fork the image, but it is the kind of thing that exists on every real software stack and is invisible on every listicle.

Boot order: what comes up, in what order, on what port

The container's startup.sh is intentionally not strict-mode bash. Non-critical services (cron, VNC) are allowed to fail without tearing down the whole boot. The order matters because Chromium needs Xvfb to exist before it can attach a display, MCP needs Chromium's CDP socket to exist before it connects, and the proxy needs all five upstreams to be addressable before it goes to one URL.

By the time the proxy on port 3000 reports ready, Vite is serving HTTP and HMR over WebSocket on 5173, Chromium is listening for CDP on 9222, Playwright MCP is forwarding browser commands on 3001, the ACP bridge is accepting agent control on 3002, and websockify is relaying VNC on 5901. The proxy fronts all of them so a single public URL can serve your iframe preview, the screencast, and the VNC viewer.

Reading the running stack with one command

If you e2b exec into a live sandbox and ask the kernel which sockets are listening, you can see the full stack at runtime. This is the part the marketing pages never show you, because most marketing pages are not for products you can ssh into.

Six listening sockets, one Debian, one Node, one Chromium, one Vite. That is a complete mobile app maker. You did not install any of it.

Why "you do not install it" is a non-trivial property

It is easy to read "no install" as marketing fluff. It is not. The reason this stack stays out of your machine has structural consequences for how iteration works. Three of them are worth naming.

First, the stack drifts in one place, not many. When @playwright/mcp ships a wire-format change or Chromium ships a CDP fix, the change goes into the Dockerfile and the image gets rebuilt by the staging template build on push to main. The production template image is rebuilt by tag. Every active sandbox eventually swaps onto the new image as the pool ages entries out at 45 minutes. Nobody runs npm update. Nobody fights a peer-dependency tree on their laptop.

Second, the test browser is the same browser on every machine. When the agent says "I built it and it renders," it is reporting from the cloud Chromium it just drove. A reader on a Mac, a Linux laptop, or an iPad gets the same answer because the rendering agent is one Debian-Chromium pair, not the visitor's local browser. The bug-or-not-a-bug question stops depending on what else is installed.

Third, the stack is one repo, not a constellation of services. The Dockerfile, the Next.js editor, the agent route handlers, the in-VM scripts (proxy.js, acp-bridge.js, brd-proxy.js, scheduler-mcp.js are each under a thousand lines), and the small Vite scaffold all sit in the appmaker codebase. The stack is not split across a vendor SaaS, an opaque agent API, and a hidden runner. You can read the lines. That is not how most software in this category is shipped.

Honest limits of the no-install stack

A few things this stack does not do, and never claims to.

• It does not produce native iOS or Android binaries. The build target is a mobile web app at 390 by 844, served from the in-VM Vite dev server. You can wrap the result in Capacitor or Expo after the fact, but the prototype loop never touches Xcode or Android Studio.
• It does not give you a long-running production server. The sandbox is a per-session prototype environment. Hosting the finished app for real users is a separate step (a static export to Cloud Run, Cloudflare Pages, your own S3, or any other static host).
• It does not solve auth, payments, or persistent multi-user state for you. The stack ships postgresql-client, ws, and a Resend integration scaffold, so you can wire those in, but they are choices the agent makes inside the project, not services the platform provides.

The honest framing: the stack is a fast iteration loop for mobile-shaped web apps that you can keep iterating on after the first AI pass. It is not a turnkey replacement for a native development environment. The fact that the whole stack is in a readable Dockerfile means you can see exactly where its limits are, instead of running into them at month three of a paid plan.