iOS’ta state management için tartışmaların merkezi. Pointfree’nin çıkardığı TCA (The Composable Architecture) iOS topluluğunda popüler. Elm’den ilham almış, Redux benzeri unidirectional data flow, güçlü test edilebilirlik sunuyor.
12 iOS uygulamamda MVVM kullandıktan sonra küçük bir projede TCA denedim. Sonuç: TCA harika bir araç ama her proje için uygun değil. Bu yazıda seçim kriterlerini anlatacağım.
MVVM’in güçlü yanları
SwiftUI’da MVVM’in doğal gelmesi. @State, @Observable, @Environment zaten Apple’ın önerdiği pattern’lere yaslanıyor.
1. Düşük öğrenme eğrisi. MVVM’i bilmeyen iOS geliştirici yok denecek kadar az. Yeni ekip üyesi 1-2 günde productive oluyor.
2. Minimum boilerplate. ViewModel bir class, View’a binding. Bu kadar. TCA’da Store, Reducer, Action, State, Environment gibi 5 farklı kavram var.
3. Apple framework’leri ile doğal uyum. SwiftUI, Combine, async/await, Observation hepsi MVVM’e native destek veriyor. TCA için bazı özel wrapper’lar gerekiyor.
4. Debug kolaylığı. ViewModel’de breakpoint’i nereye koyacağın belli. TCA’da action dispatch, reducer execution, effect processing arasında state nerede değişti izlemek daha karmaşık.
TCA’nın güçlü yanları
1. Test edilebilirlik muhteşem. TCA’nın TestStore’u gerçekten harika. Action gönderiyorsun, state’i check ediyorsun, effect’lerin çalıştığını kanıtlıyorsun. Unit test coverage %90+ üzerine çıkmak kolay.
2. Time-travel debugging. Action history’sini görüyorsun, herhangi bir state’e geri dönüp replay yapabiliyorsun. Karmaşık bug’ları reproduce etmek çok daha kolay.
3. Predictable state changes. State sadece reducer içinde değişiyor. “Bu property ne zaman bu değeri aldı” sorusunu trace etmek MVVM’e göre çok daha deterministic.
4. Feature composition. Büyük bir feature’ı küçük sub-feature’lardan birleştirmek TCA’da native. Her sub-feature kendi State, Reducer, Action’ını tanımlıyor, parent birleştiriyor.
5. Side effect yönetimi. TCA’nın Effect API’si async operasyonları declarative yönetiyor. Cancel, debounce, retry logic built-in.
Hangisi ne zaman?
MVVM seç:
- Ekibin 3 kişiden az ise
- Proje timeline’ı 3 ay altıysa
- Junior iOS geliştirici varsa (öğrenme eğrisi)
- App logic görece basitse (5’ten az karmaşık feature)
- SwiftUI dışında UIKit kullanıyorsan
- Fast prototype / MVP sürecindeysen
TCA seç:
- 5+ geliştirici var, ortak pattern’de anlaşmak kritik
- Uzun ömürlü enterprise app (3+ yıl yaşayacak)
- Feature’lar birbirine nested (dashboard → sub-dashboard → widget → setting)
- Test coverage ≥%80 hedefi var
- Time-travel debugging gereksinimi var
- Ekibin functional programming konforu var
TCA’ya geçme kararı için ipuçları
Eğer mevcut bir MVVM projesi var ve TCA’ya geçmeyi düşünüyorsan:
Geçme:
– Ekip hâlâ MVVM’de takılmıyor, feature velocity iyi
– Refactor yapmak için ayrılacak 3-6 ay yok
– Test coverage zaten %70+
Kısmen geç:
– 1-2 karmaşık feature’ı TCA ile yaz
– Geri kalan MVVM kalsın
– Coexistence mümkün ama complexity ekliyor
Tamamen geç:
– Major version’da yeni yazım (v2.0)
– Ekip TCA training’e hazır
– 3-6 ay pure refactor kabul edilebilir
TCA’nın sık gözlemlenen problemi
TCA community’sinde “ideal TCA usage” konusunda bile fikir ayrılıkları var. “Hangi reducer’lar compose edilmeli, hangi değil”, “Environment’a ne koyulmalı”, “Effect’ler nasıl organize edilmeli” tartışmaları sürekli.
Bu esneklik bazen belirsizlik oluyor. Yeni başlayan ekip için MVVM’deki “ViewModel yaz, binding kur” netliği daha pratik olabilir.
Boilerplate sayıları
Küçük bir login feature’ı:
MVVM: ~150 satır kod
– View: 50 satır
– ViewModel: 80 satır
– Model: 20 satır
TCA: ~250 satır kod
– View: 50 satır
– State: 20 satır
– Action: 15 satır
– Reducer: 70 satır
– Environment: 30 satır
– Effect’ler: 40 satır
– Store binding: 25 satır
%65 daha fazla kod. Karmaşık feature’larda oran düşüyor çünkü TCA’nın composition avantajı devreye giriyor, ama basit feature’lar için overhead ciddi.
Benim kişisel kararım
12 iOS uygulamamın hepsi MVVM. Neden? Çünkü hepsi tek-kişi-geliştirici veya 2 kişilik ekip. Timeline kısa, feature hızı önemli. TCA’nın test avantajı olsa bile, 150 LOC yerine 250 LOC yazmaya değmiyor.
Eğer 5+ kişilik bir ekibe katılsaydım ve enterprise bir app üzerinde çalışacaktım, TCA’yı ciddi olarak düşünürdüm. Ama indie developer veya küçük agency iş modeli için MVVM kazanıyor.
Sonuç
TCA güçlü bir mimari ama bütün projeler için değil. Öğrenme eğrisi yüksek, boilerplate fazla, Apple ecosystem ile bazı sürtünme noktaları var. Buna karşılık test edilebilirlik, state predictability, composition konularında ciddi avantaj sağlıyor.
Ekip büyüklüğün, proje ömrü, test coverage hedefin bu kararı belirliyor. Moda değil, gerçek ihtiyaçlarına bak.