Can you actually ship an app from your phone?

Did Pieter Levels actually build Infinite Slop from his phone?

Yes, Pieter Levels really did build and launch Infinite Slop while working from his phone.

The public timeline is unusually detailed. Marc-Antoine Ross said the idea came up in a group chat at around 2:30 p.m. UTC. About ten minutes later, Levels decided to build it. A first version was online at 3:18 p.m. They spent roughly another hour and a half testing and changing it, chose the name, spoke with fal about the video infrastructure, and launched around 5:30 p.m.

Levels then explained his setup himself. He used Termius on his iPhone to connect to a Hetzner VPS, ran Claude Code on that remote server, and opened the website in Safari to see what he was building.

That is enough for us to take the claim seriously. Every interaction with the development process happened through the phone, even though most of the computing happened somewhere else.

That distinction tells us what “building from a phone” actually means today. The interesting breakthrough is not that an iPhone suddenly became a tiny MacBook. The development machine can now sit in a data center while the developer carries only the interface.

Was Infinite Slop actually a real app or just a quick demo?

Infinite Slop was already a real public web application with meaningful traffic, so calling it a toy demo understates what Levels shipped from his phone.

The product continuously generates AI video based on prompts from viewers. Users submit ideas through a chat, prompts enter a queue, viewers vote, selected prompts are generated into 15-second clips, and those clips are fed into the stream.

Levels reported 37,000 viewers during the first day. Soon after, concurrent usage passed 2,000 viewers. As traffic grew, he changed the interface to vertical video because most visitors were on mobile, moved the prompt queue, added voting, displayed the next video being generated and kept fixing production issues remotely.

There was also a real throughput constraint. The system could produce about four 15-second clips per minute, which meant demand could exceed generation capacity when the site became busy. That forced an actual product decision: which user prompt should get scarce generation time?

The heavy video generation came from fal's infrastructure rather than Levels' server. That is completely normal for an AI product these days. Plenty of serious applications rely on Stripe for payments, AWS for compute, OpenAI for models or Cloudflare for networking.

Infinite Slop gives us a useful lower bound. We know someone can now create, deploy and operate an interactive public web product with thousands of simultaneous users while carrying only a phone.

When someone says they built an app from their phone, what is the phone actually doing?

In most serious phone-built apps today, the phone acts as the command center while servers elsewhere handle the code, compute, builds and deployment.

Levels' setup makes this easy to picture. Termius turns the iPhone into an SSH terminal. The Hetzner VPS behaves like the development computer. Claude Code reads and changes the repository on that server. The web server exposes the application publicly. Safari shows the result.

Other stacks divide the work differently. GitHub Codespaces puts a complete development environment on a remote virtual machine and exposes VS Code through a browser. Replit combines an AI agent, code, hosting and deployment behind a mobile interface for web applications. Expo sends mobile projects to remote machines when they need to be compiled.

So “phone development” currently covers several different setups. The common thread is that the developer can control the whole workflow without having the traditional development machine physically in front of them.

Part of the job	What we touch on the phone	Where the work happens
Give coding instructions	Termius, Replit, browser	Phone interface
Read and change code	AI agent or browser editor	Remote server or cloud workspace
Run Node, Python, PHP or Git	Terminal	Remote Linux machine
Store application data	Dashboard or terminal	Remote database
Preview a web app	Safari or Chrome	Phone browser
Deploy	Terminal, Git or cloud service	Remote infrastructure
Compile an iOS app	Remote command	Cloud Mac
Compile an Android app	Remote command	Cloud Linux machine

Why is building an app from a phone suddenly practical now?

AI coding agents are the main reason phone development has gone from an awkward trick to something people can genuinely use.

SSH apps have existed for years. Cloud servers have existed for years. Browser-based code editors have existed for years. We could technically access a development machine from a phone long before the current wave of AI coding tools.

The horrible part was doing the work.

Traditional programming involves thousands of tiny interactions. We jump between files, change individual lines, search through code, type commands, read documentation, inspect errors and keep several pieces of information in our head at once. A touchscreen is a terrible interface for that style of work.

Claude Code, Codex and similar agents reduce the number of human interactions dramatically. We can describe a change in a few sentences and let the agent inspect ten files, modify four of them, run tests and report what happened.

