cmake-rn: make CODE_SIGNING_ALLOWED configurable for Apple builds - #430
Merged
Conversation
Add a --code-signing-allowed flag to the Apple platform of cmake-rn. CODE_SIGNING_ALLOWED=NO remains the default (needed for the free-standing dynamic libraries we produce), but a consumer who needs signed binaries in the XCFramework - enterprise distribution, or a target whose downstream tooling verifies signatures - can now opt in. Addresses the Apple half of #418. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm
kraenhansen
force-pushed
the
claude/issue-418-apple-code-signing
branch
from
August 13, 2026 10:33
4999ae4 to
23e1cde
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This addresses the Apple half of #418 (the Android
ANDROID_STLhalf is a separate PR).packages/cmake-rn/src/platforms/apple.tspassedCODE_SIGNING_ALLOWED=NOtoxcodebuildunconditionally when building free dynamic libraries. That's the right default (we produce free-standing dynamic libraries), but a consumer who needs signed binaries in the XCFramework — enterprise distribution, or a target whose downstream tooling verifies signatures — had no way to override it.Changes
--code-signing-allowedCLI option (and correspondingAppleOpts.codeSigningAllowedprogrammatic option), following the sameOption+amendCommandpattern already used for--xcframework-extensionand--apple-bundle-identifier.false(unchanged behavior:CODE_SIGNING_ALLOWED=NO); passing--code-signing-allowednow producesCODE_SIGNING_ALLOWED=YES, still appended after--to thecmake --buildinvocation that drivesxcodebuild, matching the existing mechanism.minorchangeset forcmake-rn(backward compatible new capability; repo is in changesets pre-release mode targetingnext/rc).Validation
pnpm install && pnpm run buildpnpm --filter cmake-rn run testpnpm exec eslint packages/cmake-rn/src/platforms/apple.tspnpm exec prettier --check packages/cmake-rn/src/platforms/apple.ts .changeset/*.mdNo existing test in
cmake-rn's suite exercisesplatforms/apple.ts'sbuild()args array (it isn't set up for that kind of mocking), so no test was extended — happy to add one if there's a preferred harness for it.🤖 Generated with Claude Code
https://claude.ai/code/session_01DaK9eAAF5G8wj6UT8VekAm
Generated by Claude Code