iOS 26 Foundation Models’da Serbest Metin Yanlış Default: @Generable ile Swift Tipi Üretmek Daha Güvenli

5 Haziran 2026 itibarıyla Apple’ın güncel Generating Swift data structures with guided generation, Generable, Guide, count(_:), Generating content and performing tasks with Foundation Models ve Foundation Models updates sayfalarını birlikte okuyunca bence çok net bir teknik sonuç çıkıyor: birçok iOS ekibi Foundation Models'i hâlâ metin üreten bir API gibi düşünerek başlayabilir. Oysa Apple'ın en güçlü tarafı çoğu zaman serbest metin değil, doğrudan Swift veri yapısı üretebilmesi. @Generable bu yüzden küçük bir konfor API'si değil; AI çıktısını ürün koduna güvenli biçimde sokmanın ana mekanizması olabilir.

Foundation Models ile ilgili ilk denemelerin büyük kısmı doğal olarak aynı yere gidiyor. Bir session açılıyor, prompt veriliyor, model cevap üretiyor ve ekrana metin basılıyor. İlk demo için bu anlaşılır bir başlangıç. Ama ürün kodu açısından baktığınızda burada ciddi bir problem var: serbest metin, uygulamanın geri kalanı için zayıf bir sınır. Çünkü SwiftUI ekranı çoğu zaman metin değil, veri ister. Liste ister, enum ister, kategori ister, tarih ister, skor ister, alanlara ayrılmış bir sonuç ister. Model her seferinde düz paragraf döndürdüğünde, bütün risk uygulama tarafına geri taşınır. Siz tekrar parse etmeye, format tahmin etmeye, eksik alanları yönetmeye ve kırılgan dönüşümler yazmaya başlarsınız.

Apple’ın @Generable yaklaşımı bence tam bu yüzden önemli. Foundation Models framework'ü size yalnızca "cevap üret" demiyor. Aynı zamanda "cevabı tip sistemi içine al" diyor. Apple'ın ana Foundation Models sayfasında da bu açık biçimde vurgulanıyor: @Generable macro'su ile özel veri yapıları tanımlayabiliyorsunuz ve framework, modelin bu tiplerin örneklerini üretmesi için güçlü garantiler veriyor. Bu ifade bence konunun merkezini netleştiriyor. Asıl mesele AI cevabının etkileyici görünmesi değil; geri kalan kodun güvenle kullanabileceği bir şekle sokulması.

Serbest Metin Neden Kötü Default?

Çünkü serbest metin her şeyi modelin insafına bırakır. Aynı görevi bugün farklı, yarın farklı, locale değişince farklı, model sürümü güncellenince daha da farklı biçimde alabilirsiniz. Oysa ürün kodu çoğu zaman belirsizliği değil, kararlı veri yapısını sever. Örneğin bir not uygulamasında modelden görev çıkarıyorsanız, ekranda gösterilecek şey “güzel yazılmış bir paragraf” değil, başlığı olan, önceliği olan, gerekirse deadline alanı taşıyan bir görev listesi olabilir. Bir alışveriş uygulamasında niyet analizi yapıyorsanız, cevabın edebi olması gerekmez; kategori, bütçe aralığı ve arama etiketi üretmesi gerekir. Bir eğitim uygulamasında metinden quiz çıkarıyorsanız, size gereken şey dümdüz açıklama değil; soru, seçenekler, doğru cevap ve gerekirse açıklama alanıdır.

@Generable burada tam ürün seviyesinde işe yarıyor. Çünkü modelin yaratıcı davranış alanını tamamen kapatmıyor ama onu veri modeli sınırları içine çekiyor. Bu da SwiftUI tarafında çok daha temiz bir akış kuruyor. View'lar tahmine göre değil, somut tiplere göre render ediliyor. Form doldurma, regex ile alan ayıklama veya JSON benzeri ama tam JSON olmayan cevapları toparlama gibi ara acılar azalıyor. Bence Foundation Models kullanan iOS ekipleri için en önemli zihinsel değişim şu: "modelden ne söylesem" yerine "hangi Swift tipini üretmesini istiyorum" diye düşünmek.

Apple’ın Sessiz Mesajı: Önce Tipi Tasarla, Sonra Prompt’u

Generating Swift data structures with guided generation ve Generable sayfaları birlikte okununca Apple'ın yönü oldukça açık görünüyor. Önce modelden almak istediğiniz yapıyı tanımlayın, sonra gerekliyse açıklayıcı guide'larla bu yapının üretimini yönlendirin. Bu küçük gibi duran sıralama aslında çok önemli. Çünkü birçok ekip AI özelliğini prompt merkezli düşünmeye başlıyor: önce büyük bir instruction yazılıyor, sonra modelden buna uygun metin bekleniyor, en son "bunu biraz structured hale getirsek mi?" sorusu geliyor. Apple ise sanki bunun tersini öneriyor olabilir. Önce tip sistemini kurun, gereksiz property eklemeyin, modelin gerçekten ihtiyaç duyduğu kadar açıklama verin ve mümkün olduğunca küçük bir şema ile ilerleyin.

