> I guess I need to go back to doing things the hard way.
The moral of this story is clear but third-party developers for Apple devices don't want to face it. With a few exceptions, most Apple frameworks and application software are proprietary. If Apple's internal source code is deemed to be central to their business, outside developers will probably never get to see it. And if they can't see it, they can't fix and improve it.
If you write application software for Apple devices, you have made a Faustian bargain. You are at the mercy of the whims of Apple Software Engineering; Apple has you by the proverbial balls. If your own code is also proprietary then your customers are in the same vulnerable position, so stop complaining.
same here - you hear a split second of the loudest, worst screeching imaginable. I actually thought that was a problem with my headphones, not with MacOS, until reading this.
If this happens to you as a user of any app, the temporal workaround you can do is, go to system preferences, Audio and change the mic input to be the system one, and the sound comes back to full quality.
oh man i had a bug where my bluetooth earbuds would only play audio from one earbud unless i did this same exact fix... yikes... boy did it take a while to accidentally come across this solution. the manufacturer was equally flummoxed.
The "Bluetooth device can't do high quality" sounds like pulseaudio today to be honest. One of the reasons I'm waiting for pipewire to become more common.
Also, after reading this article I suddenly understand why my MBP sometimes goes into low-quality, mono mode during conference calls.
For a taste of it, episode 412 (and 411) of the Accidental Tech Podcast gets into the pain of the process around the 15 minute mark (and 1:30 minute mark for 411).
I’ll counter the other reply and say No with an anecdote.
When another dev and I had a blocking issue with their external accessories IAP framework, they invited us to fly to Cupertino to speak in person. Which we did. And they were extremely helpful.
Whenever I read articles like this, it reminds me that cross-platform development can serve as a hedge, and not as a feature, it you want to look at it that way.
I publish an app that works on Windows, Mac, and Linux, but if I ever ran into a situation like this repeatedly, I’d just kill the feature on that platform and save my engineering hours for something more important.
I’m interested in what Apple is going to do for me, I’m not interested in enriching their platform.
Potential customers with an iPhone are captive to that platform due to extensive lock-in, including financial investments guarded by Apple DRM. The amount of budget that is thereby worth allocating to literally double your potential market can be extremely high. Hell: often you go into business to solve a problem that you, yourself, had... and you might yourself be bought into the "wrong" platform (which is itself very specific... like, this article is fascinating as generally it is Android that has audio APIs so bad that even people willing to move mountains simply can't make their software work correctly... this is the first I have heard of an audio developer hating hard on Apple's API).
14 comments
[ 14.5 ms ] story [ 562 ms ] threadThe moral of this story is clear but third-party developers for Apple devices don't want to face it. With a few exceptions, most Apple frameworks and application software are proprietary. If Apple's internal source code is deemed to be central to their business, outside developers will probably never get to see it. And if they can't see it, they can't fix and improve it.
If you write application software for Apple devices, you have made a Faustian bargain. You are at the mercy of the whims of Apple Software Engineering; Apple has you by the proverbial balls. If your own code is also proprietary then your customers are in the same vulnerable position, so stop complaining.
When I wished for MacOS to become more Linux-like, I regret not specifying how or when.
Also, after reading this article I suddenly understand why my MBP sometimes goes into low-quality, mono mode during conference calls.
Is that just known to be so pointless that it's not worth mention?
For a taste of it, episode 412 (and 411) of the Accidental Tech Podcast gets into the pain of the process around the 15 minute mark (and 1:30 minute mark for 411).
[0] https://atp.fm/412
[1] https://atp.fm/411
When another dev and I had a blocking issue with their external accessories IAP framework, they invited us to fly to Cupertino to speak in person. Which we did. And they were extremely helpful.
I publish an app that works on Windows, Mac, and Linux, but if I ever ran into a situation like this repeatedly, I’d just kill the feature on that platform and save my engineering hours for something more important.
I’m interested in what Apple is going to do for me, I’m not interested in enriching their platform.