First attempt targeted only `target_installation_results.resource_bundle_targets` —
too narrow. With privacyManifestAggregationEnabled the Pods project has additional
bundle targets (aggregated privacy manifests) that also need code-signing disabled.
Brute-force fix: set CODE_SIGNING_ALLOWED/REQUIRED = NO and clear
EXPANDED_CODE_SIGN_IDENTITY on every target in installer.pods_project — pod
targets don't need signing, only the main app does. Added a Pod::UI.puts so we
can see the fix run in the EAS build log.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
EAS iOS build failed: "Starting from Xcode 14, resource bundles are signed by
default, which requires setting the development team for each resource bundle
target." Cause: we build with useFrameworks: "static" (expo-build-properties),
so CocoaPods generates resource-bundle targets for pods with resources, and
Xcode 14+ wants them signed. EAS has no dev team for those.
New plugin with-resource-bundle-signing-fix injects into the Podfile's existing
post_install hook: sets CODE_SIGNING_ALLOWED = 'NO' for every pod resource-bundle
target (they don't need signing). Idempotent; runs as withDangerousMod('ios')
during prebuild so it survives EAS's clean prebuild.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Plugin referenced @string/accessibility_service_summary +
@xml/accessibility_service_config in AndroidManifest but never created the
underlying resource files. EAS Cloud prebuild --clean exposed this — local
dev worked because resources were sometimes already there from previous builds.
- withStringsXml: adds accessibility_service_summary string (DE)
- withDangerousMod: writes res/xml/accessibility_service_config.xml at prebuild
- Config flags match native service (TYPE_WINDOW_CONTENT_CHANGED + STATE_CHANGED,
canRetrieveWindowContent for URL-bar reading)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
