Skip to main content

iOS Distribution: the Digia 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​

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

Per the CocoaPods announcement, 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, a public spec repo we maintain. Your Podfile needs to know about it.

Set up​

Step 1: Add the Digia spec repo​

Add these two lines at the very top of ios/Podfile, above everything else:

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.

Step 2: Do a full clean install​

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

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
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:

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.

The source lines in your Podfile tell CocoaPods where to look up podspecs. Per the Podfile reference, 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​

[!] 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.