voltra CLI: support per-scheme entitlements path and group identifier (multi-environment apps)

[adelbeke]

Feature Description

Allow ios.entitlementsPath and ios.groupIdentifier in voltra.config.ts to be configured per build scheme/configuration, not just as a single string.

Problem Statement

IOSProjectOverrides and the top-level iOS config currently type entitlementsPath and groupIdentifier as a single string. Apps that ship multiple environments (dev / test / staging / release) as separate Xcode schemes typically have one entitlements file per scheme, each with its own App Group identifier (e.g. group.com.example.app, group.com.example.app.staging, group.com.example.app.dev). With the current schema there's no way to express this: voltra apply can only target one entitlements file / one group identifier, which would either overwrite the wrong scheme's entitlements or silently leave the others unconfigured. This is currently the main blocker preventing us from adopting the CLI apply pipeline on a React Native CLI project with more than one build scheme.

We're a company shipping our app across four environments (dev, test, staging, production), each built from its own Xcode scheme with its own entitlements file and App Group identifier for widget data sharing. This isn't an edge case for us: any team with a staged rollout process (dev/QA/staging/prod) will hit the same wall.

Proposed Solution

Accept either a single string (current behavior, unchanged) or a map keyed by scheme/build configuration name for entitlementsPath and groupIdentifier, e.g.:

ios: {
  entitlementsPath: {
    Debug: './ios/App/AppDebug.entitlements',
    ReleaseStaging: './ios/App/AppReleaseStaging.entitlements',
    Release: './ios/App/AppRelease.entitlements',
  },
  groupIdentifier: {
    Debug: 'group.com.example.app.dev',
    ReleaseStaging: 'group.com.example.app.staging',
    Release: 'group.com.example.app',
  },
}

voltra apply would then mutate each listed entitlements file with its corresponding group identifier instead of assuming a single target.

Alternatives Considered

Running voltra apply once per scheme with a different config file each time doesn't work cleanly since apply also mutates shared files (Podfile, project.pbxproj, generated Swift files), so repeated runs would conflict or overwrite each other's output.

Current Library Version

voltra 2.2.0 / @use-voltra/ios-client 2.1.1

Implementation

• I would be willing to submit a pull request for this feature

Additional Context

Very interested in picking this up myself. I'd be working through the implementation with Claude (Anthropic's AI coding assistant) as support, so happy to iterate on API shape/feedback before opening a PR.