Compose Multiplatform 1.12.0 sürüm notlarında kısa ama önemli bir satır var: Compose Hot Reload artık AI ajanlarının çalışan bir Compose uygulamasıyla gerçek zamanlı etkileşim kurmasını sağlayan bir MCP server içeriyor. Bu makalede o sunucunun ne yaptığını, nasıl kurulduğunu ve Flutter tarafında fiilen elinde ne olduğunu birincil kaynaklardan karşılaştırıyoruz — AI ajanı hot reload Compose MCP server konusuna hem Kotlin hem Dart/Flutter tarafından bakıyoruz.
💡 Pro Tip: MCP server'ı ilk kurduğunda önce status aracını çağır — ajanın uygulamanın son reload hatasını görüp görmediğini böyle doğrularsın, çıktısız denemeyle vakit kaybetme.İçindekiler
- Neden hot reload AI ajanları için kritik
- Compose Hot Reload MCP server ne yapıyor
- Kurulum: ajanı çalışan uygulamaya bağlamak
- Kotlin Toolchain 0.12 ile CLI'dan çalıştırma
- Flutter tarafındaki resmi MCP eşdeğeri
- Ajanın gördüğü ve GÖREMEDİĞİ şeyler
- Güvenlik ve izin sınırları
- Neyi otomatikleştiriyor, neyi garanti etmiyor
- SSS
- Compose Hot Reload MCP server nasıl kurulur?
- AI ajanı çalışan mobil uygulamayı nasıl test eder?
- Claude Code ile Flutter/Compose hot reload nasıl birleştirilir?
- Agentic hot reload gerçekten işe yarıyor mu?
- Compose Hot Reload MCP server hangi platformlarda çalışıyor?
- Dart/Flutter MCP server'ı hangi editörlerle kullanabilirim?
- Sonuç
- Kaynaklar
Neden hot reload AI ajanları için kritik
Bir kodlama ajanının değişiklik yapıp sonucu görmesi gerekiyorsa, klasik döngü şudur: dosyayı düzenle, terminale geç, build'i izle, uygulamaya geç, ekranı kontrol et, hatayı logdan oku, tekrar dosyaya dön. Her adım ajan için ayrı bir araç çağrısı ya da insan müdahalesi demek. Compose Hot Reload'ın MCP server'ı bu döngüyü tek bir protokolün içine taşıyor: ajan reload çağırır, await_reload ile tamamlanmasını bekler, get_ui_error ile hatayı okur — hepsi aynı oturumda, ekran değiştirmeden.
Bunun kritik olmasının nedeni hot reload'ın kendi doğası: uygulamayı yeniden başlatmadan değişikliğin sonucunu görüyorsun, yani ajan da aynı oturum içinde geri bildirim alabiliyor. Kotlin Toolchain 0.12 duyurusu bu tarafta ilk reload'un artık çok daha hızlı tamamlandığını ve build'in daha az kaynak tükettiğini söylüyor; ölçülmüş bir süre vermiyor. Bu, "kod yaz → build bekle → test et" akışını "kod yaz → anında doğrula" akışına indiriyor — tabii bu yalnızca JVM/desktop hedefinde geçerli, çünkü Compose Hot Reload projede bir JVM target'ı zorunlu kılıyor ve diğer hedefler için destek henüz keşif aşamasında (kaynak: compose-hot-reload README).
Compose Hot Reload MCP server ne yapıyor
Özelliğin kaynağı, Compose Multiplatform'un ana deposundaki #5671 numaralı PR — bu PR, Compose Hot Reload (CHR) sürümünü 1.2.0'a yükselten bir cherry-pick. Asıl MCP özelliği aslında CHR'nin kendi 1.2.0 sürümünde tanıtıldı; Compose Multiplatform 1.12.0 onu yalnızca bundle etti. CHR'nin sürüm notlarındaki tanım net: yeni hot-reload-mcp modülü, hotMcpServer Gradle görevi üzerinden bir Model Context Protocol sunucusu açığa çıkarıyor. Bu sunucu çalışan Compose uygulamasına bağlanıyor, başlangıcı bekliyor, kapanmaları algılıyor ve otomatik olarak yeniden bağlanıyor.
Sürüm notlarında belgelenen araçları şu şekilde gruplayabiliriz:
Grup | Araçlar | Ne işe yarar |
|---|---|---|
Durum | status | Uygulama ve reload durumunu, son hatanın detaylarını gösterir |
Reload/Restart | reload, await_reload, restart, reset_ui | Hot reload tetikler ve tamamlanmasını bekler; uygulamayı yeniden başlatır veya çalışan UI'ı sıfırlar |
Görsel/Pencere | take_screenshot, list_windows, resize_window | Ekran görüntüsü alır, pencereleri listeler ve boyutlandırır |
UI/Log | get_semantic_tree, get_ui_error, get_logs, click, type_text, scroll | Dialog/ModalBottomSheet/Popup dahil semantik ağacı okur, hata ve logları getirir, kullanıcı etkileşimlerini simüle eder |
Bu liste aynı zamanda sınırın yönünü de gösteriyor: sürüm notlarında belgelenen araçlar arasında rastgele dosya sistemi veya build script erişimi yok. Kaynak: compose-hot-reload v1.2.0 sürüm notları. Resmi repo README'si ayrıca sunucunun deneysel statüde olduğunu ve Compose Hot Reload'ın 1.2.0-alpha01 sürümünden beri mevcut olduğunu belirtiyor — yani araç setini kalıcı bir API sözleşmesi gibi değil, değişebilecek bir önizleme gibi ele al.
Bu araçların birbirine nasıl bağlandığını anlamak için status çıktısına bakmak yeterli. README'ye göre status, bir Compose uygulamasının bağlı olup olmadığını söylüyor; bağlıysa build modunu (buildContinuous, --auto için true, explicit mod için false), reload durumunu (reloadState), son hatayı (isteğe bağlı lastErrorDetails ile birlikte), başarılı ve başarısız reload sayılarını ve o anda render edemeyen pencereleri (uiErrorWindows) raporluyor. README bu alanın işlevini de açıkça yazıyor: reload ile await_reload arasında seçim yapmak için buildContinuous değerine bakılıyor.
İkinci bağlantı noktası zaman aşımı davranışı: reload, await_reload ve restart araçlarının isteğe bağlı bir timeout_seconds parametresi var ve varsayılanı 60 saniye. Bu süre içinde iş bitmezse reload/await_reload {"status": "reloading"} döndürüyor; README'nin tarif ettiği akış, reloadState artık reloading olmayana kadar status'u yoklamak. restart için karşılığı {"reconnected": false} ve bu kez connected alanının true olmasını bekliyorsun. Pencere hedefleyen araçlarda ise window_id parametresini vermezsen sunucu "ilk kayıtlı pencere" üzerinde çalışıyor; README bunu uygulamanın pencere durumuna eklediği ilk pencere diye tanımlıyor ve o pencere kapatılırsa "ilk kayıtlı" girdinin çalışma zamanında değişebileceğini de not ediyor.
Kurulum: ajanı çalışan uygulamaya bağlamak
Ajanı bağlamanın iki ayrı yolu var. Birincisi, CHR'nin kendi README'sinin tarif ettiği yol: ajanın MCP istemci yapılandırmasını hotMcpServer Gradle görevine yöneltmek. Gradle projelerinde command alanı ./kotlin değil ./gradlew olur; README'nin .mcp.json örneği şöyle:
1{2 "mcpServers": {3 "compose-hot-reload": {4 "command": "./gradlew",5 "args": ["--no-daemon", "--quiet", "--console=plain", "hotMcpServer"]6 }7 }8}README'ye göre burada kısa ve niteliksiz hotMcpServer adı yeterli: Gradle bu adı mevcut projeye ve tüm alt projelerine karşı çözüyor, camelCase kısaltması da hedefe özgü hotMcpServerJvm/hotMcpServerDesktop görevleriyle eşleşiyor. Bir modül birden fazla JVM target tanımlıyorsa kısa ad belirsizleşir; o durumda açık :<module>:hotMcpServer<Target> biçimini yazman gerekiyor. İkincisi, Kotlin Toolchain'in sağladığı CLI yolu: ajanının MCP yapılandırmasına ./kotlin compose-hot-reload-mcp-server komutunu tanıtmak. Kotlin Toolchain 0.12 duyurusundaki mcp.json örneği şu şekilde:
1{2 "mcpServers": {3 "Compose Hot Reload": {4 "command": "./kotlin",5 "args": ["compose-hot-reload-mcp-server"]6 }7 }8}Bu girişi ajanının MCP istemcisine tanıttığında, ajan uygulamayla etkileşime girebiliyor, reload/restart tetikleyebiliyor, pencere görüntüsü alabiliyor ve composable ağacını dump edebiliyor — Kotlin Toolchain duyurusunun kendi ifadesiyle: "agents can interact with, reload, restart, and view window snapshots, and dump the tree of composables." (kaynak: JetBrains Kotlin blog, Kotlin Toolchain 0.12 duyurusu).
Pratikte akış şöyle işliyor: girdiyi tanıttıktan sonra sunucuyu elle başlatman gerekmiyor — README'nin ifadesiyle "you don't need to run this task yourself — your AI agent launches the server for you once you point it to this task". Ajan sunucuyu kendisi ayağa kaldırıyor, status ile mevcut durumu kontrol ediyor, sonra kod değişikliğini öneriyor ve await_reload ile sonucu bekliyor. Uygulamanın o anda çalışıyor olması da şart değil: README'ye göre sunucu başlıyor, uygulamanın açılmasını bekliyor ve ardından otomatik bağlanıyor.
Tipik bir oturumun akışı şöyle özetlenebilir: önce status ile mevcut durumu öğrenirsin, sonra bir kod değişikliği önerirsin (bu adım MCP sunucusunun dışında, senin veya ajanın normal dosya düzenleme aracıyla olur), ardından reload ile değişikliği tetikler, await_reload ile tamamlanmasını beklersin. Eğer sonuç beklediğin gibi değilse get_ui_error ile hatayı okur, gerekiyorsa take_screenshot ile ekranın son halini görürsün. Bu döngü, her adımda ayrı bir terminal komutu veya IDE penceresi arasında geçiş yapmadan, tek bir MCP oturumu içinde tamamlanıyor — sunucunun otomatik yeniden bağlanma özelliği sayesinde uygulama çökse veya yeniden başlatılsa bile ajan bağlantısını kaybetmiyor.
Kotlin Toolchain 0.12 ile CLI'dan çalıştırma
Kotlin Toolchain 0.12.0, 25 Ağustos 2026'da GitHub Releases üzerinden yayınlandı. Bu sürümle birlikte Compose Hot Reload'ın komut satırı desteği düzgün hale geldi:
1kotlin run --compose-hot-reload-modeKotlin blog duyurusu bu komutu şöyle tanımlıyor: "We now properly support Compose Hot Reload from the command line using the kotlin run --compose-hot-reload-mode command." Aynı duyuruda iki performans notu daha var: ilk reload artık daha hızlı tamamlanıyor ve build daha az kaynak tüketiyor; ayrıca DevTools menüsündeki "Restart the application" aksiyonu artık destekleniyor. Bu, bir ajan CLI üzerinden çalıştığında, yani IDE açmadan doğrudan terminalden, hot reload akışına erişebilmesi anlamına geliyor — ajanın MCP sunucusuna bağlanması için ayrı bir IDE oturumu açık tutman gerekmiyor.
Flutter tarafındaki resmi MCP eşdeğeri
Flutter'da resmi bir MCP server var — bu, Compose tarafındaki gelişmeyle karşılaştırırken netleştirilmesi gereken önemli bir nokta. Resmi Dart ve Flutter MCP server, Dart SDK ve Flutter araçlarına stdio üzerinden bağlanan bir Model Context Protocol sunucusu; statik analiz/diagnostik, sembol çözümleme, çalışma zamanı introspeksiyon, paket yönetimi ve test/format yetenekleri sunuyor (kaynak: docs.flutter.dev/ai/tools). Claude Code dahil birçok araç için resmi kurulum talimatları var; sunucu dart mcp-server komutuyla çağrılıyor:
1{2 "mcpServers": {3 "dart": {4 "command": "dart",5 "args": ["mcp-server"]6 }7 }8}Bu yapılandırma docs.flutter.dev/ai/get-started sayfasındaki Antigravity CLI örneğinden alınıyor; oraya projenin .agents/mcp_config.json dosyasına (ya da global olarak ~/.gemini/config/mcp_config.json içine) yazılıyor ve aynı JSON deseni sayfanın "Other" sekmesindeki MCP uyumlu istemciler için de geçerli. Claude Code ise elle JSON yazarak değil, marketplace komutlarıyla kuruluyor: claude plugin marketplace add flutter/agent-plugins ardından claude plugin install dart-flutter@dart-flutter. Dikkat edilmesi gereken bir nokta daha var: dart.dev/tools/mcp-server adresi artık docs.flutter.dev/ai/mcp-server üzerinden bu sayfaya yönlendiriliyor — yani resmi MCP dokümantasyonu "AI'a başlarken" akışının içine taşınmış durumda.
Peki iki sunucunun yetenek kapsamı birebir aynı mı? Hayır — ve bu fark makalenin en pratik kısmı:
Yetenek | Compose Hot Reload MCP | Dart/Flutter MCP |
|---|---|---|
UI etkileşim otomasyonu ( click, type_text, scroll) | Var | Dokümante araç listesinde yok |
Ekran görüntüsü ( take_screenshot) | Var | Dokümante araç listesinde yok |
Runtime introspection (çalışan uygulama durumu) | status, get_ui_error, get_logs | "Query the state of a running Flutter application during active debugging sessions" |
Statik analiz / sembol çözümleme | Yok (bu CHR'nin işi değil) | Var (analyzer entegrasyonu) |
Test/format/paket yönetimi | Yok | Var |
Yani Compose tarafı UI'ı görüp etkileşime giren bir ajan için tasarlanmış; Dart/Flutter MCP server ise ağırlıklı olarak analyzer, sembol çözümleme, test ve paket yönetimi tarafında, runtime introspection'ı da kapsıyor ama click/type/scroll gibi UI-otomasyon araçları resmi dokümanda listelenmiyor. Bunlara ek olarak Google'ın "Developer Knowledge MCP server"ı var — dokümantasyonun kendi tanımıyla bulut tabanlı bir dokümantasyon arama sunucusu; docs.flutter.dev, dart.dev ve resmi API referanslarını kapsayan Google geliştirici dokümantasyon korpusuna bağlanıyor, canlı kod introspeksiyonu değil (kaynak: docs.flutter.dev/ai/tools).
Ajanın gördüğü ve GÖREMEDİĞİ şeyler
Compose Hot Reload MCP server'ının araç listesini yakından incelediğinde bir sınır net görünüyor: ajan yalnızca sunucunun açığa çıkardığı komutlarla konuşabiliyor. status, reload, restart, take_screenshot, get_semantic_tree, get_logs, click, type_text, scroll — sürüm notlarındaki liste açık uçlu; repo README'si bunlara ek olarak long_click ve scroll_to_index araçlarını da belgeliyor. Ortak nokta, araç yüzeyinin çalışan uygulamayla sınırlı olması: iki kaynakta da dosya sistemi ya da build script erişimi veren bir araç yok. Yani ajan projendeki rastgele dosyalara erişemiyor, build script'lerini değiştiremiyor, dosya sistemine dokunamıyor; yalnızca çalışan uygulamanın kendisiyle, sunucunun tanımladığı sınırlı bir arayüzden konuşuyor.
İkinci sınır platform tarafında: Compose Hot Reload projede bir JVM target zorunluluğu getiriyor. Resmi repo README'sinde bu açıkça belirtiliyor — diğer hedefler için destek "keşif aşamasında" (kaynak: compose-hot-reload GitHub reposu). Yani Eylül 2026 itibarıyla doğrulanan duruma göre bu MCP akışı yalnızca JVM/desktop hedefinde çalışıyor; Android/iOS native çıktısı üreten bir Compose Multiplatform projesinde bu hot reload MCP akışını birebir bekleme.
Üçüncü sınır da mimari: sunucu hotMcpServer Gradle görevi üzerinden, yani projenin build sistemine gömülü, yerel bir süreç olarak ayağa kalkıyor. Ajan erişimi geliştiricinin kendi makinesinde koşan bu yerel sunucuyla sınırlı — uzak veya genel bir uç nokta değil.
Bu üç sınırı birlikte düşününce ortaya net bir kullanım profili çıkıyor: bu MCP server, geniş yetkili özerk bir "her şeyi yapabilen ajan" değil, dar kapsamlı ve öngörülebilir bir geliştirme yardımcısı. Ajan uygulamanı silemez, bağımlılıklarını değiştiremez, başka bir projeye sıçrayamaz — yalnızca MCP girdisini tanımladığın projede, o projenin çalışan Compose uygulamasıyla, sunucunun listelediği komutlar üzerinden konuşabilir. Bu sınırlılık aslında bir güvenlik özelliği: ajanın hata yapma alanı, sunucunun araç yüzeyiyle sınırlı kalıyor.
Güvenlik ve izin sınırları
Model Context Protocol'ün kendisi, resmi tanımıyla "AI uygulamalarını harici sistemlere bağlayan açık kaynak bir standart" (kaynak: modelcontextprotocol.io). Aynı sayfa, protokolün veri kaynaklarına, araçlara ve iş akışlarına standartlaştırılmış erişim sağladığını, bunun geliştirici, ajan ve son kullanıcı için farklı faydalar taşıdığını anlatıyor: "MCP results in more capable AI applications or agents that can access user data and take actions on the user's behalf when necessary."
Bu genel çerçeve, Compose Hot Reload MCP server'ı için somut bir izin modeline dönüşüyor — ama kontrol noktası çoğu kişinin sandığı yerde değil. README bunu açıkça yazıyor: "The agent then starts and stops the server on its own — there is no need to launch it manually." Yani erişimi belirleyen şey senin bir Gradle görevini ayakta tutup tutmaman değil, ajanın MCP istemci yapılandırması: bu girdi ajanın yapılandırmasında tanımlı değilse sunucu hiç ayağa kalkmaz, tanımlıysa ajan sunucuyu gerektiğinde kendisi başlatır ve durdurur. Sunucunun yine de yerel makinende ve proje bağlamında çalıştığını unutma; uzak ya da genel bir uç nokta değil. Bu yüzden CI ortamında veya paylaşılan bir sunucuda dışarıdan bir ajanın uygulamana bu yoldan erişmesi, ajanın istemci yapılandırmasında bu girdi tanımlı değilse söz konusu olmuyor. Pratik alışkanlık da buradan çıkıyor: click/type_text gibi etkileşim araçlarının yanlış zamanda tetiklenmesini istemiyorsan MCP girdisini global yapılandırmaya değil, yalnızca ajanla birlikte çalıştığın projeye yaz.
Neyi otomatikleştiriyor, neyi garanti etmiyor
Resmi kaynaklar ölçülmüş bir hızlanma değeri değil, yalnızca araç setini tanımlıyor. Kesin olarak söylenebilecek şey, sunucunun _hangi adımları tek protokol içine topladığı_: ajanın manuel olarak terminale geçip build çıktısını okuması, ekran görüntüsü almak için ayrı bir araç çağırması, log dosyasını açması gereken adımlar artık status, take_screenshot, get_logs gibi tek çağrılarla aynı oturumda yapılabiliyor.
Yanıltıcı olan taraf da şu: bu bir otomasyon _yeteneği_, otomatik doğruluk garantisi değil. Ajan get_semantic_tree ile UI'ı okuyabilir ama bunun anlamlı bir test senaryosuna dönüşmesi hâlâ senin (veya ajanın) doğru sorguyu kurmasına bağlı. Aynı şekilde click/type_text ile etkileşim simüle edebilmek, ajanın uygulamanın iş mantığını anladığı anlamına gelmiyor — yalnızca UI ağacına erişimi olduğu anlamına geliyor. Resmi kaynaklar araç setini tanımlamakla yetiniyor: sunucu adımları kısaltıyor, sonucun doğruluğunu üstlenmiyor.
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Compose ve Flutter tarafında ajanı çalışan uygulamana bağlamadan önce gözden geçirmen gereken kontrol listesi aşağıda. Bu listeyi kurulum öncesi ve MCP sunucusunu her yeniden başlattığında hızlıca tarayabilirsin.
SSS
Compose Hot Reload MCP server nasıl kurulur?
Compose Hot Reload 1.2.0 ve sonrasıyla gelen hot-reload-mcp modülü sunucuyu hotMcpServer Gradle görevi üzerinden açığa çıkarır; bu sunucu çalışan Compose uygulamasına bağlanır, başlangıcı bekler, kapanmaları algılar ve otomatik yeniden bağlanır. Kurulum, ajanın MCP istemci yapılandırmasına bir girdi eklemekten ibaret: Gradle projelerinde command alanına ./gradlew ve args içine hotMcpServer, Kotlin Toolchain kullanıyorsan ./kotlin compose-hot-reload-mcp-server. Görevi elle çalıştırman gerekmiyor — README'ye göre sunucuyu ajan başlatıp durduruyor; sonrasında status, reload, take_screenshot, click gibi araçları kullanabilirsin.
AI ajanı çalışan mobil uygulamayı nasıl test eder?
Compose tarafında ajan take_screenshot, get_semantic_tree, click/type_text/scroll araçlarıyla arayüzü gözlemleyip etkileşime girebilir, get_ui_error/get_logs ile hata teşhisi yapabilir. Flutter/Dart tarafında ise resmi MCP server runtime introspection ile çalışan uygulamanın durumunu debug oturumunda sorgulayabiliyor, ancak dokümante edilen araç listesinde doğrudan click/type gibi UI-otomasyon fonksiyonları görünmüyor — ağırlık analyzer, sembol çözümleme ve test tarafında.
Claude Code ile Flutter/Compose hot reload nasıl birleştirilir?
Flutter tarafında resmi kurulum adımları docs.flutter.dev/ai/get-started sayfasında anlatılıyor: marketplace üzerinden eklenti eklenir ve Dart/Flutter MCP server bağlanır. Compose tarafında ise Kotlin blogundaki mcp.json girdisi kullanılır: command alanına ./kotlin, args alanına compose-hot-reload-mcp-server yazılarak aynı ajanın MCP istemcisine tanıtılır. Her iki entegrasyon da aynı standart MCP protokolü üzerinden çalıştığı için prensipte tek bir ajan iki ortamda da kullanılabiliyor.
Agentic hot reload gerçekten işe yarıyor mu?
Resmi kaynaklar yalnızca özellik setini tarif ediyor: screenshot alma, click/scroll simülasyonu, semantic tree okuma, log okuma. Ölçülmüş bir güvenilirlik veya hız değeri vermiyorlar; en doğru yaklaşım, sunucunun sunduğu yetenekleri bu tanım üzerinden değerlendirip kendi projende küçük ölçekte denemek.
Compose Hot Reload MCP server hangi platformlarda çalışıyor?
Yalnızca JVM/desktop hedefinde. Compose Hot Reload'ın resmi reposu, projede bir JVM target'ı zorunlu kıldığını ve diğer hedefler için desteğin henüz keşif aşamasında olduğunu belirtiyor. Android veya iOS'a native derlenen bir Compose Multiplatform hedefinde, Eylül 2026 itibarıyla doğrulanan duruma göre bu MCP akışını bekleme.
Dart/Flutter MCP server'ı hangi editörlerle kullanabilirim?
Resmi dokümantasyon Antigravity, Claude Code, Cursor, Codex ve GitHub Copilot gibi araçlar için kurulum talimatları veriyor. Bir kısmı eklenti kurulumuyla otomatik yapılandırılıyor — dokümana göre Cursor paketlenmiş skill'leri kendisi keşfedip Dart ve Flutter MCP server'ını yapılandırıyor, Claude Code ve Codex ise marketplace komutlarıyla kuruluyor. Bir kısmında ise dart mcp-server girdisini elle eklersin: Antigravity CLI .agents/mcp_config.json içinde mcpServers, GitHub Copilot .vscode/mcp.json içinde servers anahtarını kullanıyor.
Sonuç
Compose Multiplatform 1.12.0 ile duyurulan, kaynağı asıl compose-hot-reload 1.2.0'a dayanan MCP server, AI ajanlarının çalışan bir Compose uygulamasıyla status, reload, screenshot ve UI-etkileşim araçları üzerinden konuşmasını sağlıyor — ama yalnızca JVM/desktop hedefinde ve yerel, sunucunun kendi tanımladığı sınırlı bir araç setiyle. Flutter tarafında da resmi bir MCP server var, fakat ağırlık farklı: analyzer, sembol çözümleme, test ve runtime introspection öne çıkıyor, click/type gibi UI-otomasyon araçları dokümante edilmiyor. İki ekosistemi karşılaştırırken "hangisi daha iyi" sorusundan çok "hangi ajan görevi için hangi araç seti uygun" sorusunu sormak daha doğru.
Compose tarafındaki mimari kararları ve performans notlarını Jetpack Compose 1.7 strong skipping performans yazısından takip edebilirsin. MCP protokolünün genel çalışma mantığını Claude Code MCP entegrasyon rehberinden ve MCP'nin AI entegrasyonundaki rolünü anlatan yazıdan okuyabilirsin. Ajanları production akışlarında araç kullanımıyla nasıl çalıştırdığımızı agentic AI tool use ve planner loop yazısında ele almıştık. Flutter tarafındaki güncel sürüm değişikliklerini ise Flutter 3.47 Material/Cupertino paket geçişi yazısından takip edebilirsin. Kotlin ekosisteminde çoklu platform kararlarını değerlendirenler için Kotlin Multiplatform 1.1 production case study ve Compose ile SwiftUI'ı yan yana koyan 60K LOC production karşılaştırması de ilgini çekebilir.
Kaynaklar
- Compose Multiplatform 1.12.0 release notes — MCP server'ın Compose Hot Reload'a eklendiğini duyuran resmi sürüm notu
- Compose Multiplatform #5671 PR — CHR sürümünü 1.2.0'a yükselten cherry-pick PR
- compose-hot-reload v1.2.0 release notes — MCP server'ın araç setinin (
status,reload,take_screenshotvb.) birincil kaynağı - Kotlin Toolchain 0.12 duyurusu — JetBrains Kotlin blog —
mcp.jsonyapılandırması vekotlin run --compose-hot-reload-modekomutu - Kotlin Toolchain v0.12.0 release notes — sürüm tarihi ve değişiklik listesi
- Dart ve Flutter MCP server dokümantasyonu — resmi araç setinin tanımı ve runtime introspection detayı
- Flutter AI ile başlarken rehberi — Claude Code dahil editörler için
dart mcp-serverkurulum örnekleri - Model Context Protocol resmi sitesi — MCP'nin genel tanımı ve farklı taraflar için sağladığı faydalar
- compose-hot-reload GitHub reposu — JVM target zorunluluğu ve platform desteği notu
Etiketler
iOS Geliştirme Haberleri
Haftalık Swift tips, SwiftUI tricks ve iOS best practices. Spam yok, sadece değerli içerik.
Onay e-postasındaki bağlantıyı açıp “Aboneliğimi onayla” düğmesine bastığında aboneliğin başlar. Bültende açılma/tıklama istatistikleri tutulur; dilediğin an tek tıkla ayrılabilirsin. Gizlilik
