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_AVAILABLE or similar).