Vapor’da bağlantı havuzlarını yapılandırırken – ister Redis, PostgreSQL veya diğer veritabanları için olsun – maximumActiveConnections adlı bir parametreyle karşılaşıyorsun. Doğal varsayım, bunun uygulamanın toplam maksimum bağlantısını ayarladığı. Ayarlamıyor. NIO EventLoop başına maksimumu ayarlıyor.

Bu ayrım production’da büyük önem taşıyor.

Beni Şaşırtan Hesap

Tipik bir sunucuda, Swift NIO her CPU çekirdeği için bir EventLoop oluşturuyor. Yani gerçek maksimum bağlantı sayısı:

gerçek max = maximumActiveConnections * CPU çekirdekleri * dyno/instance sayısı

maximumActiveConnections‘ı 8 olarak yapılandırmıştım, Redis bağlantılarımı iki dyno’da makul bir 16 ile sınırladığımı düşünüyordum. Gerçek sayı:

8 (event loop başına) * 8 (çekirdek) * 2 (dyno) = 128 potansiyel bağlantı

Bu, hedeflenenden bir büyüklük sırası daha fazla ve trafik zirveleri sırasında Redis sağlayıcımın bağlantı limitini aşıyordu.

Belirtiler

Başarısızlık modu özellikle sinsi: sadece yük altında ortaya çıkan aralıklı 500 hataları. Normal trafik sırasında gerçek bağlantı limitine asla ulaşmıyorsun, bu yüzden her şey sorunsuz çalışıyor. Zirveler sırasında, bağlantılar tüm event loop’larda aynı anda birikiyor ve sağlayıcının limitini aşıyor. Hatalar rastgele görünüyor ve geliştirme makinelerinde genellikle daha az çekirdek olduğundan yerel olarak tekrarlamak zor.

Doğru Değeri Nasıl Hesaplarsın

Sağlayıcının bağlantı limitini tüm instance’lardaki toplam event loop sayısına böl:

// Provider limit: 40 connections
// 2 dynos * 8 cores = 16 event loops total
// 40 / 16 = 2.5, round down to 2

app.redis.configuration = .init(
   pool: .init(maximumActiveConnections: 2)
)

Bu muhafazakar ayar, TranslateKit’teki aylardır beni şaşırtan uzun süredir devam eden nadir 500 hatalarını nihayet düzeltti. Her zaman bulut sağlayıcının bağlantı limitlerini kontrol et ve deploy etmeden önce çarpma işlemini yap.

Geliştirici topluluğunda yaygın bir inanış var: Feedback Assistant raporları (Radar’ın halefi) göndermek boşuna – raporlar bir boşluğa kaybolup hiçbir şey olmuyor. Benim bir özellik talebim Xcode 26’da uygulandı, bu da aksini kanıtlıyor.

İstediğin bir özelliğin bir keynote’ta veya sürüm notlarında görünmesi tatmin edici bir doğrulama. Ama daha da önemlisi, Apple’ın mühendislik ekiplerinin rapora doğrudan hiç yanıt vermese bile topluluk geri bildirimlerini gerçekten inceleyip önceliklendirdiğini gösteriyor.

Etkili Geri Bildirim Yazmak için İpuçları

Tüm raporlar eşit değil. İşte bir raporun eyleme geçirilebilir olma şansını artırdığını gördüğüm şeyler:

Sorun hakkında spesifik ol. “Xcode yavaş” işe yaramaz. “Dosya 3’ten fazla #Preview bloğu içerdiğinde Xcode’un SwiftUI preview’ının yenilenmesi 12 saniye sürüyor” mühendislere araştırabilecekleri bir şey veriyor.

Örnek bir proje ekle. Minimum düzeyde tekrarlama projesi ekleyebileceğin en değerli şey. Bir mühendis projeni build edip çalıştırarak sorunu görebiliyorsa, araştırma yapmasının önündeki en büyük engeli kaldırmış oluyorsun.

Sadece çözümü değil, kullanım senaryosunu anlat. “X yapan bir buton ekleyin” yerine, neden ihtiyacın olduğunu açıkla: “Büyük SPM grafikleriyle çalışırken, bir dosyanın hangi target’a ait olduğunu hızlıca belirlemem gerekiyor çünkü…” Bu, ekibe doğru çözümü tasarlamaları için bağlam veriyor ki bu hayal ettiğinden farklı olabilir.

Beta sezonunda bildir. WWDC’den sonraki haftalar, Apple’ın ekiplerinin yeni özellikler hakkında en aktif şekilde geri bildirim topladığı dönem. Bu zaman diliminde gönderilen raporlar, bir sürüm döngüsünün ortasında gönderilenlerden çok daha fazla ilgi görüyor.

Alışkanlık Haline Getir

Her WWDC beta sezonunda, uygulamalarını yeni OS ve Xcode betalarına karşı test etmek için zaman ayır. Her sorun ve eksik özellik için rapor gönder. Çoğu yanıt almayacak, ama bazıları sessizce gelecek sürümleri etkileyecek.

SwiftUI kodlarında sürekli gördüğüm bir kalıp var: Button‘ın label closure’ına doğrudan Image koyarak elle yalnızca simge butonları oluşturmak. Görsel olarak işe yarıyor, ama erişilebilirlik bilgisini çöpe atıyor ve SwiftUI’ın tasarımına karşı çalışıyor.

Yanlış Yol

Button {
   toggleSidebar()
} label: {
   Image(systemName: "sidebar.left")
}

Bu, dokunulabilir bir simge render ediyor, ama VoiceOver’ın duyuracak anlamlı bir etiketi yok. Kullanıcı “button” veya ham SF Symbol adı gibi bir şey duyuyor ki bu yardımcı değil.

Doğru Yol

Button("Toggle Sidebar", systemImage: "sidebar.left") {
   toggleSidebar()
}
.labelStyle(.iconOnly)

Veya açıkça Label kullanarak:

Button(action: toggleSidebar) {
   Label("Toggle Sidebar", systemImage: "sidebar.left")
}
.labelStyle(.iconOnly)

Neden Önemlidir

Label view’ı hem bir başlık hem de bir simge taşıyor. .labelStyle(.iconOnly) uyguladığında, SwiftUI başlığı görsel olarak gizliyor ama erişilebilirlik ağacında koruyor. VoiceOver “Toggle Sidebar, button” diye duyuracak – tam olarak kullanıcının duyması gereken şey.

