Geçen yıl WWDC 2022 için tam olarak aynı amaçla en büyük 3 dileğimi listelediğim bir yazı yazmıştım. Neyse ki bunlardan biri (3 numaralı dilek) gerçekten gerçekleşti, Xcode 14 Sürüm Notları ilgili yeni özelliği şöyle açıklıyor:
Simplify an app icon with a single 1024x1024 image that is automatically resized for its target. Choose the Single Size option in the app icon’s Attributes inspector in the asset catalog. You can still override individual sizes with the All Sizes option. (18475136) (FB5503050)
Diğer iki dileğim hala geçerli ve listenin başında duruyor:
#1: CoreData’nın yerini alacak yeni bir yalnızca Swift’e özel veritabanı framework’ü. Böyle bir framework’ün nasıl çalışabileceğini burada detaylandırdım, detaylar için oraya bak.
#2: Xcode içinde uygulama modülerleştirme desteği. Şu anda uygulamamı modülerleştirmek için uzun bir Package.swift dosyasını elle yönetmek zorundayım, daha fazlası için bunu oku.
Bunlar bir yana, işte bu yılki WWDC için 3 yeni dileğim.
#3: Swift Charts kütüphanesinde dairesel grafikler
Geçen yılki yazımın sonunda şöyle demiştim:
Geçmişte en az bir veya iki framework’le tamamen şaşırtılmıştım — 2019’da SwiftUI, 2020’de WidgetKit ve 2021’de DocC gibi. Bu yıl ne olacak? Öğrenmek için sabırsızlanıyorum!
Kesinlikle Swift Charts oldu! Her uygulamanın hemen ihtiyaç duymayabileceği yeni parlak kütüphane, ama eminim birçok geliştiriciyi uygulamalarının verilerinden bazılarını görselleştirerek kullanıcılara kattıkları verilerin daha iyi bir genel görünümünü sunmaları için ilham verecek. Yalnızca SwiftUI’a özel, yani henüz tüm ekipler bundan yararlanma fırsatı bulamadı.
Charts kütüphanesinin ilk versiyonu, hepsinin ortak özelliği olarak yalnızca bir veya iki düz eksene ihtiyaç duyan iyi miktarda grafik türüyle geldi. Mesela, çizgi grafikler, çubuk grafikler ve hatta ısı haritaları çizebilir (ve özelleştirebilirsin). Jordi Bruin bugün neler yapılabileceğine dair iyi bir genel bakış sunan ekran görüntüleri ve kaynak kodla bir GitHub repo’su hazırladı.
Ama Twitch’teki canlı yayınlarımda geliştirdiğim açık kaynak uygulama Open Focus Timer için Swift Charts kütüphanesini kendim denediğimde, kullanıcılara çalışma sürelerinin farklı projeler arasında nasıl dağıldığını gösteren bir pasta grafik göstermek istedim. Ama pasta grafikler şu anda Charts kütüphanesi tarafından desteklenmiyor, tıpkı örümcek grafikler, halka grafikler veya sunburst grafikler gibi. Bence bunlar o kadar yaygın ki, hepsi bu yıl Charts kütüphanesinin ikinci versiyonuna eklenmeli.
Ve gelecek yıl belki ağaç benzeri grafikler (veya diyagramlar) da eklenebilir; bu, profesyonel araçlar oluşturmaya yardımcı olabilir — mesela bir uygulamanın model katmanının UML diyagramını çizmek, B-ağaçları gibi veri yapılarını görselleştirmek veya özellikleri daha soyut bir düzeyde anlamaya yardımcı olabilecek interaktif durum makineleri oluşturmak için. Bu tür grafikler veya diyagramlar için harika kullanım alanları oluşturacak yeterince fikrim var!
#4: Xcode’da kodu gizleyen Yayıncı Modu
İçerik paylaşmak harika bir şey. Sadece içeriğini tüketen başkalarının yeni bir şey öğrenmesine veya ilham almasına yardımcı olmakla kalmıyor. Geri bildirimleri, içerik üreticisinin henüz düşünmediği yeni yönleri — ince hatalar, kullanıcı deneyimi sorunları veya erişilebilirlik eksikliği gibi — keşfetmesine de yardımcı olabilir. Ama paylaşılacak içerik bir kodlama projesiyle ilgiliyse, güvenlik ve gizlilik endişeleri devreye giriyor.
Mesela, 3. taraf servislerle entegre olan açık kaynak bir framework’ü toplulukla paylaşırken, hiçbir test kimlik bilgisinin repo’ya commit edilmemesini sağlamamız gerekir, yoksa sızabilir ve kötüye kullanılabilir. Aslında bu örnek, açık kaynak aracım BartyCrouch için SwiftPM’de tam olarak karşılaştığım durum — bunu nasıl çözdüğümü bu yazıda anlattım.
Ve gizli bilgiler, başkalarından saklamak istediğimiz tek şey değil: Hiçbir şirket, çözmek için çok emek harcadığı ürünlerinin temel değerinin potansiyel bir rakibe sızmasını istemez. Kopyacılar, işletmeleri yok edebilecek ciddi bir sorun. Git repo’ları için çözüm yeterince basit: Sızmaması gereken değerli kod kapalı kaynak tutulmalı ve asla dışarıdakilerle paylaşılmamalı.
Fotoğraf: Kristina Flour / Unsplash
Ama gizli bilgileri Git repo’sundan saklamak veya kod tabanının bazı kısımlarını gizli tutmak hikayenin sadece bir kısmı. Peki ya yardım etmek isteyen arkadaşlar veya yabancılarla yapılan video görüşmeleri? Peki ya çalışmalarını olabildiğince fazla canlı yayınlamak isteyen bağımsız geliştiriciler (benim gibi)? Ekranımı paylaşıp gerçek uygulamamın bağlamında belirli bir problemi veya çözümü göstermek isteyeceğim çok fazla durum var, ama yapmıyorum. Hassas kodun yanlışlıkla sızma riski benim için çok yüksek. Bu, birçok kaçırılmış fırsata yol açıyor:
Bağımsız bir geliştirici olarak, kapalı kaynak uygulamalarımın güncellemelerini bile canlı yayınlamak isterdim, ama sızdırmak istemediğim kısımlar var. Bu yüzden yaptığım tek şey açık kaynak çalışmalarımı yayınlamak. Bu büyük bir hayal kırıklığı.
Bir framework kullanıcısı olarak, hata raporları veya özellik istekleri için ekranımı hızlıca kaydedip bağlam içindeki kullanımın bir videosunu paylaşmak isterdim. Şu anda çoğu zaman bir şey raporlamayı atlıyorum çünkü bir demo hazırlamayı çok zahmetli buluyorum. Ya da bağlamdan kod parçaları kopyalıyorum ve sonra neden tam olarak böyle yaptığımı açıklamak için birçok soruya cevap vermek zorunda kalıyorum.
Haftalık geliştirici alışveriş toplantısının katılımcısı olarak, sorunlarla karşılaştığımda ekranımı paylaşıp detaylı göstermek yerine soyut düzeyde kod hakkında konuşmayı tercih ediyorum. Ve ekranımı paylaşsam bile, karşımdaki kişinin ekranımı kontrol etmesine asla izin vermem (mesela bana hızlıca bir şey göstermek için). Biliyorum, sorunun bir kısmı güven sorunlarım, ama yalnız değilim.
İstediğim şey, Xcode’da kod tabanımın belirli kısımlarını “gizli” olarak işaretleme özelliği ve ekranımı paylaştığımda tüm gizli kısımların paylaşılan ekrandan gizlenmesi. Bu tür bir özellik, Discord gibi uygulamalarda yaygın olarak “Yayıncı modu” olarak adlandırılıyor. Ve çeşitli şekillerde uygulanabilir, ben şöyle hayal ediyorum:
Gizli içerik yayıncı için görünür kalabilir ama Xcode tarafından vurgulanarak yayıncının paylaşılan hiçbir içerikte görünmeyeceğinin farkında olması sağlanır.
İçeriği “gizli” olarak işaretleme farklı seviyelerde yapılabilir — dosya seviyesi (dosyanın tüm içeriği gizlenir), tip seviyesi, fonksiyon seviyesi veya değişken seviyesi. Son durumda tüm satırlar gizlenir.
Gizlenen içeriğin adları yine gösterilebilir (dosya adı / tip adı / fonksiyon bildirimi / değişken adı) ve yalnızca gövdeleri/değerleri gizlenir.
“Gizli” olarak işaretlenmiş tüm içeriklerin adları düzenlemeden kilitlenebilir, böylece yeniden adlandırmanın geçici olarak içeriklerin sızmasına neden olması önlenir.
Gizlilik işaretlemeleri Git’e commit edilebilecek bir dosyada saklanabilir, böylece ekipteki diğer geliştiriciler de dış görüşmelerinde bunlardan faydalanabilir.
Yayıncı modu, herhangi bir uygulama ekran yakalama API’lerini kullandığında otomatik olarak etkinleştirilebilir, böylece geliştiricinin “Yayıncı modunu” elle açmayı hatırlaması gerekmez. Bu hem video görüşmeleri (FaceTime/Zoom vb.) hem de ekran kayıtları (OBS/QuickTime vb.) için çalışmalı.
Böyle bir özelliğin Xcode’a gelmesi konusunda çok iyimser değilim çünkü bu, birçok geliştirici tarafından yaygın olarak dile getirilen bir sorun gibi hissetmiyor. Niş bir konu gibi görünüyor. Ama bence, sahip olduğunu bilmeden eksikliğini hissetmediğin ama alışınca asla vazgeçmek istemeyeceğin özelliklerden biri.
#5: iPhone ile AR/VR OS geliştirme
Tim Cook, AR’ın potansiyelinden 2016’nın başlarından beri kamuoyunda bahsediyor. Apple’ın en az bir yıl öncesinden araştırmaya başlamadan bir şey hakkında konuşmayacağını varsayarsak, Apple’ın en az 8 yıldır AR ürünleri üzerinde çalıştığını rahatlıkla söyleyebiliriz. İlk iPhone’un geliştirilmesi iki buçuk yıl sürdü. İlk Apple Watch üç yıl geliştirme aldı. Dolayısıyla Apple’ın ilk AR cihazını neden hala almadığımız sorulabilir, ama ben basitçe bu yıl alacağımızı varsayacağım. Ve bu yeni cihazın kendi işletim sistemiyle geleceğini de varsayacağım, ona “AR/VR OS” diyelim.
Böyle bir cihaz duyurulduğunda geliştiriciler için bir sorun görebiliyorum: Her geliştirici hemen yeni bir cihaz satın alamayacak. Bazıları mali kısıtlamalar nedeniyle, bazıları da ilk nesil ürünlerin tüm ülkelerde aynı anda mevcut olmaması nedeniyle. Geçmişte bu büyük bir sorun değildi. iPhone, iPad, Apple Watch ve hatta Apple TV için Xcode ile gelen simülatörler var. Bazı kısıtlamalar olsa da (kamera desteği gibi), çoğu uygulama bu simülatörlerde tam olarak geliştirilebilir ve büyük ölçüde test edilebilir. Bunun nedeni, tüm bu cihazların geliştirme cihazımız Mac ile ortak bir özelliği olması: Hepsi düz bir ekranda sanal arayüz render ediyor.
Ama bir AR cihazı farklı: Tanımı gereği “gerçekliği artırıyor”, yani herhangi bir faydalı uygulamayı düzgün şekilde geliştirmek ve test etmek için “artıracak” bir şeyimiz olması adına bir kamera akışına erişmemiz gerekiyor. Apple, konum simülasyonunda yaptığı gibi AR/VR simülatöründe test için bazı örnek sanal ortamlar sağlayabilir, ama bu birçok kullanım durumu için çok kısıtlayıcı olur ve çalışması da sinir bozucu olabilir.
Bunun yerine, Apple’ın geliştiricilere bağlı bir iPhone veya iPad’in kamera akışını kullanarak AR/VR OS geliştirmesini test etme yolu sunmasını diliyorum. Bu, teknik bir gereklilikse LiDAR tarayıcılı cihazlarla sınırlandırılabilir. Ama kablosuz olarak da çalışmalı çünkü özelliklerimizi dünyanın farklı yerlerinde test etmek için etrafta yürümek isteyeceğiz. Bunun temel teknolojisi zaten iPhone’u web kamerası olarak kullanmaya izin veren Continuity Camera şeklinde gönderildi. Belki de bu özellik aslında AR ürünü üzerinde çalışan dahili ekip için yapılmış test işlevselliğinin bir yan ürünüydü. Kim bilir? Bu, geleceğinin bir işareti olabilir.
Ama daha da önemlisi, AR/VR OS için gerçek cihaz olmadan bir şekilde test yapma imkanı alacağımız konusunda neden iyimser olduğum şu: Apple, mümkün olduğunca çok uygulamanın cihazı desteklemesini istiyor. Ve bu, bunun için uygulama geliştirmenin olabildiğince kolay olması gerektiği anlamına geliyor. Sonuçta, (benzersiz) uygulamaların mevcudiyeti herhangi bir yeni yazılım platformunun önemli bir satış noktası.
Peki ya yapay zeka çılgınlığı?
Xcode’da daha iyi otomatik tamamlama desteği veya hatta ne istediğimi söyleyebildiğim ve kriterlerimi karşılayan kodu yazan bir tür sanal kodlama asistanı istesem de, henüz o noktada olduğumuzu düşünmüyorum. ChatGPT ile oynadım, ama kod sorduğumda %80 oranında yanlış cevaplar verdi. Sürekli kullanımdan kaldırılmış API’ler kullanmakla kalmadı, derlemeyen kod da üretti. Çoğu zaman ne istediğimi bile anlamadı.
Apple’dan kodlamaya özel bir model daha iyi sonuçlar verebilir, ama “güvenilir” olarak adlandıracağım seviyeye yaklaşacağını düşünmüyorum. Ve Apple’ın bunu bildiğinden eminim. Gelecekte böyle bir özelliği keşfedebilirler, ama umarım mevcut trend trenine atlayıp yarım yamalak bir şeyi Xcode’a yerleştirmeye çalışmazlar. Güvenebileceğim ve tahmin edilebilir araçları tercih ederim. Apple’ın da öyle düşündüğüne inanıyorum. Ama teknoloji henüz hazır değil. Bu yönde büyük bir şeyi en erken gelecek yıl bekliyorum, bu yıl varsa bile çok küçük bir şey olur.
Sonuç
İşte bunlar WWDC 2023 için benim en büyük 5 dileğim. Benimle aynı fikirde misin? Seninkiler neler? Twitter’da burada veya Mastodon’da şurada yorum yaparak bana bildir.