Mobil Ekipte Teknik Borç: Ölçme, Önceliklendirme, Ödeme

Mobil ekipte teknik borç yönetimi, "sonra düzeltiriz" dediğiniz her kısayolun faturasını kesen görünmez bir bütçedir. Bir View Controller'a eklenen beşinci sorumluluk, atlanmış bir test, ya da güncellenmeyen bir bağımlılık tek başına zararsız görünür; ama birikince build süresi uzar, crash-free oran düşer ve yeni bir özellik eklemek haftalar sürmeye başlar. Bu yazı, teknik borcu duygudan çıkarıp ölçülebilir, önceliklendirilebilir ve sürüm planına gömülebilir bir disipline çevirmenin yolunu gösteriyor.

💡 Pro Tip: Teknik borcu "temizlik" olarak değil, "faiz ödemesi" olarak sun — yöneticinin bütçe dilinde konuştuğun an, borç ödeme zamanı bulmak çok daha kolaylaşır.

İçindekiler

• Mobilde teknik borcun dört tipi ve gecikmeli faturası
• Kod borcu
• Test borcu
• Mimari borcu
• Altyapı ve araç borcu
• Ölçüm: build süresi, crash-free oran, değişim maliyeti, test kapsamı
• Build süresi
• Crash-free oran ve ANR benzeri donmalar
• Değişim maliyeti
• Test kapsamı
• Borcu iş etkisine çevirme dili
• Önceliklendirme matrisi: risk × sıklık ÷ maliyet
• Sürüm planına borç kotası koymak
• Büyük refactor yerine kademeli sıkıştırma
• Strangler pattern mobilde
• Boy Scout kuralı, otomatikleştirilmiş
• Üç aylık borç denetimi şablonu
• Android ve iOS platform sinyalleri borcu nasıl açığa çıkarır
• SSS
• Teknik borç nasıl ölçülür?
• Refactor için yöneticiden nasıl zaman alınır?
• Hangi borç önce ödenmeli?
• Büyük bir refactor'a ne zaman ihtiyaç var, ne zaman kademeli sıkıştırma yeter?
• Borç kaydını nerede tutmalıyım?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Mobilde teknik borcun dört tipi ve gecikmeli faturası

Teknik borç tek bir şey değil; mobil ekiplerde dört farklı yüzü var ve her biri farklı bir şekilde fatura keser.

Kod borcu

Force unwrap zincirleri, kopyala-yapıştır view'lar, tek dosyada 2.000 satırlık view controller — kısa vadede hızlı, orta vadede her değişikliği riskli hale getirir.

Test borcu

Kritik akışları (ödeme, giriş, senkronizasyon) kapsamayan test paketi, her refactor'ı bir kumara çevirir. iOS'ta Test-Driven Development (TDD) rehberinde bu borcun nasıl biriktiği ve nasıl geri ödendiği anlatılıyor.

Mimari borcu

