Are all headers in /usr/include considered to be Public API on the MAS?
Are all headers in /usr/include guaranteed to be considered part of the Public APIs when it comes to Mac App Store submissions?
Consider for example the file /usr/include/copyfile.h
The comments in this file say this: "This implementation is incomplete and the interface may change in a future release." Does this render 开发者_运维知识库the header non-public? How do I determine if a header is considered public?
It's public if it's documented. You've got LOTS of .h files on your system that refer to private APIs. That's not how you know whether it's store-safe. It's store-safe it it's documented in the framework documentation.
Read the bottom section of this documentation page.
Excerpt:
Mac OS X includes many dynamic libraries in the /usr/lib directory and its subdirectories. Dynamic shared libraries are identified by their .dylib extension. Header files for the libraries are located in /usr/include.
It seems like the implication here is that the .dylib
libraries included with OS X are fair game for use in your application, but you need to be aware that they don't guarantee to have a particular version of the lib on e.g. Lion, so you should include the most generic version you can.
As @Dan said, the other thing which would tip you off to a library being OK to use would be if it has a manpage. copyfile has a man page, so it's fine to use (since they're showing you how to use it!). To make things even fuzzier, check out the getattrlist man page, and search for 'copyfile'. One of the flags you can read for volume capabilities indicates support for a second copyfile() API. So in this case there are 2 copyfile() APIs and you're only allowed to use the one with a manpage, as the other one is marked here as being private and undocumented.
Any headers not contained in a Framework folder and not matched with a .dylib
or a manpage, I would generally avoid using.
精彩评论