Why FaangCoder Ships Nothing on macOS (And Might Never)

The most common email we get reads, in some variant: "Will you ship a Mac version?" The answer is no. Not "no, not yet" — no, with an asterisk for "we might in some hypothetical future where Apple's platform model meaningfully shifts, and that shift is not on Apple's roadmap as far as anyone outside Cupertino can read it."

This is the longer version of the FAQ answer. It exists because the right context for "why no Mac" is not a one-line FAQ blurb — it's a structural read of how Apple has built macOS over the last decade and what that means for any product class whose value lives in OS-level stealth. Mac users who land here looking for a tool deserve the explanation, even if it ends with "buy a Windows laptop."

Key takeaways

• macOS has spent ten years systematically closing the layers an interview-stealth tool needs. System Integrity Protection (2015), kernel extension deprecation (2019), DriverKit replacement (2019), System Extensions moved to user-space (2019-2020), ScreenCaptureKit with mandatory consent indicators (2022). Each of these was a deliberate platform choice; each one is exactly the surface area a stealth-grade tool would need.
• Windows kept the same ground open — kernel-mode drivers are still a supported, signable construct; the WDDM display pipeline can be entered below DWM by a kernel component; process and window enumeration can be filtered at the kernel layer. We did not pick Windows because Mac is hard. We picked Windows because Mac's platform model doesn't permit our class of product.
• The competitors that "ship Mac" in 2026 — Interview Coder, Cluely, the rest — ship the user-mode-stealth equivalent: a CGWindowID excluded from CGWindowListCopyWindowInfo, plus some kCGWindowListOptionExcludeDesktopElements shimming. Apple's screen-capture stack queries those lists differently in different APIs, and stealth that works against CGDisplayStream may not work against ScreenCaptureKit. The Mac ecosystem has structural ceilings these tools are running into now.

What "stealth-grade" actually requires from an OS

Before getting into Apple's platform decisions, it helps to name what an interview-stealth tool needs from the operating system. We covered this in detail in the four stealth layers post; the condensed version is four asks:

1. A way to render a surface to the user that isn't in the screen-capture path. Either: opt out of compositing at the layer the capture API reads from, or render through a path that's never composited into the captured frame.
2. A way to keep the process out of process enumeration. When proctoring scans the running process list — via EnumProcesses, WMI, Get-Process, whatever — the tool's PID does not appear.
3. A way to keep the window out of window enumeration. When proctoring asks the OS for the list of visible top-level windows, the tool's window does not appear.
4. A way to answer fingerprint queries with a story that holds together across transports. Same answer regardless of whether the proctor asks via API A or API B.

Each of these asks has a clean answer on Windows (kernel-resident driver does each) and a structurally constrained answer on macOS. The constraint is not "Apple makes it hard." It's "Apple has removed the layer that would do it."

What macOS used to allow

Pre-2015 macOS shipped a kernel-extension model that looked architecturally similar to Windows kernel drivers. The relevant header was <IOKit/IOService.h>; you wrote a kext, signed it with an Apple-issued kernel signing entitlement, and loaded it via kextload. The kext could mediate I/O, hook system calls (with care), inspect process memory, install hooks in the WindowServer.

The 2015 release of macOS El Capitan introduced System Integrity Protection — Apple's term for what other OSes have called HVCI or kernel write protection. SIP locks down /System, prevents code injection into Apple-signed binaries, and most importantly, restricts what a kernel extension can do once loaded. It also requires a reboot into Recovery to disable, with active warnings.

Up to that point, kernel-resident hooks of arbitrary precision were possible. After SIP, the easy hooks closed. Apple framed this as a security improvement; in practice it was the first move in a longer arc.

The kext deprecation arc (2019-2024)

In 2019, at WWDC, Apple announced the deprecation of kernel extensions in favor of user-space alternatives. The replacement: DriverKit, a user-space framework for I/O drivers, and System Extensions, a user-space mechanism for the kinds of work network filters and endpoint security agents previously did in kernel.

The migration was phased. macOS Catalina (10.15, 2019) introduced DriverKit. Big Sur (11.0, 2020) sharpened the requirement. Monterey (12.0, 2021) tightened it further. By the Apple Silicon transition, kernel extensions on Apple Silicon Macs require entering Reduced Security mode in Recovery — a deliberate per-machine consent step, with persistent UI indicators that the system is in a non-default trust posture.

