FB12702048
Thanks for that.
Does that mean that it's an undocumented function that I shouldn't be
using?
No. My general guidelines for this sort of thing is that, barring any other info to the contrary [1], you’re allowed to use stuff that’s in the SDK headers.
Situations like this are one of the reasons I no longer use the phrase “undocumented API”.
Serious question. Recall libcache on iOS and see FB5480758
.
That leads to a bug (r. 8513040) which leads to an iteration 1 DevForums URL:
https://devforums.apple.com/message/307500#307500
Sadly, that’s as far as I can follow the issue [2]. I think I know the thread you’re talking about, but I only have my half of the conversation so I’m not 100% sure.
Regardless, I don’t see any obstacle to using libcache in an iOS app:
-
The header, <cache.h>
, is in the iOS SDK.
-
The routines are all decorated with availability macros that indicate it’s available starting with iOS 4.0.
-
It’s even documentated, albeit in man pages.
Every now and again I see folks get a bee in their bonnet about man pages, claiming that APIs that are only documented in man pages are macOS only. This is nonsense. By that reasoning, iOS apps wouldn’t be allowed to call printf
! [3]
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] The most egregious example of something that was in the SDK but wasn’t OK to use was the MAC framework. See QA1574 Kernel’s MAC framework. We’ve fixed that, finally!, but it did cause me to write QA1575 Supported KPIs.
[2] See here.
[3] Weirdly, printf
is documented in the main docs, but only the Kernel framework version of it. That claims the function is only available on macOS, which is, again, nonsense. I coulda sworn I’d filed a bug about that, but I can’t seem to find the number )-: