Cognition Announces Native Cloud macOS Support for Its AI Software Engineer Devin

Cognition has announced macOS support for its autonomous AI coding agent Devin, expanding its autonomous cloud development workflow to iOS applications, native macOS software, and any project that relies on Apple developer tooling.

Why Devin Must Have a Mac

To enable an AI agent to independently complete development tasks across the Apple ecosystem, two progressive real-world requirements emerge:

• Compilation and startup do not prove runtime behavior is correct: In local development, code assistants can easily tweak code iteratively based on compiler errors until a build succeeds. But for user-facing graphical interface applications, having code compile cleanly and processes launch successfully does not mean the app actually works; real verification lies in runtime behavior and state restoration.
• Native application verification and toolchains depend on a macOS workspace: Native applications in Apple's ecosystem depend heavily on dedicated toolchains like Xcode and the iOS Simulator; to verify an application's authentic runtime behavior, an agent must have a native macOS workspace where it can actually run, operate, and verify the app.

For example, when developing an iPhone mobile game, a core requirement is that even if a user exits the game, reopening it should accurately return to the state where it was paused. Merely compiling cleanly and launching successfully cannot ensure that the game engine correctly saved and restored runtime data. The agent must complete the full closed loop of "play, pause, exit, reopen, and verify recovery" just like a real user.

Running this closed loop in the cloud is no simple feat. Getting macOS to run inside a virtual machine is merely the first step; turning it into a usable autonomous development workspace requires solving data state persistence, session network security isolation, hands-off boot configuration, and real-time screen streaming and control manipulation for both humans and agents at the underlying level.

These efforts link together sequentially along the same five-layer verification chain: the foundation establishes storage snapshots and secures network boundaries, image preparation moves manual dialogs out of active task time, live video feeds allow users to observe and take over running applications, and the structured accessibility tree empowers Devin to query, act upon, and inspect native UI controls.

1. Storage Layer Design: Connecting Cross-Session Snapshots via NBD Protocol

Devin's cloud service is built on AWS EC2 Mac bare-metal servers, where the host machine runs guest macOS virtual machines using Apple's official Virtualization.framework.

A defining characteristic of cloud agent development is asynchronous collaboration: once users hand off tasks to an agent, they do not need to monitor the session continuously, nor does an idle session require the virtual machine to run indefinitely. To allow users to return directly to their previous work progress the next time they open a session, the system requires a snapshot mechanism to preserve all dependencies, project files, and code changes within the session, eliminating the need to rebuild environments from scratch.

To an operating system, a virtual disk is an underlying block device—responsible solely for reading and writing raw data in fixed-size blocks, without awareness of the higher-level file system or specific snapshot storage implementation. In Linux virtual machines, Devin typically uses the vhost-user protocol to delegate virtual disk I/O operations directly to an independent storage process on the host. However, Apple's Virtualization.framework does not support vhost-user.

As an alternative, Apple's virtualization framework supports another classic communication protocol: Network Block Device (NBD). NBD allows clients to read and write remote or host block devices directly over local sockets. The team added a Network Block Device (NBD) frontend in front of their existing snapshot storage system, successfully reusing the existing persistence architecture without altering the underlying snapshot backend, while the guest virtual machine still sees a standard virtual disk.

Virtual Machine to Snapshot Storage Connection Path

[macOS Guest VM]
App & filesystem reads/writes
       ↓
Standard virtual disk (block device)
       ↓
[System Boundary: Host]
Virtualization.framework
       ↓ (NBD protocol / local Unix Socket)
Host snapshot storage process (NBD frontend connected to existing snapshot backend)

The virtual machine's shutdown lifecycle also requires strict control. When a virtual machine finishes its task, disconnects, and exits, the storage process on the host remains running to save pending writes and upload snapshots. The host hypervisor strictly waits for this finalization process to complete before proceeding with final resource cleanup.

VM Exit and Snapshot Finalization Sequence

