Flutter'da CocoaPods'a Veda: SwiftPM Geçiş Rehberi

Flutter ekibi 12 Ağustos 2026'da yayınladığı 3.47 duyurusunda çarpıcı bir rakam paylaştı: en popüler 100 iOS plugin'inin 92'si artık Swift Package Manager'a (SwiftPM) geçmiş durumda. Bu sayı Nisan 2026'da yüzde 61'di — yani birkaç ay içinde ekosistem CocoaPods'tan hızla uzaklaşıyor. Eğer hâlâ Podfile ile boğuşuyorsan ya da bir plugin bakımcısıysan, bu rehber sana hem uygulama hem plugin tarafında ne yapman gerektiğini, kaynaklı ve adım adım anlatıyor.

💡 Pro Tip: SwiftPM geçişini test etmeden önce flutter clean çalıştır ve ios/Pods/, ios/.symlinks/ dizinlerini elle sil — eski CocoaPods artefaktları yeni Xcode proje yapılandırmasıyla çakışıp yanıltıcı build hataları üretebiliyor.

İçindekiler

• Neden Şimdi: CocoaPods Bakım Modunda, Plugin Ekosistemi Göç Etti
• flutter config --enable-swift-package-manager ile Açmak
• Geçişin Gerçekten Uygulandığını Nasıl Doğrularsın
• Uygulama Tarafında Neyin Değiştiği: Podfile, Workspace, CI
• CI Pipeline'ında Geçiş Dönemi Yapılandırması
• Plugin Bakımcısıysan: Package.swift ve Resmi Göç Rehberi
• Karma Durum: Hem CocoaPods Hem SwiftPM Bağımlılığı Olan Proje
• pub.dev Puanı ve Ekosistem Baskısı
• Build Süresi Kazancı: Scheme Filtreleme Optimizasyonu
• Geri Dönüş Planı ve Bilinen Sorunlar
• SSS
• Flutter'da SwiftPM nasıl açılır?
• CocoaPods Flutter'da ne zaman kaldırılacak?
• Flutter plugin'imi SwiftPM'e nasıl taşırım?
• CI'da pod install adımını ne zaman kaldırabilirim?
• SwiftPM'e geçmeyen plugin'ler çalışmayı durduracak mı?
• Sonuç
• Kaynaklar

Neden Şimdi: CocoaPods Bakım Modunda, Plugin Ekosistemi Göç Etti

Flutter ekibi, iOS/macOS tarafında SwiftPM'i Flutter 3.44 ile varsayılan bağımlılık yöneticisi yaptı. Bu tercih tesadüfi değil: CocoaPods, kendi resmi blog yazısında paket kayıt sunucusu trunk'ın 2 Aralık 2026'da kalıcı olarak salt-okunur hale geleceğini duyurdu — yani bu tarihten sonra yeni bir podspec yayınlanamayacak (test denemesi 1-7 Kasım 2026'da yapılacak). Flutter'ın 30 Nisan 2026 tarihli duyurusu durumu tek cümlede özetliyor: "CocoaPods is officially in maintenance mode" — pratik sonucu şu: trunk'a yeni katkı kapanıyor, mevcut build'ler çalışmaya devam ediyor.

Sayılar da bu yönü destekliyor:

Flutter'ın 12 Ağustos 2026 tarihli 3.47 duyurusundaki ifade birebir şöyle: "plugins that do not migrate to SwiftPM will eventually stop working" (göç etmeyenler eninde sonunda çalışmayı bırakacak); bu arada pub.dev puanlaması da düşük tutuluyor — yani hem teknik hem ekosistem baskısı aynı yöne işaret ediyor. Ayrıca React Native de 11 Ağustos 2026'da yayınlanan 0.87 sürümüyle iOS için deneysel SwiftPM desteği ekledi; bu, tek bir framework'ün tercihi değil, çapraz-platform ekosisteminin genel yönelimi olduğunu gösteriyor.

flutter config --enable-swift-package-manager ile Açmak

Flutter 3.44'ten beri SwiftPM zaten varsayılan olarak açık. Eğer projede daha önce bilinçli olarak kapatıldıysa (opt-out edildiyse), tek satırlık bir komutla yeniden deneyebilirsin:

1flutter config --enable-swift-package-manager
2flutter clean
3flutter run

Flutter CLI, flutter run veya flutter build ios çalıştırdığında Xcode projesini otomatik olarak SwiftPM kullanacak şekilde günceller — elle .xcodeproj düzenlemesi gerekmiyor. Bu davranış hem 30 Nisan 2026 tarihli "Saying Goodbye to CocoaPods" yazısında hem de app geliştirici dokümanında birebir doğrulanmış durumda: "When you run or build your iOS or macOS app, the CLI automatically updates your Xcode project to use Swift Package Manager." (CLI, uygulamanı çalıştırdığında ya da derlediğinde Xcode projeni otomatik günceller.)

Eğer projendeki bağımlılıklardan biri bile henüz SwiftPM desteklemiyorsa, Flutter otomatik olarak CocoaPods'a geri düşer (fallback) ve hangi bağımlılıkların desteklenmediğini konsola uyarı olarak basar. Bu, "hepsi ya da hiçbiri" değil, kademeli bir geçiş modeli.

Geçişin Gerçekten Uygulandığını Nasıl Doğrularsın

Resmi dokümanın kanonik doğrulama yöntemi şu: Xcode'da uygulamayı çalıştır ve iki kanıtı ara — build günlüğünde Run Prepare Flutter Framework Script adımının bir pre-action olarak koştuğunu ve FlutterGeneratedPluginSwiftPackage paketinin hedefin bağımlılıkları arasında yer aldığını gör. İkincil bir ipucu olarak ios/Runner.xcworkspace dosyasını açıp sol paneldeki proje gezgininde "Package Dependencies" bölümüne bakabilirsin — SwiftPM ile çözülen bağımlılıklar burada listelenir. Desteklenmeyen bir bağımlılık varsa Flutter'ın bastığı uyarı satırını dikkatle oku — hangi paketin sorumlu olduğu orada belirtiliyor; o paketi güncelleyene ya da alternatifini bulana kadar CocoaPods fallback'i devrede kalır.

Uygulama Tarafında Neyin Değiştiği: Podfile, Workspace, CI

SwiftPM'e geçiş, ios/ dizinindeki dosya yapısını değiştiriyor. CocoaPods'u tamamen kaldırmak istiyorsan resmi rehber şu adımları öneriyor:

1cd ios
2pod deintegrate
3cd ..
4rm -f ios/Podfile ios/Podfile.lock
5rm -rf ios/Pods/ ios/.symlinks/
6# ios/Flutter/Debug.xcconfig ve ios/Flutter/Release.xcconfig dosyalarında
7# "Pods/Target Support Files" referanslı #include satırları kaldıysa sil
8flutter clean
9flutter pub get
10flutter run