Bu noktada Apple’ın Generable docs'undaki tavsiye özellikle değerli: type complexity'yi azaltın ve property'ler gerçekten gerekli mi diye değerlendirin. Bu tavsiye yalnızca sadelik önerisi değil; doğrudan kalite ve performans önerisi. Çünkü şema büyüdükçe modelin taşıması gereken yük artıyor. Her yeni property, belirsizlik için yeni yüzey açıyor. Her uzun açıklama, token bütçesinden yiyor. Foundation Models updates ile Generating content and performing tasks with Foundation Models tarafını birlikte okuyunca bunun neden önemli olduğu daha da netleşiyor: session başına 4,096 token sınırı var ve bu bütçeye yalnızca prompt değil, instructions ve çıktı da dahil. Dolayısıyla gereksiz büyük @Generable tipleri yalnızca "daha açıklayıcı" olmaz; daha pahalı ve daha kırılgan da olabilir.

Guide(description:) Doğru Kullanılmazsa Yardım Değil Yük Olabilir

Apple’ın Guide ve Generable dokümanlarında bence çok olgun bir fikir var: property isimleri zaten yeterince açıksa, her alanı uzun uzun açıklamak zorunda değilsiniz. Bu nokta önemli çünkü birçok ekip guide'ları prompt gibi kullanmaya başlayabilir. Her property'nin altına uzun açıklamalar, ton kuralları, edge case listeleri ve neredeyse mini bir specification yazmak cazip gelebilir. Ama bu yaklaşım her zaman akıllıca olmayabilir.

Ben bunu şu şekilde okuyorum: Guide, belirsizliği azaltmak için var; şemayı şişirmek için değil. Eğer title, priority, dueDate gibi alanlar zaten açıkça ne taşıdığını söylüyorsa, modelin üzerine fazladan söz yüklemek yerine daha küçük ve daha anlaşılır bir yapı kurmak çoğu zaman daha doğru olabilir. Guide asıl değerini, modelin tek başına tam çıkaramayacağı sınırlarda gösterir. Örneğin bir puan aralığı, belirli bir etiket sayısı, çok net bir içerik kısıtı veya alanın niçin var olduğu gibi noktalar gerçekten yönlendirme ister. Ama her property için roman yazmak, guided generation'ı structured output olmaktan çıkarıp yeniden prompt kalabalığına döndürebilir.

count(_:) Küçük Görünüyor Ama Ürün Kalitesi İçin Çok Değerli

Apple’ın count(_:) generation guide örneği ilk bakışta küçük bir API detayı gibi durabilir. Oysa bence burada çok pratik bir kalite mesajı var. Ürünler çoğu zaman "bir liste üret" demez; "tam üç öneri üret", "dört seçenek ver", "beş madde çıkar" gibi net beklentiler taşır. Serbest metin yaklaşımında bu tip nicelik kuralları her zaman kayabilir. Model bazen iki sonuç döner, bazen altı sonuç döner, bazen listenin içine açıklama da ekler. count(_:) gibi generation guide'lar ise bu belirsizliği ürün lehine daraltır.

Bu özellikle SwiftUI tarafında önemli. Çünkü birçok arayüz belirli sayıda kart, belirli sayıda seçenek veya belirli sayıda öneri göstermek üzere tasarlanır. Eğer modelin döndürdüğü eleman sayısı kararsızsa, UI ya gereksiz esner ya da sonradan budama mantığı eklemek zorunda kalırsınız. Halbuki doğru yerde kullanılan count(_:), model davranışını doğrudan tasarım kararına yaklaştırır. Bence bu da @Generable dünyasının asıl gücünü anlatıyor: modeli yalnızca "doğru cevap veren şey" gibi değil, UI kontratına uyan üretim katmanı gibi kullanmak.

İyi @Generable Tipi, Büyük Tip Demek Değil

Bence birçok ekip burada yanlış yöne gidebilir. “Madem structured output alabiliyoruz, o zaman tek seferde bütün ekran modelini üretelim” fikri ilk bakışta çok çekici gelir. Başlık, alt başlık, etiketler, aksiyon maddeleri, renk önerisi, ikon adı, confidence skoru, analytics label, fallback açıklaması ve daha fazlasını aynı tipte toplamak kolayca mümkün görünür. Ama ürün mühendisliği açısından bu çoğu zaman kötü default olabilir.