Bu kalıp aynı zamanda kodunu daha esnek yapıyor. Daha sonra simgenin yanında metin göstermeye karar verirsen (örneğin iPad’de bir araç çubuğunda), label stilini .titleAndIcon olarak değiştirmen yeterli. Yeniden yapılandırma gerekmiyor.

Butonların Ötesinde

Aynı prensip Label kabul eden her view için geçerli: NavigationLink, Toggle, Picker, menü öğeleri. Çıplak bir Image kullanmak istediğinde, stili modifier ile bir Label’ın daha uygun olup olmayacağını kendine sor. Neredeyse her durumda, öyle.

Birden fazla kişi bir Swift paketine katkıda bulunduğunda, girintileme tutarsızlıkları sızıyor. Bir katkıcı 4 boşluk kullanıyor, bir diğeri tab kullanıyor, üçüncüsü 2 boşluk kullanıyor. Pull request’ler sadece boşluk değişiklikleriyle gürültülü hale geliyor ve kod tabanı tutarsız bir karmaşaya doğru kayıyor. Çözüm, eklemesi 30 saniye süren tek bir dosya.

.editorconfig Standardı

EditorConfig, proje bazında kodlama stili ayarlarını tanımlamak için yaygın olarak desteklenen bir standart. Xcode .editorconfig dosyalarına saygı gösteriyor, böylece katkıcılar projeyi açtıklarında otomatik olarak doğru girintileme ayarlarını alıyor – elle yapılandırma yok, okunacak dokümantasyon yok.

İşte her SwiftPM paketi için önerdiğim .editorconfig:

root = true

[*.swift]
indent_style = space
indent_size = 3

[*.{yml,yaml,json}]
indent_style = space
indent_size = 2

Swift için 3 boşluk girintileme bilinçli bir tercih. 2 veya 4 boşluktan daha az yaygın, ama iyi bir denge noktası: iç içe closure’lar için 2 boşluktan daha okunabilir, yatay alanı 4 boşluktan daha az israf ediyor. Bir kez denediğinde, standart seçenekler ya çok sıkışık ya da çok dağınık hissetmeye başlıyor.

Neden Global Ayarları Geçiyor

Her geliştiricinin genel olarak yapılandırılmış kendi Xcode girintileme tercihleri var. .editorconfig olmadan, bu genel ayarlar açtıkları her projeye uygulanıyor. Bu, 4 boşluk tab’lı bir katkıcının bir dosyayı düzenlerken sessizce kodu yeniden biçimlendireceği anlamına geliyor, proje kuralı farklı olsa bile.

Depo kökünde .editorconfig ile Xcode, genel ayarları projeye özel olanlarla geçersiz kılıyor. Katkıcıların hiçbir şeyi değiştirmesi gerekmiyor – sadece çalışıyor.

Benimseme

Bu dosyayı paket köküne bırak ve commit et. Hepsi bu. Build adımı yok, bağımlılık yok, dosyanın kendisi dışında yapılandırma yok. Çoğu modern editör (VS Code, Vim, Sublime Text) de EditorConfig destekliyor, bu yüzden Xcode kullanmayan katkıcılar da faydalanıyor.

App Store Connect iOS uygulamasının çoğu geliştiricinin hiç keşfetmediği bir özelliği var: yeni kullanıcı değerlendirmeleri için push bildirimleri. Varsayılan olarak kapalı ve her uygulama için ayrı ayrı etkinleştirmen gerekiyor, bu yüzden muhtemelen bu kadar az kişi biliyor.

Nasıl Etkinleştirilir

iPhone’unda App Store Connect uygulamasını aç, sonra şuraya git:

1. Profil simgene dokun veya Settings’e git

2. Notifications seçeneğini seç

3. Tüm uygulamalarının bir listesini göreceksin

4. Her uygulama için Customer Reviews seçeneğini aç

Bu kadar. Bundan sonra, birisi o uygulama için yeni bir değerlendirme bıraktığında push bildirimi alacaksın.

Bağımsız Geliştiriciler İçin Neden Önemlidir

App Store değerlendirmelerine hızlı yanıt vermenin somut bir etkisi var. Bir kullanıcı bir hata hakkında olumsuz değerlendirme bıraktığında, sorunu kabul eden (veya bir çözüme yönlendiren) hızlı bir yanıt, kullanıcının puanını güncellemesine yol açabiliyor. Olumlu değerlendirmeler de takdiri hak ediyor – kullanıcıları geri bildirim vermeye devam etmeye teşvik ediyor.

Bildirimler olmadan, çoğu geliştirici değerlendirmeleri ancak hatırladığında kontrol ediyor ki bu günler veya haftalar sonra olabiliyor. O zamana kadar kullanıcı çoktan unutmuş oluyor ve yanıtın sonradan akla gelen bir şey gibi hissettiriyor.

Bir Uyarı Notu

Yüksek değerlendirme hacmine sahip birden fazla uygulamanın varsa, hepsi için bunu etkinleştirmek gürültülü olabilir. En önemli uygulamalarınla başla ve gerçekte ne kadar bildirim aldığına göre ayarla. Birkaç uygulaması olan çoğu bağımsız geliştirici için hacim gayet yönetilebilir ve faydaları anında.

Çoğu geliştirici DocC’nin standart markdown desteklediğini bilir, ama şaşırtıcı derecede az kullanılan iki güçlü direktif var: video gömme ve sekmeli içerik. Her ikisi de Xcode’un dokümantasyon görüntüleyicisinde ve barındırılan DocC web sitelerinde çalışıyor.

Video Gömme

Dokümantasyonuna video eklemek tek bir direktifle yapılıyor:

@Video(source: "setup-walkthrough.mp4")

Video dosyasını dokümantasyon kataloğunun Resources klasörüne yerleştir. Bu, dokümantasyonun içinde doğrudan satır içi bir video oynatıcısı olarak render ediyor; harici bir URL’ye bağlantı vermekten veya görsel bir süreci metin olarak anlatmaktan çok daha etkili. Kurulum rehberleri, UI yürüyüşleri veya animasyon gösterimleri için iyi çalışıyor.

TabNavigator ile Sekmeli İçerik

Alternatif yaklaşımlar veya platforma özel talimatlar göstermen gerektiğinde, sekmeler okuyucuyu bunaltmadan şeyleri düzenli tutuyor:

@TabNavigator {
   @Tab("SwiftUI") {
      Use the `.environment` modifier to inject dependencies.
   }
   @Tab("UIKit") {
      Override `viewDidLoad` and configure your dependencies there.
   }
}

