Bir iOS Uygulamasını Geleceğe Hazırlamak: Modularization, Build Performance ve Developer Experience

Tek hedefli bir iOS projesinde her değişiklik derleyicinin büyük bir kod kümesini yeniden değerlendirmesine yol açar, herkes her tipe erişebilir ve bir ekranı tek başına çalıştırmak neredeyse imkânsızdır. Modülerleştirme bu üç sorunu birlikte çözer: değişiklik yalnızca etkilenen modülleri yeniden derletir, erişim kontrolüyle sınırlar zorlanır ve her modül kendi demo uygulamasıyla izole geliştirilebilir.

Apple'ın kendi derleme rehberi de aynı şeyi söylüyor: monolitik hedefler Xcode'u görevleri sıraya dizmeye zorlar, hedefleri bölmek paralelliği artırır ama karmaşıklık da ekler, bu yüzden her değişiklikten sonra ölçmek gerekir.

Ama modülerleştirme bedava değildir. Her yeni modül ek proje yapılandırması, bağımlılık yönetimi ve link süresi getirir. Pratik eşikler: projede 4-5'ten fazla geliştirici aynı anda çalışıyorsa, artımlı derleme 30-60 saniyeyi aşıyorsa ya da birleştirme çakışmalarının çoğu .pbxproj dosyasında çıkıyorsa, modülerleştirmenin zamanı gelmiştir.

Anti-pattern: bir sabah 40 modüle bölmeye karar vermek. Daha güvenli yol, önce en az bağımlılığı olan katmanları ayırmak: tasarım sistemi, ağ istemcisi, analytics. Ardından feature'lar birer birer bu çekirdek modüllerin üzerine taşınır.

Son 12 ayda iOS derleme zinciri üç yönde değişti. Birincisi araç tabanı: Xcode 27, 14 Eylül 2026'da yayımlandı; yalnızca Apple silicon Mac'lerde ve macOS Tahoe 26.6 üzerinde çalışıyor, ld64 bağlayıcısı kaldırıldı ve -ld_classic artık yok sayılıyor. Swift 6.4, SwiftPM'de Swift Build'i varsayılan derleme sistemi yaptı; Swift 6.3 ise prebuilt swift-syntax desteğiyle macro kullanan projelerin temiz derleme maliyetini azaltmıştı. İkincisi önbellek: Tuist'in Ekim 2025'te Xcode 26.0.1 ile yaptığı ölçümlerde compilation cache projeye göre yüzde 18 ile 77 arasında hızlanma sağladı (2025 verisi); Tuist Eylül 2026'da Xcode, Bazel ve Gradle derlemelerine hizmet eden Kura adlı dağıtık önbelleği duyurdu. Toss'un yaklaşık bin modüllü iOS kod tabanında binary cache ile bir dakikanın altında biten yerel derlemelerin payı üç katından fazla arttı. Üçüncüsü Agent'lar: Xcode 27'de Agent'lar plan modu, paralel sub-agent'lar ve Device Hub ile kendi işini derleyip test ederek doğruluyor; Apple Xcode 27'nin yüzde 30 daha küçük olduğunu söylüyor. Bu, Build Time'ı bir konfor konusu olmaktan çıkarıp Agent döngüsünün temposu hâline getirdi.

Sağlıklı bir modül grafiği katmanlıdır ve bağımlılıklar tek yöne akar. Yaygın bir yapı: en altta Foundation benzeri yardımcılar ve tasarım sistemi gibi core modüller, ortada feature modülleri, en üstte hepsini birleştiren uygulama hedefi. Feature'ların birbirine doğrudan bağımlı olması, grafiği hızla bir örümcek ağına çevirir.

Bunu önlemenin yolu interface modülleri. ProfileInterface yalnızca protokolleri ve modelleri içerir, Profile modülü ise uygulamayı. Diğer feature'lar yalnızca ProfileInterface'e bağımlı olur; Profile'ın içi değiştiğinde onlar yeniden derlenmez. Bağımlılıkları uygulama hedefinde birleştiren basit bir dependency injection kurgusu bu yapıyı tamamlar.

Tuist'in önerdiği mikro-feature mimarisi bu fikri sistematik hâle getiriyor: her feature için Interface, kaynak, Testing (sahte uygulamalar), Tests ve Example hedefleri. Somut kazanç, Example hedefiyle tek bir ekranı tüm uygulamayı derlemeden saniyeler içinde çalıştırabilmek. Bir kural koyun: feature modülü başka bir feature'ın uygulama modülünü import ediyorsa CI kırılmalı.

Modüller nasıl tanımlanacak? Üç yaygın yol var. Birincisi Xcode projesinde elle hedef açmak; küçük projelerde çalışır ama .pbxproj dosyası büyüdükçe birleştirme çatışmaları günlük derde dönüşür. İkincisi yerel Swift paketleri: her modül Package.swift ile tanımlanır, metin tabanlı olduğu için incelemesi kolaydır ve Apple'ın resmî aracıdır. Üçüncüsü Tuist gibi proje üreticileri: projeyi Swift ile yazılmış bir manifestten üretir, .pbxproj'u repo'dan çıkarır ve modül tanımlarını şablonlaştırır.