Bu adımlar workspace'in artık CocoaPods referansı taşımamasını sağlıyor. CI tarafında değişen en önemli şey: pod install adımını pipeline'dan çıkarabilirsin (bağımlılıklar SwiftPM tarafından Xcode build sürecinin bir parçası olarak çözülüyor), ama karma bir proje kullanıyorsan (bazı bağımlılıklar hâlâ CocoaPods'ta) bu adımı korumalısın — aşağıdaki "karma durum" bölümüne bak.

Dikkat: bu temizlik adımını yalnızca tüm bağımlılıkların SwiftPM desteklediğini doğruladıktan sonra uygula. Aksi halde flutter build ios CocoaPods'a fallback yapamayacağı için build kırılır.

CI Pipeline'ında Geçiş Dönemi Yapılandırması

Karma dönemde CI adımlarını değiştirmek yerine, koşullu bir yapı kurmak daha güvenli. Aşağıdaki gibi bir GitHub Actions adımı, Podfile dosyası hâlâ varsa pod install çalıştırır, yoksa doğrudan SwiftPM'in çözümlemesine bırakır:

1- name: iOS bağımlılıklarını çöz
2  run: |
3    cd ios
4    if [ -f Podfile ]; then
5      pod install --repo-update
6    fi
7    cd ..
8    flutter build ios --release --no-codesign

Bu yaklaşım, ekibindeki farklı geliştiricilerin farklı geçiş aşamalarında olduğu dönemlerde pipeline'ı kırmadan ilerlemeni sağlar.

Plugin Bakımcısıysan: Package.swift ve Resmi Göç Rehberi

Eğer pub.dev'de bir Flutter plugin yayınlıyorsan, önce Flutter 3.44 veya üzerini kullandığından emin ol — SwiftPM'in varsayılan olarak açık olduğu sürüm bu. Ardından ios/ (ya da macos/, darwin/) altında plugin adıyla bir dizin açıp ios/plugin_name/Package.swift ile ios/plugin_name/Sources/plugin_name/ yapısını kurman, ios/Classes içindeki kaynakları da buraya taşıman gerekiyor. Resmi plugin yazarı dokümanının şablonu şöyle (TODO yorumları sadeleştirildi):

1// swift-tools-version: 5.9
2import PackageDescription
3 
4let package = Package(
5    name: "plugin_name",
6    platforms: [
7        .iOS("13.0"),
8        .macOS("10.15")
9    ],
10    products: [
11        // Plugin adı "_" içeriyorsa library adında "-" kullan.
12        .library(name: "plugin-name", targets: ["plugin_name"])
13    ],
14    dependencies: [
15        .package(name: "FlutterFramework", path: "../FlutterFramework")
16    ],
17    targets: [
18        .target(
19            name: "plugin_name",
20            dependencies: [
21                .product(name: "FlutterFramework", package: "FlutterFramework")
22            ],
23            resources: [
24                // PrivacyInfo.xcprivacy gerekiyorsa bu satırı aç:
25                // .process("PrivacyInfo.xcprivacy"),
26            ]
27        )
28    ]
29)

Şablondaki .iOS("13.0") ve .macOS("10.15") değerleri plugin yazarı dokümanında hâlâ böyle veriliyor; buna karşılık Flutter 3.47 duyurusu Flutter'ın kendi minimum desteklenen sürümlerini iOS 13'ten 15'e, macOS 10.15'ten 12'ye yükseltti. Plugin'in hedef kitlesine göre bu değerleri yükseltmen gerekebilir.

Eğer plugin'ini 2025 pilot döneminde zaten SwiftPM'e taşıdıysan, tamamlaman gereken yeni bir adım var: Package.swift dosyana FlutterFramework'ü bağımlılık olarak eklemen gerekiyor. Bu zorunluluk 30 Nisan 2026 tarihli duyuruda birebir şöyle geçiyor: "If you already migrated your plugin during the 2025 pilot, you need to complete one new step: you must add FlutterFramework as a dependency in your Package.swift file."

Flutter ekibi şu an için plugin'lerin "further notice"a (yeni bir duyuruya) kadar hem CocoaPods hem SwiftPM'i desteklemesini istiyor — yani tam CocoaPods terki henüz zorunlu değil, ama yönü net.

Bağımlılık bir sürüm kısıtıyla değil, yerel bir path ile tanımlanıyor. Resmi dokümanın "Add the FlutterFramework as a dependency" adımı tam olarak şu iki girdiyi ekletiyor — paket düzeyinde dependencies ve hedefin kendi dependencies alanında ürün referansı:

1dependencies: [
2    .package(name: "FlutterFramework", path: "../FlutterFramework")
3],
4targets: [
5    .target(
6        name: "plugin_name",
7        dependencies: [
8            .product(name: "FlutterFramework", package: "FlutterFramework")
9        ]
10    )
11]

Karma Durum: Hem CocoaPods Hem SwiftPM Bağımlılığı Olan Proje

Çoğu gerçek proje şu anda tam bir geçişte değil, karma bir durumda. Resmi doküman bunu açıkça desteklenen bir ara hâl olarak tanımlıyor: proje bağımlılıklarından biri bile SwiftPM desteklemiyorsa Flutter otomatik olarak CocoaPods'a geri düşüyor. Yani Podfile'ını silmek için tüm bağımlılıklarının göç etmiş olmasını beklemen gerekiyor.

Ters yönde bir kısıtlama da var: Flutter 3.44 itibarıyla, CocoaPods desteklemeyen (yalnızca SwiftPM ile yayınlanan) plugin'ler, henüz SwiftPM'e geçmemiş projelerde kullanılamıyor. Bu, iki yönlü bir baskı yaratıyor — hem app geliştiricisini hem plugin yazarını aynı anda geçişe itiyor.

Pratikte bu şu anlama geliyor: flutter pub deps ile bağımlılık ağacını gözden geçir, flutter run ya da flutter build ios çıktısındaki desteklenmeyen bağımlılık uyarı listesini oku, sonra CI'da hem pod install hem SwiftPM resolve adımını bir süre paralel tut. Tüm bağımlılıklar yeşile döndüğünde CocoaPods'u kaldır.

Aşağıdaki tablo, farklı bağımlılık senaryolarında Flutter'ın resmi dokümanda tarif edilen davranışını özetliyor:

Bağımlılık ağacını hızlıca listeleyip hangi paketlerin gözden geçirilmesi gerektiğini görmek için standart Dart komutunu kullanabilirsin:

1flutter pub deps --style=compact

Ama hangi bağımlılığın seni CocoaPods'a bağladığını netleştirmenin kesin yolu bu liste değil, Flutter'ın kendi uyarısı: 30 Nisan 2026 tarihli duyurunun ifadesiyle, SwiftPM'i benimsememiş plugin'lere dayanan bir uygulamada "Flutter will print a warning listing exactly which of your dependencies are unsupported." İkincil bir kontrol olarak plugin'in deposunda Package.swift dosyasının bulunup bulunmadığına bakabilirsin.

pub.dev Puanı ve Ekosistem Baskısı

SwiftPM göçünü sadece teknik bir tercih olarak görme — pub.dev tarafında doğrudan ekonomik baskı da var. Flutter ekibinin 30 Nisan 2026 tarihli duyurusunda belirttiği gibi, SwiftPM desteği olmayan paketler artık göç edene kadar daha düşük pub.dev skoru alıyor. Bu politika 12 Ağustos 2026 tarihli 3.47 duyurusunda da tekrar teyit edildi — yani geçici bir kural değil, sürekli uygulanan bir politika.

Bir plugin bakımcısı için bu, doğrudan bir görünürlük meselesi: SwiftPM desteklemeyen iOS/macOS plugin'leri pub points'in "platform desteği / modern toolchain" kaleminden tam puan alamıyor ve bu skor hem arama sonuçlarında hem paket sayfasında görünüyor. Kullanıcı tarafında da bu aynı zamanda bir sinyal: bir plugin'i seçerken pub.dev skoru düşükse, SwiftPM desteğinin olup olmadığını kontrol etmek makul bir ilk adım.

Ben genelde yeni bir bağımlılık eklemeden önce pub.dev sayfasındaki skor detayını açıp puanın hangi bileşenden düştüğüne bakmayı tercih ediyorum: düşük puanın kaynağı SwiftPM göçü mü, başka bir kalite sorunu mu — bu ayrımı bağımlılığı projene almadan önce yapmak, sonradan iki paket yöneticisi arasında sıkışan bir bağımlılıkla uğraşmanın önüne geçer.

Build Süresi Kazancı: Scheme Filtreleme Optimizasyonu

3.47 sürümüyle birlikte gelen bir başka iyileştirme doğrudan build performansını hedefliyor. Flutter ekibi, build pipeline'ını gereksiz SwiftPM paket scheme'lerini süreç başlarken erken filtreleyecek şekilde optimize etti — bu değişiklik topluluk katkısıyla geldi (GitHub PR #186006). Sonuç, duyurunun ifadesiyle "optimized build times" — daha kısa Xcode build süreleri; kaynakta bir ölçüm verilmiyor.

Bu tür scheme-seviyesi optimizasyonlar SwiftPM'in CocoaPods'a göre bir diğer avantajını gösteriyor: paket çözümleme Xcode'un kendi build sistemine entegre olduğu için, ayrı bir "pod install" adımı ve onun getirdiği ek IO/ağ maliyeti ortadan kalkıyor. Büyük bir monorepo'da veya çok sayıda plugin kullanan bir projede bu fark CI süresinde gözle görülür olabilir.

Geri Dönüş Planı ve Bilinen Sorunlar

SwiftPM geçişi sorun çıkarırsa panik yapmana gerek yok — geçici bir devre dışı bırakma yolu resmi olarak destekleniyor. pubspec.yaml dosyanda config bloğu altına şunu ekleyebilirsin:

1flutter:
2  config:
3    enable-swift-package-manager: false

Bu bayrağı false yaptığında proje bir önceki CocoaPods tabanlı akışa döner. Flutter ekibi, bu şekilde opt-out eden geliştiricilerden resmi GitHub issue şablonunu kullanarak hata bildirmelerini istiyor — bildirimde hata detaylarını, kullandığın plugin listesini ve versiyonlarını, mümkünse Xcode proje dosyalarını paylaşman bekleniyor. Bu, ekip tarafından bilinen sorunları toplamak için resmi olarak tanımlanmış bir süreç.

Pratik öneri: geri dönüşü "son çare" olarak düşün. Geçici olarak devre dışı bırakıp hatayı bildirdikten sonra, kaynak plugin güncellenene kadar bekle; kalıcı olarak CocoaPods'ta kalmak, 2 Aralık 2026'daki trunk kapanmasından sonra giderek daha kırılgan bir pozisyon olacak.

SSS

Flutter'da SwiftPM nasıl açılır?

Flutter 3.44'ten itibaren SwiftPM zaten varsayılan olarak açık. Daha önce bilinçli olarak kapattıysan, terminalde flutter config --enable-swift-package-manager komutunu çalıştırıp ardından flutter run veya flutter build ios demen yeterli — Flutter CLI Xcode projeni otomatik olarak günceller.

CocoaPods Flutter'da ne zaman kaldırılacak?

Flutter'da CocoaPods tamamen kaldırılmış değil; SwiftPM desteklemeyen bağımlılıklar için hâlâ otomatik fallback olarak çalışıyor. Ancak CocoaPods'un kendi trunk (paket kayıt) sunucusu 2 Aralık 2026'da kalıcı olarak salt-okunur hale gelecek — bu tarihten sonra yeni pod versiyonu yayınlanamayacak, mevcut build'ler çalışmaya devam edecek. Öncesinde 1-7 Kasım 2026'da bir test denemesi planlanıyor.

Flutter plugin'imi SwiftPM'e nasıl taşırım?

ios/ (ya da macos/, darwin/) altında plugin adıyla bir dizin açıp ios/plugin_name/Package.swift ile ios/plugin_name/Sources/plugin_name/ yapısını kurman, kaynakları ios/Classes altından buraya taşıman gerekiyor. 2025 pilot döneminde zaten göç ettiysen, ek olarak Package.swift dosyana FlutterFramework'ü bağımlılık olarak eklemen yeni bir zorunluluk. Detaylı adımlar için resmi plugin yazarı rehberine bakabilirsin.

CI'da pod install adımını ne zaman kaldırabilirim?

Projendeki tüm plugin'ler SwiftPM destekler hâle geldiğinde. Resmi app geliştirici dokümanı bunu açık bir ön koşula bağlıyor: CocoaPods'u kaldırmadan önce projendeki tüm plugin'lerin Swift Package Manager desteklediğinden emin ol. Tek bir bağımlılık bile desteklemiyorsa Flutter CocoaPods'a geri düşer; pod install adımını erken silersen bu fallback çalışamaz ve CI build'in kırılır.

SwiftPM'e geçmeyen plugin'ler çalışmayı durduracak mı?

Flutter'ın kendi ifadesiyle evet — göç etmeyen plugin'ler eninde sonunda çalışmayı bırakacak; bu arada pub.dev skor puanlaması da düşük tutuluyor. Şu an için CocoaPods'a fallback hâlâ çalışıyor ama bu kalıcı bir çözüm olarak sunulmuyor.

Sonuç

SwiftPM'e geçiş artık bir tercih değil, Flutter ekosisteminin genel yönü. CocoaPods'un trunk sunucusunun 2 Aralık 2026'da kalıcı salt-okunur hale gelecek olması, en popüler 100 plugin'in %92'sinin zaten göç etmiş olması ve pub.dev'in düşük skorla göç etmeyenleri cezalandırması aynı sinyali veriyor: erken taşınan projeler daha az sürtünmeyle geçiyor. flutter config --enable-swift-package-manager ile başlayıp Package.swift dosyanı doğru kurarak ilerlemen, hem app hem plugin tarafında en güvenli yol.

Flutter 3.47'nin getirdiği diğer değişiklikler için Flutter 3.47: material_ui ve cupertino_ui Paketlerine Geçiş yazısına göz atabilirsin. iOS entegrasyonu tarafında native modüllerle çalışıyorsan Flutter ile iOS Entegrasyonu: Platform Channel ve Native Modüller faydalı olacaktır. SwiftPM'in modüler mimarideki yerini native iOS tarafında görmek istersen Modular iOS Architecture ve Swift Package Manager yazısı iyi bir tamamlayıcı. Build performansını genel olarak iyileştirmek istiyorsan Flutter Performans Optimizasyonu: 60fps Garanti Rehberi yazısını, iOS 27 tarafında başka bir zorunlu geçiş için de Flutter'da UIScene Zorunluluğu: iOS 27 Migrasyonu yazısını öneririm.

Kaynaklar

• What's new in Flutter 3.47 — 92/100 plugin göçü, minimum iOS/macOS sürüm yükseltmesi, build scheme filtreleme optimizasyonu (12 Ağustos 2026).
• Saying Goodbye to CocoaPods: Swift Package Manager Is Soon the Default in Flutter — %61 göç oranı, "maintenance mode" ifadesi, FlutterFramework yeni bağımlılık zorunluluğu, desteklenmeyen bağımlılık uyarısı, otomatik Xcode güncellemesi, pubspec.yaml geri dönüş bayrağı (30 Nisan 2026).
• Swift Package Manager for app developers — flutter config komutu, pod deintegrate temizlik adımları, karma durum fallback davranışı.
• Swift Package Manager for plugin authors — Package.swift şablonu, FlutterFramework bağımlılık adımı, CocoaPods doğrulama lint'i, CocoaPods+SwiftPM birlikte destek zorunluluğu.
• CocoaPods Specs Repo Sunset Announcement — trunk'ın 2 Aralık 2026'da salt-okunur olacağı, 1-7 Kasım 2026 test penceresi.
• React Native 0.87 — iOS için deneysel SwiftPM desteği, çapraz-platform ekosistem yönelimi (11 Ağustos 2026).