Apple’ın current docs çizgisinden benim çıkardığım sonuç şu: guided generation en iyi, küçük ve göreve özel veri yapılarında çalışır. Çünkü görev küçüldükçe başarı kriteri netleşir. Modelin hata yüzeyi azalır. Test etmek kolaylaşır. Aynı işi başka ekranda yeniden kullanmak daha temiz olur. Örneğin bir meeting note parser yazıyorsanız, önce yalnızca ActionItem listesi üreten küçük bir tip kurmak; aynı anda her şeyi çıkarmaya çalışan dev bir MeetingSummaryScreenModel üretmekten daha güvenli olabilir. Bu yaklaşım aynı zamanda prompt tuning sürecini de sadeleştirir, çünkü hangi alanın neden kötü üretildiğini ayırt etmek kolaylaşır.

Kod Tarafında Daha Sağlam Başlangıç Nasıl Görünür?

Bence iyi başlangıç, küçük ama gerçekten ürün değeri olan bir veri tipi seçmek. Mesela serbest metin yeniden yazma yerine, kullanıcıdan gelen nottan görev çıkarmak gibi.

import FoundationModels

@Generable
struct ActionItem {
    @Guide(description: "A short task title written in Turkish")
    let title: String

    @Guide(description: "A priority level from low, medium, or high")
    let priority: String
}

@Generable
struct ActionItemList {
    @Guide(description: "A list of extracted action items", .count(3))
    let items: [ActionItem]
}

let session = LanguageModelSession()
let result = try await session.respond(
    generating: ActionItemList.self,
    to: "Toplantı notundan üç aksiyon maddesi çıkar: Yarın tasarım dosyası güncellenecek, cuma günü müşteri demosu hazırlanacak, bütçe revizyonu finans ekibiyle kontrol edilecek."
)

Bu örnekte asıl önemli olan syntax değil. Önemli olan, modelin düz paragraf yerine doğrudan UI ve iş mantığının kullanabileceği bir sonuç üretmesi. Bundan sonra ForEach ile liste render etmek, önceliğe göre renk atamak, kullanıcıya seçim yaptırmak veya sonucu veri tabanına yazmak çok daha doğal hale geliyor. Structured output burada yalnızca geliştirici konforu değil; ürün akışının geri kalanını sadeleştiren bir mimari karar.

@Generable, Parse Kodunu Azaltmaktan Daha Fazlasını Yapıyor

Bu konuyu yalnızca “regex yazmaktan kurtarıyor” diye okumak eksik kalır. Daha önemli tarafı, uygulama davranışını test edilebilir hale getirmesi. Serbest metin kullandığınızda, kalite problemleri genelde UI tarafında geç fark edilir. Çünkü modelin neyi yanlış yaptığı çoğu zaman ancak kullanıcı akışında görünür hale gelir. Ama belirli bir tipe üretim yaptırdığınızda, hatalar çok daha somutlaşır. Eksik alan mı var, sayı yanlış mı geldi, enum benzeri alan sapıyor mu, liste boyutu bozuldu mu; bunların hepsi daha erken fark edilir.

Bu aynı zamanda ekip içi tartışmayı da iyileştirir. Konuşma artık “cevap biraz garip olmuş” seviyesinde kalmaz. “Bu tip gereğinden büyük”, “şu property belirsiz”, “guide fazla uzun”, “count yanlış yerde”, “bu alan aslında ikinci aşamaya taşınmalı” gibi çok daha mühendislik odaklı hale gelir. Bence Apple’ın guided generation çizgisinin asıl olgunluğu burada. Modeli sihirli metin kutusu olmaktan çıkarıp, sınırları konuşulabilen bir üretim bileşenine dönüştürüyor.

5 Haziran 2026 İtibarıyla Benim Çıkardığım Sonuç

Apple’ın güncel Foundation Models dokümanlarını birlikte okuyunca benim için tablo oldukça net. @Generable, iOS tarafında AI entegrasyonunu daha güvenilir hale getiren en önemli katmanlardan biri olabilir. Çünkü mesele yalnızca modelden cevap almak değil; cevabı Swift tip sistemi, SwiftUI akışı ve ürün kontratları içine güvenli biçimde yerleştirmek. Bu yüzden ben bugün Foundation Models kullanan bir iOS ekibinde olsam, ilk soruyu "hangi prompt'u yazalım?" diye sormazdım. İlk sorum şu olurdu: "hangi küçük ama değerli veri tipini modele ürettirirsek, uygulamanın geri kalanı daha sade ve daha güvenilir hale gelir?"

Benim için bu konunun özeti şu: iOS 26 Foundation Models döneminde serbest metin çoğu zaman ilk demo’nun default’u olabilir. Ama gerçek ürün kodu için doğru default, giderek daha fazla @Generable olacak gibi görünüyor.