Bu, okuyucuların bölümler arasında geçiş yapabildiği düzgün bir sekmeli arayüz olarak render ediyor. Birden fazla platformu, API sürümlerini veya yapılandırma yaklaşımlarını kapsayan dokümantasyon için özellikle yararlı.

Pratik Tavsiyeler

Contributing rehberimi bu iki özelliği de kullanacak şekilde güncelledim ve sonuç bir metin duvarından belirgin şekilde daha yaklaşılabilir oldu. Video, paragraflarla anlatılması gereken kurulum sürecini gösteriyor ve sekmeler platforma özel adımları temiz bir şekilde ayırıyor.

Bu direktifler Apple’ın DocC dokümantasyonunda belgelenmiş ama öğreticilerde nadiren bahsedilmiş. Açık kaynak bir Swift paketi sürdürüyorsan, bunları dokümantasyon kataloğuna eklemeyi düşün – insanların dokümanlarını nasıl deneyimlediğinde gerçek bir fark yaratıyorlar.

Ücretli bir uygulamayı freemium’a geçirmek yaygın bir iş kararı, ama bir adalet sorunu ile geliyor: uygulama için daha önce ödeme yapmış kullanıcılar aniden özellikleri kaybetmemeli veya tekrar ödeme yapmaları istenmemeli. StoreKit’in AppTransaction API’si bunu temiz bir şekilde çözüyor.

Satın Alma Geçmişini Kontrol Etmek için AppTransaction Kullanımı

Anahtar, uygulamanın orijinal işlemi hakkında bilgi sağlayan AppTransaction.shared. Spesifik olarak, originalAppVersion kullanıcının uygulamayı ilk indirdiği sürümü söylüyor. Eğer o sürüm ücretli bir sürümdüyse, kullanıcının zaten ödeme yaptığını biliyorsun.

import StoreKit

func shouldGrantFullAccess() async -> Bool {
   do {
      let result = try await AppTransaction.shared
      if case .verified(let transaction) = result {
         let originalVersion = transaction.originalAppVersion
         // Version "2.0" was when the app went freemium
         if originalVersion.compare("2.0", options: .numeric) == .orderedAscending {
            return true // User purchased before freemium transition
         }
      }
   } catch {
      // Handle verification failure
   }
   return false
}

Mantık basit: kullanıcının originalAppVersion değerini freemium geçişini yaptığın sürümle karşılaştır. Orijinal sürümleri değişiklikten önceyse, otomatik olarak tam erişim ver.

Önemli Ayrıntılar

originalAppVersion, orijinal satın alma (veya ücretsiz uygulamalar için indirme) sırasındaki CFBundleShortVersionString değerine karşılık geliyor. Geçiş noktanı tam olarak hangi sürüm numarasının işaretlediğini bildiğinden emin ol.

Bu yaklaşım sunucu altyapısı ve migrasyon kodu gerektirmiyor. StoreKit, doğrulamayı App Store makbuz zinciri üzerinden yapıyor, bu yüzden kontrol kurcalamaya karşı dayanıklı. Apple bu kalıbı iş modeli geçişi için orijinal API belgesinde dokümante ediyor.

TestFlight ve simülatör testleri için, originalAppVersion bunun yerine CFBundleVersion (build numarası) döndürüyor, bu yüzden test senaryolarını buna göre planla.

Yıllardır Xcode’da dokümantasyon kontrol etme iş akışım hep aynıydı: bir sembole Cmd-click yap, bağlam menüsünden “Show Quick Help” seç, popup’ı oku, sonra kapat ve kodlamaya devam et. Çalışıyor, ama kesintiye uğratıcı – her arama üç eylem gerektiriyor ve düzenleme akışını bozuyor.

Sonra yanlışlıkla sağ kenar çubuğundaki Quick Help inspector panelini keşfettim.

Nasıl Çalışır

Quick Help inspector’ı Option+Cmd+3 ile aç veya View > Inspectors > Quick Help’e git. Bu, sağ kenar çubuğunda imlecinin şu anda üzerinde olduğu sembolün dokümantasyonunu gösteren bir panel açıyor. Kodunda imlecini hareket ettirdikçe – bir metoda tıklama, parametreler arasında ok tuşlarıyla gezme, bir tür seçme – kenar çubuğu otomatik güncelleniyor.

Tıklama yok, kapatılacak popup yok, kesinti yok. Sadece kodlamaya devam ediyorsun ve ilgili dokümantasyon seni takip ediyor.

Cmd-Click’ten Neden Üstündür

Cmd-click yaklaşımının belirli bir maliyeti var: bakmadan önce “bunun için dokümana ihtiyacım var” diye karar vermen gerekiyor. Kenar çubuğu bunu tersine çeviriyor. Her zaman görünür olduğu için, dokümantasyonu pasif olarak özümsüyorsun. Parametre açıklamalarını, dönüş türlerini, kullanımdan kaldırma uyarılarını ve kullanılabilirlik notlarını bilinçli bir çaba harcamadan fark ediyorsun.

Bu özellikle alışık olmadığın API’lerle çalışırken değerli. Her ikinci sembole Cmd-click yapmak yerine, imlecini kodda gezdirip kenar çubuğunu okuyorsun. Dokümantasyon aramasını ayrı bir eylemden sürekli bir akışa dönüştürüyor.

Panel, Quick Help popup’ı ile aynı içeriği gösteriyor: tanımlama, açıklama, parametreler, dönüş değeri, kullanılabilirlik ve ilgili semboller. Tek fark, belirir ve kaybolmak yerine kalıcı olması ve yerinde güncellenmesi.

Sağ kenar çubuğu için ekran alanın varsa, kodlarken Quick Help’i açık tutmak zamanla birikerek fark yaratan küçük iş akışı değişikliklerinden biri.

Standart SwiftUI Button eylemleri senkrondur. Asenkron bir işlem yapman gerektiğinde – bir ağ isteği, veritabanı yazımı, StoreKit satın alımı – elle bir Task yönetmek, yükleme durumunu takip etmek, butonu devre dışı bırakmak ve hataları ele almak zorunda kalıyorsun. Bu kalıp kod, uygulamandaki her asenkron butonda tekrarlanıyor.

Tüm bunları tek bir yeniden kullanılabilir view’da saran bir AsyncButton bileşeni oluşturdum.

Basitleştirilmiş Bir Uygulama

İşte temel fikir:

