# iOS Distribution: the Digia Spec Repo

URL: https://www.digia.tech/docs/developer/reference/ios-spec-repo

CocoaPods is making its public registry ( **trunk** ) read-only, so new pod versions can no longer be published there. For Digia releases that need a new iOS SDK version, we now publish the underlying iOS SDK through our own CocoaPods **spec repo** instead.

For you, this is a **one-time, two-step change** to your React Native iOS project.

info
**This change applies to you if all of the following are true:**
- Your app is a **React Native** app that builds for **iOS using CocoaPods** (a `Podfile` in `ios/` ).
- You are upgrading to `@digia-engage/core`**`3.3.0` or later** .
**It does not apply if:**
- You only build for **Android** .
- You are a **native iOS** app that installs Digia with **Swift Package Manager** .
- You stay on an earlier Digia release, such as `@digia-engage/core` below `3.3.0` .
**Nothing breaks if you do nothing today.** Versions you already use keep installing from the public registry. You only need to make this change when you upgrade to a release in the range above.

## What changed and why

| Date | Event | Nov 1–7, 2026 | CocoaPods runs a read-only **test** of trunk. Publishing may be refused. | Dec 2, 2026 | Trunk becomes **permanently read-only** . No new pods or pod versions are accepted. 

Per the [CocoaPods announcement](https://blog.cocoapods.org/CocoaPods-Specs-Repo/) , existing pods stay installable and existing builds keep working. What stops is *new* versions.

So that Digia can keep shipping iOS releases, new `DigiaEngage` versions are published to [`digia-podspecs`](https://github.com/Digia-Technology-Private-Limited/digia-podspecs) , a public spec repo we maintain. Your Podfile needs to know about it.

## Set up

### Step 1: Add the Digia spec repo

- React Native CLI - Expo
Add these two lines at the **very top** of `ios/Podfile` , above everything else:
```ruby
source 'https://github.com/Digia-Technology-Private-Limited/digia-podspecs.git'
source 'https://cdn.cocoapods.org/'
```

Keep the CDN line. Once you list any custom source, CocoaPods no longer adds the public registry for you, so every other pod in your app would stop resolving without it.

Expo regenerates `ios/Podfile` on every prebuild, so you cannot edit it by hand. The `@digia-engage/core` config plugin adds the source lines for you. Add it to `app.json` :
```json
{
  "expo": {
    "plugins": ["@digia-engage/core"]
  }
}
```

**Using a `@digia-engage/core` version that does not include the plugin?** Upgrade to one that does, or add this small local plugin instead. Save it as `plugins/withDigiaPodspecsSource.js` :
```js
const { withDangerousMod } = require('@expo/config-plugins');
const fs = require('fs');
const path = require('path');

const SOURCES = [
  "source 'https://github.com/Digia-Technology-Private-Limited/digia-podspecs.git'",
  "source 'https://cdn.cocoapods.org/'",
];

module.exports = (config) =>
  withDangerousMod(config, [
    'ios',
    (cfg) => {
      const podfile = path.join(cfg.modRequest.platformProjectRoot, 'Podfile');
      const contents = fs.readFileSync(podfile, 'utf8');
      const missing = SOURCES.filter((s) => !contents.includes(s));
      if (missing.length) {
        fs.writeFileSync(podfile, missing.join('\n') + '\n' + contents);
      }
      return cfg;
    },
  ]);
```

Then register it in `app.json` (or `app.config.ts` ) as `"./plugins/withDigiaPodspecsSource"` . It is idempotent, so running prebuild repeatedly adds the lines only once.

### Step 2: Do a full clean install

A clean install makes sure stale pods and caches don't hide the change.

- React Native CLI - Expo

```bash
npm install @digia-engage/core@3.3.1
rm -rf node_modules ios/Pods ios/build ~/Library/Developer/Xcode/DerivedData
npm install
cd ios && pod install --repo-update --clean-install
```

```bash
npm install @digia-engage/core@3.3.1
npx expo prebuild --clean --platform ios
cd ios && pod install --repo-update
```

`prebuild --clean` regenerates `ios/` , so use it only if you don't hand-edit native files there.

warning
**Keep your `Podfile.lock` . Do not delete it.** Deleting it re-resolves every pod and can pull in unrelated upgrades. `pod install` moves `DigiaEngage` forward on its own. Commit the updated lockfile.

If your CI caches `Pods/` or Xcode DerivedData, clear that cache once.

### Step 3: Verify

Open `ios/Podfile.lock` . Under `SPEC REPOS` you should see the Digia repo listing `DigiaEngage` :

```yaml
SPEC REPOS:
  https://github.com/Digia-Technology-Private-Limited/digia-podspecs.git:
    - DigiaEngage
  trunk:
    - ...
```

Then build and run your app as usual. After this one-time setup, future Digia upgrades are just `npm install` and `pod install` .

## How it works

A CocoaPods **spec repo** is a git repository of **podspec** files. A podspec is a small text file that gives a pod's name, version, and where to download it. The public registry (trunk) is the same kind of thing. Hosting your own spec repo is a documented CocoaPods feature; see the CocoaPods [Private Pods guide](https://guides.cocoapods.org/making/private-cocoapods.html) .

The `source` lines in your Podfile tell CocoaPods where to look up podspecs. Per the [Podfile reference](https://guides.cocoapods.org/syntax/podfile.html#source) , CocoaPods uses the highest version of a pod from the **first source that contains that pod** . With the Digia repo listed first and the CDN second:

- `DigiaEngage*` pods resolve from `digia-podspecs` .
- Every other pod in your app resolves from the public CDN, exactly as before.
The spec repo holds **only podspec text files** , not source code. The podspec points at the same release download on GitHub that the trunk podspec used, so the SDK binary comes from the same place as before.

## Why this is safe

- **It is a standard CocoaPods feature** , documented by the CocoaPods team. It is not a hack or an unofficial workaround.
- **It only affects Digia pods.** Your other dependencies keep resolving from the public CDN.
- **Versions stay pinned.** Your `Podfile.lock` records the exact version and podspec checksum of every pod, so installs are reproducible and any change shows up in code review.
- **No credentials.** The spec repo and the SDK downloads are public. No tokens or logins are needed locally or in CI.
- **It is independent of trunk.** It keeps working after Dec 2, when trunk stops accepting new versions.
- **Easy to undo.** Remove the two `source` lines and you are back to trunk-only. Versions already on trunk keep resolving.
info
**Dependency on GitHub.** New Digia iOS versions are served from our GitHub spec repo and GitHub Releases. Committing your `Podfile.lock` and caching `Pods/` in CI keeps your builds independent of GitHub availability for versions you have already installed.

## Troubleshooting

### `None of your spec sources contain a spec satisfying the dependency: DigiaEngage`

```text
[!] CocoaPods could not find compatible versions for pod "DigiaEngage":
  ...
None of your spec sources contain a spec satisfying the dependency: `DigiaEngage (< 5.0.0, >= 4.3.2)`.
```

Your Podfile does not list the Digia spec repo. Complete Step 1 and run `pod install --repo-update` again. On Expo, run `npx expo prebuild --platform ios` first so the plugin rewrites the Podfile.

### Other pods stopped resolving after adding the source

The CDN line is missing. Make sure `source 'https://cdn.cocoapods.org/'` is present **after** the Digia line. Listing a custom source removes the implicit public registry.

### A warning about multiple sources containing the same pod

CocoaPods warns when two sources contain the same pod at the same version. This can happen for older `DigiaEngage` versions that exist in both the spec repo and trunk. It is harmless: the first source (Digia) wins, and the binary is identical.

### CI still fails after the change

Clear the cached `Pods/` directory and Xcode DerivedData in CI once, then re-run. A stale cache can hide the new source.

### Do I need to change anything for versions I already have installed?

No. Existing versions keep installing from trunk. This only matters when you upgrade to a Digia release that needs a newer iOS SDK.

## What's next

CocoaPods itself keeps working after Dec 2, and the spec repo keeps our releases flowing. React Native is also moving iOS builds to Swift Package Manager over the next releases. We are evaluating Swift Package Manager support for the React Native SDK and will announce it, with migration steps, before anything else changes.

Questions or stuck on the setup? Contact [engg@digia.tech](mailto:engg@digia.tech) .