CocoaPods Goes Read-Only on 2 December: What Flutter iOS Teams Should Check Now

On 2 December 2026, CocoaPods trunk stops accepting new podspecs, so no new pods or pod versions can be published there (CocoaPods Trunk Read-only Plan). Your existing Flutter iOS and macOS builds won't break that day. Pods that are already published keep installing. What changes is that any native SDK still shipped only as a CocoaPod stops getting updates.

Flutter has been getting ready for this. Since Flutter 3.44, Swift Package Manager (SwiftPM) has been the default dependency manager for iOS and macOS. Flutter falls back to CocoaPods only for plugins that don't ship a Package.swift yet. So the question for most teams isn't "will my app build on 3 December?" It's "which of my plugins, or the SDKs under them, are still CocoaPods-only, and what's my plan for each one?"

To answer that for real code, we checked 35 popular plugins for a Package.swift at their latest release. The results are below, after the dates and a table of what breaks, and before checklists for app teams and plugin authors.

When does CocoaPods trunk become read-only?

CocoaPods trunk becomes read-only on Wednesday, 2 December 2026. From that day it accepts no new pods and no new versions of existing pods, after a test run planned for 1 to 7 November 2026. Pods already published stay installable through the Specs repo and CDN.

The plan comes from CocoaPods maintainer Orta Therox. He published it on 30 November 2024 and updated it in May 2025 (CocoaPods blog). The full timeline:

• May 2025: new podspecs that use prepare_command are blocked.
• Mid to late 2025: podspec contributors get an email about the switch.
• September to October 2026: a second email, about a month before a test run.
• 1 to 7 November 2026: a test run, "giving automation a chance to break early".
• 2 December 2026: trunk permanently stops accepting new podspecs.

The post says the dates "are not set in stone", and that they could move later for a good reason, but not earlier. As of 11 October 2026 the date still stands. The cocoapods.org banner counts down to it ("there are 3 months to go" when we checked), and Flutter's own docs repeat 2 December 2026 (Flutter docs).

None of this came out of nowhere. In August 2024 the team said openly that CocoaPods is in maintenance mode, and that framework maintainers "will (and should) be migrating to Swift Package Manager with time" (CocoaPods Support & Maintenance Plans).

What read-only trunk breaks, and what keeps working

The short version: nothing that works today stops working on 2 December. What stops is anything new arriving through trunk.

That second-to-last row is the real cost, and some vendors have already acted on it. Firebase says it will stop publishing new versions to CocoaPods in October 2026, that Firebase 12 is the last major version published there, and that pipelines running pod install keep working for existing versions but "will not pull any new Firebase library updates released after October 2026" (Firebase: CocoaPods deprecation). Google's Maps SDK for iOS went into CocoaPods maintenance mode in August 2025, and its 11.0.0 release notes say CocoaPods is deprecated (Maps SDK for iOS release notes).

So a Flutter app that stays on CocoaPods keeps building. Its iOS Firebase and Maps SDKs, though, stop moving forward from here.

Flutter's Swift Package Manager support in 3.44 and later