struct AsyncButton<Label: View>: View {
   let action: () async throws -> Void
   let label: () -> Label

   @State private var isRunning = false
   @State private var result: Result<Void, Error>?

   var body: some View {
      Button {
         isRunning = true
         Task {
            do {
               try await action()
               result = .success(())
            } catch {
               result = .failure(error)
            }
            isRunning = false
         }
      } label: {
         HStack(spacing: 8) {
            label()
            if isRunning {
               ProgressView()
            }
         }
      }
      .disabled(isRunning)
   }
}

Buton dahili olarak bir Task oluşturuyor, böylece çağıranlar action closure’ında doğrudan await kullanabiliyor. Task çalışırken, etiketin yanında bir ProgressView görünüyor ve mükerrer gönderileri önlemek için buton devre dışı bırakılıyor. result state’i başarı veya başarısızlık göstergelerini – bir onay işareti, bir renk flaşı veya bir sallama animasyonu – yönlendirebilir.

Kullanım

Kullanımı doğal hissettiriyor:

AsyncButton {
   try await viewModel.submitOrder()
} label: {
   Text("Place Order")
}

Elle state yönetimi yok, çağrı noktasında Task oluşturma yok. HandySwiftUI paketindeki tam implementasyon yapılandırılabilir başarı/başarısızlık animasyonları, özelleştirilebilir ilerleme göstergeleri ve buton stilleri desteği ekliyor. Ama yukarıdaki temel kalıp en yaygın durumu kapsıyor ve kendi projelerine uyarlaması kolay.

SwiftUI’ın ImageRenderer‘ı herhangi bir SwiftUI view’ını UIImage veya CGImage‘a dönüştürmeye olanak tanıyor. Saf SwiftUI view’larında iyi çalışıyor, ama view ağacında UIKit veya AppKit tarafından desteklenen bileşenler olduğunda sessizce başarısız oluyor – boş veya eksik bir görsel üretiyor. Bu, yaygın olarak kullanılan birçok view’ı kapsıyor:

• List (UITableView / NSTableView sarmalıyor)

• ScrollView (UIScrollView / NSScrollView sarmalıyor)

• TextEditor (UITextView / NSTextView sarmalıyor)

• Map (MKMapView sarmalıyor)

Herhangi bir derleyici uyarısı veya çalışma zamanı hatası yok. Renderer sadece view hiyerarşisinin o kısımlarını yakalamıyor.

Geçici Çözüm

Liste benzeri bir düzeni görsel olarak export etmem gerektiğinde, çözüm List’i VStack ve manuel stillendirmeden oluşan saf bir SwiftUI karşılığıyla değiştirmek oldu:

let exportView = VStack(spacing: 0) {
   ForEach(items) { item in
      HStack {
         Text(item.name)
         Spacer()
         Text(item.value)
            .foregroundStyle(.secondary)
      }
      .padding(.horizontal, 16)
      .padding(.vertical, 12)

      if item.id != items.last?.id {
         Divider()
      }
   }
}
.background(.white)
.frame(width: 390)

let renderer = ImageRenderer(content: exportView)
renderer.scale = UIScreen.main.scale

if let image = renderer.uiImage {
   // Use the rendered image
}

ForEach ile VStack, UIKit destekli herhangi bir view’a bağlı kalmadan List’in görsel yapısını kopyalıyor. Ayırıcılar, dolgu ve arka plan eklemek, export amaçları için standart bir listeye yeterince yakın bir sonuç üretiyor.

Pratik Tavsiye

Uygulamanda ImageRenderer kullanmayı planlıyorsan, export edilecek view’larını en başından bu kısıtlamayı göz önünde bulundurarak tasarla. Bunları temel SwiftUI bileşenlerinden oluştur: stack’ler, metin, şekiller ve görseller. Platform-özel bir kontrolü sardığını bildiğin herhangi bir view’dan kaçın. Render çıktısını erken test etmek, daha sonra boş bölgeler keşfetmenin hayal kırıklığından kurtarıyor.

Orta büyüklükteki herhangi bir Swift projesinde, neredeyse her dosyanın başında aynı import setini yazıyorsun. Foundation, SwiftUI, OSLog, belki Observation – yeni framework’ler benimsedikçe liste büyüyor. OSLog üzerinden yapılandırılmış loglama’ya geçişle birlikte, kendimi neredeyse her dosyaya alışılagelen isimlerin yanına import OSLog eklerken buldum.

Çözüm, sık ihtiyaç duyduğun her şeyi tek bir import üzerinden yeniden export eden bir wrapper modül.

Wrapper Modülü Kurma

Swift paketinde veya Xcode projesinde yeni bir target oluştur. Benim durumumda adını AppFoundation koydum. Modülün tamamı tek bir dosyadan oluşuyor:

// Sources/AppFoundation/Exports.swift
@_exported import Foundation
@_exported import SwiftUI
@_exported import OSLog
@_exported import Observation

@_exported attribute’u, her framework’ten tüm public sembolleri AppFoundation’ı import eden herhangi bir dosyaya erişilebilir yapıyor. Artık uygulamandaki her dosyanın sadece şuna ihtiyacı var:

import AppFoundation

Package.swift dosyanda, target’ın export dosyası dışında kendi kaynak kodu yok. Uygulama target’ın AppFoundation‘a bağımlılık tanımlıyor ve yeniden export edilen tüm framework’ler her yerde kullanılabilir oluyor.

Göz Önünde Bulundurulacak Ödünler

Bu yaklaşımın açık faydaları var: daha az kalıp kod, import bölümlerinde daha az merge çakışması ve yeni framework import’ları eklemek için tek bir yer. Ama ödünler de var.

Birincisi, @_exported alt çizgili bir attribute, yani resmi olarak stabil Swift API’sinin parçası değil. Pratikte yıllardır stabil ve ekosistemde yaygın olarak kullanılıyor, ama resmi bir garanti taşımıyor.

İkincisi, örtük bağımlılıklar bir dosyanın gerçekte ne kullandığını anlamayı zorlaştırabilir. Her dosyanın her şeye erişimi olduğunda, açık import’ların dokümantasyon değerini kaybediyorsun. Daha sonra bir modülü bağımsız bir pakete çıkarırsan, açık import’ları geri eklemen gerekecek.

Kolaylığın katı modülerlikten daha önemli olduğu uygulama target’ları için, wrapper modül kalıbı gerçek zaman kazandırıyor. Yeniden kullanılabilir kütüphaneler için ise açık import’lar daha iyi bir seçim olmaya devam ediyor.

