Repository navigation
Download the Intercom iOS SDK from its GitHub release instead of CocoaPods - #475
Conversation
The Intercom pod is no longer published to the CocoaPods trunk, so the podspec now downloads Intercom.xcframework for a pinned version from the intercom-ios GitHub release, verifies its SHA-256 and vendors it. The dependency update workflow bumps the pinned version and checksum. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
DD-Intercom
left a comment
DD-Intercom
left a comment
There was a problem hiding this comment.
Approach is right: a podspec can't redirect a dependency to a non-trunk source, so downloading in the podspec is the option that doesn't push work onto every consumer. Versioned extract path, .gitignore entry, cache override and exact pin all look good, and the workflow keeps version and checksum moving together.
Main concern: no CI job runs pod install, so nothing here exercises the download/checksum/extract path. Plus two workflow robustness items. All inline.
With no line to attach to: the examples' Podfile.locks no longer record the Intercom SDK version, so pod install is no longer a place SDK drift would surface. Expected, just noting it.
A CircleCI job now installs the example app's pods with an empty SDK cache, so every PR exercises the download, checksum and extract. The update workflow takes the release digest from the release it already fetched and fails if the podspec version and checksum weren't rewritten. Stale extracted SDK versions are removed, and the helper logs without CocoaPods loaded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
React Native 0.81's pod install refuses Xcode older than 16.1, and the shared macOS config pins 16.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Xcode 26 image has no Ruby 3.3.4, so rbenv refused to run pod. Install it from .ruby-version as script/setup does, and run pod through bundler so CI uses the Gemfile's CocoaPods. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Closing this PR as newer SDK versions are available. A new PR will be created with the latest versions. |
The full-text search also matched PRs whose comments mention those words, so the daily run closed an unrelated open PR. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
DD-Intercom
left a comment
DD-Intercom
left a comment
There was a problem hiding this comment.
All six addressed, and the pod-install job is the important one — download, checksum and extract now run with an empty cache on every PR, and the ls on the cache zip means it can't silently stop exercising that path.
Taking the digest from the latest release JSON is cleaner than what I suggested, and since ios_new_version comes from that same payload the two can't drift apart. Non-blocking nit: the job proves the zip landed in the cache but not that extraction produced a framework — ls ../../../intercom-ios-sdk/*/Intercom.xcframework/Info.plist would close that. Not worth another round on its own.
dSYM thread resolved in your favour. LGTM.
Why?
The Intercom iOS SDK is no longer published to the CocoaPods trunk, so the
Intercompod dependency can't pick up new SDK versions (19.10.0 isn't there). The daily dependency update workflow has failed since that release.How?
During
pod installthe podspec now downloads the pinned SDK release from GitHub, checks its SHA-256, caches it and links it as a vendored framework. The update workflow bumps the pinned version and checksum after checking them against the release, and only treats PRs titled as SDK bumps as its own.Notes for reviewers
The iOS version is now an exact pin rather than
~>, and apps that addedpod 'Intercom'themselves need to remove it (README updated). The version stays at 19.9.2 here; the update workflow should open the 19.10.0 bump once this lands.tested:
pod install(fresh and cached) and a simulator build and launch of the with-notifications example, with Intercom.framework embedded and loaded.Generated with Claude Code