Swift 6.4 ile SwiftPM'nin varsayılan derleme sistemi Xcode'un da kullandığı açık kaynak Swift Build oldu; komut satırı ile Xcode arasındaki davranış farkları azalıyor. Yine de SPM'nin zayıf yanları büyük projelerde belirginleşiyor: paket çözümleme süresi, kaynak dosyaların ve build ayarlarının sınırlı esnekliği, Xcode'un çok sayıda yerel paketi açarken yavaşlaması. Tuist'in güçlü yanı ise derleme önbelleği, ortak ayarları tek yerde toplama ve modül grafiğini doğrulama.

Karar ölçütü basit tutulabilir: 10'dan az modül ve tek ekip için yerel SPM paketleri yeterli. Onlarca modül, birden fazla ekip ve CI süresi baskısı varsa proje üreticisinin getirdiği önbellek ve tutarlılık yatırımı karşılar.

Xcode 26 iki önemli değişiklik getirdi. Birincisi, Swift hedefleri artık varsayılan olarak explicit modules ile derleniyor: modül bağımlılıkları derleme öncesinde tarandığı için derleme sistemi işleri daha iyi paralelleştirip tekrar kullanabiliyor. İkincisi, isteğe bağlı compilation caching: COMPILATION_CACHE_ENABLE_CACHING ayarıyla açılan bu önbellek, derleme çıktılarını dosya yoluna değil içerik özetine göre saklıyor. Dal değiştirmek ya da temiz derleme yapmak, daha önce derlenmiş içeriği yeniden kullanabiliyor.

Tuist, bu önbelleği ekip ve CI genelinde paylaşan uzak bir servis sundu. Tuist'in Ekim 2025'te Xcode 26.0.1 ile yayınladığı karşılaştırmalarda (2025 verisi) yerel önbellek projeye göre yüzde 19 ile yüzde 77 arasında hızlanma sağladı; Tuist ile üretilmiş Mastodon projesinde uzak önbellek yüzde 69'a ulaştı, Wikipedia'da ise yüzde 18'de kaldı. Aynı yazı, derleme grafiğinin hesaplanması gibi bazı işlerin henüz önbelleklenemediğini de belirtiyor.

Buna ek olarak, Swift macro kullanan projelerde swift-syntax'ın her temiz derlemede baştan derlenmesi ciddi süre ekliyordu; Swift 6.3 ile gelen prebuilt swift-syntax desteği bu maliyeti azaltıyor. En büyük kazanç ise hiç derlememekten geliyor: yaklaşık bin modüllü bir kod tabanında, geliştiricinin dokunmadığı modülleri önceden derlenmiş XCFramework'lerden çeken bir binary cache, bir dakikanın altında biten yerel derlemelerin payını üç katından fazla artırdı.

Derleme süresini iyileştirmenin ilk adımı onu bir metrik gibi izlemek. Üç sayı yeterli bir başlangıç: temiz derleme süresi, tipik bir değişiklik sonrası artımlı derleme süresi ve CI'daki toplam pipeline süresi. Bunları her gün aynı makinede, aynı komutla ölçüp bir panoda göstermek, “derleme yavaşladı” şikâyetini somut bir regresyon grafiğine çevirir.

Product > Perform Action > Build With Timing Summary ya da xcodebuild -showBuildTimingSummary, her görevin süresini verir. Xcode'un Build Timeline görünümü hangi hedeflerin kritik yolda olduğunu, hangilerinin paralel çalışamadığını gösterir. Uzun süren tekil fonksiyonları bulmak için -warn-long-function-bodies=200 ve -warn-long-expression-type-checking=200 bayrakları, tip denetimi 200 milisaniyeyi aşan yerleri uyarı olarak işaretler. Genelde suçlu, tipi belirtilmemiş uzun zincirli ifadeler ya da çok büyük SwiftUI body'leridir.

Anti-pattern: modülerleştirmeyi tamamlayıp ölçmeden “artık daha hızlı” varsaymak. Çok sayıda küçük dinamik framework, link ve uygulama açılış süresini uzatabilir. Xcode 27'de ld64 tamamen kaldırıldığı için eski bağlayıcıya dayanan geçici çözümler de artık işe yaramıyor; link süresini yeni bağlayıcıyla yeniden ölçün. Statik ve dinamik bağlama kararını ölçümle verin.

Geliştirici deneyimi (DX) soyut bir memnuniyet konusu değil, geri bildirim döngüsünün uzunluğu. Bir değişikliği yapıp sonucunu ekranda görmek 10 saniye mi, 2 dakika mı sürüyor? Bu süre günde onlarca kez tekrarlandığında, kişi başına saatlere ulaşır. Example uygulamaları, SwiftUI önizlemeleri ve hızlı birim testleri bu döngüyü kısaltan en etkili araçlar.

Bu konunun 2026'daki yeni boyutu AI Agent'ları. Xcode 27'de Agent'lar plan modunda yaklaşım öneriyor, paralel sub-agent'larla keşif yapıyor ve test yazıp çalıştırarak, önizlemeleri kontrol ederek, Device Hub'daki simülatörle etkileşerek kendi işlerini doğruluyor; plug-in'lerle özel skill'ler, MCP tool'ları ve ACP uyumlu Agent'lar eklenebiliyor. Her doğrulama turu bir derleme demek. 3 dakikalık artımlı derleme, ajanın saatte yapabileceği deneme sayısını ciddi biçimde sınırlar; modüler bir proje ise ajana tek bir modülü derleyip test etme imkânı verir.

Pratik öneri: her modülün kendi test hedefini tek komutla koşabildiğinden emin olun ve bu komutları ajanın okuyacağı proje talimat dosyasına yazın. İnsan için iyi DX, ajan için de iyi DX'tir.