Anthropic measured this change in millions of Claude Code interactions. In its 2026 research on agent autonomy, the longest-running Claude Code sessions went from less than 25 minutes of autonomous work to more than 45 minutes within three months.

That trajectory is particularly useful on a phone. The smaller the amount of manual interaction required from us, the less painful the small screen becomes.

The big change these days is therefore the amount of software work that can happen between two human messages.

Can you ship a real web app entirely from your phone today?

Yes, shipping a real web app from a phone is already practical today, especially if the application uses a remote server or a managed platform.

The SSH route gives us almost the same command line we would use on a laptop. We can connect to a Linux VPS, clone a repository, install packages, run a database migration, restart an application, inspect logs, push to Git and deploy.

Termius currently supports iPhone and iPad alongside desktop platforms, which makes this workflow straightforward. A remote Linux machine can stay online permanently, so the development environment is still there when we reconnect from another device.

Managed platforms make the process easier for people who do not want to administer Linux. Replit explicitly markets its current mobile app around creating, changing and publishing websites and web apps from iOS or Android. Its Agent can generate code from natural-language instructions, preview the result and deploy it to a live URL.

GitHub Codespaces offers another route. GitHub says a codespace can be opened through a browser, where we can edit code, run Git commands, use a terminal, debug the application and run it on the remote machine.

These are three quite different products converging on the same architecture.

For web software, owning a physical development computer is becoming optional.

Can you actually debug and run the backend from a phone?

Yes, we can handle a surprising amount of debugging and backend work from a phone, although difficult bugs expose the limitations of the screen very quickly.

Server-side work fits this workflow particularly well. An AI coding agent can search application logs, inspect a stack trace, query a database, find the relevant code, run a test and propose a fix while we stay inside one terminal conversation.

Backend infrastructure was already designed to be operated remotely. SSH gives us access to processes, configuration files, databases and logs. Managed databases and hosting platforms add browser dashboards on top of that.

Simple debugging can therefore feel almost effortless. We tell the agent that registration is returning a 500 error. The agent checks the server logs, follows the failing function, finds an unexpected database value, changes the code, runs the tests and shows us the diff.

The experience deteriorates once we need to inspect lots of information ourselves. Comparing several source files, watching network requests, studying a browser rendering problem and reading a large diff are all much easier on a large display.

So phone debugging works best while the agent understands the problem. When we have to become the debugger ourselves, screen size starts to hurt.

Can you really ship an iPhone app without opening a Mac?

Yes, an iPhone app can now be built and submitted without a local Mac if we use a cloud build service such as Expo EAS.

Apple still keeps its full native development environment on larger devices. Xcode runs on Mac, while Apple's Swift Playgrounds app supports building and submitting apps from iPad and Mac. Apple does not currently offer that same Swift Playgrounds workflow on iPhone.

Cloud build systems get around the hardware constraint.

Expo's current EAS infrastructure sends iOS projects to isolated macOS virtual machines running Xcode, Fastlane, CocoaPods and the rest of the Apple build toolchain. Expo says EAS Submit works from macOS, Linux and Windows, so the machine initiating the submission does not need to be a Mac.

That gives us a workable phone-controlled route. The repository can live on a remote Linux server. We access it through the phone, change the application with an agent, run the EAS command remotely, and Expo builds the binary on its Mac infrastructure. The resulting build can then be sent to App Store Connect.

The awkward part appears when something goes wrong deep inside the native stack. Complex signing problems, unusual entitlements, Instruments profiling or low-level Xcode debugging are much less pleasant without direct access to a Mac.

iOS step	Possible without a local Mac?	How
Write React Native / Expo code	Yes	Remote server or cloud IDE
Test on an iPhone	Yes	Physical device / Expo
Compile the App Store build	Yes	EAS cloud Mac
Manage signing credentials	Yes	EAS / Apple account
Upload the binary	Yes	EAS Submit
Manage TestFlight and App Store status	Yes	App Store Connect
Use full Xcode locally	No	Mac required
Use Apple's Swift Playgrounds workflow	No on iPhone	iPad or Mac

Is shipping an Android app from a phone easier than shipping an iPhone app?

Technically, Android is easier to build remotely, although Google Play can make the final launch surprisingly slow.

Android compilation already fits naturally on Linux. Expo's current build infrastructure runs Android builds on remote Linux virtual machines with Gradle, the Android SDK and the other required tools. We can trigger that process from a remote development environment controlled through our phone.

