Answer to the question
Capacitor does not provide a built‑in, per‑platform key/value store inside capacitor.config.ts that would be read at runtime. The only supported way to make a plugin behave differently on iOS and Android without editing the native files manually is to use a config‑plugin (or edit‑config tags) that writes the desired changes into the native project when npx cap sync runs.
In short: Use a config‑plugin to generate platform‑specific native files; the overrides are applied at sync time, not at runtime.
Platform‑specific plugin inclusion/exclusion
Capacitor lets you include or exclude a plugin on a per‑platform basis by adding a platform field to the plugin declaration in capacitor.config.ts or package.json. Example:
// capacitor.config.ts
export default {
plugins: {
Camera: {
ios: {
// iOS‑only options
},
android: {
// Android‑only options
}
}
}
}
This only controls auto‑inclusion; it does not modify native properties such as permissions or initialization parameters.
Config‑plugin overrides for native properties
To change a native plugin’s behavior (e.g., toggle a permission, set a flag in AndroidManifest.xml or Info.plist) you must provide a config‑plugin package. The plugin’s plugin.xml contains <edit-config> or <config-plugin> entries that are applied during cap sync.
Example for Android:
<edit-config target="android/app/src/main/AndroidManifest.xml" file="AndroidManifest.xml" mode="merge">
<uses-permission android:name="android.permission.CAMERA" />
</edit-config>
Example for iOS:
<config-plugin platform="ios" target="Info.plist">
<add key="NSCameraUsageDescription" value="We need camera access" />
</config-plugin>
When you run npx cap sync, Capacitor copies these overrides into the native project, so you never touch AndroidManifest.xml or Info.plist directly.
Can these overrides change bridge initialization?
Bridge initialization parameters are set by the native plugin’s code at runtime. A config‑plugin can only modify static files (manifest, plist, Gradle, etc.). If the plugin’s native code reads a value from those files during onCreate (Android) or application:didFinishLaunchingWithOptions: (iOS), then the override will affect the runtime behavior. However, you cannot change the JavaScript‑to‑native bridge’s API signature or the way the plugin is registered via the config alone.
What to verify after adding a config‑plugin
- Run
npx cap sync and inspect the generated AndroidManifest.xml or Info.plist for the expected entries.
- Build the native project and ensure no build warnings about missing
<edit-config> targets.
- Execute the plugin on the target platform and confirm that the overridden behavior (e.g., permission prompt, feature flag) is in effect.
Missing diagnostic detail
To give you the most precise snippet for your case, could you tell me which plugin’s property you want to override and on which platform?