UIKit’te navigasyon imperatiftir. Sisteme tam olarak ne yapacağını söylersin:

let detailVC = DetailViewController()
detailVC.item = selectedItem
navigationController?.pushViewController(detailVC, animated: true)

Bir view controller oluşturursun, yapılandırırsın ve yığına itersin. Eylemi sen kontrol edersin.

SwiftUI farklı çalışıyor. Navigasyon yapmıyorsun – verileri yeni view’larda sunuyorsun. Her şey veri odaklı. View’ları kontrol etmiyorsun. Verileri kontrol ediyorsun.

Veri Odaklı Navigasyon Pratikte

NavigationStack ile navigasyon state tarafından yönlendiriliyor. Hangi verinin hangi view’a karşılık geldiğini tanımlıyorsun, geçişleri SwiftUI hallediyor:

struct ContentView: View {
   @State private var path: [Item] = []

   var body: some View {
      NavigationStack(path: $path) {
         List(items) { item in
            Button(item.name) {
               path.append(item)  // Modify data, not views
            }
         }
         .navigationDestination(for: Item.self) { item in
            DetailView(item: item)
         }
      }
   }
}

Kilit satır path.append(item). Bir view itmiyorsun. Bir diziye veri ekliyorsun. SwiftUI değişikliği gözlemliyor ve karşılık gelen view’ı otomatik olarak sunuyor.

Bu Neden Önemli

Bu ayrım sadece felsefi değil – pratik sonuçları var. Navigasyon state olduğu için, doğru path dizisini oluşturarak deep linking’i bedavaya alıyorsun. Path’i kaydederek navigasyon state’ini kalıcı hale getirebilir ve geri yükleyebilirsin. Aynı anda birden fazla öğe ekleyerek programatik olarak herhangi bir derinliğe gidebilirsin.

Bu aynı zamanda kapatmanın sadece veri silme olduğu anlamına geliyor. path.removeLast() çağrısı en üstteki view’ı kaldırıyor. Diziyi temizlemek köke döndürüyor. View controller referanslarını takip etmeye veya navigasyon hiyerarşisinde dolaşmaya gerek yok.

Bu değişimi içselleştirmek zaman alıyor, özellikle yıllarca UIKit deneyimin varsa. Ama bir kez oturduğunda, SwiftUI navigasyonu çok daha tahmin edilebilir hale geliyor. View’ların verilerinin saf fonksiyonları oluyor ve navigasyon da o verinin sadece bir parçası.

SwiftUI’ın AsyncImage‘ı uzak görselleri yüklemek için kullanışlı, ama şaşırtıcı bir sınırlaması var: .resizable() modifier’ını uygulayamıyorsun. Bu kod derleniyor ama beklendiği gibi çalışmıyor:

// This does NOT work as intended
AsyncImage(url: imageURL)
   .resizable()  // Has no effect -- AsyncImage is not an Image
   .aspectRatio(contentMode: .fill)
   .frame(width: 200, height: 200)

Nedeni, AsyncImage‘ın bir Image olmaması – yükleme durumunu yöneten bir konteyner view. .resizable() modifier’ı sadece Image üzerinde tanımlı, bu yüzden onu AsyncImage’a uygulamak sadece genel View versiyonunu çağırıyor ki o da işe yaramıyor.

Çözüm

Çözüm, yükleme tamamlandıktan sonra alttaki Image değerine doğrudan erişim sağlayan phase tabanlı başlatıcıyı kullanmak:

AsyncImage(url: imageURL) { phase in
   switch phase {
   case .success(let image):
      image
         .resizable()
         .aspectRatio(contentMode: .fill)
   case .failure:
      Image(systemName: "photo")
         .foregroundStyle(.secondary)
   case .empty:
      ProgressView()
   @unknown default:
      EmptyView()
   }
}
.frame(width: 200, height: 200)
.clipped()

.success durumunun içinde, image gerçek bir Image değeri, bu yüzden .resizable() doğru çalışıyor. Bu ayrıca yükleme ve hata durumları üzerinde kontrol sağlıyor ki bu zaten daha iyi bir uygulama.

Ne Zaman Manuel Yüklenir

Ham görsel verisine ihtiyacın varsa – örneğin önbelleğe almak, boyutunu incelemek veya bir UIImage oluşturmak için – AsyncImage’ı tamamen atlayıp URLSession ile yüklemek isteyebilirsin. Ama çoğu sadece görüntüleme amaçlı durum için, phase tabanlı başlatıcı ekstra karmaşıklık olmadan ihtiyacı karşılıyor.

Bu, basit başlatıcının çekici göründüğü ama pratikte yetersiz kaldığı SwiftUI API’lerinden biri. Görsel-özel modifier’lara ihtiyacın olduğunda varsayılan olarak phase tabanlı versiyonu kullan.

Xcode 15, küçük ama etkili bir düzenleme kısayolu tanıttı: Ctrl+M. İmlecini bir fonksiyon çağrısına, başlatıcıya veya virgülle ayrılmış herhangi bir parametre listesine yerleştir, Ctrl+M’ye bas ve Xcode otomatik olarak onu birden fazla satıra genişletiyor – her satırda bir parametre, düzgün girintili.

Bu kısayoldan önce, uzun bir fonksiyon çağrısını yeniden biçimlendirmek elle satır sonları eklemek ve girintiyi düzeltmek demekti. Şöyle bir çağrıyı düşün:

let label = UILabel(frame: .zero, font: .systemFont(ofSize: 14), textColor: .label, numberOfLines: 0)

İmleç o satırdayken Ctrl+M’ye bastıktan sonra, Xcode şöyle yeniden biçimlendiriyor:

let label = UILabel(
   frame: .zero,
   font: .systemFont(ofSize: 14),
   textColor: .label,
   numberOfLines: 0
)

Ne Zaman Kullanılır

Bu kısayol, zamanla parametre biriktiren SwiftUI view modifier’ları veya başlatıcılar yazarken en değerli. İki parametreyle başlayan bir view, yapılandırma ekledikçe genellikle beş veya altıya çıkıyor. Her seferinde elle yeniden biçimlendirmek yerine, Ctrl+M bunu tek bir tuş vuruşuyla halledebiliyor.

Tersi yönde de çalışıyor – parametrelerin zaten ayrı satırlardaysa, Ctrl+M’ye basmak onları tekrar tek satıra daraltıyor. Bu geçiş davranışı, okunabilirlik ihtiyacına göre kompakt ve genişletilmiş formatlar arasında kolayca geçiş yapmayı sağlıyor.

