Amp Can Now Build Your iOS App on a Cloud Mac—Here's What That Actually Costs

There is a gap every AI coding tool runs into with Apple platforms. The AI is perfectly happy writing Swift all day on a Linux server. But an iOS app does not exist until something compiles it, launches it in a simulator, and taps through it—and all of that requires a Mac. Writing the code was never the hard part. The hard part is everything after the code is written, and somebody has to pay for the machine that does it.

On October 29, 2026, Amp announced its answer: macOS Satellites. When a task needs macOS, Amp boots a fresh cloud Mac with Xcode and the iOS simulators installed—about 30 seconds, according to the announcement—and your work splits across two machines. The AI keeps editing on its Linux environment, and the Mac only shows up for the parts that genuinely need one: building, running, testing. Screenshots, logs, and build output flow back into your thread, and a Mac tab lets you watch the Mac's screen live or grab the controls and tap through the app yourself.

It is a clean piece of engineering. It is also a new line on your bill, and the details of that bill are worth understanding before you point Amp at the app you have been meaning to build.

What the Mac time costs

There are two sizes. The default, mac.medium, is 6 CPUs and 14 GB of memory at $2 per hour. The bigger mac.large doubles that to 12 CPUs and 28 GB at $4 per hour. Every Mac starts as a medium; you can ask for a large, or flip a setting to always get one.

The order in which money leaves your account matters. Mac time first eats into the compute usage included in your Amp plan—charged at a higher rate than ordinary usage—and once that is gone, it draws from your Amp credit balance. A Mac will not start at all if you have neither left.

One thing the price list does not tell you: these are Mac-hours only. The AI's own work—reading your codebase, writing the code, reasoning through the fix—is billed separately, the way it always is. The satellite fee is the cost of the machine that compiles and runs the result, not the cost of the whole task.

The 20-minute detail that will show up on your invoice

Here is the part worth reading twice. When Amp finishes with a Mac, the Mac does not disappear. It stays running for 20 more minutes. The reason is genuinely useful: if you send a follow-up within that window, Amp reuses the same Mac and, more importantly, its warm build cache, instead of booting a fresh machine and rebuilding from zero. Anyone who has watched Xcode index a project knows why that matters.

But the flip side is that those 20 idle minutes are not free. You pay while a Mac runs, and a Mac runs until it has been idle for 20 minutes. End a task, go make coffee, and the meter is still going.

Two more billing traps hide in the same paragraph of the docs. A long build counts as use, which is fair enough. But so does having the Mac tab open. Sitting there watching the simulator do its thing on the streamed screen is, as far as the meter is concerned, the same as working. And every Mac starts completely fresh with nothing saved, so a session that lapses past 20 minutes means the next one pays for a cold build again.

If you want the Mac gone now, archiving the thread kills it immediately, as does asking Amp to stop it. Closing the Mac tab when you are done watching is the cheapest habit you can build.

How the architecture saves you money, actually

Credit where due: the design exists to avoid a worse bill. Amp's announcement is candid that it first tried running entire sessions on Macs—an experiment it called Morbs—and abandoned it. Docker and backends took minutes to start on Mac hardware, and keeping a Mac disk alive for every thread got expensive. Splitting the work means the cheap Linux machine does the cheap work, and the $2-an-hour machine only spins up when Xcode is truly involved. Your AI reasoning time does not burn Mac rates.

The build-cache reuse plays the same role. Twenty minutes of paid idle time is annoying; twenty minutes that saves a five-minute cold rebuild on every follow-up is a bargain. The docs also note that projects can pin an Xcode version, and Amp will pick a matching Mac image on its own—three images are available, covering Xcode 15.4 through 27.2 and iOS simulators from 15.5 up—so you are not paying to discover version mismatches.

Who can use it right now

Not everyone, yet. macOS Satellites are in beta, and access rolls out through a waitlist as Amp adds Mac capacity. You join under Settings, Experimental Features; a Move Me Up button once a day nudges you forward, and the most persistent clickers go first. Amp has not published how long the wait runs or the full list of eligible regions and plans, so treat this as "sign up and see," not "available today."

Also worth saying plainly: this builds and tests your app. It does not put anything on the App Store, and it does not change anything about Apple's own review, signing, or developer account requirements.

The honest bottom line

Amp's cloud Macs close a real gap: the difference between an AI that can write iOS code and one that can prove the code works. The pricing is not hidden, but it is easy to misread. Two to four dollars an hour sounds trivial until you remember the meter runs through idle coffee breaks and open browser tabs, and that it stacks on top of what the AI itself already costs. Batch your follow-ups into the 20-minute window, close the Mac tab when you are done looking, and check Settings, Usage, Satellites after your first real session. That first invoice is the only documentation that is really about you.

We have not tested the feature ourselves; everything above comes from Amp's announcement and documentation.