Gerçekten çılgın bir dönemden geçiyoruz. Yeni AI araçları ve fikirleri, geliştiricilerin çalışma şeklini neredeyse her gün yeniden şekillendiriyor — AI workflow’umu iyileştirmek için zaman ayırdığım anda yeni bir şey çıkıyor ve daha az önce kurduğum workflow eskimiş gibi görünmeye başlıyor. Apple platform geliştirmenin eskiden verdiği hisle taban tabana zıt. Yeni araçlar geleneksel olarak yılda bir kez, tek bir büyük etkinlikte gelirdi; WWDC haftası en azından benim için „mesai saatlerinde Noel” gibiydi: rahat, planlanabilir ve heyecan verici.
Bu rahatlık zaten bir süredir aşınıyordu. Açık kaynak Swift, Swift Evolution süreci, birkaç haftada bir yayınlanan paketler ve araçlar, Swift on Android — bunların hepsi yavaş yavaş aksiyonun bir kısmını WWDC’nin sınırlarının dışına taşıdı. Ama işler asıl ChatGPT ve Claude Code ile birlikte çatladı. Açık konuşayım: agent öncesi dönemde, „geliştiriciler için AI” çoğunlukla chat pencerelerini ve autocomplete’i kastederken AI araçlarına şüpheyle yaklaşıyordum. Bu son on iki ayın bir noktasında benim için değişti, o günden beri de geliştirme workflow’umun şu an gerçekten neye benzediğini çözmeye çalışıyorum. Pek çok kişi gibi.
Bu yüzden Apple WWDC26’yı 8 Haziran haftası için duyurduğunda ve bunu açıkça şöyle ifade ettiğinde gerçekten sevindim: „Apple platformları için inanılmaz güncellemeler, AI gelişmeleri ve heyecan verici yeni yazılım ile geliştirici araçları dahil.” Ben de oturup kendime sordum: yalnızca Apple’ın sunabileceği ve agent destekli geliştirme workflow’umu en çok iyileştirecek beş şey ne olurdu? İşte ortaya çıkan liste.
ℹ️ Geçmiş WWDC dilek listelerimden çıkan maddelerin yaklaşık %33’ü gerçekten geldi. WWDC24 dilek listemden iki tanesi sonradan ortaya çıktı: WWDC25’te String Catalog’da çoklu seçim ve Xcode 26.3 MCP sunucusundaki yeni
RenderPreviewaracı (döngü ortasında, Şubat’ta). Yani Apple aslında teslim ediyor — bazen WWDC tanıtımının dışında.
#1 – LLM seviyesinde bir UI introspection API’si
Agent’ıma „kodu değiştirdikten sonra ekran gerçekten doğru görünüyor mu” diye doğrulatmak istediğimde bugün iki seçeneğim var: ya screenshot’ları multimodal bir modele yolluyorum (yavaş, pahalı, kırılgan) ya da accessibility tree’yi Peekaboo / xcodebuildmcp üzerinden sorguluyorum (daha iyi, ama AX API’si screen reader’lar için tasarlanmıştı). AX tree sana „bu, ‘Save’ label’lı bir button” diyor — sana bu button’un 44pt yüksekliğinde olduğunu, corner radius’ünün 12 olduğunu, 16pt spacing’li bir HStack’in içinde oturduğunu, 0.3 saniyelik bir transition ile fade in olduğunu ve dokununca async bir network çağrısı tetiklediğini söylemiyor.
Xcode’un View Debugger’ı bunların büyük kısmını zaten gösteriyor. Çalışan bir uygulamada her view’in frame’ini, modifier stack’ini, constraint’lerini, layer property’lerini ve bağlı gesture recognizer’larını yapısal bir biçimde görebiliyorsun. Eksik olan, bu verinin metin tabanlı, makine tarafından okunabilir bir export’u. Düşün ki agent’ım çalışan uygulamaya şunu sorabiliyor: „bana her etkileşimli element için boyut, renk, jest, animasyon ve async hook bilgileriyle birlikte tam layout tree’sini JSON olarak ver.” Tıklama niyetleri belirleyici hale geliyor. Agent, polling yapmak yerine doğru async işlemini bekleyebiliyor. Bir dokunuştan sonra yeni layout’u okuyup beklenen state ile karşılaştırabiliyor — hiç screenshot almadan.
Ve eğer Simulator, SwiftUI Previews gibi hot reloading desteği alsa — ve aynı introspection API’si Previews’in kendisi tarafından da sunulsa — hem insan hem de agent yönetimli UI çalışmasının iterasyon döngüsü dakikalardan saniyelere düşerdi.
Accessibility tree, agent’lar için yanlış soyutlama. Bu, doğrusal navigasyon yapan screen reader kullanıcıları için optimize edilmiş bir yapı. Agent’ların gezmesi gereken şey gerçek view hierarchy: tıklanabilir bölgeler, scroll edilebilir alanlar, loading state’leri, animasyon zamanlaması, async hook’lar. Xcode’a sadece debug modunda eklenecek bir „AI değerlendirmesi için animasyonları kapat” toggle’ı, agent’ların tüm bir uygulamayı dakikalar yerine saniyeler içinde gezmesine olanak tanırdı. Daha büyük resimde ise bu API’nin sistem geneline yayılmış bir varyantı — sadece debugger altındaki uygulamalar değil, her uygulama tarafından sunulan bir hali — agent’ların sistemdeki herhangi bir uygulamada gezinmesine izin verirdi; geliştiricilerse debug modunda üstüne ekstra tatlılar alırdı.
Agent’ların subscribe olabileceği yapılandırılmış bir layout/style/gesture API’si istiyorum — buna ek olarak bir „animasyonları kapat” debug toggle’ı ve aynı yüzeyin SwiftUI Previews ile Simulator’da hot reloading destekli olarak sunulması.
#2 – Niyet seviyesinde UI flow’ları için bir Swift DSL’i
İtiraf edeyim: Hiç UI testi yazmıyorum. Sıfır. CrossCraft, TranslateKit, Posters — hiçbirinin UI testi yok. Her denediğimde — 2024 ve öncesinde — bir sonraki layout düzenlemesinde testler bozuldu, ben de testin yakalaması gereken hata yerine testi düzeltmeye daha fazla zaman harcadım. Vazgeçtim. O zamandan beri bir tane bile yazmadım.
Sorun test etmek değil — bağlama meselesi. Bugünün testleri kendilerini accessibility ID’lere, button label’larına veya pixel pozisyonlarına bağlıyor; dolayısıyla Next‘i Continue yapınca veya yerine bir chevron ikonu koyunca hepsi kırılıyor. Aslında ifade etmek istediğim şey niyet: „bir sonraki ekrana ilerleten button’a dokun.” Bunu okuyan bir insan, label ne olursa olsun ne yapması gerektiğini biliyor.
Eğer #1 numaralı dilek agent’a ekranda olanın yapılandırılmış bir görünümünü veriyorsa, bu da geliştiriciye, agent’ın yürüyeceği flow’ları anlatmak için Swift’e doğal bir DSL veriyor. Apple tarafından tasarlanmış küçük bir markup dili, bize @Observable, @Model ve #Preview‘i veren aynı macro toolkit’iyle ifade edilen:
#UIFlow("Ana ekrandan 9×9 bir bulmaca oluştur") {
action("yeni bir bulmaca başlat")
choose("9×9", from: "grid boyutu picker'ı")
action("oluşturmayı onayla")
wait("üretim tamamlanana kadar", timeout: .seconds(30))
expect("boş bir 9×9 bulmaca grid'i gösteriliyor")
}Fiiller bilinçli olarak niyet odaklı. action("yeni bir bulmaca başlat") button’un ismini değil, sonucu adlandırıyor. Eğer benim ekranımda „yeni bir bulmaca başlat” diyebilecek tek belirgin bir affordance yoksa, bu testin başka her şeyden önce yakalayacağı bir kullanılabilirlik hatası: tüm layout tree’sine sahip bir LLM, uygulamayı ilk kez deneyen bir kullanıcı için oldukça iyi bir vekil. Agent net bir eşleşme bulamıyorsa, muhtemelen benim bilgi mimarimin gözden geçirilmesi gerekiyor.
Performans baseline’larında olduğu gibi, sistem bir flow ilk kez başarıyla çalıştığında referans bir snapshot saklayabilirdi — pixel mükemmelliğinde bir hedef değil, daha önce onayladığım layout state’i. Sonraki çalıştırmalarda agent şunu karşılaştırır: bu state iyiydi, yeni state bu, kullanıcı „boş bir 9×9 grid” istiyor — referansta öyleydi, şimdi de hâlâ öyle mi? İnsanların da „bozuk” diyeceği bir durum çıkmadıkça düşmeyecek testler için tam doğru bulanıklık seviyesi.
Apple’ın tasarladığı bir Swift DSL’i istiyorum: UI flow’larını niyete göre tarif ettiğim, agent’ların bunları çalışan uygulamada yürüttüğü ve referans snapshot’ların layout’un daha önce onayladığım bir state ile hâlâ eşleşip eşleşmediğini agent’a söylediği bir yapı.
#3 – Daha yetenekli on-device LLM’ler
Beşinin içinde, hemen bugün üzerine atılmak isteyeceğim madde bu. On-device LLM’ler gizlilikte, latency’de ve maliyette kazanıyor; harici API çağrılarımı onlarca yerde bunlarla değiştirmeyi çok isterdim. Ama SystemLanguageModel.default, input + output birlikte 4.096 token ile sınırlanmış durumda — bu sınır iPhone’da da, 36 GB’lık M4 Max Mac Studio’mda da aynı. Daha fazla context istemenin, daha büyük bir model talep etmenin ya da kullanıcının kendi modelini getirmesinin bir yolu yok.
Bu, iki yönlü bir kaçırılmış fırsat. Mac Studio’mda 30 GB’ı aşkın atıl RAM var ve sistem bunu bana daha iyi cevap vermek için kullanmıyor. Ve üçüncü taraf model sahipleri — Mistral, Qwen, gelecek yıl güzel bir Swift coding 14B modeli çıkaracak her kim olursa — uygulamaların zaten kullandığı sistem yüzeyine bağlanacak bir yola sahip değil.
İstediğim, gereksinim tabanlı bir API. Geliştiricinin çağrı noktasında ifade edebilmesi gereken birbirinden bağımsız iki eksen:
Inference budget – bu çağrı kendine ne kadar düşünme süresi verebilir? Bir notu kategorize etmek anlık olmalı; uzun bir dokümanı özetlemek ise daha kapsamlı bir geçiş için birkaç saniye bekleyebilir.
Model yeteneği – modelin ne kadar yetenekli olması gerek? Bir takvim etkinliğini etiketlemek mevcut en küçük modelde sorunsuz çalışır; cilalı bir e-posta yazmak ya da yapılandırılmış veri üzerinde akıl yürütmek, cihazın çalıştırabileceği en büyük modeli ister.
Bunların yanında bariz olan da var: prompt’un gerçekten ihtiyaç duyduğu minimum context window. Bugün on-device API kabaca şöyle — temiz, ama SystemLanguageModel.default’a kilitli:
let session = LanguageModelSession()
let response = try await session.respond(to: prompt)Bunun yerine, çağrının gereksinimlerini session sınırında bildirmek ve sisteme uyan modeli seçtirmek istiyorum:
let session = LanguageModelSession(
requirements: .init(
minimumContextTokens: 32_000,
capability: .high,
inferenceBudget: .relaxed
)
)
let response = try await session.respond(to: prompt)Sistem, bu gereksinimleri gerçekte mevcut olanlarla — hangi modeller kuruluymuş, ne kadar RAM boşmuş, Neural Engine ne kadar meşgulmüş — eşleştirip seçer. Ayrıca istekleri RAM’i taşırmayacak şekilde queue’lamalı: iki modeli paralel çalıştırırken Mac Studio’mu kaç kez çökerttiğimi sayamam, ve Swift async sistemdeki diğer her kaynağı zaten halledebiliyorken inference’ın elle koordine edilmesi gereken tek istisna olmaması gerekir.
Apple’ın taahhüt etmesini en çok istediğim parça: kullanıcı tarafından kurulan üçüncü taraf modellerin birinci sınıf bir kavram olması. Kullanıcı Sistem Ayarları → Apple Intelligence → Yüklü Modeller‘e gidiyor ve seçiyor: Apple’ınkini, Mistral’ınkini, bir Qwen-coder fine-tune’unu — neye güveniyorsa ve neye depo alanı varsa. Uygulamalar tek satır değişmiyor, çünkü sisteme model isimleriyle değil yetenek terimleriyle konuşuyorlardı. Kullanıcının seçtiği model çağrının gereksinimlerini karşılıyorsa sistem onu kullanır; karşılamıyorsa, gereksinimleri karşılayan başka bir kurulu modele düşer. Uygulama hangi modelin çağrıyı aldığıyla ilgilenmez, yalnızca gereksinimlerinin karşılandığıyla. Apple API sözleşmesinin kontrolünü elinde tutar; kullanıcı ise cihazında hangi modelin yaşadığının kontrolünü.
Aynı tema: tek bir sistem genelinde model registry’si. Bugün diskimde OpenWhispr’in kullandığı parakeet-tdt-0.6b-v3 modeli duruyor — ve çalıştırdığım iki başka transcription pipeline’ı da aynı modelin kendi kopyalarını ayrı ayrı indirmiş durumda. Bir Qwen modelinde de aynı sorun var: LM Studio onu zaten indirmiş, ben de ayrı bir projede CLI üzerinden kendi kopyamı çekiyorum, hâlihazırda olanı kullanmak yerine. Düpedüz dağınıklık. Birleşik bir kurulum registry’si olsaydı Mac’teki herhangi bir uygulama mevcut modelleri keşfedip yeniden kullanabilir, her aracın kendi kopyasını yönetmesi gerekmezdi.
Bu arada lafı açılmışken: lütfen AB’de ilk gün lansman yapın. 🙏
Kullanıcı kurulumuna açık üçüncü taraf modeller, sistem yönetimli RAM ve istek queue’lama, paylaşılan tek bir model registry’si — ve AB’de de ilk gün aynı anda sunulan, gereksinim tabanlı bir on-device LLM API’si istiyorum.
#4 – AI agent’ları için headless bir Xcode
Bugünlerde zamanımın çoğunu kod yazmadan geçiriyorum. Spesifikasyonlar yazıyorum, agent’larımdan gelen PR’ları review ediyorum ve TestFlight build’lerinin iPhone’uma düşmesini izliyorum. Şu an tüm projelerimdeki Claude Code ve Codex oturumlarımı orkestre eden bir Mac mini uygulaması yapıyorum — temelde PlanKit ve TandemKit’in bugün yaptığını, üstüne Sandcastle tarzı bir „Mac uygulamasını companion bir uzaktan-kumanda uygulamasıyla yönetme” fikrini ekleyerek — yolda da review edebilmem için TestFlight beta dağıtımı olan native bir macOS uygulaması olarak paketliyorum. Mac mini orada duruyor, agent’lar otonom çalışıyor, ben de sonucu hiç Xcode’u kendim açmadan inceliyorum.
Bu workflow’da Xcode’u görmem nadiren gerekiyor. IDE pencereleri, Project Navigator, source editor — bunlar artık benim için değil. Agent’ım için. Ve agent’ımın pencereye ihtiyacı yok; bir API’ye ihtiyacı var.
Asıl istediğim, menü bar’ında bir Xcode Server: tam MCP yüzeyini sunan, build’leri birden fazla proje arasında zamanlayan (iki büyük Swift compile’ı çekirdekler için kavga etmesin diye), proje başına derived data’yı talep üzerine temizleyen ve hiçbir pencere açmayan headless bir build daemon. IDE’nin akıllı parçalarını koruyup UI’ını çıkarmış bir xcodebuild --daemon düşün. Hâlâ elle kod yazan geliştiriciler için tam Xcode kalır — ama pek çok uygulama üzerinde agent filoları yöneten bizler için pencere içermeyen bir Xcode ciddi anlamda kaynak ve sürtünme tasarrufu sağlar. (Build zamanlaması ve derived data kısımlarını sonunda muhtemelen kendi uygulamamda zaten gerçekleştireceğim — ama yerleşik gelseydi tabii ki daha hoş olurdu.)
Menü bar’da yaşayan, headless ve agent öncelikli bir Xcode Server istiyorum.
#5 – LLM yerelinde geliştirme için yeni bir paradigma
Spekülatif kısma geldik. Apple’ın geliştiricileri gerçek anlamda şaşırttığı son sefer — kimsenin bingo kartında olmayan türden bir duyuru — 2019’da SwiftUI’ydi. Neredeyse yedi yıl önce. AI agent’ları, çalışma şeklimiz açısından bu kuşağın sismik kaymasını oluşturuyor; ben de kendime soruyorum: Swift ve SwiftUI bu yeni dünya için hâlâ doğru primitive’ler mi?
Belki LLM’ler, kodlarını ürettikleri dil baştan onları gözeterek tasarlanmış olsaydı daha güvenilir kod üreticileri olurlardı — daha az muğlak DSL tuzağı, daha ortogonal kompozisyon, layout ve davranışın aynı anda hem insan tarafından okunabilen hem de agent tarafından introspekte edilebilen tek bir bildirim biçiminde ifade edilmesi. Belki yeni bir dil bile değil, henüz tam olarak hayal edemediğim yeni bir paradigma. Her ne ise, o anı bekliyorum.
Apple, „AI gelişmeleri” ifadesiyle çıtayı yükseltti. Geliştirici tarafına gelen şey sonunda yalnızca Gemini destekli bir Siri ile Xcode coding assistant’ı için kozmetik cilalar veya bug fix’lerse, bu bir hayal kırıklığı olur. Bana platform seviyesinde yeniden düşünmeyi gösterin.
AI yerelinde bir paradigma istiyorum — bir sonraki SwiftUI anını.
Sonuç
Apple ender bir konumda — şirket silikonu, OS’i, IDE’yi, App Store’u ve modeli kontrol ediyor. Bu listedeki dileklerin neredeyse tamamı, yalnızca böyle entegre bir stack’in iyi yapabileceği şeyler. Hâlâ başka bir platforma geçmek yerine Apple platformları üzerinde inşa etmeye devam etmemin ve WWDC26’nın AI tooling’i bir „eklenti” gibi ele almak yerine bu avantaja gerçekten yaslandığı yıl olmasını ummamın sebebi de bu. Keynote’u izlerken bu liste yanımda açık olacak.
Senin listende neler var? Bluesky veya Mastodon üzerinden bana yaz.
P.S. – Bunu Top 5’e koymadım çünkü dilekten çok bug gibi geliyor; ama benim asıl en üst sıram bu diyalog:
Lütfen, lütfen, lütfen bunu bana günde 50 kez göstermeyi bırakın. Her. Bir. Oturumda. Tekrar. Ve tekrar. Üstelik düzeltme için WWDC’yi beklemeye gerek de yok. Şimdiden teşekkürler. 🤍 (Şu workaround’u kullanıyorum.)