Challenge 3: Why No Windows Version Is Architectural, Not a Backlog
Item -- Solution Walkthrough

The chapter frames this as an architectural decision because Screen
Studio isn't simply missing a Windows build the team hasn't gotten
around to yet -- it's built directly on technology that only exists
on macOS: Metal for graphics rendering, AVFoundation for capture, and
Apple's own Cocoa application framework. None of these have a direct
equivalent the app could simply be recompiled against on Windows; the
app's core recording and rendering logic is written in terms of
Mac-specific frameworks from the ground up.

Bringing Screen Studio to Windows would therefore mean rewriting that
core logic against entirely different underlying technology (Windows'
own graphics and capture APIs), not porting existing code with minor
adjustments the way a typical cross-platform app update might work.
The team has explicitly chosen not to take on that rewrite, favoring
continued investment in polishing the Mac app instead -- a real,
stated tradeoff, not an oversight or a lower-priority item still on a
roadmap. This is exactly why the chapter treats it as a durable
boundary rather than a "not yet" gap likely to close with a future
release, and why Chapter 5's Cap exists specifically to give
Windows/Linux readers a genuine equivalent rather than asking them to
simply wait.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader understands the distinction
between "not built yet" and "built on technology that structurally
excludes the platform" -- correctly identifying that a full rewrite
against different underlying frameworks, not a simple port, is what
a Windows version would actually require, and why the team's own
explicit choice not to pursue that makes this a stable rather than
temporary limitation.