Managing Native Settings Across Rork-Exported Apps with a Custom Expo Config Plugin

Writing the smallest possible config plugin

To get the feel, let's add a single key to Info.plist. Put plugins/withHello.js at the project root.

// plugins/withHello.js
const { withInfoPlist } = require("@expo/config-plugins");
 
module.exports = function withHello(config) {
  return withInfoPlist(config, (config) => {
    // config.modResults is the Info.plist contents (a JS object)
    config.modResults.NSAppGreeting = "Hello from a config plugin";
    return config;
  });
};

Then register it in the plugins array of app.config.ts.

// app.config.ts
export default {
  expo: {
    name: "WallpaperApp",
    plugins: [
      "./plugins/withHello.js",
    ],
  },
};

Run npx expo prebuild --clean and the generated ios/WallpaperApp/Info.plist now contains NSAppGreeting — without you ever opening the file. That is the "native settings generated from declarations" feeling in miniature.

A plugin that injects AdMob and ATT together

Now the real work. Every wallpaper app needs the AdMob App ID, the ATT (App Tracking Transparency) description, and the SKAdNetwork identifier list. Let's consolidate them into one plugin.

The Before workflow was a manual edit after each prebuild:

# Manual work after every prebuild (destined to disappear)
1. Open ios/WallpaperApp/Info.plist
2. Paste GADApplicationIdentifier
3. Write NSUserTrackingUsageDescription
4. Paste the SKAdNetworkItems list, endlessly
5. -> next prebuild wipes it all -> back to 1

After, that entire procedure moves into the plugin.

// plugins/withAdConfig.js
const { withInfoPlist } = require("@expo/config-plugins");
 
// Frequently used SKAdNetwork IDs (grow this to match your ad SDK)
const SKADNETWORK_IDS = [
  "cstr6suwn9.skadnetwork",
  "4fzdc2evr5.skadnetwork",
  "v9wttpbfk9.skadnetwork",
];
 
module.exports = function withAdConfig(config, props) {
  const { admobAppId, trackingMessage } = props;
 
  return withInfoPlist(config, (config) => {
    const plist = config.modResults;
 
    // 1) AdMob App ID
    plist.GADApplicationIdentifier = admobAppId;
 
    // 2) ATT description (localize separately via InfoPlist.strings)
    plist.NSUserTrackingUsageDescription = trackingMessage;
 
    // 3) Build the SKAdNetwork list idempotently
    plist.SKAdNetworkItems = SKADNETWORK_IDS.map((id) => ({
      SKAdNetworkIdentifier: id,
    }));
 
    return config;
  });
};

The caller passes props as the second element of the array.

// app.config.ts
export default {
  expo: {
    name: "WallpaperApp",
    plugins: [
      [
        "./plugins/withAdConfig.js",
        {
          admobAppId: process.env.ADMOB_IOS_APP_ID,
          trackingMessage:
            "Used to show wallpapers and recommendations tailored to you.",
        },
      ],
    ],
  },
};

The key point is reading the App ID from process.env. You never hard-code the value, so the same plugin works across apps simply by switching .env. Having once shipped a release with no ads because of a mispasted ID, I strongly recommend defining each ID in exactly one place.

Sharing it across six apps

Copying withAdConfig.js into all six repositories just multiplies the number of places you have to edit. The SKAdNetwork list changes from time to time as ad SDKs update, so keeping six copies in sync by hand is not realistic.

I moved it into a shared package. The procedure is three steps:

1. Create a small npm package @dolice/native-config (or an internal monorepo package) holding withAdConfig.js and the SKAdNetwork list
2. Add it as a dependency in each app's package.json
3. Reference it by package name from app.config.ts

// Each app's app.config.ts (identical across all six)
export default {
  expo: {
    name: "WallpaperApp",
    plugins: [
      [
        "@dolice/native-config/withAdConfig",
        {
          admobAppId: process.env.ADMOB_IOS_APP_ID,
          admobAndroidId: process.env.ADMOB_ANDROID_APP_ID,
          trackingMessage: process.env.ATT_MESSAGE,
        },
      ],
    ],
  },
};

Now when the SKAdNetwork list changes, you edit exactly one file in the package. Each app just bumps the dependency version and prebuilds, and the same change lands in all six. App-specific values (App ID, localized strings) stay in .env, so shared code and per-app settings remain cleanly separated.

Covering Android with the same plugin

The same philosophy applies to Android's AndroidManifest.xml. AdMob's App ID has to go into a manifest <meta-data> entry. Using withAndroidManifest, the one plugin function handles both platforms.

// plugins/withAdConfig.js (Android part added)
const {
  withInfoPlist,
  withAndroidManifest,
  AndroidConfig,
} = require("@expo/config-plugins");
 
function withAndroidAdConfig(config, props) {
  return withAndroidManifest(config, (config) => {
    const app = AndroidConfig.Manifest.getMainApplicationOrThrow(
      config.modResults
    );
    AndroidConfig.Manifest.addMetaDataItemToMainApplication(
      app,
      "com.google.android.gms.ads.APPLICATION_ID",
      props.admobAndroidId
    );
    return config;
  });
}
 
module.exports = function withAdConfig(config, props) {
  config = withIosAdConfig(config, props); // the iOS part, extracted into a function
  config = withAndroidAdConfig(config, props);
  return config;
};

The AndroidConfig.Manifest helpers spare you from editing XML as raw strings. addMetaDataItemToMainApplication overwrites a same-named key, so no matter how many times you prebuild, the <meta-data> never duplicates. That idempotency pays off later.

Production gotchas I hit

Even after the plugin was running, a few things tripped me up in production. I'll leave them here as notes.

First, plugins only run during prebuild. EAS Update (OTA) does not change native settings, so even if you "fixed" the App ID, nothing changes until you build and ship a new binary. I lost a couple of hours wondering why my fix wasn't taking. The cure is to remember that native changes always require a build.

Second, a plugin written in TypeScript can't be loaded as-is. app.config.ts itself is fine, but the plugin referenced from the plugins array must be CommonJS .js (or precompiled). I settled on writing plugins plainly in .js.

Third, mod ordering matters when several mods touch the same file. Register two withInfoPlist mods and the later one may overwrite the earlier. Consolidate processing for a single plist into one mod.

Fourth, when you use withDangerousMod, you must guarantee idempotency yourself. If you append to a file, the line count grows on every prebuild. Always check "does this line already exist" before appending. Where possible I recommend avoiding withDangerousMod and using structured mods like withInfoPlist.

Finally, when a change isn't taking, npx expo prebuild --clean rebuilds ios/ and android/ and makes diagnosis far easier. Stale output can hide your plugin changes.

Your next step

Start by writing the smallest plugin — one that adds a single key to Info.plist — in a Rork project you have on hand, then prebuild. Once you can see that value in the generated plist with your own eyes, you've internalized the feeling of reproducing native settings from source. From there you can move every hand-edited setting, AdMob and ATT alike, into the plugin one at a time.

I braced myself at first, treating native as a black box, but going through config plugins brought me close to the carpenter's drawing: the same input always builds the same house. If you are juggling multiple apps too, I hope this helps you out of settings hell.