Apple notification group
Github Labels: O-macos, O-ios, O-tvos, O-watchos and O-visionos
Ping command: @rustbot ping apple
This list will be used to ask for help both in diagnosing and testing Apple-related issues as well as suggestions on how to resolve interesting questions regarding our macOS/iOS/tvOS/watchOS/visionOS support.
To get a better idea for what the group will do, here are some examples of the kinds of questions where we would have reached out to the group for advice in determining the best course of action:
- Raising the minimum supported versions (e.g. #104385)
- Additional Apple targets (e.g. #121419)
- Obscure Xcode linker details (e.g. #121430)
Deployment targets
Apple platforms have a concept of "deployment target", controlled with the
*_DEPLOYMENT_TARGET environment variables, and specifies the minimum OS
version that a binary runs on.
Using an API from a newer OS version in the standard library than the default
that rustc uses will result in either a static or a dynamic linker error.
For this reason, try to suggest that people document on extern "C" APIs
which OS version they were introduced with, and if that's newer than the
current default used by rustc, suggest to use weak linking.
The App Store and private APIs
Apple are very protective about using undocumented APIs, so it's important that whenever a change uses a new function, that they are verified to actually be public API, as even just mentioning undocumented APIs in the binary (without calling it) can lead to rejections from the App Store.
For example, Darwin / the XNU kernel actually has futex syscalls, but we can't
use them in std because they are not public API.
In general, for an API to be considered public by Apple, it has to:
- Appear in a public header (i.e. one distributed with Xcode, and found for
the specific platform under
xcrun --show-sdk-path --sdk $SDK). - Have an availability attribute on it (like
__API_AVAILABLE,API_AVAILABLEor similar).