An appeal to Apple from Anukari • Hacker News Board

Re: An appeal to Apple from Anukari

#31

Post by eigenspace » Tue, May 06, 2025, 1:39 PM UTC

thraway3837 wrote: post #30

This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is. Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but stil…

It's honestly nuts that so many developers continue to try to make software on MacOS. I understand the appeal of their current hardware, and I used to even be a big fan of the user experience, but it really seems like attempting to build software in MacOS is like trying to build a house on a sandbar.

Apple has done nothing and continues to do nothing to engender any confidence in their platform as a development target.

Re: An appeal to Apple from Anukari

#32

Post by bambax » Tue, May 06, 2025, 1:40 PM UTC

bambax wrote: post #9

krackers wrote: post #6

>The Metal profiler has an incredibly useful feature: it allows you to choose the Metal “Performance State” while profiling the application. This is not configurable outside of the profiler. Seems like there might be a private API for this. Maybe it's easier to go the reverse engineering route? Unless it'll end up requiring some special entitlement that you can't bypass without disabling SIP.

There has to be a private API for this; the post says: > The Metal profiler has an incredibly useful feature: it allows you to choose the Metal “Performance State” while profiling the application. This is not configurable outside of the profiler. How would the Metal profiler be able to do that if not for a private API? (Could some debugging tool find out what's going on by watching the profiler?)

Lol I just read the parent comment without noticing that they were quoting the exact same sentence from the blog! ;-)

Sorry about that!

Re: An appeal to Apple from Anukari

#33

Post by gjsman-1000 » Tue, May 06, 2025, 1:50 PM UTC

eigenspace wrote: post #31

thraway3837 wrote: post #30

This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is. Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but stil…

It's honestly nuts that so many developers continue to try to make software on MacOS. I understand the appeal of their current hardware, and I used to even be a big fan of the user experience, but it really seems like attempting to build software in MacOS is like trying to build a house on a sandbar. Apple has done nothing and continues to do nothing to engender any confidence in their platform as a development targe…

The problem is that this could be easily applied to many things. To paraphrase:

It’s honestly nuts that so many developers continue to try to make software using a bloated JavaScript framework and thousands of Node dependencies.

That might also be true but that misses the point - programming is not engineering; nothing is done to an engineer’s preferred standard; and probably never will.

It’s like being a CNC Technician and complaining about how 90% of stuff on store shelves is plastic. A metal gallon of milk would be so much more durable! Less milk would be spilled from puncturing! Production costs, and how they go downstream, are being ignored.

(Edit for the downvotes, dispute me if you care enough, but literally nobody other than computer programmers ogles your clean code. Just like how nobody other than CNC mechanics are going to ogle the milk carton made on a lathe.)

Re: An appeal to Apple from Anukari

#34

Post by vlovich123 » Tue, May 06, 2025, 1:57 PM UTC

humbledrone wrote: post #2

Some folks may have seen my Show HN post for Anukari here: https://news.ycombinator.com/item?id=43873074 In that thread, the topic of macOS performance came up there. Basically Anukari works great for most people on Apple silicon, including base-model M1 hardware. I've done all my testing on a base M1 and it works wonderfully. The hardware is incredible. But to make it work, I had to implement an unholy abomination o…

Interesting post & problem. I wonder if the reason that the idea of running the tasks on the same queue fails is for the same reason you have a problem in the first place - variable clock rate means it’s impossible to schedule precisely and you end up aliasing your spin stop time ideal time based on how the OS decided to clock the GPU. But that suggests that maybe your spin job isn’t complex enough to run the GPU at the highest clock because if it is running at max then you should be able to reliably time the stop of the spin even without adding a software PLL (which may not be a bad idea). I didn’t see a detailed explanation of how the spin is implemented and I suspect a more thorough spin loop that consistently drives more of the GPU might be more effective at keeping the clock rate at max perf.

Re: An appeal to Apple from Anukari

#35

Post by philistine » Tue, May 06, 2025, 2:00 PM UTC

eigenspace wrote: post #31

thraway3837 wrote: post #30

This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is. Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but stil…

It's honestly nuts that so many developers continue to try to make software on MacOS. I understand the appeal of their current hardware, and I used to even be a big fan of the user experience, but it really seems like attempting to build software in MacOS is like trying to build a house on a sandbar. Apple has done nothing and continues to do nothing to engender any confidence in their platform as a development targe…

> Apple has done nothing and continues to do nothing to engender any confidence in their platform as a development target.

