Code Signing Issue with Resource Bundles in kokoro-ios / MisakiSwift Swift Packages (Xcode 15.3)

[johneliott]

Code Signing Issue with Resource Bundles in kokoro-ios / MisakiSwift Swift Packages (Xcode 15.3)

Environment:
• Operating System: macOS (darwin)
• Xcode Version: 15.3 (Build 17C529)
• iOS SDK: 16.0 (also occurs with deployment target 18.0)
• Project Generation: XcodeGen
• kokoro-ios version: 1.0.11 (via Package.swift resolved source packages)
• MisakiSwift version: 1.0.6 (via Package.swift resolved source packages)

⸻

Description

We are currently developing an iOS On-Device Voice Assistant App using ASR (whisper.cpp), LLM (llama.cpp), and your kokoro-ios library for TTS. These components are integrated into a SwiftUI application using XcodeGen for project generation.

We are encountering a persistent build failure when integrating kokoro-ios as a Swift Package Manager (SPM) dependency. The build consistently fails during the code signing phase for resource bundles originating from MisakiSwift (a dependency of kokoro-ios) and kokoro-ios itself.

The specific error message from xcodebuild is:

CodeSign /Users/lagorgeous/Library/Developer/Xcode/DerivedData/.../MisakiSwift_MisakiSwift.bundle (in target 'MisakiSwift_MisakiSwift' from project 'MisakiSwift')
/Users/lagorgeous/Library/Developer/Xcode/DerivedData/.../MisakiSwift_MisakiSwift.bundle: bundle format unrecognized, invalid, or unsuitable
Command CodeSign failed with a nonzero exit code

CodeSign /Users/lagorgeous/Library/Developer/Xcode/DerivedData/.../KokoroSwift_KokoroSwift.bundle (in target 'KokoroSwift_KokoroSwift' from project 'KokoroSwift')
/Users/lagorgeous/Library/Developer/Xcode/DerivedData/.../KokoroSwift_KokoroSwift.bundle: bundle format unrecognized, invalid, or unsuitable
Command CodeSign failed with a nonzero exit code

⸻

Steps Taken to Isolate/Resolve (and their outcomes)
1. Initial build failure: The project failed to build with kokoro-ios integrated.
2. Isolated build: Building the project without kokoro-ios as a dependency succeeded, confirming the issue originates from kokoro-ios or its sub-dependencies.
3. Deployment Target Adjustment: Changed the project’s deploymentTarget in project.yml from 16.0 to 18.0 (to match kokoro-ios’s Package.swift platforms declaration). This did not resolve the codesigning issue.
4. postBuild Script (attempt to unsign): Added a postBuild script via XcodeGen to run codesign --remove-signature on the problematic .bundle files. This failed because the CodeSign step occurs during the build process, before the postBuild script executes, meaning the build failed before the script could run.
5. embed: false for KokoroSwift dependency: Set embed: false for the KokoroSwift product dependency in project.yml. This did not prevent the codesigning attempts on the resource bundles.
6. CODE_SIGN_STYLE=Manual with xcodebuild: Passed CODE_SIGN_STYLE=Manual as an xcodebuild argument. This also failed with the same codesigning errors.

⸻

Observation from kokoro-ios’s Package.swift

The kokoro-ios Package.swift declares its resources using:

resources: [.copy("../../Resources/")]

This uses .copy() and points to a directory outside the immediate package structure, which is an unconventional approach for SPM resources and could potentially contribute to Xcode’s confusion regarding how to handle and sign these bundles.

⸻

Request for Assistance

It appears Xcode’s internal SPM integration is attempting to codesign these resource bundles, and our attempts to prevent this through XcodeGen or xcodebuild parameters have been unsuccessful, likely because the relevant build settings for these internal SPM product targets are not directly configurable from our consuming project.

We would appreciate any guidance you can provide on how to resolve this. Specifically, we’d like to know if there’s a recommended way to configure kokoro-ios and MisakiSwift or our consuming project to prevent Xcode from attempting to codesign these resource bundles, or if adjustments are needed in the Package.swift files (e.g., using .process for resources, or a different resource declaration) to align with modern Xcode/SPM best practices.

[m13v]

We ran into a very similar code signing issue with SPM resource bundles in our macOS app. The root cause is usually that Xcode treats .copy() resource bundles differently from .process() ones during code signing, and when the bundle structure does not match what codesign expects, you get the "bundle format unrecognized" error.

Two things that worked for us:

1. Switch from .copy("../../Resources/") to .process("Resources") with the resources directory moved inside the package's Sources folder. The relative path going up two directories is especially problematic because Xcode's SPM integration does not handle out-of-tree resources well during the signing phase.

2. If you cannot restructure the package, add CODE_SIGN_IDENTITY="" and CODE_SIGNING_ALLOWED=NO to the build settings for the resource bundle targets. With XcodeGen, you can do this via configFiles or settings on the dependency. The key insight is that resource bundles inside frameworks/apps do not actually need their own code signature on iOS -- they get signed as part of the parent target.

The fact that this works fine on Xcode 16 but breaks on 15.3 suggests Apple changed how SPM resource bundles are handled in the signing pipeline. If you are stuck on 15.3, option 2 is probably the fastest path forward.

[m13v]

For a working example of SPM resource handling and code signing in a macOS app built entirely with Swift Package Manager, here is our CI config: https://github.com/m13v/fazm/blob/main/codemagic.yaml

It covers Developer ID signing, notarization, and Sparkle update packaging in one pipeline.

[johneliott]

Thank you for the thoughtful response. As stated, upgrading to Xcode 16 was sufficient.