One prompt.

Could have done this from a phone, Linux, Windows, anything with a browser.

Setup was 5 clicks. Write-up and the full video are in the article. https://t.co/Jnt3x3kjgP

You don’t need a mac to build SwiftUI iOS apps in 2026.

You do not need a MacBook to build a SwiftUI iOS app and I found the easiest way to do it, with a merged PR backing this claim.

Today i did the entire app development of a native iOS SwiftUI app on a Mac for free. And the setup was 5 clicks. I did it to show you that it’s possible so you can take advantage of this opportunity.

I didn’t pay a single dime for the mac.

One prompt and Devin built a SwiftUI habit tracker, ran it in the iPhone 16 Pro Simulator, tapped through every habit while recording the screen, then pushed the code and merged the PR. Xcode never touched a laptop.

For a long time the answer to “can I build an iOS app on Windows or Linux” was no, and everyone repeated it, including me. Apple’s toolchain needs macOS, so the hardware was the gate. That gate is now a configuration field.

People find ways to do it, rent a mac online or do other things like using other macs friends, but I found a way easier way.

I keep repeating that I have been reluctant about cloud agents for a long time, caue I got so used to the local way of working, local repo, local files.

I like watching my own machine do the work. For years I was using a windows Lenovo Thinkpad and I knew building such apps would require vairous workarounds.

This method I will show you is by far the easiest, requiring the least setup and is runs fully in the cloud but at the same time giving you full control over the development process if you only wish to.

What’s a Devin Outpost?

Devin Outpost - is a queue of Devin sessions that runs on machines you control instead of Devin’s own sandbox. You register an outpost in your Devin org, it shows up as a machine option next to Ubuntu and Windows, and sessions you start on it wait in its queue until one of your machines picks the work up.

The split is simple. The agent loop, planning, and inference stay in Devin’s cloud. Every shell command, file edit, build, and repo access happens on your machine.

Namespace Devbox - is a full, isolated machine (Linux or macOS) that Namespace provisions fresh for a session and tears down when the session ends. Namespace is a launch partner for Outposts and, per their docs, the only Outposts provider that runs Devin sessions on macOS, on Apple Silicon rather than an emulated stand-in.

Devbox blueprint - is the saved configuration for that machine: operating system, base image (for macOS this picks the macOS and Xcode version), machine size, access mode. Connect the blueprint to your Devin org and it appears as a virtual environment you can select for any session.

That is the whole trick behind “iOS without a Mac”. You are not renting a Mac and remoting into it. You are giving the agent one.

Why outposts? Why not just Devin Cloud directly?

Because Devin Cloud gives you Linux by default, and Xcode does not run on Linux. Apple’s toolchain needs macOS, and that is exactly the gap an outpost fills.

The other reason is the stuff that has nothing to do with Macs: your own base image, your internal network, your egress rules. Cognition is clear in the docs that Outposts moves real operational responsibility to you, provisioning, isolation, access control, capacity, monitoring. For a hobby iOS build that is fine. For a company, read that page before you commit.

How the Mac gets created (blueprint, devbox, session)

This is the setup path, straight from the Namespace and Devin docs, in the order you actually do it:

• Create a Devbox blueprint in the Namespace dashboard, under Devboxes then Blueprints, with New Blueprint.

• Fill in the name (this is the name you will see inside Devin), operating system macOS, base image (this is where you choose the macOS and Xcode version), machine size for vCPU and RAM, and access mode, which must be Workspace-wide (shared).

• Press Connect with Devin and follow the flow. That links the blueprint to your Devin organization.

• In Devin Cloud, start a new session, open Settings, expand Virtual environments, and pick the blueprint. The session gets queued, Namespace claims it, provisions a fresh Devbox, and starts the Devin worker inside it.

If you go the do-it-yourself route instead of a partner, the Devin side is Settings then Environment then Outposts then Create Outpost, you pick a name and machine type, and you get an Outpost token that is shown exactly once. Save it properly. Then you run devin worker start –outpost=NAME –token=TOKEN on your own Mac, in a directory you are comfortable letting an agent work in freely, and sessions land in the repos subfolder of it.

Only outbound HTTPS is used either way. No inbound ports, no public IP, no VPN tunnel to babysit. That detail is from the Namespace docs, and it is the part that makes this usable inside a company network.

Blueprints on the Devin side are a separate thing worth knowing about: Devin can read a repo and suggest an initialization and maintenance script for it, you review and approve it, and approved blueprints get baked into a snapshot that future sessions boot from. My session ran from a prebuilt snapshot of the macOS environment. I did not create a new one for this project, so it installed nothing at session start.

The machine Devin actually got

This is what the session reported:

• macOS 26.6, Apple Silicon

• Xcode 26.4.1 (build 17E202)

• 6 vCPU, 14 GB RAM, 150 GB free on the work volume

• iOS Simulator runtimes 18.6, 26.2, 26.4 already installed

• Working directory on the devbox volume, with repos under it

Namespace’s blog says macOS devboxes run on M4 Pro or M5 Max hardware and support VNC so you can watch the same screen the agent sees. I did not open VNC, I watched through Devin’s own screen recording and Devin’s own screen view where I can see live what Devin is doing or take over control.