VM Status:              [ Running ] ────────> [ Disconnected / Stopped ]
Storage Process Status: [ Handling I/O ] ───> [ Flushing Pending Data ] ──> [ Snapshot Ready ]
Hypervisor:                                   [ Waiting for Flush ] ──────> [ Clean Up Resources ]

2. Network Layer Control: Building a User-Space Ethernet Gateway to Avoid Firewall Race Conditions

Cloud workspaces require stringent network perimeter protection: virtual machines must access external dependency networks in accordance with session policies, while access to the host's private infrastructure must be strictly blocked.

Apple's Virtualization.framework provides three ways to connect virtual machines to the network:

Bridged mode: Sends virtual machine Ethernet frames directly to the host's physical network adapter.

NAT mode: Lets the virtual machine share the host's external IP address, with the macOS operating system managing address translation.

File-handle attachment mode: Directly transmits and receives raw Ethernet frames via a local Unix datagram socket (Unix Datagram Socket) on the host, with each datagram carrying a single frame, leaving subsequent processing to the receiving end.

While NAT mode is straightforward, in this deployment environment, both macOS's Apple NAT and Devin's network control mechanism manage the underlying packet filtering firewall (pf, Packet Filter). When both run concurrently, they contend to configure the same packet filter, creating configuration conflicts and race conditions.

To circumvent this conflict, the team abandoned Apple-managed NAT and chose the lowest-level "file-handle attachment mode." The challenge of this choice is that the host no longer receives easily routable Layer 3 IP packets, but rather Layer 2 Ethernet frames containing physical link information such as MAC addresses. For example, before a virtual machine can send packets outbound, it must first broadcast an ARP (Address Resolution Protocol) request on the local network to determine the gateway's physical address.

To handle this, a custom user-space Ethernet gateway was built on the host to manage these communication details:

VM Network Packet Round-Trip Link

[ macOS Virtual Machine ]
       │ Raw Ethernet frames (Guest MAC → Gateway MAC)
       ▼
[ Host User-Space Ethernet Gateway ]
  ├── Responds to VM ARP queries for physical address
  ├── Validates Ethernet source/destination MAC addresses
  └── Verifies source IP matches system assignment
       │ Passes through sanitized Layer 3 IP packets
       ▼
[ Host Tunnel Interface ]
       │
       ▼
[ pf Firewall Rules & Proxy Service ] ──> Applies session access control policies & routes outbound

This represents an explicit technical trade-off: the deliberate cost incurred by the team was taking on data link layer parsing and verification on the host side, thereby avoiding firewall configuration contention with Apple's built-in NAT, while handing accepted IP packets over to the host tunnel, pf rules, and proxy services.

3. Image Prebuilding and Warmup: Eliminating Permission Dialogs Before System Boot

Anyone who has installed developer tools on a Mac knows that a machine freshly installed with the operating system is far from ready for actual work. The system lacks user accounts, a usable desktop, Xcode tools, and more critically, the various system permissions required for automated interaction.

macOS displays authorization confirmation dialogs for permissions like screen recording and accessibility control. If these issues are left to be dealt with after a session begins, every dialog could cause Devin to halt and wait for a human click.

One approach would be to use UI automation after boot to create users, log into the desktop, trigger permission requests, and approve them one by one, but coordinating this sequence of interface operations is both unreliable and costly.

The system adopts a staged preparation strategy: first, during the base image build phase, it mounts the guest disk offline. The host mounts the virtual disk directly as a local directory, bypassing the GUI to create system users and modify internal macOS configuration databases, completing baseline setup prior to boot.

However, certain dependencies cannot be fully configured in an offline state. Leaving these tasks until after an agent takes over would force Devin to compete with system initialization for resources. Therefore, the system also performs an "online warmup" during the image build phase:

• Boots the prebuilt image, installs remaining developer tools, and verifies the Xcode environment.
• Launches and "wakes up" the iOS Simulator in advance, waiting for its internal OS to finish booting.
• Waits for Spotlight desktop indexing and background initialization tasks to complete entirely, and proactively disables unrelated background system daemons.

