Eski iOS Uygulamalarını Modernize Etmek: SwiftUI, Swift Concurrency ve Observation'a Kademeli Geçiş

Modernizasyonu tetikleyen şey çoğu zaman bir mimari heves değil, takvimdir. Apple, Nisan 2027'den itibaren App Store Connect'e yüklenen uygulamaların 27 SDK ile derlenmesini şart koşuyor. iOS 27 SDK ile derlendiğinde sistem UIDesignRequiresCompatibility anahtarını yok sayıyor; yani Liquid Glass'tan geri çekilme seçeneği kalmıyor. Bu, özel çizilmiş navigation bar ve tab bar'ları olan eski UIKit ekranlarının bir anda görsel regresyon üretmesi demek. İkinci kapı UIScene: Apple'ın TN3187 teknik notuna göre iOS 26'dan sonraki ilk büyük sürümde, en güncel SDK ile derlenen ve scene tabanlı yaşam döngüsüne geçmemiş uygulama açılmıyor. Hâlâ yalnızca UIApplicationDelegate ile yaşayan eski projeler için bu, takvimdeki en somut iş kalemi.

Sahada sık gördüğüm tablo şu: projede yüzlerce derleyici uyarısı birikmiş, kimse bakmıyor, Swift 6 moduna geçiş denemesi ilk gün Sendable hatalarıyla rafa kalkıyor. Pratik bir eşik koymak işe yarıyor: önce uyarı sayısını sıfıra indirmeyi hedefleyen bir sprint, sonra her yeni Pull Request için “yeni uyarı yok” kuralı. Modernizasyonun ilk ölçülebilir çıktısı yeni bir ekran değil, CI'da kırmızıya dönen bir uyarı bütçesidir.

Son 12 ayda iOS modernizasyonu bir tercih olmaktan çıkıp takvime bağlandı. 28 Nisan 2026'dan beri App Store Connect'e yüklenen uygulamalar Xcode 26 ve iOS 26 SDK ile derlenmek zorunda; 9 Eylül 2026'dan beri minimum deployment target da iOS 13. iOS 27, Xcode 27 ve Swift 6.4, 14-15 Eylül 2026'da yayımlandı ve Apple 27 SDK ile gönderimleri açtı; Nisan 2027'de 27 SDK zorunlu hâle gelecek. Xcode 27 yalnızca Apple silicon Mac'lerde ve macOS Tahoe 26.6 üzerinde çalışıyor, cihazda hata ayıklama için en az iOS 17 istiyor. iOS 27 SDK ile derlenen uygulamalarda iki kaçış kapısı kapandı: Liquid Glass uyumluluk anahtarı yok sayılıyor ve UIScene'e geçmemiş uygulama açılmıyor. Dil tarafında Swift 6.3 (Mart 2026) Swift Testing'e test iptali ve görüntü ekleri getirdi; Swift 6.4 ise defer içinde await, withTaskCancellationShield ve SwiftPM'de varsayılan Swift Build ile geldi. WWDC26'da SwiftUI'da State bir makroya dönüştü. Xcode 27 hâlâ Swift 6, 5, 4.2 ve 4 dil modlarını destekliyor; yani Swift 6 moduna geçiş zorunlu değil, ama Approachable Concurrency ile UI modüllerinde varsayılan MainActor izolasyonu önerilen başlangıç noktası olmaya devam ediyor.

Büyük patlama tarzı yeniden yazım (big-bang rewrite) iOS'ta neredeyse her zaman takvimi kaçırır. Daha güvenli yol strangler fig yaklaşımı: eski uygulamanın kabuğu UIKit olarak kalır, yeni ve değişen ekranlar SwiftUI ile yazılıp UIHostingController içinde gösterilir. Tersi de mümkün: SwiftUI ekranın içinde hâlâ gereken bir UIKit bileşenini UIViewRepresentable ile sarabilirsiniz.

Hangi ekrandan başlanacağı için basit bir puanlama kullanılabilir: değişim sıklığı yüksek, iş mantığı az, özel animasyonu olmayan ekranlar önce. Ayarlar, profil, onboarding gibi formlar ideal adaylar. Ödeme akışı, karmaşık koleksiyon görünümleri ve klavye etkileşimi ağır ekranlar sona kalmalı.

Anti-pattern: SwiftUI ekranını yazıp içine eski view controller'ın 1.500 satırlık mantığını olduğu gibi kopyalamak. Görünüm katmanı değişir ama test edilemezlik aynen taşınır. Geçişten önce mantığı ayrı bir model tipine çıkarmak, geçişin asıl kazancıdır.

Swift Concurrency'ye geçişte en ucuz kazanç, ağ ve veri katmanındaki completion handler'ları async fonksiyonlara çevirmek. Mevcut callback tabanlı API'leri bir anda silmek gerekmiyor; withCheckedThrowingContinuation ile async bir sarmalayıcı yazıp çağıranları kademeli taşıyabilirsiniz. Combine zincirlerinin büyük kısmı da AsyncSequence ve basit async döngülerle daha okunur hâle gelir.

