Xcode error 65 and code signing failures on Apple Silicon

After this, the build actually tells you what failed, instead of just handing you a bare exit code.

M1M2M3M4 · macOS 14–26 · Verified 2026-09-08
On this page
Quick answer

"Error 65" is a generic Unix exit code that xcodebuild returns whenever any build phase fails — it is not a specific, single fault, and it isn't inherently a code-signing problem even though signing failures are one common cause. Scroll up in the actual build log to find the real error above the exit-code line. On Apple Silicon, a specific and very common real cause is a CocoaPods dependency built only for x86_64 failing to link against the arm64 iOS Simulator.

Why this happens

Exit code 65 comes from the standard Unix sysexits.h convention for "bad data input" and gets surfaced by xcodebuild, Fastlane, and CocoaPods alike whenever some build phase exits non-zero — the actual failing step is logged separately, usually as either Command PhaseScriptExecution failed with a nonzero exit code or, when it really is signing, Command CodeSign failed with a nonzero exit code. Treating "error 65" itself as the diagnosis is the single biggest time-waster here; it's a wrapper, not a cause.

The Apple-Silicon-specific version of this that shows up constantly in real projects: since Xcode 12, the iOS Simulator runs natively as arm64 on Apple Silicon Macs, instead of always running as x86_64 under Rosetta the way it did on every Intel Mac. Any CocoaPods pod or static library that was only ever built for x86_64 now fails to link — and often fails to sign — the moment Xcode tries to build it for the arm64 simulator slice, with a linker error like building for iOS Simulator, but linking in object file built for iOS, for architecture arm64. This is a real, common category, distinct from a plain expired-certificate or provisioning-profile problem.

Fix it

  1. Scroll up in Xcode's build log (or your CI log) past the "error 65" or "exit code 65" line to find the actual failing command — it's almost always a few lines above, and it names the real problem (a missing certificate, a linker error, a failed script). Don't start changing signing settings until you've read that line.

  2. If the real error mentions linking or an architecture mismatch for the simulator specifically, exclude arm64 from the simulator build target in your Podfile — this is the standard, widely-used fix for x86_64-only pods:

    post_install do |installer|
      installer.pods_project.build_configurations.each do |config|
        config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64"
      end
    end

    This is a project file edit, not a system command — add it to your Podfile and run pod install again. The long-term fix is updating to a pod version that ships a proper universal build or an XCFramework, which sidesteps this class of error entirely; the exclusion above is the pragmatic workaround until then.

  3. If the real error is actually about signing (certificates, provisioning, "no signing certificate found"), check what Xcode can actually see in your keychain:

    Reads the system

    What it does: lists valid code-signing identities available in your keychain.

    After: nothing changes, this only reads.

    security find-identity -v -p codesigning

    An empty or 0 valid identities found result means Xcode has nothing to sign with — check Xcode's own Signing & Capabilities tab for the exact certificate/profile it expects, and confirm that certificate is actually present and not expired in Keychain Access.

Still broken?

Verified on

ChipmacOSVerified
M1 (MacBook Air)26.62026-09-08
M2 Pro (Mac mini)26.62026-09-08
M3 (MacBook Pro)26.6.22026-09-08
M4 (MacBook Pro)26.62026-09-08

Related problems