feat(CodeSigningPlugin): auto-embed public key into native project files

[bartekkrok]

Linked to: #1323

Summary

Setting up code signing with CodeSigningPlugin required users to manually add the RSA public key to native project
files (Info.plist on iOS and strings.xml on Android). This is error-prone, easy to forget, and creates a
maintenance burden every time the key is rotated.

This PR adds two new optional config options — publicKeyPath and nativeProjectPaths — that automate public key
embedding during the build:

new CodeSigningPlugin({
  privateKeyPath: './keys/private.pem',
  publicKeyPath: './keys/public.pem',      // new                                                                      
  nativeProjectPaths: {                    // new, optional overrides
    ios: './ios/MyApp/Info.plist',                                                                                     
    android: './android/app/src/main/res/values/strings.xml',
  },                                                                                                                   
});

When publicKeyPath is set the plugin:

• Auto-detects ios//Info.plist and android/app/src/main/res/values/strings.xml (standard RN project layout)
• Inserts or updates the RepackPublicKey entry in each file on every build
• Creates strings.xml if it doesn't exist yet
• Accepts nativeProjectPaths to override either path for non-standard layouts
• Logs a warning and skips gracefully if the key file or target files are not found

The embedding logic lives in the new embedPublicKey.ts module, also exported publicly for standalone use.

Both platforms are idempotent — re-running the build updates the existing entry rather than duplicating it.

Test plan

• Add publicKeyPath pointing to a valid public key in CodeSigningPlugin config
• Run a build and verify RepackPublicKey entry is inserted into ios//Info.plist
• Run a build and verify RepackPublicKey entry is inserted into android/app/src/main/res/values/strings.xml
• Run the build again and confirm the entry is updated, not duplicated
• Remove strings.xml, run a build, and confirm the file is created with the key
• Set publicKeyPath to a non-existent file and confirm a warning is logged, build continues
• Use nativeProjectPaths to override paths and confirm the plugin writes to the specified files

Live demo iOS

Changes were tested on: https://github.com/callstack/super-app-showcase

Screen.Recording.2026-04-16.at.15.mp4

[vercel]

@bartekkrok is attempting to deploy a commit to the Callstack Team on Vercel.

A member of the Team first needs to authorize it.

[changeset-bot]

🦋 Changeset detected

Latest commit: be8801c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@callstack/repack	Major
@callstack/repack-plugin-expo-modules	Major
@callstack/repack-plugin-nativewind	Major
@callstack/repack-plugin-reanimated	Major
@callstack/repack-dev-server	Major
@callstack/repack-init	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[MikitasK]

very solid work done 👍👍
I verified both Android & iOS platforms & auto-embeding works perfectly fine 🚀

iOS

Screen.Recording.2026-04-20.at.18.33.16.mp4

Android

Screen.Recording.2026-04-20.at.19.39.58.mp4

here are just a few things to consider before merge:

[MikitasK]

LGTM ✅

[dannyhw]

@bartekkrok please check the linting 🙏

[dannyhw]

@bartekkrok can you check the conflicts here?

[dannyhw]

this ! seems like it would be better to avoid, perhaps we can just handle the undefined case

[dannyhw]

same thing about the ! here

[dannyhw]

I wonder if regex is the right move here

fast-xml-parser and plist or @plist/parse / @plist/plist

could probably be used to be more accurate/robust.

what do you think?

[dannyhw]

I guess the tradeoff would be plist parsing could be slower

[dannyhw]

I wonder if we would want to think of a way to not always try to embed, like some kind of cache or something if we know it was already embedded? Maybe not worth the effort though, what do you think?