My problems start long before the special APIs come into play. When we supported Mac, I just wrapped the APIs like you do for any other system. The problem is I don't use Mac, so building software for Macs is inherently troublesome. I can build and test for Windows just fine from Linux and OpenBSD. I can't for Mac.

Now you might say this is problematic, Apple doesn't want third-party developers locking their platform behind some conditionally compiled set of abstractions that ruin everything they've worked for. Putting aside how ridiculous that is given system APIs are often wrapped for normal abstraction reasons anyways, that's totally fine. But then, it's also not my problem because I'm not Apple. I don't mind supporting their platform, I'll even turn a blind eye to the audacity of charging a developer fee while offering abysmal documentation and support. But I'm not going to crawl and beg for the privilege.

> Do you want them to use cross platform frameworks that are not optimized for their system?

Just like everybody else, because it hardly matters. Outside of Apple-land, Intel, AMD and Nvidia all get along just fine with rewriting SPIR-V to their microarchitectures. CPUs get along just fine rewriting abstract instruction sets like AMD64 and the various ARMs to their microarchitectures. Code is by-default compiled for instruction compatibility. APIs like CUDA and ROCm explicitly exist for vendor lock-in reasons. There's absolutely no reason why the throughput of these APIs can't be generically applied to compute shaders. None at all. The hardware vendors just want to capture the market.

Apple isn't exactly working with exotic hardware. The M1 is yet another ARM chip, not some crazy graph-reduction machine. These standards are fine and used across a wide-derth of hardware to no real detriment. I would suggest you may over-estimate how much they actually care about this idea of "specially optimized APIs." Consider that Apple pushes Swift as the primary language you Should be Using to ship software on OSX, and yet garbage collection is still handled in software. That's not what vertical integration for engineering purposes looks like.

Again, it all hardly matters. I wouldn't mind just wrapping these APIs, they're not particularly special or exotic any more than their hardware is. But the fact of the matter is that as a non-mac user, they go through a lot of effort to ensure putting software on their platform is as unattractive as possible.

The way I see it, they mainly just aren’t interested in devs treating macOS as just another lowest-common-denominator target, which makes some amount of sense. Such software is likely to not be as nice to use as something purpose-built for the OS, particularly when considering that the dev probably never even tested the software in question under macOS, greatly hampering their ability to find and eliminate bugs.

Why would I want to use software that you never tested on the target machine?

I explicitly conflated building with testing not even 4 sentences into my post.

Because it's not 1982 anymore?

I didn’t buy a Mac to use your lowest common denominator untested, unoptimized application that doesn’t take advantage of my hardware to its fullest.

You're using HN right now. The web is one of many types of write-once-run-anywhere software you are critically reliant on in your day-to-day life.

And I run Safari - a browser built by Apple to be battery efficient, memory efficient and better optimized than Chrome and uses native frameworks and UI.

My computer, the processor that runs in it, the operating system, much of the software and the rest of my computer life - phone, watch, set top device, tablet work together. I can copy text from one and paste it into the other. My watch unlocks my computer. My iPad can be used as a second monitor without any third party software.

I bet you HN tested it on iOS if not the Mac and not just hope the site looks fine