Dikkat edilmesi gereken bir şey: kısayol, imleç konumundaki en içteki parametre listesi üzerinde çalışıyor. İç içe fonksiyon çağrıların varsa, doğru olanı genişletmek için imlecini dikkatli konumlandır.

Çoğu Xcode kullanıcısı Shift+Cmd+O’ya aşinadır – projendeki herhangi bir dosyaya, sembole veya türe atlamanı sağlayan “Open Quickly” kısayolu. Xcode’u kullanmaya başladıktan birkaç gün sonra refleks haline gelen kısayollardan biri. Yakın zamana kadar fark etmediğim şey, aynı kısayolun artık DocC tarafından desteklenen Apple Developer dokümantasyon web sitesinde de çalıştığı.

developer.apple.com/documentation adresinde gezinirken Shift+Cmd+O tuşlarına basmak, Xcode’un Open Quickly diyaloğu gibi davranan bir arama katmanı açıyor. Bir framework adı, bir sınıf, bir metod veya kısmi bir eşleşme yazabilirsin ve sonuçlar anında görünüyor. Bir sonucu seçmek doğrudan o dokümantasyon sayfasına yönlendiriyor.

Bu Neden Önemli

Bu özellikten önce, Apple dokümantasyonunda arama yapmak kenar çubuğu hiyerarşisinde gezinmek veya genel arama çubuğunu kullanmak demekti; bu da genellikle makalelerin, öğreticilerin ve API referanslarının bir karışımını döndürüyordu. Open Quickly katmanı, sonuçları API sembolleri ve sayfalarıyla filtreleyerek çok daha hassas hale getiriyor.

Bu özellikle bir tarayıcıda WWDC makalesi veya forum konusu okurken ve hızlıca ilgili bir API’nin imzasını kontrol etmen gerektiğinde çok yararlı. Xcode’a geri dönmek yerine, bağlamında kalıp doğrudan bakabilirsin.

Bu özellik, Apple’ın DocC’yi bir dokümantasyon platformu olarak daha geniş yatırımının bir parçası. DocC hem Xcode’un dokümantasyon görüntüleyicisini hem de web tabanlı dokümantasyonu güçlendirdiğinden, aynı etkileşim kalıplarının taşınması mantıklı. Apple dokümanlarını tarayıcıda okumaya vakit harcıyorsan, bu kısayolu kas hafızana yerleştirmek çabaya değer.

Xcode 15’teki daha sessiz ama etkili değişikliklerden biri, asset catalog’lara yerleşik tür güvenli erişim. Daha önce, asset catalog’undan bir görsel veya renk referansı almak string literal gerektiriyordu:

// Before Xcode 15
Image("custom-header-icon")
Color("primaryBrand")

Bu kırılgandı. Bir asset’i yeniden adlandır, kodun sorunsuz derlenir ama çalışma zamanında çöker veya hiçbir şey göstermez. SwiftGen gibi araçlar, asset catalog’larından tür güvenli sabitler üreterek tam olarak bu sorunu çözmek için vardı.

Ne Değişti

Xcode 15 artık asset catalog’undaki her görsel ve renk için otomatik olarak Swift erişimcileri üretiyor. Bunlara resource başlatıcıları aracılığıyla erişiyorsun:

// Xcode 15+
Image(.customHeaderIcon)
Color(.primaryBrand)

Derleyici asset’lerini biliyor. Tam otomatik tamamlama alıyorsun ve bir asset’i silersen veya yeniden adlandırırsan, sessiz bir çalışma zamanı hatası yerine derleme zamanı hatası alıyorsun.

Apple SwiftGen’i Sherlocked Etti

Bu aslında Apple’ın SwiftGen’in yıllardır sunduğunu entegre etmesi. Halihazırda SwiftGen kullanan ekipler için, hala ona ihtiyaç duyup duymadığınızı değerlendirmek için iyi bir zaman. Yerleşik çözüm, en yaygın iki kullanım alanını – görseller ve renkler – herhangi bir build phase scripti veya kod üretme adımı olmadan kapsıyor.

SwiftGen’i fontlar, yerelleştirilmiş dizeler veya diğer kaynak türleri için kullanıyorsan, onu tutmak için hala nedenler var. Ama özellikle asset catalog’ları için, yerel çözüm artık çoğu proje için yeterince iyi ve sıfır yapılandırmayla kutudan çıkar çalışıyor.

.strings ve .stringsdict dosyalarıyla çalışmak her zaman Apple geliştirmesinin daha pürüzlü taraflarından biri olmuştur. Düz metin anahtar-değer dosyalarında hata yapmak kolay – eksik noktalı virgüller, diller arasında uyumsuz anahtarlar, çeviri ilerlemesini bir bakışta görme imkanı yok. Ve çoğullaştırma kuralları için kullanılan .stringsdict dosyaları ise XML tabanlı plist dosyaları olup elle yazmak oldukça zor.

String Catalogs Ne Getiriyor

Xcode 15, String Catalogs adında yeni bir .xcstrings dosya formatı tanıtıyor. Hem .strings hem de .stringsdict dosyalarını, özel bir görsel editörle gelen tek bir dosyayla değiştiriyor.

Temel iyileştirmeler oldukça önemli:

Görsel editör – Tüm yerelleştirilebilir dizeler, her dil için sütunlar içeren bir tabloda gösteriliyor. Çevirileri, dosyalar arasında geçiş yapmadan veya harici araçlar kullanmadan satır içinde görebilir ve düzenleyebilirsin.

Çeviri ilerleme takibi – Her dil bir tamamlanma yüzdesi gösteriyor. Bir bakışta hangi dillerin ilgiye ihtiyacı olduğunu ve hangi dizelerin henüz çevrilmediğini görebilirsin.

Otomatik dize çıkarma – Xcode, Swift kodunu tarayarak yerelleştirme gerektiren dizeleri otomatik olarak keşfediyor. Yeni dizeler, herhangi bir elle kayıt adımı olmadan katalogda görünüyor.

Yerleşik geçiş – Mevcut .strings ve .stringsdict dosyalarından bir geçiş yolu var. Mevcut yerelleştirme dosyalarına sağ tıkla, Xcode bunları yeni formata dönüştürmeyi teklif ediyor.

Pratik Etki

