/usr/include 中的所有标头是否都被视为 MAS 上的公共 API？
当涉及到 Mac App Store 提交时，/usr/include 中的所有标头是否都保证被视为公共 API 的一部分？
例如，考虑文件 /usr/include/copyfile.h
该文件中的注释是这样说的：“此实现不完整，接口可能会在将来的版本中更改。”这是否会使标头变得非公开？如何确定标头是否被视为公开？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果有记录的话，它就是公开的。您的系统上有很多引用私有 API 的 .h 文件。这不是您知道它是否在商店安全的方法。它是存储安全的，它记录在框架文档中。
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.
阅读此内容的底部部分文档页面。
摘抄：
这里似乎暗示 OS X 中包含的
.dylib库非常适合在您的应用程序中使用，但您需要注意它们并不保证具有特定版本的例如 Lion 上的库，因此您应该包含最通用的版本。正如@Dan 所说，另一个让你知道库可以使用的事情是它是否有联机帮助页。 copyfile 有一个男人页面，所以使用起来很好（因为他们向您展示了如何使用它！）。为了让事情变得更加模糊，请查看 getattrlist 手册页，然后搜索“copyfile”。您可以读取的卷功能标志之一表示支持第二个 copyfile() API。因此，在本例中，有 2 个 copyfile() API，并且您只能使用带有联机帮助页的一个 API，因为另一个在此被标记为私有且未记录。
任何未包含在 Framework 文件夹中且与
.dylib或联机帮助页不匹配的标头，我通常会避免使用。Read the bottom section of this documentation page.
Excerpt:
It seems like the implication here is that the
.dyliblibraries 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
.dylibor a manpage, I would generally avoid using.