[bug] [v2] [iOS] Manual Xcode build fails with `cargo: command not found`

[stijnfrishert]

Describe the bug

I generate an Xcode project through cargo tauri. When I then open it and try to build in Xcode manually, the script execution phase fails with the following error (long line, scroll to the end):

/Users/stijn/Library/Developer/Xcode/DerivedData/temp-epvdqgocduaasecmmqocxpzwtttl/Build/Intermediates.noindex/temp.build/debug-iphoneos/temp_iOS.build/Script-6BC118688969AAE7C46FEBA4.sh: line 2: cargo: command not found
Command PhaseScriptExecution failed with a nonzero exit code

I looked at the script it tries to execute, which is only this:

#!/bin/sh
cargo tauri ios xcode-script -v --platform ${PLATFORM_DISPLAY_NAME:?} --sdk-root ${SDKROOT:?} --framework-search-paths "${FRAMEWORK_SEARCH_PATHS:?}" --header-search-paths "${HEADER_SEARCH_PATHS:?}" --gcc-preprocessor-definitions "${GCC_PREPROCESSOR_DEFINITIONS:-}" --configuration ${CONFIGURATION:?} ${FORCE_COLOR} ${ARCHS:?}

That's weird, because cargo is obviously installed on my system. The shell listed is /bin/sh, and when I manually open a terminal by running /bin/sh, I can run e.g. cargo --version just fine.

Replacing cargo in the script with /Users/stijn/.cargo/bin/cargo does the trick, so there's probably something wrong with the PATH.

Reproduction

1. Create a new project. I used pnpm + Svelte + TS, but I guess this fails with any combination.
2. I also ran pnpm install for good measure
3. cargo tauri ios init
4. cargo tauri ios dev --open --host
5. When Xcode has opened, hit Cmd + B and see the failure

Expected behavior

I expect the Xcode build to finish

Full tauri info output

[✔] Environment
    - OS: Mac OS 14.6.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.80.1 (3f5fd8dd4 2024-08-06)
    ✔ cargo: 1.80.1 (376290515 2024-07-16)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-apple-darwin (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.14.0
    - pnpm: 9.6.0
    - yarn: 1.22.22
    - npm: 10.7.0

[-] Packages
    - tauri [RUST]: 2.0.0-rc (no lockfile)
    - tauri-build [RUST]: no manifest (no lockfile)
    - wry [RUST]: no manifest (no lockfile)
    - tao [RUST]: no manifest (no lockfile)
    - tauri-cli [RUST]: 2.0.0-rc.4
    - @tauri-apps/api [NPM]: 2.0.0-rc.1
    - @tauri-apps/cli [NPM]: 2.0.0-rc.4

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../build
    - devUrl: http://localhost:1420/
    - framework: Svelte
    - bundler: Vite

[-] iOS
    - Developer Teams: <redacted>

### Stack trace

```text
N.A.

Additional context

N.A.

[jqpe]

This is an oddity with Xcode, and as you said probably related to how PATH is resolved. You can link cargo to /usr/local/bin so Xcode will pick it up. Don't ask me why. Something like ln -s $(which cargo) /usr/local/bin/cargo.

I had a similar issue with pnpm and node, but not cargo which is odd. Did you install via rustup?

[stijnfrishert]

Wow, that's super weird. Thanks Xcode!

Linking to my cargo install works perfectly. I guess that resolves the issue, it's a problem in Xcode.

Yeah, I installed with rustup, the usual path.

[jqpe]

Seems this can be done in a cleaner way by sourcing a shell profile in the prebuild scripts, e.g.

(src-tauri/gen/apple/project.yml)

# ...
targets:
  app_iOS:
    type: application
    platform: iOS
    preBuildScripts:
+      - script: source ~/.zshrc && source ~/.profile
+        name: Load shell profile

      - script: tauri ios xcode-script
        name: Build Rust Code
        basedOnDependencyAnalysis: false

This could be something that Tauri provides out of the box. Example above assumes zsh, but a more robust shell detection would be needed if this is built-in. Maybe just documenting this would be ok?

[songjiachao]

same problem

[DickyChengg]

I changed it to this and it works:

/Users/<user>/.cargo/bin/cargo  tauri ios xcode-script -v --platform ${PLATFORM_DISPLAY_NAME:?} --sdk-root ${SDKROOT:?} --framework-search-paths "${FRAMEWORK_SEARCH_PATHS:?}" --header-search-paths "${HEADER_SEARCH_PATHS:?}" --gcc-preprocessor-definitions "${GCC_PREPROCESSOR_DEFINITIONS:-}" --configuration ${CONFIGURATION:?} ${FORCE_COLOR} ${ARCHS:?}

[stijnfrishert]

Yeah, that works for me as well, but:

a) As soon as you regenerate the XCode project that fix gets thrown away b) I don't think we should hard-code the tool to assume cargo is at /Users/<user>/.cargo/bin/cargo, because people might have installed it elsewhere.

Still, happy to hear that solved it for you as well. At least you can continue work temporarily. :)