Apple's public guidance is unambiguous: "Use DriverKit instead of writing kernel extensions." For new development, a kernel extension is not a supported deployment target.

What does DriverKit not let you do?

• Hook arbitrary system calls the way a kext could.
• Read or modify another process's memory outside the narrow task_for_pid permissions, which themselves require the entitlement com.apple.security.cs.debugger and an SIP-friendly hardening profile.
• Filter process or window enumeration results. Those tables are owned by WindowServer and kernel_task respectively; user-space frameworks read from them but don't mutate the read view returned to other processes.
• Sit below the WindowServer compositor the way a Windows kernel-resident component can sit below DWM.

For a Windows-equivalent class of product, DriverKit is not a substitute for kext access. It's a different shape of API for a different shape of work — exactly what Apple intended.

ScreenCaptureKit and the consent indicator

The other side of the screen-capture pipeline tightened in parallel. macOS Monterey (2021) shipped the ScreenCaptureKit framework as the modern replacement for CGDisplayStream. ScreenCaptureKit is a stricter API: it requires explicit user consent through a system dialog, surfaces a persistent menu-bar indicator while capture is active, and enumerates content through SCShareableContent rather than the old CGWindowList* calls.

For any tool that wants to be invisible to ScreenCaptureKit, the architectural problem is that SCShareableContent queries are ultimately resolved by WindowServer — a privileged Apple system service that no third-party code, kernel or otherwise, gets to mediate. There is no documented exclusion analogous to WDA_EXCLUDEFROMCAPTURE, and the architectural opt-out (rendering outside WindowServer) requires sitting in the same trust position as Apple's own system processes, which third parties don't get.

A user-mode tool can set kCGWindowListOptionExcludeDesktopElements on its own window-creation flags so the window doesn't appear in some legacy enumeration calls. That handles CGWindowListCopyWindowInfo. It does not handle SCShareableContent, and it does not handle anything the proctor adds via Quartz Display Services queries on macOS 14+. The cat-and-mouse on macOS is fragmented across multiple capture APIs, each of which got tightened on a different release schedule.

Why our competitors' Mac versions are the upper bound

Look at the public stealth claims any AI interview tool makes for macOS. Every one we've seen amounts to: the window is excluded from some subset of window-list APIs, the process uses a benign name, the hotkey is registered through an Accessibility API event tap. That's the upper bound for an Apple-signed, notarized, App-Store-friendly (or DMG-distributed-with-Gatekeeper) Mac binary in 2026.

That upper bound is enough to stay invisible to:

• A naïve participant sharing their screen via QuickTime
• A Zoom screen-share that reads the legacy CGDisplayStream
• An interviewer who's not actively hunting

It is not enough to stay invisible to:

• A proctoring stack that asks SCShareableContent for the list of shareable windows
• A proctoring stack that asks Quartz directly for any window above a certain layer
• A modern endpoint-security product running EndpointSecurity framework hooks
• A custom proctoring helper distributed as a notarized macOS app (which CoderPad Enterprise and similar can ship)

This is why public reports of Interview Coder being detected describe Apple-platform interviews going badly when the proctor is more than a screen-share — and why the competitor reviews on TeamBlind cluster around CoderPad and Karat-administered rounds. The stealth ceiling on macOS is structurally lower, and serious proctoring stacks have moved above that ceiling.

Why Windows kept the door open

The structural counterpoint: Windows still permits the architecture our product depends on. Kernel-mode drivers are a documented, supported, signable construct (we covered the signing pipeline in the kernel driver attestation post). The display pipeline allows kernel-resident components to interact with WDDM below DWM. Process and window enumeration tables are mediable by a kernel component running on the same machine. Microsoft has tightened the signing requirements over time but has not removed the architectural surface a kernel-resident product needs.

Microsoft's own stance on this is mostly inferable from action: they continue to ship the WDK, continue to support and document driver development, and continue to update the WHCP attestation pipeline rather than deprecating it. Anti-cheat products like BattlEye, EasyAntiCheat, Vanguard, and the broader endpoint-protection industry depend on this surface area. So do legitimate niche products — accessibility tools, hardware drivers, virtualization extensions. Closing the kernel surface on Windows would break a much larger swath of the ecosystem than closing it on macOS did.