Through offline configuration and post-boot warmup preparation, the workspace completes tool installation, environment verification, and unnecessary background daemon shutdown before the agent connects, minimizing post-boot initialization disruption.

4. Live Video: Keeping Remote Interaction Responsive

Once the development environment is ready, the system needs two types of participants to interact with applications: human developers need to observe screens and take over as needed, while AI agents need to inspect UI execution results efficiently.

Remote human access relies primarily on the VNC protocol to present the macOS desktop, supplemented by an independent viewer panel dedicated to mirroring the iOS Simulator window. To keep real-time visuals responsive, the team addressed two specific video engineering details:

Buffer contention: ScreenCaptureKit uses a finite pool of reusable buffers. If the system needs to retain a frame, it creates an independent copy to avoid tying up buffers needed by the capture pipeline.

Queue backlog: If video processing lags during capture, encoding, transmission, or display, old frames accumulate in queues, causing action lag in remote visuals.

To prevent decoding artifacts caused by blindly dropping frames, the system caps the maximum number of queued frames. Once lag is detected in the simulator stream, the system recovers from a recent keyframe or requests a new keyframe, allowing the player to synchronize with the latest state without replaying backlog history.

5. Accessibility Tree: Making Native Controls Queryable

For AI agents, manipulating graphical interfaces relies on more efficient and stable interaction pathways. Relying solely on screenshots for a multimodal path is described in the article as slow and expensive: the agent must capture a full-screen image, locate button pixel coordinates via a multimodal model, invoke a virtual mouse, and capture another screenshot after every action for verification. In long interaction workflows, this approach is exceptionally heavy.

Similar to how web environments use the DOM tree to locate elements, native applications possess an underlying foundation—the Accessibility Tree. The system organizes interface elements into a structured semantic tree containing roles, names, values, states, relationships, and supported actions.

Using accessibility-cli from the open-source Dioxus project, the system gains underlying primitives for accessibility, input, and capture. From this, Devin establishes a structured interaction loop:

Agent Semantic Closed Loop for Operating iOS Simulator

1. Agent initiates a structured control query
{
  "action": "query",
  "target": "ios",
  "role": "button",
  "name": "Resume"
}

2. System returns semantic tree match and temporary handle
@i17 button "Resume" {press}
(@i17 is handle, button is role, Resume is name, press is supported operation)

3. Agent invokes handle directly to perform action
{
  "action": "act",
  "target": "ios",
  "reference": "@i17",
  "operation": "press"
}

4. Agent re-reads accessibility tree and reports state change

Through this tool, Devin can query and reference controls directly via the semantic tree to execute actions, eliminating the need to guess control coordinates from pixel images.

However, the accessibility tree cannot cover all visual content. For example, visual states like custom-rendered game graphics are not reflected in the accessibility tree. The system retains screenshot capabilities, pairing them with screenshots when necessary to complete full state verification.

Applicability Boundaries and Engineering Insights

Devin's macOS support establishes a technical pathway for cloud-based development and verification of native Apple applications. However, when evaluating its scope of applicability, one must remain clear about its technical premises and engineering boundaries:

• The accessibility tree cannot cover all visual states: Seeing a pause menu disappear does not prove that a game character's position was restored correctly; directly rendered graphics may not appear in the tree at all, so screenshots remain necessary to verify visual outcomes.
• No quantitative benchmarks: This technical explanation details the cloud workspace's architecture and product capabilities, but provides no quantitative data regarding runtime performance, infrastructure costs, or security efficacy. It cannot be used to compare efficiency or cost against other development environments.

From virtual disks, network boundaries, and image preparation to live video feeds, semantic controls, and screenshot verification, this underlying engineering provides Devin with the complete Apple workspace required to build and test native applications, extending simple code writing into a "develop-run-verify closed loop" within real operating interfaces. This is the most substantive change brought by Devin's macOS support.