If you open the transmission_4 derivation file, you can see a line:
"-DENABLE_MAC=OFF" # requires xcodebuild
so I guess that the package does not package the mac native interface as it is more complicated to be compatible with XCodeBuild, I guess because of licensing reasons. The documentation mentions:
Since Xcode can’t be packaged with Nix, nor we can publish it as a Nix package (because of its license) this is basically the only integration strategy making it possible to do iOS application builds that integrate with other components of the Nix ecosystem
Yet, the documentation mentions here that it is possible to build applications for IOs, involving xcode, and this part of the documentation mentions:
The package xcbuild
can be used to build projects that really depend on Xcode. However, this
replacement is not 100% compatible with Xcode and can occasionally cause issues.
The doc also mentions here:
xcbuildHook: Overrides the build and install phases to run the “xcbuild” command. This hook is needed when a project only comes with build files for the XCode build system. You can disable this behavior by setting buildPhase and configurePhase to a custom value. xcbuildFlags controls flags passed only to xcbuild.
While browsing the source with rg xcode
, I also found many references to:
-
xcodebuild
which seems to be more or less equal to xcbuild
, see for instance pkgs/os-specific/darwin/apple-sdk-11.0/default.nix
-
xcode
and many related packages like xcode_14_1
… in pkgs/os-specific/darwin/xcode/default.nix
-
apple_sdk
which seems to contain internally xcodebuild
- some packages seem to directly hardcode the path to
/usr/bin/xcodebuild
in the build phase like in pkgs/development/tools/swiftformat/default.nix
, so I guess it is another way to support xcode? But in that case this derivation mentions “This derivation is impure: it relies on an Xcode toolchain being installed and available in the expected place. The values of sandboxProfile and hydraPlatforms are copied pretty directly from the MacVim derivation, which is also impure.”. This is also the case of MacVim (whose name sounds like it should use native Mac GUI) in pkgs/applications/editors/vim/macvim.nix
if you want to grab more inspirations.
and there are many applications that rely on xcbuild
:
$ rg xcbuild
…
pkgs/applications/misc/cardpeek/default.nix
13:, xcbuild
pkgs/applications/misc/mupdf/default.nix
37:, xcbuild
103: ++ lib.optionals stdenv.isDarwin [ desktopToDarwinBundle fixDarwinDylibNames xcbuild ];
pkgs/applications/video/crunchy-cli/default.nix
5:, xcbuild
28: xcbuild
pkgs/applications/video/mpv/default.nix
21:, xcbuild
158: ++ lib.optionals stdenv.isDarwin [ xcbuild.xcrun sigtool ]
pkgs/applications/version-management/p4/default.nix
12:, xcbuild
pkgs/applications/editors/neovim/neovide/default.nix
14:, xcbuild
68: ] ++ lib.optionals stdenv.isDarwin [ xcbuild ];
pkgs/applications/science/biology/neuron/default.nix
13:, xcbuild
35: ++ lib.optionals stdenv.isDarwin [ xcbuild ];
…
so I guess native Mac GUI it is a relatively well supported use case that might only require a ++ lib.optionals stdenv.isDarwin [ xcbuild ];
to work… but since I know nothing about MacOs and have no Mac to test, I can’t say much more. But feel free to try to adapt the package, and ask for more help here or on the Nix on MacOs matrix channel. If you don’t want to spend time on this, you can also just fill a bug report.