That's not a moral judgment, it's a platform-design choice. Apple optimized for security and consistency at the cost of some classes of third-party product. Microsoft kept the kernel surface accessible at the cost of some classes of platform attack. We sit on Windows because Windows lets us; we don't sit on macOS because macOS structurally doesn't.

What "might never" actually means

The "might never" in the title is doing real work. The conditions under which we'd ship a macOS version:

• Apple reverses the kext deprecation. (They have not signaled this; they have done the opposite, twice — Big Sur and the Apple Silicon Reduced Security gate.)
• Apple ships a new privileged-extension class that gives third parties the architectural surface our four stealth layers need. (DriverKit is not that surface; System Extensions are not that surface; the Endpoint Security framework is for detecting, not being invisible.)
• A change in our product strategy that accepts a structurally lower stealth tier on Mac and ships a Plus-equivalent product without the Pro driver. (We've considered this. The math doesn't work — Mac users searching for an AI interview tool overwhelmingly land on us through "stealth" / "undetectable" terms. Shipping a strictly weaker Mac product would dilute the brand the rest of the surface depends on.)

None of those conditions is on the visible horizon. The honest answer to "when does the Mac version ship" is "we are not building it; the platform doesn't permit the product class."

What to do if you have a Mac and an upcoming round

• If your interview is via screen-share only (Zoom, Meet, Chime) and the proctor isn't running a deeper stack: Interview Coder, Cluely, and similar are at their upper bound here. They might work. They might also get caught. The risk is not zero.
• If your interview is on CoderPad Enterprise, HackerRank with Skills Verification, CodeSignal certified, or any platform with an active proctor companion: the tool tier you'd need doesn't exist on Mac. Borrow or buy a Windows machine for the round.
• If you're a Mac user evaluating tools generally: the "tools that get you caught versus tools that don't" audit has the per-tool breakdown. The pattern is consistent — Mac-flavored tools fare worse against modern proctoring stacks than Windows-flavored tools, for the structural reasons above.

For the four-layer Windows architecture our product is built around, see the kernel driver tour. For the signing pipeline that makes kernel-resident distribution possible on Windows in 2026, see the kernel driver attestation post.

FAQ

Could you ship a Mac version that's user-mode-only? We've considered it. The product would be approximately at parity with Interview Coder and Cluely on Mac — a user-mode hotkey overlay with CGWindowList exclusion. We could not honestly market it as "hasn't been caught on CoderPad Enterprise," because it would be caught on CoderPad Enterprise. Shipping a strictly weaker Mac product would erode the trust on the Windows side. The decision was no.

What about iPad? Surely an iPad-side tool could help on a Mac round. An iPad next to your Mac is a second device. Proctoring stacks that look for second devices — Honorlock, Proctorio, parts of CodeSignal certified — have been tightening this surface for two years. Some platforms outright require the candidate to pan the webcam around the room before the round starts. A second device is no longer a free pass.

Does this mean macOS is "more secure"? For most users, yes — the same constraints that block our class of product also block real macOS-targeted malware that would have used the same APIs. Apple is making a deliberate trade-off. We're a casualty of that trade-off in our category, and the trade-off is defensible at the platform level.

Can I dual-boot Windows on a Mac? On Intel Macs (becoming rare), yes via Boot Camp, but recent Windows Patch Tuesday updates have not all played nicely with Boot Camp drivers. On Apple Silicon Macs, no — Apple Silicon doesn't support native Windows boot. Parallels and similar virtualization run Windows in a VM, where our kernel-resident architecture doesn't sit at the same depth. A second physical Windows machine is the practical answer.

What about Linux? Same structural answer as macOS, different mechanics. Linux desktops fragment the display server (X11 vs Wayland) and the screen-capture story is different on each. Most coding-interview platforms aren't optimized for Linux candidates anyway. We have no Linux roadmap.

If you're a Windows user, FaangCoder is built for the round you're prepping for. $399 lifetime, $199 monthly. If you're a Mac user, this post is the honest answer.