Skip to content
TrustList
News

CocoaPods goes read-only on 2 December, and Google moves its ads SDK

Editorial

By TrustList Editorial

Existing builds keep working, but new versions of the Google Mobile Ads SDK and its mediation adapters will arrive only through Swift Package Manager or manual download.

About CocoaPods goes read-only on 2 December, and Google moves its ads SDK

CocoaPods goes read-only on 2 December, and Google moves its ads SDK

6 November 2026: The CocoaPods Specs repository "will permanently transition to read-only mode" on 2 December, and Google has told iOS developers it will stop publishing the Google Mobile Ads SDK and its mediation adapters there from that date. Apps keep building, but any fix or new feature in those SDKs will arrive only through Swift Package Manager or a manual download.

Not yet independently verified. The CocoaPods dates come from its 2024 plan, updated in May 2025, and Google's post repeats the 2 December date. We have not confirmed that the 2 to 6 November trial ran, or which other SDK makers are moving. We will update this when it can be confirmed, and remove this note.

What stops working and what does not

CocoaPods' maintainers set out the plan in a post by Orta Therox, first published in November 2024 and updated in May 2025. Trunk will refuse any new Podspec at server level and the CocoaPods/Specs repository will be archived on GitHub. A test run of refusing new Podspecs was scheduled for 2 to 6 November, and the permanent switch follows on 2 December.

Nothing already published goes away. "This will keep all existing builds working," the project says, and teams with their own specs repositories or fully vendored dependencies are not affected. So the deadline does not break a project on the day. Its effect is slower: a Podfile will quietly stop receiving updates, and that includes security fixes from any publisher that leaves.

Google's move away from pods

Justin Malandruccolo of Google's Mobile Ads Developer Relations team names two pods in the post, Google-Mobile-Ads-SDK and GoogleUserMessagingPlatform. The second is the one to watch for anyone serving users in regions with consent rules, since it handles the consent message and needs to stay current.

Google's steps are short. Run pod deintegrate if CocoaPods is being removed altogether. Then in Xcode choose File, Add Package Dependencies, and enter https://github.com/googleads/swift-package-manager-google-mobile-ads.git with the rule Up to Next Major Version. Mediation adapters already support Swift Package Manager, with package addresses in the mediation documents.

Publishers and build pipelines

Companies that publish their own iOS SDK through CocoaPods have the most urgent job. After 2 December they cannot push a new version to trunk at all, so a security fix would have no route to customers who still install that way. They should ship a Swift Package Manager release before the date, and tell customers.

App teams should run a dependency audit now. Every pod in a Podfile.lock needs one of three answers: already available as a Swift package, frozen but acceptable, or a risk that needs replacing. A pod with a native module that was last released some years ago is the likely trouble spot, and Google's move suggests other large SDK publishers may be on similar timetables, although we have not confirmed any.

CI machines deserve a look too. A build that runs pod repo update should keep working against the archived repository, yet any step that publishes a Podspec will start to fail, and it is better to find that in a planned change than during a release.

Sources

Categories & features

TrustList Weekly

The week in software and IT, in one email

The news that matters to buyers, new rankings and our own research. Every Thursday, free, and easy to leave.

We will email you to confirm. Unsubscribe with one click in any issue. Privacy policy

You may be interested in