Dikkat edilmesi gereken iki tuzak var. Birincisi, continuation'ı iki kez resume etmek ya da hiç etmemek; checked varyant bunu çalışma zamanında yakalar, bu yüzden geçiş döneminde unsafe varyanta inmeyin. İkincisi, Task { } ile her yere yapılandırılmamış görev saçmak. Bir view kapandığında iptal edilmeyen görevler, eski delegate sızıntılarının yeni hâlidir. SwiftUI'da .task değiştiricisi görevi view yaşam döngüsüne bağlar ve iptali otomatik yapar. Swift 6.4 burada iki pratik araç ekledi: defer bloğu içinde await kullanılabiliyor (SE-0493) ve withTaskCancellationShield, iptal edilmiş bir görevde bile temizlik ya da geri alma kodunun tamamlanmasını sağlıyor (SE-0504). Eskiden ayrı bir Task içine sarılan async temizlik kodu artık doğrudan yazılabiliyor.

Ölçü olarak, bir modülde kalan completion handler sayısını grep ile sayıp sprint başına düşüşünü izlemek yeterince somut bir metrik.

Swift 6 dil modu, Swift 5'te uyarı olan veri yarışı kontrollerini derleme hatasına çevirir. Eski projelerde bu, Sendable olmayan tiplerin aktörler arasında geçtiği yüzlerce satır demek. Swift 6.2 ile gelen Approachable Concurrency bu yükü azaltmak için birkaç ayarı bir araya getiriyor: SE-0466 ile modül genelinde varsayılan izolasyonu MainActor yapabiliyorsunuz, SE-0461 (NonisolatedNonsendingByDefault) ile nonisolated async fonksiyonlar çağıranın aktöründe çalışıyor, SE-0470 ile izole protokol uyumları çıkarsanıyor. Xcode 26 ile açılan yeni projelerde bunlar varsayılan geliyor; Swift paketlerinde ise Package.swift içinde .defaultIsolation(MainActor.self) ile açılıyor.

Uygulama hedefleri için mantıklı strateji: UI ağırlıklı modüllerde MainActor varsayılanını açmak, gerçekten paralel iş yapan kodu @concurrent ile açıkça işaretlemek. Geçişi modül modül yapın: önce uyarı düzeyinde complete checking, sıfır uyarı, sonra Swift 6 modu. @unchecked Sendable ve nonisolated(unsafe) birer kaçış kapısıdır; her kullanımı bir yorum ve bir takip kaydıyla gelmeli.

iOS 17 ile gelen Observation çerçevesi, @Observable makrosuyla ObservableObject ve @Published ikilisinin yerini alıyor. Fark yalnızca sözdizimsel değil: eski modelde bir @Published özelliği değiştiğinde ona abone olan tüm view'lar yeniden değerlendirilir; @Observable ise view'ın gövdede gerçekten okuduğu özellikleri takip eder. Büyük bir ayarlar modeli olan ekranlarda gereksiz yeniden çizimlerin ciddi kısmı bu şekilde kaybolur.

Geçişte eşleme basit: @StateObject yerine @State, @ObservedObject yerine düz özellik ya da @Bindable, @EnvironmentObject yerine tip tabanlı @Environment. iOS 26 ile UIKit de bu işe katıldı: updateProperties() ve viewWillLayoutSubviews() içinde okunan @Observable özellikleri otomatik takip ediliyor, değiştiklerinde view güncelleniyor. iOS 18'de aynı davranış Info.plist'e UIObservationTrackingEnabled anahtarı eklenerek açılabiliyor.

WWDC26 ile SwiftUI'da State bir makroya dönüştü: @State içinde tutulan sınıflar artık view ömrü başına bir kez ve tembel olarak başlatılıyor. Bunun bir bedeli de var; Xcode 27 ile @State özelliğine bildirim yerinde değer atayan bazı initializer'lar artık derlenmiyor, bu yüzden SwiftUI ekranlarını yeni SDK'ya taşırken ilk derleme hatası listesine hazırlıklı olun.

Anti-pattern: @Observable sınıfı içinde hesaplanan, pahalı bir özelliği her body çağrısında okumak. Takip doğru çalışır ama maliyet view'a taşınır.

Modernizasyonun en büyük riski, kullanıcıya görünmeyen davranış değişiklikleridir: bir async çevirisinden sonra iki istek artık paralel gidiyor, MainActor varsayılanından sonra bir ağır iş ana iş parçacığına kayıyor. Bunu yakalamanın yolu geçişten önce bir referans çizgisi almak. Üç metrik genelde yeterli: soğuk açılış süresi, kilit ekranların ilk çizim süresi ve crash-free session oranı. Hedef koyarken somut olun; örneğin “geçiş boyunca crash-free session oranı yüzde 99,8'in altına inmeyecek”.

Test tarafında Swift Testing, paralel ve parametreli testleri kolaylaştırıyor; async kodu test etmek için XCTest'teki expectation dansına gerek kalmıyor. Swift 6.3 ile uyarı düzeyinde sorun bildirme, test iptali ve görüntü ekleri geldi; başarısız bir UI testine ekran görüntüsü iliştirmek artık çerçevenin kendi işi. SwiftUI ekranları için snapshot testleri, Liquid Glass gibi otomatik görsel değişikliklerde regresyonu yakalamanın en ucuz yolu.

Her geçiş adımı bir feature flag arkasında, sunucudan kapatılabilir olmalı. Yeni SwiftUI ekranında sorun çıkarsa eski UIKit ekranına dönmek bir yapılandırma değişikliği kadar ucuz olmalı.