The brief I gave it

I have Devin a simple task for the sake of this demonstration. One paragraph, no spec document:

Build an iOS SwiftUI habit tracker app. It should come pre-loaded with 4 habits: Drink water, Workout, Read 20 min, and Meditate, each with a current streak already set (12, 5, 8, 3 days) so the app looks lived-in. Each habit shows an Apple-style animated progress ring that fills with a spring animation when tapped, plus its streak counter. Dark, polished UI. Run it in the iOS Simulator, test it by tapping through each habit, and record the test. Then create a new GitHub repo, push the code, open a PR, and merge it.

What came back

420 lines of Swift across five files: the habit model with per-habit accent colors, a small observable store that seeds the four habits and owns the toggle logic, the card view, the ring, and the app entry point.

The ring is a trimmed Circle with a gradient stroke, rounded cap, rotated so it starts at the top, animated with .spring(response: 0.6, dampingFraction: 0.7). Tapping a card toggles completion and moves the streak, up on complete, back down on undo, with light haptics through .sensoryFeedback and real accessibility labels on every card.

Final build in the iPhone 16 Pro Simulator, dark UI, four habits with streaks

The build and run loop is three commands, and they are the same three you would run on your own Mac:

xcodebuild -project HabitTracker.xcodeproj -scheme HabitTracker
-destination ‘platform=iOS Simulator,name=iPhone 16 Pro,OS=18.6,arch=arm64’
CODE_SIGNING_ALLOWED=NO build

xcrun simctl install BOOTED_UDID …/HabitTracker.app xcrun simctl launch BOOTED_UDID com.example.HabitTracker

Testing it, without me clicking anything

This is the part I actually wanted. Devin drove the Simulator through the GUI, tapped each habit in order, and recorded the screen.

Drink water 12 to 13. Workout 5 to 6. Read 20 min 8 to 9. Meditate 3 to 4. Daily progress ring walked 0 of 4 up to 4 of 4 and the copy switched to “You showed up for every habit.”

Three of four habits complete during the tap-through

All four complete, 4 of 4, every ring filled

Then it untapped Drink water and confirmed the streak went back to 12 and the counter to 3 of 4, which is the check I would have skipped myself.

The detail I liked most: it captured frames mid animation, with the rings partially drawn, to prove the spring was actually animating and not snapping straight to full. I would not have thought to ask for that.

The one small mistake I made

I did not prepare the GitHub side. The devbox had no GitHub auth for creating repos, the CLI was not logged in and the API answered 401. Devin could push to an existing repo through its git proxy, but not create a new one. It stopped and asked, I created the repo by hand, and we lost a few minutes to that. Pre-create the repo, or wire up a token, before you start.

Was this fully automated head to toes?

No, but because of me.

I wrote the prompt. I answered one blocking question about GitHub. I asked twice vie side chat how’s the progress - for the sake of showing in the video the side chat feature.

Everything between those interventions, the Swift, the build, the Simulator, the tap-through, the recording, the commit, the PR, was the agent.

I stopped being the person who clicks through the app, and became the person who reads the report. Two PRs merged, one for the app, one for a reusable iOS Simulator testing skill so the next session does not rediscover the simctl dance.

What this changes

The bottleneck in iOS was never writing SwiftUI. It was owning a Mac to compile it on - honestly many people build apps on windows or linux machines and don’t want or can’t afford a mac.

A blueprint with macOS and an Xcode version removes that, and the machine goes away when the session ends, so you pay for a session instead of a laptop.

In the free trial of namespace I paid nothing.

If you are on Windows or Linux, that is the entire unlock. Your machine writes the brief and reads the report, the Mac work happens somewhere else and disappears afterwards.

I am not going to pretend one habit tracker proves an App Store pipeline. Signing, provisioning profiles, TestFlight, real devices, none of that was in scope here and I have not done it in this setup yet.

That is the next thing I want to try.

Next steps

What do you want to know more about?

I already wrote about the other direction: Devin taking over my own MacBook to test a Chrome extension:

Chris W@Chris_Wozniczek·Aug 4I refused to test my chrome extension so Devin took over my mac and did it for me. ArticleDevin took my macbook, tested my app and saved me hours of clicking!I am not a frequent cloud agent user but I like to experiment with different solutions in order to achieve my goals. The goal here was simple.

Automate testing. Not just unit testing but the testing…34132K

If you want the full map of Desktop, cloud, CLI, Outposts, Fusion, Deepwiki, start here:

Chris W@Chris_Wozniczek·Aug 20I keep seeing these questions:

What’s Devin? What’s Devin Desktop? What happened to Windsurf?

I put it all in one place. Desktop, cloud, CLI, Outposts, Fusion, Deepwiki, review, testing, security.

if you feel lost, start here.

https://x.com/cognition/status/2085390050141810996/video/1… ArticleThe Ultimate Guide to Building Apps and Products in 2026 with Devin Local and CloudI have been reluctant to trying out cloud agents for a long time and got so used to my way of working using local agents. Now I use both but starting to push more work to the cloud. I spend most of my…62177K

happy to assist just let me know how, hope you enjoyed the read😉