CocoaPods Trunk Goes Read-Only on December 2, 2026: Keeping the Airbridge iOS SDK Installable

You are shipping a release for your iOS subscription app on a Tuesday night, and a routine dependency check reminds you that your Podfile needs attention before the CocoaPods Trunk transition. When you are managing a monthly paid ad budget and watching every trial conversion across your campaigns, you want a clear plan for updating how your project pulls in its SDKs and checking your event logs afterward. Moving an existing Xcode project away from CocoaPods Trunk—or updating how your attribution SDK is pulled in—works best when you handle repository sources, project settings, and event verification step by step.

What the Read-Only Cutover Changes

December 2, 2026, is on the timeline for the CocoaPods Trunk read-only plan CocoaPods Trunk Read-only Plan - CocoaPods Blog. The read-only change is intended to keep all existing builds working. In fact, the central Specs repository and CDN are expected to keep running for as long as GitHub and jsDelivr exist.

What changes is how you receive future SDK updates. Once CocoaPods Trunk transitions to read-only mode, new versions of the iOS SDK are published to the Airbridge GitHub CocoaPods Spec repository. Leaving your project pointed solely at the legacy central trunk means you will not pull those newer SDK versions published after the transition.

Auditing Pods and Attribution Dependencies

Open your Podfile and list every library your app pulls in, paying close attention to how your attribution and subscription stack fit together. In a consumer subscription app, subscription revenue from tools in your stack is connected through subscription revenue aggregation. Reviewing these integrations alongside your pod list helps you keep track of which dependencies you are removing and which ones require an updated source path on CocoaPods.

To install or update to newer Airbridge SDK versions published to the Airbridge GitHub CocoaPods Spec repository after the CocoaPods Trunk read-only transition, use the Private CocoaPods configuration. In that setup, the CocoaPods dependency uses the airbridge-ios-sdk pod and the source URL https://github.com/ab180/airbridge-cocoapods-specs.git, where you replace $HERE_LATEST_VERSION with a version available in the spec repository.

Preparing Xcode Project Build Settings

Before you install the iOS SDK, open the Xcode project's Build Settings and set User Script Sandboxing to No.

Stripping Out Legacy Pods Cleanly

If you decide to install the SDK with Swift Package Manager instead of the Private CocoaPods setup, run the dedicated CocoaPods cleanup command from your terminal rather than hunting down references manually in Xcode. Skip this step if you stay on CocoaPods.

pod deintegrate removes all traces of CocoaPods from an Xcode project CocoaPods command-line documentation. The command syntax is pod deintegrate [XCODE_PROJECT], with an optional Xcode project argument CocoaPods command-line documentation.

Verifying Attribution Events After Migration

On the Core Plan, a developer installs the Airbridge SDK to record predefined events and verifies the setup in the Test Console, with Google, Meta, Apple Ads, and TikTok channel integrations and 25 standard events pre-configured (for subscription events, only Start Trial, Subscribe, and Unsubscribe are included). For purchase flows in Swift, the SDK-provided standard event category ORDER_COMPLETED can be tracked with Airbridge.trackEvent(category: AirbridgeCategory.ORDER_COMPLETED). The SDK option builder also supports a setOnAttributionReceived callback that runs when attribution is received.

To confirm your events are collected, use the Airbridge dashboard's App Real-time Logs to check whether in-app events were collected according to the event taxonomy. However, a test event can be absent from real-time logs even when collected, because the logs are sampled Testing - iOS SDK.

Register the identifier for a test device, browser, user account, or IP address as a test identifier to see every event from it. Events from registered test identifiers appear in full without sampling. When viewing event details in the real-time logs, install-event details can take up to 10 minutes from the event occurrence to appear in the real-time logs.