You're missing the forest for the trees. Apple is very difficult to work with indeed, but they have a shit-ton of paying users. Still to this day, iOS is a better revenue maker than Android. Same for macOS compared to Windows. You want to make a living? Release on macOS. People there pay for software.

Re: An appeal to Apple from Anukari

#36

Post by [deleted] » Tue, May 06, 2025, 2:04 PM UTC

philistine wrote: post #35

eigenspace wrote: post #31

Earlier quoted context omitted.

It's honestly nuts that so many developers continue to try to make software on MacOS. I understand the appeal of their current hardware, and I used to even be a big fan of the user experience, but it really seems like attempting to build software in MacOS is like trying to build a house on a sandbar. Apple has done nothing and continues to do nothing to engender any confidence in their platform as a development targe…

> Apple has done nothing and continues to do nothing to engender any confidence in their platform as a development target. You're missing the forest for the trees. Apple is very difficult to work with indeed, but they have a shit-ton of paying users. Still to this day, iOS is a better revenue maker than Android. Same for macOS compared to Windows. You want to make a living? Release on macOS. People there pay for soft…

[deleted]

Re: An appeal to Apple from Anukari

#37

Post by duped » Tue, May 06, 2025, 2:09 PM UTC

thraway3837 wrote: post #30

This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is. Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but stil…

I don't disagree with you, but there simply isn't an alternative for pro audio developers. You go where the users are and the majority of the market (by revenue) are Mac users.

Now a lot of people may reply to this that Windows isn't that bad with ASIO (third party driver framework) or modern APIs like WASAPI (which is still lacking), or how pipewire is changing things on Linux so you don't need jack anymore (but god forbid, you want to write pipewire native software in a language besides C, since the only documented API are macros). Despite these changes you have to go where the revenue is, which is on MacOS.

Re: An appeal to Apple from Anukari

#38

Post by Someone » Tue, May 06, 2025, 2:22 PM UTC

kllrnohj wrote: post #28

Someone wrote: post #12

One thing I don’t understand: if latency is important for this use case, why isn’t the CPU busy preparing the next GPU ‘job’ while a GPU ‘job’ is running? Is that a limitation of the audio plug-in APIs?

That's pipelining and it's good for throughput but it sacrifices latency. Audio is not a continuous bit stream but a series of small packets. To begin working on the next one on the CPU while the previous one is on the GPU requires 2 samples in flight which necessarily means higher latency

I don’t see that. If the CPU part starts processing packet #2 while the GPU processes packet #1, not after it has done so, it will have the data that has to be sent to the GPU for packet #2 ready earlier, so it can send it earlier, potentially the moment the GPU has finished processing packet #1 (if the GPU is powerful enough, possibly even before that)

That’s why I asked about the plug-in APIs. They may have to be async, with functions not returning when they’re fully done processing a ‘packet’ but as soon as they can accept more data, which may be earlier.

Re: An appeal to Apple from Anukari

#39

Post by pjmlp » Tue, May 06, 2025, 2:23 PM UTC

eigenspace wrote: post #31

thraway3837 wrote: post #30

This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is. Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but stil…

It's honestly nuts that so many developers continue to try to make software on MacOS. I understand the appeal of their current hardware, and I used to even be a big fan of the user experience, but it really seems like attempting to build software in MacOS is like trying to build a house on a sandbar. Apple has done nothing and continues to do nothing to engender any confidence in their platform as a development targe…

It is still better engineered that dealing with the distribution of the day, reinventing the way to do sound, graphics stack, UI, ......

Once upon a time I thought either GNOME or KDE would win, and we could all enjoy the one Linux distribution, I was proven wrong.

Then again, I have been back on Windows as main OS since Windows 7.

Re: An appeal to Apple from Anukari

#40

Post by pjmlp » Tue, May 06, 2025, 2:24 PM UTC

thraway3837 wrote: post #30

This is all just too much Stockholm syndrome. Apple’s DX (developer experience) has always been utterly abysmal, and these continued blog posts just goes to show just how bad it is. Proprietary technologies, poor or no documentation, silent deprecations and removals of APIs, slow trickle feed of yearly WWDC releases that enable just a bit more functionality, introducing newer more entrenched ways to do stuff but stil…

On the old Mac OS, and early OS X day, the documentation was great, I dunno what happened to the documentation team.

Swift on the server is for Apple ecosystem developers, to share code, just like all those reasons to apparently use JavaScript on the server instead of something saner.