The Flutter 3.44 announcement (20 May 2026) says SwiftPM "replaces CocoaPods as the default dependency manager for iOS and macOS apps". It adds that the CLI handles the migration automatically, and that "CocoaPods support will eventually be removed entirely" (What's new in Flutter 3.44). The current stable release is Flutter 3.47.7, released 8 October 2026 (Flutter release archive). The 3.47.7 tool source still ships the feature as on by default on every channel (features.dart).

Here's what that means in practice:

• Upgrading migrates you. "Upgrading Flutter and running your app automatically adds SwiftPM integration" (for app developers). The tool edits ios/Runner.xcodeproj/project.pbxproj and the Runner scheme. It adds a local package, FlutterGeneratedPluginSwiftPackage, plus a scheme pre-action called "Run Prepare Flutter Framework Script". The same goes for macos/.
• Mixed mode is automatic. The tool counts your plugins. If even one plugin lacks a Package.swift, it keeps the Podfile and runs CocoaPods for those plugins only (darwin_dependency_management.dart).
• It names the stragglers. When it falls back, the tool prints: "The following plugins do not support Swift Package Manager for ios: ... This will become an error in a future version of Flutter. Please contact the plugin maintainers to request Swift Package Manager adoption."
• It tells you when CocoaPods can go. Once every plugin is a Swift package, it says so and lists the removal steps. If your Podfile has custom logic, it tells you to migrate by hand instead.
• It needs Xcode 15 or later. On older Xcode the project stays on CocoaPods (compatibleWithSwiftPackageManager in xcode_project.dart).

You can still opt out. Use flutter config --no-enable-swift-package-manager for your user account, or add this to pubspec.yaml for everyone on the project:

flutter:
  config:
    enable-swift-package-manager: false

The docs' advice is blunt: "In general, don't do this. Remember that the CocoaPods registry becomes read-only on December 2, 2026 and disabling SwiftPM won't be allowed in the future." Opting out has a second catch. If a plugin ever ships only a Package.swift, with no podspec, the build stops with "The following plugin(s) are only compatible with Swift Package Manager" until you turn SwiftPM back on.

Add-to-app projects have their own path. Since 3.44 they use flutter build swift-package --platform ios, which needs Xcode 15 or later (add-to-app iOS setup).

If you're also handling Apple's Xcode 27 scene changes this autumn, that's a separate migration with its own checks. We covered it in Flutter UIScene migration for Xcode 27.

Which popular Flutter plugins support Swift Package Manager?

To see how much of a typical app still depends on CocoaPods, we checked the iOS code of 35 widely used Flutter plugins on 11 October 2026.

First-party and most-installed plugins (21 checked):

Longer tail (14 checked):

* No matching release tag on GitHub. Checked on the default branch (the develop branch for google_mlkit_text_recognition), whose pubspec version matched the latest pub.dev release.

What the check shows. The most-installed plugins are basically ready. Of the 20 big-name plugins with native code, 19 ship a Package.swift next to their podspec. The gaps sit in two places:

1. A deliberate holdout in a big plugin. google_maps_flutter_ios, the default iOS implementation that google_maps_flutter pulls in, "cannot support Swift Package Manager". SwiftPM can't pick a Maps SDK version based on your deployment target, and the README says Google won't release Maps SDK versions beyond 10.x through CocoaPods (google_maps_flutter_ios README). The fix is to add google_maps_flutter_ios_sdk10 (iOS 16+) or google_maps_flutter_ios_sdk9 (iOS 15+). Both shipped a Package.swift at version 2.19.0 in our check. We walk through that choice in Flutter maps in 2026.
2. The long tail. Three of the 14 smaller plugins had no Package.swift. open_filex's latest release dates from March 2025 (pub.dev), which suggests slow maintenance. flutter_tts ships a podspec for iOS and macOS but no Swift package. google_mlkit_text_recognition's podspec depends on the GoogleMLKit/TextRecognition pod, so whether it can move depends on how ML Kit itself is distributed. We didn't check that.

Our sample leans toward well-maintained packages, because popular plugins usually are. The plugins most likely to be missing a Package.swift are the small, single-maintainer ones in your own pubspec.yaml. That's why your own check matters more than our table.

Checklist for app teams before 2 December

1. Get on Flutter 3.44 or later. 3.47.7 is current. Run your iOS and macOS builds once so the tool can add SwiftPM integration, then commit the project.pbxproj and .xcscheme changes.
2. Make sure nobody turned it off. Check flutter config output on dev machines and CI for a disabled enable-swift-package-manager. Check pubspec.yaml for enable-swift-package-manager: false, and check CI for the FLUTTER_SWIFT_PACKAGE_MANAGER environment variable, which the tool also reads.
3. Get your list of CocoaPods-only plugins. Run flutter build ios --config-only (and flutter build macos --config-only if you ship macOS) on a Mac with Xcode 15 or later. Copy the "do not support Swift Package Manager" list from the output. In 3.47.7 the check runs before the config-only step exits, but it needs Xcode, so do this on a Mac or a macOS CI runner. We read this from the tool source and haven't run it ourselves.
4. Decide per plugin. For each name on the list, run flutter pub outdated to see whether a newer version already ships a Package.swift. If not, look for an alternative implementation, like the Maps SDK-specific packages. Check the plugin's issue tracker and file a request if nobody has, since that's what the warning asks you to do. If the plugin looks abandoned, plan to fork or replace it.
5. Move hand-added pods. If you edited the Podfile to add pods that aren't Flutter plugins, Flutter won't migrate them. Add their Swift package equivalents in Xcode under Package Dependencies, then remove the pod lines.
6. Remove CocoaPods once the list is empty. The tool prints the steps: pod deintegrate, delete the Podfile, Podfile.lock, Pods/ and .symlinks/, and remove the Pods/Target Support Files includes from Debug.xcconfig and Release.xcconfig. Flutter says doing this "will improve the project's build time".
7. Update CI. Runners need Xcode 15 or later, and the first SwiftPM resolve downloads packages. Flutter 3.44 added a warning for slow SwiftPM downloads and a shared SwiftPM cache (3.44 release notes), so the cache is worth keeping between CI runs. If your iOS builds run on hosted macOS runners, our notes on Flutter CI/CD with no Mac in the loop cover that setup.
8. Don't panic about release day. If you can't finish, your app still builds on 3 December with the pods it resolves today. Keep Podfile.lock committed so CI resolves exactly those versions.

Checklist for plugin authors

Flutter's guide for plugin authors is specific (for plugin authors):

• Create ios/<plugin_name>/Package.swift (or macos/ or darwin/) with sources in Sources/<plugin_name>/. Swift plugins move ios/Classes there. Objective-C plugins put public headers in Sources/<plugin_name>/include/<plugin_name>/.
• Depend on the local FlutterFramework package (path: "../FlutterFramework"). If your plugin name has underscores, use dashes in the library product name.
• Move PrivacyInfo.xcprivacy and other resources under Sources/<plugin_name>, and load them with Bundle.module (Swift) or SWIFTPM_MODULE_BUNDLE (Objective-C) inside #if SWIFT_PACKAGE.
• Turn every s.dependency in your podspec into a SwiftPM dependency. If that dependency only exists as a pod, this is where you'll get stuck, so check early.
• Keep the podspec. Update its paths to the new locations. The docs say plugins "should support both SwiftPM and CocoaPods until further notice" and that "plugins without SwiftPM support are not usable by projects that have migrated."
• Test both ways. Run flutter config --no-enable-swift-package-manager with pod lib lint, then flutter config --enable-swift-package-manager with flutter run on the example app. Migrating the example app raises its Flutter SDK floor to 3.24.

One thing the read-only switch does not do is block your plugin releases. Flutter plugins are published to pub.dev and wired in as local pods, so you can ship a Package.swift in a normal pub release after 2 December too. The pressure comes from your users' builds and from the tool's "future error", not from trunk.

Exported and AI-generated Flutter projects

A Flutter project from a template, a teammate or an AI Flutter app builder has the same ios/ folder as any other Flutter app, so all of the above applies. FlutterGo, for example, lets you export the generated Dart as a regular Flutter project. Once it's on your machine, open it with Flutter 3.44 or later, run the config-only build, and read the plugin warning before you add more native dependencies.

Sources

All accessed 11 October 2026.

• CocoaPods: Trunk Read-only Plan, Support & Maintenance Plans, cocoapods.org
• Flutter: SwiftPM for app developers, SwiftPM for plugin authors, add-to-app iOS setup, What's new in Flutter 3.44, 3.44 release notes, flutter_tools source at tag 3.47.7
• Vendors: Firebase CocoaPods deprecation, Maps SDK for iOS release notes, google_maps_flutter_ios README
• Plugin data: package repositories on GitHub at the versions listed in the tables, fetched through raw.githubusercontent.com