· ReadyStack
Worked example
Real numbers from this tool, line by line.
Swift Package Manager: 6 findings. That is what an iOS team's ShopApp Podfile returned on 2026-10-11, 52 days before CocoaPods trunk turns read-only on 2026-12-02.
| Podfile line | Swift Package Manager line |
|---|---|
| no source line | trunk is the default source |
| pod 'Alamofire', '~> 5.8' | .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.8.0") |
| pod 'Kingfisher', '~> 7.10.0' | .upToNextMinor(from: "7.10.0") |
| pod 'SnapKit' | from: "<version in Podfile.lock>" |
| pod 'Firebase/Analytics', '~> 10.0' | .product(name: "FirebaseAnalytics", package: "firebase-ios-sdk") |
| pod 'AcmeLegacyKit', '1.4.2' | no Swift package: vendor repo or .binaryTarget |
What changes on 2026-12-02
The CocoaPods team published its plan on blog.cocoapods.org/CocoaPods-Specs-Repo. A test run is planned for 2026-11-01 to 11-07, and on 2026-12-02 trunk stops accepting new podspecs for good. Existing builds keep working: the Specs repo and the CDN stay up. What stops is the flow of new versions. Every pod that resolves from trunk is frozen at the last version pushed before that day, and every library released with pod trunk push has no release path left there. Since May 2025 trunk has also refused new pods that use prepare_command.
Why the first finding is a line that is not there
The ShopApp Podfile has no source line. CocoaPods then resolves every pod from trunk at cdn.cocoapods.org, so the whole file depends on trunk without saying so. The check reports that at line 1 with the clock: on 2026-10-11, 21 days to the test run and 52 days to read-only. Put a different date in and the sentence changes; on 2026-12-15 it says trunk has been read-only for 13 days.
Why the version rules matter
A Podfile's ~> is not Swift Package Manager's from. '~> 5.8' allows 5.8 up to, not including, 6.0, which is from: "5.8.0". '~> 7.10.0' allows 7.10.x only, which is .upToNextMinor(from: "7.10.0"). A bare '6.5.0' is exact: "6.5.0". A pod with no version, like SnapKit here, has no rule to copy, so the line asks for the version already in Podfile.lock.
Why product names matter
Firebase/Analytics is a subspec in CocoaPods. In Swift Package Manager it is the product FirebaseAnalytics inside the package firebase-ios-sdk. lottie-ios becomes the product Lottie. GRDB.swift becomes GRDB. The 17 map rules come from each vendor's own Package.swift, so the product names are the ones Xcode will accept.
What it leaves alone
Pods pulled with :git, :path or :podspec do not come from trunk. A Podfile whose only source is a private specs repo returns 0 findings. AcmeLegacyKit in the sample has no Swift package in the map, so the finding tells you to check the vendor repo for a Package.swift or ship an XCFramework as a .binaryTarget.
For SDK maintainers
Open your .podspec. A sample AcmePay 2.3.1 podspec gave 3 findings: the pod trunk push release path, a prepare_command, and its Alamofire dependency with the .package line for it. The first one also writes the line your users will need: .package(url: "https://github.com/acme/AcmePay.git", from: "2.3.1"), once you add a Package.swift and tag the same version.
Free and team use
The check of the open Podfile or .podspec is free, in VS Code and on the web page, with all 23 rules. A licence key adds a whole-workspace migration plan with a Package.swift dependencies block, a dated trunk exposure report and a CI gate that fails a build adding a new trunk pod.
15 seconds — what it actually does
Questions people ask
What does the Swift Package Manager migration check do?
It reads a Podfile or .podspec in VS Code and flags every dependency that still resolves from CocoaPods trunk, which turns read-only on 2026-12-02. For each pod it writes the exact Swift Package Manager line: package URL, version rule and product name. It has 23 rules and 2 inputs, the file and the date.
Who is this CocoaPods to Swift Package Manager check for?
iOS and macOS developers whose app still lists pods in a Podfile, and SDK maintainers who release a library with pod trunk push. Both lose updates on 2026-12-02 when CocoaPods trunk stops accepting new pods and new versions, so both need to know which lines to move first.
Why not ask a chatbot to convert my Podfile to Swift Package Manager?
A chatbot guesses package URLs, product names and version rules. Firebase/Analytics is the product FirebaseAnalytics inside the firebase-ios-sdk package, and a pessimistic rule like ~> 7.10.0 needs .upToNextMinor, not from. This check reads a map built from each vendor's own Package.swift and skips pods that come from :git or :path.
What is free and what does the licence key add?
Free: the open Podfile or .podspec, every trunk dependency with its line and the Swift Package Manager line that replaces it, plus the days left before trunk turns read-only. The key adds a whole-workspace migration plan with a Package.swift dependencies block, a dated trunk exposure report and a CI gate for new trunk pods.
What does a manual CocoaPods migration audit cost compared with this?
By hand, someone opens every vendor repository, reads its Package.swift for the URL and product name and translates each ~> rule. The free check does this for one file at no cost. The workspace plan, exposure report and CI gate are 29 dollars once for one licence key, per person or team seat.
When does CocoaPods trunk change next?
The CocoaPods blog plan lists a test run on 2026-11-01 to 11-07 and a permanent switch on 2026-12-02, after which trunk accepts no new podspecs. Existing builds keep working. The author says the dates are not set in stone and could move later but not earlier. Source: blog.cocoapods.org/CocoaPods-Specs-Repo.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.