The app-store rules are where things become less instant.

Google currently requires personal developer accounts created after November 2023 to complete a closed test before receiving production access. At least 12 testers must remain opted in continuously for 14 days. Only after that period can the developer apply for production distribution.

A recent Google Play support discussion shows that developers are still running into this requirement now, including cases where Google asks for additional testing when the first test does not appear convincing enough.

The result is a funny situation. An AI agent might help us build a small Android app over a weekend, while Google can require two weeks of testing before the public launch.

For Android, the engineering path is already very phone-friendly. Distribution rules can take longer than the coding.

Can someone who barely knows how to code ship a web app from a phone?

Yes, a beginner can now get a functional web app online from a phone, but operating the product becomes harder as soon as real users and real data arrive.

Replit is probably the clearest example. Its mobile product currently lets people describe a web application in natural language, watch Agent build it, request changes and publish it from the phone.

That covers far more than a landing page. Modern agent platforms can generate authentication flows, database-backed dashboards, forms, simple marketplaces, internal tools and AI applications.

The hard part moves later in the process.

A beginner may reach a convincing first version without understanding much of the generated code. Then someone finds a permissions bug. A payment webhook fires twice. A database migration destroys a column. A user submits malformed input. An API key leaks into the frontend. A production deployment fails halfway through.

AI agents can help solve all of those problems too, but somebody still needs enough judgment to recognize when the proposed fix is safe.

The barrier to creating software has dropped much faster than the barrier to being responsible for software.

Does Replit replace Termius and a VPS for phone development?

For many people building their first web app, Replit is currently the easier phone setup because it hides most of the infrastructure that Termius and a VPS make us manage ourselves.

With the Termius route, we choose the server, configure Linux, install the development tools, secure access, run the application and decide how deployment works. That gives us control, but it assumes we understand what we are controlling.

Replit bundles much of that experience behind Agent and its hosting platform. We can spend more time describing the product and less time thinking about SSH keys, processes and server configuration.

There is an important limit in Replit's current product positioning. Replit specifically says its iOS and Android mobile app is built for websites and web apps. For its full native iOS and Android workflow, Replit tells developers to use the web version, where Agent works with Expo previews and the app-store submission process.

So the easiest setup depends on what we are building.

For a web product, Replit is now much closer to “open the phone and start building.”

For developers who want full server control, a Termius connection to their own VPS remains much more flexible.

What kinds of apps can realistically be shipped from a phone now?

Web apps, SaaS products, AI tools and server-heavy applications are already strong candidates for phone development, while projects dominated by complex visual tooling remain much less comfortable.

The decisive factor is how much of the workflow can live behind text commands, APIs and automated builds.

An AI application can be technically ambitious while remaining easy to control from a phone because the model inference already happens on external infrastructure. A SaaS dashboard can have authentication, subscriptions, databases and thousands of users without requiring special local hardware.

A large 3D game creates the opposite situation. Building the product may involve scene editors, shaders, animation timelines, asset management and constant visual inspection. Moving those tools to a remote computer does little to solve the six-inch-screen problem.

Architecture tells us more than app complexity here.

Product	Phone development today	Main reason
Landing page or directory	Very practical	Browser and remote hosting cover nearly everything
SaaS or dashboard	Very practical	Mostly code, database and APIs
AI application	Very practical	Heavy compute already happens remotely
Bot or automation	Very practical	Mostly server-side work
Interactive web app	Practical	Browser provides the real test environment
React Native / Expo app	Possible	Cloud builds cover native compilation
Fully native iOS app	Possible but awkward	Deep Xcode work remains difficult
Hardware-heavy mobile app	Awkward	Device debugging becomes important
Large 3D game	Poor fit	Visual desktop tools dominate
Huge mature codebase	Mixed	Reviewing complexity becomes the bottleneck

Where does phone-only development break first?

Phone-only development usually breaks when we need to personally absorb a lot of technical information at once.

The six-inch display remains the obvious problem. A coding agent can hide most of the repository while everything is going well. One ugly bug can suddenly require us to inspect three source files, two terminals, a database query, browser network requests and a large Git diff.

Laptops handle this through space. We can leave several windows open and keep visual context while moving between them. A phone forces us to replace one context with another repeatedly.

Visual development tools create an even harder limit. Xcode's advanced debugging tools, game engines, design-heavy interfaces and graphics software were built around large displays, precise pointing devices and multiple panels.

