macOS syscalls are explicitly not stable and may change from release to release. The only supported interface to them on macOS is libc.

That file doesn't even exist on my system, but in any case public means official, not in some header.

If you have the command line tools installed, it should also be under /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/syscall.h. macOS, by default, does not ship with these headers at all, and as of macOS Mojave they no longer provide them under /usr/include unless you install a certain package.

With that being said, I disagree with your characterization of “some header”–anything that’s in Apple’s headers is public API, whether it has a fancy page on developer.apple.com or not. Apple has a very clear definition of what they consider to be “private”, and anything in /usr/include isn’t it.

Actually the path is:

  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/syscall.h 

and you can clearly see that the file is wrapped with:

  #ifdef __APPLE_API_PRIVATE
  ...
  #endif /* __APPLE_API_PRIVATE */

Again, if you have the Command Line Tools installed, it'll be under /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/. Xcode also has a copy, but I think fewer people have that installed.

Nope, on my system, without xcode, the previous poster's path is correct: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/syscall.h

They need to be public and stable in order to be a usable userspace API for anything other than libc. I don't think the latter requirement is satisfied:

https://github.com/golang/go/commit/02118ad0a0cacb00c1d834b3...

Nope, in fact it's so absolutely not stable (or supported) that libSystem can't be statically linked to.