Birkaç desteklenen dili olan projeler için bile, bu önemli bir yaşam kalitesi iyileştirmesi. Görsel editör tek başına bir biçimlendirme hatası sınıfını tamamen ortadan kaldırıyor. Otomatik çıkarmayla birleştirildiğinde, daha az unutulan dize ve tüm proje genelinde yerelleştirme durumunun daha net bir görüntüsü demek.

Xcode 15’te yeni bir proje başlıyorsan, String Catalogs varsayılan. Mevcut projeler için geçiş kolay ve kesinlikle yapılmaya değer.

Birçok parametresi olan uzun fonksiyon çağrıları ve tanımlamaları, Swift kodunda en yaygın okunabilirlik sorunlarından biri. Makul herhangi bir sütun sınırının çok ötesine uzanan satırlarla karşılaşıyorsun:

func configureView(title: String, subtitle: String, icon: Image, backgroundColor: Color, isEnabled: Bool, action: @escaping () -> Void) {

Bunu elle birden fazla satıra bölmek sıkıcı. İmleci konumlandırman, satır sonları eklemen, her parametreyi girintilemen ve kapanış parantezinin doğru hizalandığından emin olman gerekiyor.

Xcode 15’teki Yeni Eylem

Xcode 15, bunu otomatik yapan bir “Format to Multiple Lines” eylemi sunuyor. İmlecini birden fazla parametresi olan bir fonksiyon çağrısına veya tanımlamasına yerleştir, Xcode yeniden biçimlendirmeyi sunuyor:

Sonuç, her satırda bir parametre olacak şekilde temiz biçimlendirilmiş:

func configureView(
   title: String,
   subtitle: String,
   icon: Image,
   backgroundColor: Color,
   isEnabled: Bool,
   action: @escaping () -> Void
) {

Bu eylemi fonksiyon imzasına sağ tıklayıp Refactor altında arayarak veya Editor menüsünü kullanarak bulabilirsin. Hem fonksiyon tanımlamalarında hem de çağrı noktalarında çalışıyor.

Ne Zaman Kullanılır

Bu, yeni bir fonksiyon yazdıktan veya mevcut birine parametreler ekledikten hemen sonra en çok işe yarıyor. Yazarken elle biçimlendirmek yerine, her şeyi tek satıra yazıp sonra biçimlendiriciyi tek bir eylemle uygulayabilirsin. Ayrıca başka birinin uzun tek satırlık imzalar bıraktığı kodu incelerken de yardımcı oluyor – seç ve elle düzenleme yapmadan yeniden biçimlendir.

Ters işlem (birden fazla satırı tekrar tek satıra daraltma) şu anda mevcut değil, ama o yön genellikle daha az gerekli.

Asenkron verilere bağımlı view’lar oluştururken, genellikle bir spinner veya placeholder gösteren bir yükleme durumun oluyor. Production’da bu durum, veriler ağdan veya veritabanından yüklenirken kısa süreliğine görünüyor. Ama SwiftUI preview’larında mock verilerin anında hazır olduğundan, yükleme durumu incelemek için çok hızlı geçiyor – ya da hiç görünmüyor.

Sadece Preview İçin Gecikme Yardımcısı

Çözüm, sadece preview veya debug bağlamlarında yapay bir gecikme ekleyen küçük bir yardımcı. İşte kalıp:

struct DelayedStatePreview<Content: View>: View {
   @State private var isLoaded = false
   let delay: Duration
   let content: (Bool) -> Content

   init(
      delay: Duration = .seconds(2),
      @ViewBuilder content: @escaping (Bool) -> Content
   ) {
      self.delay = delay
      self.content = content
   }

   var body: some View {
      content(isLoaded)
         .task {
            try? await Task.sleep(for: delay)
            isLoaded = true
         }
   }
}

Bunu bir preview’da şöyle kullanıyorsun:

#Preview {
   DelayedStatePreview { isLoaded in
      if isLoaded {
         ArticleListView(articles: mockArticles)
      } else {
         LoadingView()
      }
   }
}

Bu Neden Önemli

Temel fayda, production kodunun temiz kalması. Gerçek view’larına yapay gecikmeler veya debug bayrakları eklemiyorsun. Yardımcı tamamen preview katmanında var olarak, yükleme durumlarının doğru göründüğünü, geçişlerin düzgün animasyon yaptığını ve veriler geldiğinde düzenin sıçramadığını görsel olarak doğrulama imkanı tanıyor.

Bu, özellikle iskelet yükleyicileri veya parıltı efektleri olan view’lar için çok yararlı; yükleme durumunun görsel kalitesinin kullanıcı deneyiminin bir parçası olduğu durumlar.

Xcode’da Run’a bastıktan sonra uygulamanın gerçekten görünmesi arasında bir gecikme – bazen birkaç saniye – fark ettiysen, suçlu genellikle LLDB debugger’ının sürecine bağlanmasıdır. Bu süre zarfında Simulator, debugger başlatılırken boş bir ekran gösteriyor.

Ayar Nerede Bulunur

Ayar scheme yapılandırmasında bulunuyor:

1. Product > Scheme > Edit Scheme menüsüne git (veya Cmd+Shift+< tuşlarına bas)

2. Sol tarafta Run eylemini seç

3. Info sekmesine geç

4. Debug executable seçeneğinin işaretini kaldır

Bu Ne Yapar

“Debug executable” etkinken (varsayılan), Xcode başlatmada LLDB debugger’ını uygulama sürecine bağlıyor. Bu, breakpoint’leri, hata ayıklama bellek grafiğini, view hiyerarşisi debugger’ını ve konsolda po komutlarını mümkün kılan şey.

Bunu devre dışı bırakmak debugger bağlantısını tamamen atlıyor. Uyguaman fark edilir şekilde daha hızlı başlıyor – benim deneyimimde, büyük projelerde fark 2 ila 5 saniye olabiliyor. print() ve os_log ile konsol çıktısı normal şekilde çalışmaya devam ediyor, yani hata ayıklama için loglama kullanmaya devam edebilirsin.

Takas

Debugger bağlı olmadan şunları kaybediyorsun:

• Breakpoint’ler (tetiklenmezler)

• Konsolda po ve expression komutları

• Bellek grafiği ve view hiyerarşisi hata ayıklama araçları

Bu, ayarı özellikle UI iterasyon çalışmaları için ideal yapıyor; görsel düzenlemeler yapıp sık sık yeniden çalıştırdığın zamanlar. Breakpoint’lerle belirli bir hatayı araştırman gerektiğinde, geçici olarak onay kutusunu tekrar etkinleştir. Ben çoğu zaman kapalı tutuyorum ve sadece kod üzerinde adım adım ilerlemem gerektiğinde açıyorum.

Swift’in #warning direktifi, özel bir mesajla derleyici uyarısı üretiyor. Yorumlardan farklı olarak, bunlar Issue Navigator’da ve derleme çıktısında görünüyor, bu yüzden gözden kaçırmaları imkansız. Ben bunları yayınlamadan önce mutlaka ele alınması gereken şeyler için kesin hatırlatıcılar olarak kullanıyorum.

Her Gün Kullandığım İki Snippet

Bu amaçla yapılandırdığım iki Xcode kod snippet’im var.

“nyi” – Not Yet Implemented:

#warning("Not yet implemented!")

Prototipleme sırasında bir fonksiyonu stub’ladığımda veya bir kod yolunu atladığımda nyi yazıp Enter’a basıyorum. Sorunsuz derleniyor ama uyarı, işi bitirmek için geri dönmemi sağlıyor.

“dw” – Developer Warning:

#warning("<#message#>")

Bu, bir placeholder token kullanıyor, böylece dw yazıp Enter’a bastıktan sonra imleç mesajın içine düşüyor ve özel bir not yazabiliyorum. Bunu #warning("Çevrimdışı mod için hata durumunu ele al") veya #warning("Yayınlamadan önce kaldır") gibi şeyler için kullanıyorum.

Xcode Snippet’leri Nasıl Oluşturulur

Bunları ayarlamak her biri yaklaşık 30 saniye sürüyor:

1. Snippet olarak istediğin kodu herhangi bir Swift dosyasına yaz

2. Kodu seç

3. Sağ tıkla ve Create Code Snippet seçeneğini seç

4. Bir başlık ver (ör. “Developer Warning”)

5. Completion kısayolunu ayarla (ör. dw)

6. Availability seçeneğini “All” veya “Swift” olarak ayarla

7. Done’a tıkla

Bu noktadan sonra, herhangi bir Swift dosyasında kısayolu yazmak, snippet’i otomatik tamamlama aracılığıyla sunuyor.

Düz yorumlara göre temel avantaj görünürlük. Bir // TODO: yorumunu görmezden gelmek kolay ve tutarlı bir şekilde aramak zor. Bir #warning ise derleyiciyi her derlemede bunu yüzeye çıkarmaya zorluyor, sen çözene kadar tamamlanmamış işini ön planda tutuyor.

Swift Evolution teklifleri tasarım gereği kapsamlıdır. Motivasyonu, detaylı tasarımı, değerlendirilen alternatifleri, ABI etkilerini ve daha fazlasını kapsarlar. Bu kapsamlılık inceleme süreci için gerekli, ama sadece bir teklifin ne yaptığını ve neden yaptığını anlamak istediğinde, binlerce kelimeyi okumak biraz fazla olabiliyor.

URL Hilesi

GitHub’daki herhangi bir Swift Evolution teklifinin özetlenmiş versiyonunu almanın basit bir yolu var. Şöyle bir URL’deki bir teklifi görüntülüyorsan:

https://github.com/apple/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md

apple kısmını FlineDev ile değiştir:

https://github.com/FlineDev/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md

Bu seni swift-evolution deposunun bir fork’una götürüyor. Burada tekliflerin başına yapay zeka tarafından oluşturulmuş özetler eklenmiş. Her özet, teklifin ne getirdiğini, neden önemli olduğunu ve temel sözdizimini birkaç paragrafa sığdırıyor.

Ne Zaman İşe Yarıyor

Bu özellikle sürüm notlarında veya sosyal medyada bir tekliften bahsedildiğini gördüğünde ve hızlıca özünü anlamak istediğinde işe yarıyor. Tam teklifi okumak için 15 dakika harcamak yerine, temel bilgiyi birkaç dakika içinde alıyorsun.

Özetler son zamanlarda kabul edilen tekliflerin çoğunu kapsıyor. Fork’dan önce gelen eski teklifler için orijinal metni görürsün. Ama Swift Evolution’ın son birkaç yılı için özetlenmiş versiyon gerçek bir zaman tasarrufu.

Bu fork’u, teklifleri sürekli sadece ana fikri bulmak için göz gezdirirken oluşturdum ve diğer geliştiricilerin de aynı kısayoldan faydalanabileceğini düşündüm.

Bir onboarding akışı oluştururken, kullanıcının dikkatini yapması gereken bir sonraki işleme yönlendirmek zorlu olabiliyor. Butonlarda ince bir titreşim animasyonu, göze batmadan dikkati çekiyor. Ben bunu SwiftUI’da scaleEffect ve opacity modifier’larını tekrarlayan bir animasyonla birleştirerek gerçekleştirdim.

İşte temel yaklaşım:

struct PulsatingButtonStyle: ButtonStyle {
   @State private var isPulsating = false

   func makeBody(configuration: Configuration) -> some View {
      configuration.label
         .scaleEffect(isPulsating ? 1.06 : 1.0)
         .opacity(isPulsating ? 0.8 : 1.0)
         .animation(
            .easeInOut(duration: 0.8)
               .repeatForever(autoreverses: true),
            value: isPulsating
         )
         .onAppear {
            isPulsating = true
         }
   }
}

İşin sırrı, senkronize çalışan iki animasyonu – ölçek ve opaklık – birleştirmek. repeatForever(autoreverses: true) modifier’ı animasyonun sürekli ileri geri gitmesini sağlıyor. isPulsating değerini onAppear’da değiştirerek, animasyon view göründüğü anda başlıyor.

1.06’lık ölçek faktörü bilerek ince tutulmuş. Çok fazla büyütmek (mesela 1.2) animasyonun agresif ve dikkat dağıtıcı hissettiriyor. Hafif opaklık değişimi, butonu okunmaz yapmadan derinlik hissi katıyor.

Bu kalıp, “Devam Et” veya “Başla” butonunu vurgulamak istediğin onboarding ekranları için çok iyi çalışıyor. Kullanıcı onboarding’i geçtikten sonra animasyon artık gösterilmiyor, böylece zamanla sinir bozucu olmuyor.

Bunu herhangi bir butona .buttonStyle(PulsatingButtonStyle()) ile uygulayabilirsin, böylece animasyon mantığı buton içeriğinden temiz bir şekilde ayrılmış oluyor.