Current State Mac (June/2020)

[reiichi]

The trick is that the macOS version would probably need to draw more from the PS4 version than the Windows one in other areas; PS4's "Orbis" operating system is derived from FreeBSD, and macOS's userspace derives from FreeBSD as well. But Orbis has diverged in a number of places and has custom functionality that wouldn't exist on macOS or Linux/BSD systems. Add to that the fact that while older versions had to have been processor-agnostic (i.e., back when PS3 was supported), there's no guarantee they aren't using assembly blocks in the code to speed up processing of certain tasks; the PS4 is an x86-64 architecture a'la Windows PCs (and current Mac hardware), and if they have blocks like that in there, that'd be an obstacle to porting to ARM-based systems.
/

Gonna focus only on this part because I'm in general agreement with everything else.

While Darwin does hail from BSD roots, the overlap with actual BSD when it comes to anything graphical is basically nonexistent as Apple's frameworks are nothing like what you'd get out of something more generic. It's fine for dev/cli stuff, but that's about where compatibility ends. But even on that note, the kernels are completely different and even projects like porting a BSD driver over to macOS is a monumental task, like the projects for intel wifi cards.

I'd imagine they can probably compile for general platforms, but that there's nothing currently done to target Vulkan, let alone Metal in their Luminous-ish Crystal Tools+ fork. So at a minimum, we're likely to still see DirectX calls being converted over, but that's honestly not super horrible overhead when you consider some games on DXVK are performing better on Linux than natively on Windows.

So there's maybe a chance we'll see a future version of the Mac port maybe being a weird amalgamation of Windows client bases compiled with WineLib. ...but most likely, we'll see WINE/Crossover getting custom x86 to ARM support if Rosetta 2 doesn't perform well enough or when it's eventually dropped in like 2 years. It wouldn't be the first time as the ancient DarWINE project had x86 to PPC for pre-Intel Macs with varying success.

[Packetdancer]

While Darwin does hail from BSD roots, the overlap with actual BSD when it comes to anything graphical is basically nonexistent as Apple's frameworks are nothing like what you'd get out of something more generic. It's fine for dev/cli stuff, but that's about where compatibility ends. But even on that note, the kernels are completely different and even projects like porting a BSD driver over to macOS is a monumental task, like the projects for intel wifi cards.

Sure, which is why I focused on Vulkan for the graphical stuff; you can map Vulkan to Metal (Apple's graphical API) via MoltenVK. (And the kernel is, as you rightly point out, completely separate; Darwin uses Mach as the basis of its kernel, and just takes the userspace and general library APIs from FreeBSD.) Where I meant the BSD similarities were for things like general system APIs; saving off configuration files, dealing with timers, networking APIs, etc. The Windows client likely uses Win32 APIs for that, but the PS4 Orbis system uses standard FreeBSD APIs for that and so the PS4 version likely uses those APIs, and those are available on macOS.

I.e., a translation/port would want to take the DirectX graphics layer (since you can do DirectX -> DXVK -> Vulkan -> MoltenVK -> Metal, and there's no similar GSMX -> Metal translation path that I'm aware of) or write a native Vulkan one (longer-term) to pick up Linux and then use MoltenVK directly, but probably would have less work if it took the PS4 filesystem/networking layers. Because while the kernel drivers for WiFi would be very different between FreeBSD and macOS, the actual networking calls in a userspace application are the same.

So I think we're actually on the same page there.