The QuickTime API in C is horrific. It requires tons of unsafe-looking casts and even memcpy()-like operations between types. QuickTime Kit (an Objective C API) was released with QuickTime 7, which can only be better.

Here are excerpts from some code I wrote back in the day to import audio files into Audacity using QuickTime:

   // GetMediaSampleDescription takes a SampleDescriptionHandle, but apparently
   // if the media is a sound (which presumably we know it is) then it will treat
   // it as a SoundDescriptionHandle (which in addition to the format of single
   // samples, also tells you sample rate, number of channels, etc.)
   // Pretty messed up interface, if you ask me.
   SoundDescriptionHandle soundDescription = (SoundDescriptionHandle)NewHandle(0);
   GetMediaSampleDescription(mMedia, 1, (SampleDescriptionHandle)soundDescription);

   // If this is a compressed format, it may have out-of-stream compression
   // parameters that need to be passed to the sound converter.  We retrieve
   // these in the form of an audio atom.  To do this, however we have to
   // get the data by way of a handle, then copy it manually from the handle to
   // the atom.  These interfaces get worse all the time!
   Handle decompressionParamsHandle = NewHandle(0);
   AudioFormatAtomPtr decompressionParamsAtom = NULL;
   err = GetSoundDescriptionExtension(soundDescription, &decompressionParamsHandle,
                                      siDecompressionParams);
   if(err == noErr)
   {
      // this stream has decompression parameters.  copy from the handle to the atom.
      int paramsSize = GetHandleSize(decompressionParamsHandle);
      HLock(decompressionParamsHandle);
      decompressionParamsAtom = (AudioFormatAtomPtr)NewPtr(paramsSize);
      BlockMoveData(*decompressionParamsHandle, decompressionParamsAtom, paramsSize);
      HUnlock(decompressionParamsHandle);
   }

This is just dishonest. QTKit was released 5 years ago and works just fine. If you want to cherry pick code from 6 years ago that was originally targeted at an architecture from 15 years ago you can do a lot worse than QT API.

Your characterization of my comment is unfair and untrue. I didn't "cherry pick" anything; the above code is from my only significant experience with any Apple-designed API. The grandparent comment in glowing and general terms praised Apple APIs as noticeably better than other APIs, and this ran strongly contrary to my own experience with them. I even mentioned that this was old code, that QTKit has been released in the meantime, and that it is probably better.

I'm not sure why you think that old APIs designed for old architectures are obviously bad or are not relevant to the discussion. How is C substantially different than in 1994, that newer APIs would be better? Why do you think that architectures from 15 years ago required bad APIs? I can think of many excellent APIs that I was using ten years ago or more.

Feel free to say that the new Apple APIs are much better than the old ones, but my experience says that historically Apple has had some very poor ones.

The Quicktime C APIs have been written nearly 20 years ago for a different OS. The primary goals back then have been performance and economy, not abstraction and clarity.

The UNIX APIs were written nearly 40 years ago, and somehow managed to achieve performance and economy without giving up abstraction and clarity.

"but Infinite Loop's API's have a noticeably higher degree of engineering than any other API / toolchain I've used."

Any specific examples?

The documentation is generally excellent.

At the very least, this demonstrates both respect and sympathy for other engineers who need to use an API. Often, it also correlates to a well engineered product underneath.

"At the very least, this demonstrates both respect and sympathy for other engineers who need to use an API. "

Sympathy? As when an API is sort of hacky or kludgey or ad hoc?

"Often, it also correlates to a well engineered product underneath."

When I did Windows development I marveled at the amount and quality of detailed docs available for the platform. In some cases the underlying each was well-engineered, But there's no real correlation. The docs existed because a company really wanted people to develop for their platform.

Docs (or lack of) say more about business than engineering.