Code review is another weak point that deserves more attention now. AI agents can generate hundreds of lines of code very quickly. The easier code becomes to produce, the more important it becomes to review what the agent changed. Reading a 1,000-line diff on a phone is possible. Few developers would choose it.

Phone development works surprisingly well when we stay at the level of instructions and outcomes.

The moment the job becomes detailed inspection, we start wanting the laptop back.

Is developing from a phone actually faster than using a laptop?

Usually no, a laptop is still faster for focused development; the phone wins because it lets us work during moments when the laptop is unavailable.

That distinction matters.

Levels getting a first version online in under an hour is evidence that the phone did not prevent rapid execution. We cannot infer that the phone made him faster. An experienced developer at a desk with a keyboard and a large monitor could easily be faster still.

The advantage appears elsewhere.

A founder notices a bug while having lunch. Instead of remembering to fix it four hours later, she tells an agent to investigate immediately. Someone has an idea in a taxi. Instead of writing it into Notes, he starts the application and already has a working version by the time he gets home.

This converts previously dead development time into usable development time.

For focused three-hour programming sessions, the laptop still wins easily.

For turning random 15-minute windows into productive software work, the phone has become much more interesting.

Can you maintain a real app from your phone after launch?

Yes, routine maintenance on a real app can now be handled from a phone surprisingly well, especially when deployment and monitoring are already automated.

Small production changes fit the agent workflow nicely. We can report a bug, ask the agent to inspect the logs, review its explanation, run the tests and deploy a small fix.

Remote infrastructure also means we can reconnect to exactly the same environment later. A VPS keeps running. A Codespace can be reopened. Git preserves the history. Cloud deployment systems handle the release. App Store Connect can show native app status and TestFlight information from an iPhone.

A serious incident is where this gets much less attractive.

If customers cannot log in, payments are failing and several services are throwing different errors, we will probably want more than a phone screen. The same applies to a major refactor or a large agent-generated change that deserves careful review.

So there is little reason to make “phone-only” a permanent rule.

The useful change is that leaving the desk no longer means losing access to the product.

Are app stores becoming a bigger bottleneck than actually building the app?

For small native apps, yes: publishing rules can now take longer than creating the software itself.

Apple requires the app to meet its store rules, provide the necessary metadata and privacy information, use an accepted SDK and go through App Review. Apple currently requires new iOS and iPadOS submissions to be built with the iOS and iPadOS 26 SDK or later.

Google can impose an even clearer time floor for new personal accounts. The 12-tester closed test has to run continuously for 14 days before the developer can apply for production access.

Compare that with the tooling on the development side. Expo says a small Android or iOS cloud build can start within minutes. Replit markets the creation of complete applications through a natural-language conversation. Coding agents can work independently for increasingly long stretches.

Software creation is compressing toward hours.

Store distribution still includes waiting periods, identity checks, testing, metadata, privacy disclosures and human review.

That gap will probably make web apps even more attractive for fast experiments. A public web application becomes usable as soon as we deploy it to a URL. There is no mandatory store gate between the developer and the first user.

So can you actually ship an app from your phone?

Yes. You can genuinely ship an app from your phone now, and for web apps the technical argument is basically settled.

We have a real recent example of an interactive web application being conceived, built, deployed and then modified under live traffic through an iPhone. We also have mainstream tools designed around the same model: Termius for remote servers, GitHub Codespaces for cloud development environments, Replit for mobile web-app creation, Claude Code for agentic coding and Expo for remote native builds.

Native apps require more qualifications. An iPhone still cannot run Xcode locally, Apple keeps Swift Playgrounds development on iPad and Mac, and native debugging becomes awkward when problems reach deep into the platform. Cloud services can now handle enough of the missing build infrastructure that an iPhone-controlled workflow is technically possible from code to store submission.

The larger shift is easier to see if we stop thinking about the phone's hardware.

Code can live on a server. The coding agent can run beside it. Databases already live in the cloud. AI inference happens through APIs. iOS compilation can happen on a remote Mac. Android compilation can happen on remote Linux. Deployment can run automatically.

Once all of those pieces leave the local computer, the developer mainly needs an interface for telling the system what to do and checking what came back.

A laptop is still much better when we want to sit down and develop seriously.

But carrying one is no longer a requirement for shipping software.