Add Apple notification group (rust-lang#1964)

Author: madsmtm

src/doc/rustc-dev-guide/src/SUMMARY.md

@@ -50,6 +50,7 @@
 - [Using external repositories](./external-repos.md)
 - [Fuzzing](./fuzzing.md)
 - [Notification groups](notification-groups/about.md)
+    - [Apple](notification-groups/apple.md)
     - [ARM](notification-groups/arm.md)
     - [Cleanup Crew](notification-groups/cleanup-crew.md)
     - [LLVM](notification-groups/llvm.md)

src/doc/rustc-dev-guide/src/notification-groups/about.md

@@ -19,6 +19,7 @@ search for existing issues that haven't been claimed yet.
 ## List of notification groups
 
 Here's the list of the notification groups:
+- [Apple](./apple.md)
 - [ARM](./arm.md)
 - [Cleanup Crew](./cleanup-crew.md)
 - [LLVM](./llvm.md)
@@ -57,6 +58,7 @@ cargo run add-person $your_user_name
 
 Example PRs:
 
+* [Example of adding yourself to the Apple group.](https://github.com/rust-lang/team/pull/1434)
 * [Example of adding yourself to the ARM group.](https://github.com/rust-lang/team/pull/358)
 * [Example of adding yourself to the Cleanup Crew.](https://github.com/rust-lang/team/pull/221)
 * [Example of adding yourself to the LLVM group.](https://github.com/rust-lang/team/pull/140)
@@ -70,6 +72,7 @@ To tag an issue as appropriate for a notification group, you give
 group. For example:
 
 ```text
+@rustbot ping apple
 @rustbot ping llvm
 @rustbot ping cleanup-crew
 @rustbot ping windows

src/doc/rustc-dev-guide/src/notification-groups/apple.md

@@ -0,0 +1,53 @@
+# Apple notification group
+
+**Github Labels:** [O-macos], [O-ios], [O-tvos], [O-watchos] and [O-visionos] <br>
+**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])
+
+[O-macos]: https://github.com/rust-lang/rust/labels/O-macos
+[O-ios]: https://github.com/rust-lang/rust/labels/O-ios
+[O-tvos]: https://github.com/rust-lang/rust/labels/O-tvos
+[O-watchos]: https://github.com/rust-lang/rust/labels/O-watchos
+[O-visionos]: https://github.com/rust-lang/rust/labels/O-visionos
+[#104385]: https://github.com/rust-lang/rust/pull/104385
+[#121419]: https://github.com/rust-lang/rust/pull/121419
+[#121430]: https://github.com/rust-lang/rust/pull/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).