· kaynak dev.to (home feed)
Apple'ın iOS 27 SDK'sı UIDesignRequiresCompatibility'ı yok sayacak: Liquid Glass'tan çıkışın sonu
iOS 27 SDK ile derlenen uygulamalarda UIDesignRequiresCompatibility anahtarı yok sayılacak ve App Store kuralları Nisan 2027'den itibaren bu SDK'yı zorunlu kılacak; böylece Liquid Glass geçişleri kaçınılmaz hale gelecek.

Son kullanma tarihi olan bir çıkış kapısı
iOS 26, Liquid Glass yeniden tasarımıyla geldiğinde birçok ekip, görsel düzenlemeyi tek bir Info.plist girdisi ekleyerek erteledi: UIDesignRequiresCompatibility değerinin YES yapılması. Muhittin Camdali'nin dev.to'daki yazısında alıntıladığı Apple dokümantasyonu, bu anahtarı her zaman geçici bir çözüm olarak tanımladı — "Uygulamanızın kullanıcı arayüzünü gözden geçirirken ve inceltirken bu anahtarı geçici olarak kullanın" — ve artık kesin bir bitiş tarihi var: "iOS 27 veya sonrası için derleme yaptığınızda sistem bu anahtarı yok sayar."
Bu takvim büyük ölçüde geliştiricilerin elinde değil. Apple'ın App Store gönderim kılavuzu, Nisan 2027'den itibaren App Store Connect'e yüklenen iOS uygulamalarının iOS & iPadOS 27 SDK veya sonrasıyla derlenmiş olması gerektiğini belirtiyor. Camdali'nin de belirttiği gibi, güncel Upcoming Requirements sayfası henüz iOS 26 SDK istediği için ekiplerin önünde süre var; ancak bitiş tarihi sabit.
27 Ekim 2026'da deposuna kaydedilen ve yazı için yeniden çalıştırmadığını söylediği bir simulator karşılaştırması pratikteki etkiyi gösteriyor: Xcode 27.1 ile derlenen aynı UIKit uygulaması, anahtarla ve anahtarsız, iOS 27.0 üzerinde aynı, iOS 26.4 üzerinde ise farklı şekilde görüntüleniyor. Anahtar plist'te kaldığı sürece, tek bir binary, çalıştığı cihaza göre iki farklı tasarıma hizmet ediyor.
Camın üzerine boya yapan kod
Anahtarı silmek tek satırlık bir değişiklik; asıl iş, yeni tasarımla çatışan kodu bulmak. Apple'ın Adopting Liquid Glass kılavuzu, bar'lardaki özel arka plan ve appearance'ların "Liquid Glass'ın üzerine binebileceğini veya onu engelleyebileceğini" uyarıyor. Yeniden tasarımdan önceki bir UIKit uygulamasında Camdali'nin örneği bilinen şüphelileri gösteriyor: opak arka plana, marka arka plan rengine ve temizlenmiş bir gölgeye sahip bir UINavigationBarAppearance; opak ve saydam olmayan bir UITabBarAppearance; ve bir UIToolbar barTintColor. Bunların hiçbiri yanlış değil — eski bir tasarım için verilmiş bir marka kararı — ancak çıkış kapısı yok sayıldığında, sistemin artık kendisinin çizmek istediği bir malzemenin üzerinde duruyorlar.
Daha sinsi tuzak, sabit bar geometrisi varsayan yerleşim hesaplamaları; örneğin bir paneli alttaki safe area'nın 49 point yukarısına sabitlemek — klasik tab bar'ın yüksekliği. Önerilen çözüm, bir bar yüksekliği eklemek yerine safeAreaLayoutGuide'a göre kısıtlamak, yerleşim için tab bar'ın frame'ini okumamak ve ekranı tab bar küçültülmüşken test etmek.
Geiş için bir tarayıcı
Camdali ayrıca glassready'nin yazarı; GitHub'da yayımlanan, MIT lisanslı, açık kaynak bu CLI, native iOS, Flutter ve React Native/Expo projelerini okuyarak hem çıkış anahtarını hem de özel stillendirmenin yeni tasarımla çatıştığı noktaları listeliyor. Tamamen statik: hiçbir şey derlemiyor, çalıştırmıyor veya değiştirmiyor. Onun UIKit fixture'ında glassready 0.1.3, yok sayılan çıkış anahtarı için bir hata; opak bar appearance'ları ile eski renk ve saydamlık ayarlarını kapsayan dört uyarı; ve iki bilgilendirici bulgu raporladı: Liquid Glass karşılığı olmayan bir blur katmanı ile sabit yükseklikli safe area hesaplaması.
Her bulgu bir çözümle geliyor. Opak appearance'lar kaldırılmalı veya if #available(iOS 26.0, *) arkasına alınmalı, marka renkleri tintColor'a taşınmalı. Eski barTintColor ve isTranslucent atamaları aynı muameleyi görüyor. Yüzen panellerin arkasındaki blur katmanları iOS 26 ve sonrasında UIGlassEffect'e geçmeli, eski blur yedek olarak kalmalı.
Platformlar arası projeler de kapsanıyor. React Native'de anahtar iOS Info.plist içinde yer alıyor; Expo'da app.json içinde ios.infoPlist altında ayarlanabiliyor. React Native 0.88.1 fixture'ında araç, headerStyle.backgroundColor ile boyanan native bir stack header ve JavaScript'te çizilen bir alt tab bar işaretledi — kural verilerine göre, çevresindeki native header ve sheet'ler cama dönerken bu tab bar iOS 27 SDK altında kendi görünümünü koruyor. Flutter'da kurallar, Flutter'ın kendisinin çizdiği Cupertino bar'ları ve Flutter widget'larının yanına yerleştirilmiş UiKitView platform view'larını işaretliyor.
Bilinen sınırlamalar
Araç kodu derlemek yerine desen eşleştirmesi yapıyor: kuralları kaynak metin üzerinde düzenli ifadeler, dolayısıyla üretilmiş kod, makrolar veya alışılmadık biçimlendirme gözden kaçabilir ya da yanlış pozitif tetikleyebilir. Yalnızca uygulamanın kendi kaynaklarını okuyor — CocoaPods, harici Swift paketleri, node_modules veya Flutter plugin'leri yok — ve .xcconfig dosyalarını ayrıştırmıyor. Camdali ayrıca bir uyarının, kodun bir bar'ın üzerine boya yaptığının işareti olduğunu, tercihin mutlaka yanlış olduğu anlamına gelmediğini hatırlatıyor; karar vermeden önce ekran yine de bir iOS 27 simulator'da kontrol edilmeli.
Neden önemli
Nisan 2027 SDK zorunluluğu, tek satırlık bir kaçış kapısını planlanmış bir geçişe dönüştürüyor. Liquid Glass'tan çıkmayı seçen her uygulamanın, özel bar stillendirmesini sistem tasarımıyla uzlaştırması için artık sınırlı bir penceresi var ve bu iş bir anahtar çevirmek değil, kod bulmak. Platformlar arası ekipler için ek bir sorun daha var: JavaScript ve Flutter ile çizilen bar'lar, Liquid Glass'ı benimseyen native chrome'dan görsel olarak ayrık duracak. Göz önünde bulundurulması gereken bir uyarı: bu anlatım, tarayıcının kendi yazarının tek bir dev.to yazısından geliyor; dolayısıyla buradaki sağlam bilgiler Apple dokümantasyonu alıntıları, aracın kapsam iddiaları ise kendi beyanına dayanıyor.
- #ios
- #apple
- #liquid-glass
- #uikit
- #developer-tools
- #react-native