Katmanlar birbirine sızdığında (network kodu view'da, business logic ViewModel dışında) her yeni özellik eskisinden daha yavaş biter. Modular iOS Architecture ve Swift Package Manager ve iOS Design Patterns: Pratik Örneklerle 15 Tasarım Deseni bu borcu önlemenin somut desenlerini gösteriyor.

Altyapı ve araç borcu

Eski Xcode sürümüne kilitlenmiş bir CI, elle yürütülen dağıtım adımları, güncellenmeyen bağımlılıklar — bunlar günlük işi yavaşlatmaz ama platform bir zorunluluk getirdiğinde (yeni SDK, yeni API seviyesi) aniden en pahalı borca dönüşür.

Aşağıdaki tablo dört tipi, tipik belirtisini ve gecikirse ödenecek faturayı karşılaştırıyor:

Gecikmeli fatura burada kilit kelime: borcun kendisi anında acı vermez, acıyı biriktirip başka bir güne erteler — genellikle en kötü zamanda, bir platform zorunluluğuyla aynı ana denk gelerek.

Ölçüm: build süresi, crash-free oran, değişim maliyeti, test kapsamı

Teknik borcu yönetmenin ilk adımı onu görünür kılmak. Dört metrik, borcun nerede biriktiğini gösteren en pratik göstergelerdir.

Build süresi

Temiz build ve incremental build sürelerini CI'da her sürümde kaydet. Xcode'da hızlı bir başlangıç noktası:

1xcodebuild clean build \
2  -scheme "MyApp" \
3  -destination "generic/platform=iOS" \
4  -resultBundlePath build-result.xcresult \
5  | xcpretty

Sonuçları haftalık bir tabloya işlediğinde build süresindeki yavaş büyüme (haftada birkaç saniye) aylar içinde fark edilir bir borca dönüşür.

Crash-free oran ve ANR benzeri donmalar

Android tarafında Google, "core vitals" eşiklerini resmi olarak tanımlıyor: genel kullanıcı tabanında %1,09 kullanıcı-algılı çökme oranı ve %0,47 ANR oranı "kötü davranış" eşiği sayılıyor; tek bir cihaz modeline özgü ölçümde ise bu eşik %8'e çıkıyor. Ölçüm, Google Play'in uygulama kalitesini değerlendirirken genel olarak son 28 günlük veriyi baz aldığı bir pencerede yapılıyor. Bu eşikleri kendi crash-free hedefin için referans al; iOS tarafında da benzer bir hedefi (örneğin crash-free oturum ≥ %99,5) sürüm kriterine bağla.

Değişim maliyeti

Bir özelliğin ortalama teslim süresini (PR açılıştan merge'e) izlemek, mimari borcun günlük işi ne kadar yavaşlattığının dolaylı ama güvenilir bir göstergesidir.

Test kapsamı

Yüzde kapsama sayısı tek başına yanıltıcıdır (getter/setter'ı test edip kritik akışı boş bırakabilirsin). Bunun yerine kritik akış listesi çıkar (giriş, ödeme, senkronizasyon, veri kaybı senaryoları) ve her birinin en az bir uçtan uca testi olup olmadığını işaretle. iOS'ta Test-Driven Development (TDD) yazısında kritik akış odaklı test stratejisi detaylandırılıyor.

Toplu bir kod tabanı için endüstri çapında kullanılan bir başka referans, SonarQube'ün teknik borç oranı modelidir: borç oranı, remediation maliyetinin kod tabanını sıfırdan geliştirme maliyetine bölünmesiyle hesaplanır (geliştirme maliyeti, satır sayısı × varsayılan 30 dakika/satır sabitiyle bulunur). SonarQube'ün varsayılan bakım-yapılabilirlik ölçeğinde %5 ve altı "A", %20-50 aralığı "D" notuna denk düşüyor; bu oranın tek bir kod tabanı içinde zaman içindeki trendi, farklı projeler arasında yapılan ham kıyaslamadan çok daha anlamlı.

Borcu iş etkisine çevirme dili

Bir mühendisin "bu kod çok kirli" cümlesi, bir ürün yöneticisinin veya yöneticinin bütçe kararı vermesi için yeterli değil. İşe yarayan yaklaşım, teknik borcu inanca dayalı bir talepten ("bize %20 zaman ayırın") kanıta dayalı bir çerçeveye taşımak: borcu aylık biriken bir "vergi" olarak göster ve bu verginin ne zaman durdurulacağını, ödemenin kaç ayda kendini amorti edeceğini net şekilde ifade et.

Bunun için üç cümlelik bir kalıp kullanabilirsin: "Şu an X modülünde her değişiklik Y kadar sürüyor, çünkü Z borcu birikmiş. Z'yi ödemek N sprint sürer, ödemezsek her sprint bu yavaşlık büyüyerek devam eder. Ödeme penceresini şu sprinte koyarsak kayıp bugün durur." Bu kalıp, borcu bir "istek" olmaktan çıkarıp bir "risk azaltma kararı"na çevirir — ben genelde bu cümleyi sprint planlamasına, ekstra bir toplantı açmadan, doğrudan taşımayı tercih ederim.

Sprint kapasitesinin küçük ama sabit bir payını borç ödemesine ayırmak, ara sıra açılan "kahramanlık" temizlik sprintlerinden daha sürdürülebilir bir yaklaşımdır; çünkü borç sabit bir kadansla ödendiğinde birikme hızını asla yakalayamayacağı bir noktaya ulaşmıyor.

Önceliklendirme matrisi: risk × sıklık ÷ maliyet

Her borç kalemini aynı anda ödeyemezsin; üç eksenli basit bir puanlama, hangi kalemin önce ödeneceğine karar vermeni kolaylaştırır. Her eksene 1-3 arası puan ver:

• Risk: Bu borç patladığında kullanıcıya ne kadar zarar verir? (1 = kozmetik, 3 = veri kaybı/ödeme hatası)
• Sıklık: Bu kod yolu ne sıklıkla değişiyor veya çalışıyor? (1 = nadiren dokunulan modül, 3 = her sürümde değişen çekirdek akış)
• Maliyet: Ödemek ne kadar sürer? (1 = birkaç saat, 3 = çok sprintlik refactor)

Puanı risk × sıklık ÷ maliyet formülüyle hesapla; skoru yüksek olan kalem, düşük maliyetle yüksek risk azaltan kalemdir, sırayı bu belirler.

Bu basit hesap, "hangisi acil" sorusunu duygudan çıkarıp sıradan bir sprint planlama girdisine çevirir; skoru en yüksek üç kalem bir sonraki borç ödeme penceresine girer.

Sürüm planına borç kotası koymak

Borcu bir kerelik "temizlik sprinti" olarak ele almak yerine, her sürüm döngüsüne sabit bir kota koymak daha sürdürülebilir. Pratikte bu, her sprint planlamasında şu üç soruyu sormak demektir:

1. Bu sprintte kapasitenin ne kadarı borç ödemesine ayrıldı?
2. Ödenen kalem, önceliklendirme matrisinde en yüksek skorlu kalem miydi?
3. Kota bu sprint atlandıysa, bir sonraki sprintte telafi edildi mi?

Kotayı görünür tutmak için basit bir borç kaydı tutmak işe yarar; her kalemi kod tabanında bir JSON/YAML dosyasında veya proje yönetim aracında izlenebilir tutabilirsin:

1{
2  "id": "DEBT-014",
3  "module": "PaymentFlow",
4  "type": "kod-borcu",
5  "risk": 3,
6  "frequency": 3,
7  "cost": 1,
8  "score": 9.0,
9  "owner": "ios-team",
10  "openedAt": "2025-02-10",
11  "status": "planlandi"
12}

Bu kayıt, hem sprint planlamasında referans hem de üç aylık denetimde "ne kadarını ödedik" sorusunun cevabı olur.

Büyük refactor yerine kademeli sıkıştırma

"Her şeyi yeniden yazalım" cümlesi mobil ekiplerde en pahalı tuzaklardan biri: büyük refactor'lar genellikle özellik teslimatını aylarca durdurur ve yarıda kalma riski taşır. Bunun yerine borcu küçük, güvenli adımlarla "sıkıştırmak" — her PR'da az miktarda borcu, mevcut özellik çalışmasının yanına ekleyerek ödemek — çok daha az risklidir.

Strangler pattern mobilde

Web dünyasından ödünç alınan "strangler fig" yaklaşımı mobilde de işler: eski ve riskli bir modülü tek seferde silmek yerine, yeni bir arayüzün arkasına alıp trafiği (veya çağrıları) yavaş yavaş yeni implementasyona kaydırırsın. Basit bir Swift örneği:

1protocol SyncEngine {
2    func sync() async throws
3}
4 
5// Eski implementasyon canlıda kalırken yeni implementasyon arkada test edilir
6struct LegacySyncEngine: SyncEngine {
7    func sync() async throws { /* eski kod */ }
8}
9 
10struct ModernSyncEngine: SyncEngine {
11    func sync() async throws { /* yeni, test kapsamı yüksek kod */ }
12}
13 
14final class SyncEngineRouter: SyncEngine {
15    private let useModern: () -> Bool
16    private let legacy = LegacySyncEngine()
17    private let modern = ModernSyncEngine()
18 
19    init(useModern: @escaping () -> Bool) {
20        self.useModern = useModern
21    }
22 
23    func sync() async throws {
24        if useModern() {
25            try await modern.sync()
26        } else {
27            try await legacy.sync()
28        }
29    }
30}

Bir feature flag ile trafiği kademeli artırmak, riski tek bir "büyük patlama" yerine ölçülebilir küçük parçalara böler.

Boy Scout kuralı, otomatikleştirilmiş

"Bir dosyaya dokunduğunda onu bulduğundan biraz daha temiz bırak" kuralı, CI'da bir uyarı adımına bağlandığında daha tutarlı çalışır. Örnek bir GitHub Actions adımı, değişen dosyalarda yeni force-unwrap eklenmesini işaretler:

1- name: Force-unwrap uyarısı
2  run: |
3    git diff --name-only origin/main...HEAD -- '*.swift' | while read -r file; do
4      if [ -f "$file" ]; then
5        NEW_UNWRAPS=$(git diff origin/main...HEAD -- "$file" | grep -c '^+.*[A-Za-z0-9]!\s' || true)
6        if [ "$NEW_UNWRAPS" -gt 0 ]; then
7          echo "::warning file=$file::$NEW_UNWRAPS yeni force-unwrap eklendi"
8        fi
9      fi
10    done

Bu tür küçük, otomatik uyarılar borcun büyüme hızını yavaşlatır; her PR'ı sıfırdan mükemmel yapmaya çalışmaktan çok daha sürdürülebilir bir yaklaşımdır.

Üç aylık borç denetimi şablonu

Kademeli ödeme günlük işi kapsıyor, ama borcun bütününü görmek için üç ayda bir ayrı bir denetim turu gerekiyor. Aşağıdaki şablon dört adımdan oluşuyor:

• Envanter çıkar: Açık borç kayıtlarını (DEBT-XXX) modül bazında topla, skorla.
• Metrikleri karşılaştır: Build süresi, crash-free oran ve ortalama teslim süresini bir önceki denetimle kıyasla; kötüleşen metrik varsa nedenini borç kaydına bağla.
• Kotayı gözden geçir: Sprint kapasitesinin ayrılan payı yeterli mi, yoksa borç birikme hızı ödeme hızını mı geçti?
• Yönetime rapor et: Bu denetimin çıktısını, "borcu iş etkisine çevirme dili" bölümündeki kalıpla birlikte kısa bir özet olarak paylaş — sayısal trend + bir sonraki çeyrek için kota önerisi.

Bu dört adım, teknik borcu bir kerelik proje değil, sürekli izlenen bir operasyonel gösterge haline getirir; iOS App Launch Optimizasyonu yazısındaki ölçüm disiplini de aynı mantığı başlatma süresi özelinde uyguluyor.

Android ve iOS platform sinyalleri borcu nasıl açığa çıkarır

Platformların kendi kalite eşikleri, teknik borcu görmezden gelmeyi giderek zorlaştırıyor; bu sinyalleri borç denetiminin bir girdisi olarak kullanmak değerli.

Apple App Store Review Guidelines'ın 2.5.1 maddesi, uygulamaların yalnızca genel kullanıma açık (public) API'leri kullanmasını ve o an yayında olan işletim sistemi sürümünde çalışmasını şart koşuyor; bu, "özel API kısayoluyla borç öteleme" stratejisini kapatan bir kural. UIWebView gibi kaldırılmış API'ler App Store Connect yüklemesinde 2020'den beri ITMS-90809 koduyla reddediliyor; bu, deprecated API borcunu App Review öncesinde somut bir engel haline getiriyor.

Aynı rehberin 4.2 Minimum Functionality maddesi ise uygulamanın "elevate it beyond a repackaged website" (bir web sitesinin yeniden paketlenmesinin ötesine geçmesi) gerektiğini vurguluyor — yani asgari fonksiyonellik ve gerçek platform entegrasyonu, App Review'dan geçmenin ön koşulu. Bu iki madde, mimari borcunu "sonra düzeltirim" diyerek ertelemiş bir ekip için doğrudan yayın riskine dönüşebilir.

Android tarafında ise crash-free ve ANR eşiklerinin (%1,09 / %0,47 genel, %8 cihaz-özel, 28 günlük pencere) mağaza görünürlüğünü etkileyebilmesi, test ve gözlemlenebilirlik borcunu bir "iyi olsa güzel olur" değil, dolaysız bir iş riski haline getiriyor. Bu eşikleri üç aylık denetimin metrik karşılaştırma adımına doğrudan referans olarak koymak, borç konuşmasını soyut bir kod kalitesi tartışmasından somut bir mağaza-uygunluk tartışmasına taşır.

SSS

Teknik borç nasıl ölçülür?

Tek bir sayı yerine dört göstergeyi birlikte izle: build süresi (temiz ve incremental), crash-free/ANR oranı, ortalama özellik teslim süresi ve kritik akışların test kapsamı. Bu dördü haftalık veya sprint bazında kaydettiğinde, borcun büyüme yönünü ve hızını görebilirsin; tek seferlik bir "kod kalitesi puanı" bu trendi yakalayamaz.

Refactor için yöneticiden nasıl zaman alınır?

Süre değil, kayıp diliyle konuş: borcun şu an ne kadar zaman çaldığını ve ödenmezse bu kaybın nasıl büyüyeceğini göster. Önceliklendirme matrisindeki skoru kanıt olarak kullan ve sprint kapasitesinden sabit bir pay iste — tek seferlik büyük bir onay yerine, sürekli küçük bir bütçe kalemi olarak sun.

Hangi borç önce ödenmeli?

Risk × sıklık ÷ maliyet skoruna göre sırala. Sık çalışan ve yüksek riskli bir akıştaki düşük maliyetli bir düzeltme (örneğin ödeme akışındaki bir force-unwrap), nadiren dokunulan bir ekrandaki büyük bir mimari refactor'dan neredeyse her zaman önce gelir.

Büyük bir refactor'a ne zaman ihtiyaç var, ne zaman kademeli sıkıştırma yeter?

Kademeli sıkıştırma çoğu durumda yeterlidir çünkü riski küçük parçalara böler. Büyük bir refactor'ı ancak modülün mimarisi kademeli değişikliğe izin vermeyecek kadar sıkı bağlıysa (örneğin katmanlar tamamen iç içe geçmişse) ve strangler pattern gibi bir ara katman bile eklemek mevcut yapıda mümkün değilse düşün; aksi halde önce ara katmanı ekleyip kademeli geçişi dene.

Borç kaydını nerede tutmalıyım?

Kod tabanına yakın bir yerde tut — bir JSON/YAML dosyası, ya da ekibin zaten kullandığı proje yönetim aracı. Önemli olan araç değil, her kalemin risk/sıklık/maliyet skoruyla birlikte kayıtlı olması ve üç aylık denetimde kolayca filtrelenebilmesi.

Güncelleme (Eylül 2026)

Bu makale 2025-04-09 tarihindeki araç ve politika koşullarıyla yazıldı; aradan geçen sürede platform tarafında borcu görmezden gelmeyi zorlaştıran somut değişiklikler oldu.

Google Play, 31 Ağustos 2026 itibarıyla yeni uygulama ve güncellemelerin Android 16 (API 36) hedeflemesini, mevcut uygulamaların en az Android 15 (API 35) hedeflemesini şart koştu; uzatma talep eden geliştiriciler 1 Kasım 2026'ya kadar erteleyebiliyor.

Bu eşiği karşılamayan uygulamalar, cihaz OS sürümü hedef seviyeden daha yeni olan kullanıcılara mağazada keşfedilemez hale geliyor — yani hedef API seviyesini erteleme, artık sessizce biriken bir borç değil, doğrudan kullanıcı erişimini kesen bir risk. Google ayrıca 26 Ağustos 2026'da duyurduğu Play Console "teknik kalite gereksinimleri" ile Şubat 2027'den itibaren yeni "kötü davranış" ve optimizasyon eşiklerini, Nisan 2027'den itibaren de "Zero-Tap Sign-In" gerekliliğini (Android Restore Credentials API ile oturum durumunun yeni cihazda otomatik geri yüklenmesi) zorunlu kılacağını açıkladı; bu, borç ödemesi için somut bir takvim koyuyor.

Ölçüm tarafında Android vitals, Ağustos 2026'da bellek metrikleriyle genişledi: dinamik bellek kullanımı (anonymous RSS + swap) ve bitmap bellek kullanımı artık persentil ve RAM-bucket kırılımıyla izlenebiliyor, OS'un bellek baskısıyla uygulamayı sonlandırdığı çökmeler için ayrı bir filtre eklendi — bu, daha önce "ölçülemeyen borç" kategorisinde kalan bir alana somut bir gösterge kazandırdı.

Apple tarafında 28 Nisan 2026'dan itibaren App Store Connect'e yüklenen her yeni gönderim ve güncellemenin iOS 26 / iPadOS 26 / tvOS 26 / visionOS 26 / watchOS 26 SDK'sı ile derlenmiş olması zorunlu tutuldu; bu, eski SDK'yla borç biriktirip erteleme stratejisini fiilen kapattı.

Araç zinciri tarafında SDK zorunluluğu 28 Nisan 2026'da yürürlüğe girdi; @unchecked Sendable gibi kaçış kapılarını ben ayrı bir borç kalemi olarak kaydetmeni öneririm. Kotlin tarafında da Kotlin 2.3.0'dan itibaren org.jetbrains.kotlin.android Gradle eklentisi AGP 9.0.0+ ile birlikte kullanıldığında konfigürasyon hatası veriyor (eklenti artık gereksiz, AGP Kotlin desteğini yerleşik sağlıyor) ve Kotlin 2.4.0 (Temmuz 2026) bazı deprecation uyarılarını hataya çevirdi — bir sonraki AGP/Kotlin sürümüne geçiş artık deprecated kullanımların önceden temizlenmesini zorunlu kılıyor.

Ölçüm çerçevesinde, DX'in 18 Mart 2026 tarihli DORA araçları incelemesine göre DORA metrikleri yüzeyde iyileşirken kalite altta bozulabiliyor: lead time kısalırken kod bakım yapılabilirliği (maintainability) kötüleşebiliyor; bu nedenle DORA'yı borç denetiminin yerine değil, tamamlayıcısı olarak kullan.

Sonuç

Teknik borç, mobil ekiplerde kaçınılması gereken bir hata değil, yönetilmesi gereken bir bütçe kalemidir. Dört göstergeyle (build süresi, crash-free oran, değişim maliyeti, test kapsamı) ölçüp risk×sıklık÷maliyet matrisiyle önceliklendirdiğinde, borç konuşması duygudan çıkıp somut bir karara dönüşür. Sürüm planına sabit bir kota koymak ve büyük refactor'lar yerine kademeli sıkıştırmayı tercih etmek, borcun asla yakalanamayacak bir hıza ulaşmasını önler; üç aylık denetim ise bu disiplinin sürdüğünü doğrular.

Mimari borcu kaynağında azaltmak istiyorsan Modular iOS Architecture ve Swift Package Manager ve iOS Design Patterns: Pratik Örneklerle 15 Tasarım Deseni yazılarına bak; test borcunu kapatmak için iOS'ta Test-Driven Development (TDD) rehberi; altyapı borcunu otomatik CI uyarılarıyla görünür kılmak için iOS CI/CD Pipeline Kurulumu yazısı; başlatma süresindeki borcu görünür kılmak için de iOS App Launch Optimizasyonu rehberi bu makaledeki ölçüm disiplinini tamamlıyor.

Kaynaklar

• Android vitals — Google Play Console yardım merkezi — crash-free ve ANR core vitals eşiklerini, 28 günlük ölçüm penceresini tanımlayan resmi kaynak.
• Apple App Store Review Guidelines — 2.5.1 (public API/güncel OS şartı) ve 4.2 Minimum Functionality maddelerinin birincil kaynağı.
• Apple — Upcoming requirements — 28 Nisan 2026 Xcode 26 / iOS 26 SDK zorunluluğunun birincil kaynağı.
• Google Play hedef API seviyesi zorunluluğu — resmi duyuru — 31 Ağustos 2026 eşiğinin ve mağaza keşfedilebilirliği etkisinin birincil kaynağı.
• Play Console teknik kalite gereksinimleri duyurusu — Şubat/Nisan 2027 eşiklerinin duyurusu.
• Android vitals'a bellek metrikleri eklendi — Ağustos 2026 duyurusu, resmi Android geliştirici blogu.
• SonarQube Technical Debt / SQALE Rating dokümantasyonu — borç oranı ve nota dair birincil kaynak.
• DORA metrikleri 2026: ne ölçülüyor, ne eksik (DX) — DORA metrikleri yüzeyde iyileşirken kalitenin (maintainability) altta bozulabileceğine dair DX'in 18 Mart 2026 tarihli analizi.
• Kotlin 2.3.0 sürüm notları — org.jetbrains.kotlin.android eklentisinin AGP 9.0.0+ ile konfigürasyon hatası vermesi.
• Kotlin 2.4.0 sürüm notları — sürüm tarihi ve yenilikler.
• Kotlin 2.4.0 uyumluluk kılavuzu — bazı uyarıların hataya çevrildiği değişiklikler.
• Apple Developer Forums — ITMS-90809 — kaldırılmış API'ler için App Store Connect ret kodu.