Today, many iOS developers either build apps entirely in SwiftUI or use parts of SwiftUI without fully understanding how the framework works. Some developers misuse SwiftUI or apply UIKit patterns directly, which can lead to inefficient or confusing code. So, in this article, I will be basic and tell this terminologies as if you are beginners. This article may also help developers who migrated from UIKit

and still approach SwiftUI with UIKit-style thinking. Let’s begin.

View

Views in SwiftUI is the essential layer of the framework. A View is a protocol which you conform to any views to build your UI.

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Hello, world!")
        }
        .padding()
    }
}

A SwiftUI View is conceptually closer to UIKit’s UIView rather than UIViewController. It describes a piece of UI and how it should react to state changes. You use modifiers, states, ViewBuilders & computed variables to shape a UI and control the status of it.

Some people may prefer to keep all logics inside of the View, and that’s understandable since Views are conformed with struct types, which are value types. Because SwiftUI views are structs (value types), they are cheap to create and discard.

SwiftUI recreates view values frequently during state updates.

Why some View?

The reason why we declare the View as some in our views is that the View itself is a protocol. `some View` is an opaque return type. It means the function returns a specific concrete type that conforms to `View`, but the exact type is hidden from the caller.

VStack? Text?, Button?, Group?

This means technically, you can write it like this:

import SwiftUI

struct ContentView: View {
    var body: Text {
        Text("Hello, world!")
    }
}

But this is not correct:

import SwiftUI

struct ContentView: View {
    var body: View {
        Text("Hello, world!")
    }
}

View Composition

How would you build your UI in SwiftUI? You have:

• ViewBuilders
• Containers
• Reusable Views

ViewBuilders

@ViewBuilder allows multiple views to be declared in a closure and combines them

into a single view type behind the scenes. This is useful when there’s a condition based UI part(i.e. if condition { ThisView() }). Containers in itself(VStack, HStack etc.) actually do use ViewBuilder in it.

Actually, even var body: some View {} is a ViewBuilder. You just don’t see it directly.

Containers

Containers are layout views that arrange and group child views. We usually use VStack, HStack & ZStack. LazyVStack, LazyHStack, LazyVGrid & LazyHGrid.

You can also create your own container by defining the layout with types.

struct Carousel<Content: View>: View {
    
    let content: Content
    
    init(@ViewBuilder content: () -> Content) {
        self.content = content()
    }
    
    var body: some View {
        ScrollView(.horizontal) {
            HStack {
                content
            }
            .padding()
        }
    }
}

Reusable Views

SwiftUI is better aligned with sub-views. Instead of creating a view with 6 HStack, those having some VStack, and even deeper, it’s best to wrap the view with subviews. You can introduce a local variable via:

var statusView: some View {
        VStack {
            Text("")
        }
    }

or

func statusView(lastPosition: Int) -> some View {
        VStack {
            Text("\(lastPosition)")
        }
    }

If you want to use this sub-view with other screens, it’s best to move it under a View file with parameters to feed

struct Status {
    let value: Int
}

struct StatusView: View {
    
    let lastStatus: Status
    
    var body: some View {
        Text("\(lastStatus.value)")
    }
}

Modifiers

Modifiers are powerful in SwiftUI when developing any app. They get your view, apply the change you want, and returns a brand new View to be used.

You can customize your app with them, style with .font() & .background() etc., lay them out with .padding(), .offset(x:y:), frame(width:height:) etc., make it accessible with .accessibilityLabel(), add interactivity with .onTapGesture(), .onChange(of:) & .disabled() & present it with .sheet(), .alert(), .navigationTitle() etc.

They are pretty flexible, always create a new view for the SwiftUI view & reusable with custom ViewModifiers you write them.

You can chain them together like:

Text("Hello")
     .padding(4)
     .foregroundStyle(Color.black)
     .font(.headline)

To create a custom modifier, we first define it via creating a Modifier struct, conforming it to ViewModifier protocol, use the body type to shape it & write a View extension to convert it into a modifier to be used.

struct BorderedCaption: ViewModifier {
    func body(content: Content) -> some View {
        content
            .font(.caption2)
            .padding(10)
            .foregroundColor(Color.blue)
        // … other modifiers
    }
}
extension View {
    func borderedCaption() -> some View {
        modifier(BorderedCaption())
    }
}
// Usage: Text("Example").borderedCaption()

The order of them matters, since Swift checks them line by line from top to the bottom. It’s also important to use it when required.

Some developers encourage to use conditioned modifiers such as .if(condition) { apply this modifier } but it has some serious drawbacks on the animation & state changes so I would encourage to not use it as such.

States

States are property wrappers to manage the view’s persistence while it’s available(it’s not a long term persistence solution since states gets killed with the view dismissal).

When we mark a variable or an observed object(iOS 17+) with @State, SwiftUI starts tracking the the value to persists locally, present to us via .wrappedValue & updates it whenever there’s a change. Each state change essentially redraws the view since SwiftUI views are designed to be re-created. State holds value, so the change in a state does not reset other state value.

States are private to their View and it’s advised as such. SwiftUI animations works best with States to animate their changes such as:

.scaleEffect(isPlaying ? 1 : 1.5)

If you want to share it’s state with a subview, @Binding can be set into the child view, so that the state can be changed from child view.

States in Data Flow

In SwiftUI, there are some states to manage your data across the app.

@State is essential on a view to manage the local state of a value.

@Binding helps the two-way binding between the view & the sub view to manage the data.

@Observable state allows the custom models and its values to be tracked.

If you develop apps prior to iOS 17, @ObservableObject & @StateObject manages the same work as @Observable does.

@Environment & @EnvironmentObject helps developers to share data across the view hierarchy. Environment is more practical to manage states such as colorScheme, locale, calendar & others, where EnvironmentObject is used to share your custom model across the views, such as using a UserModel across different screens. The difference between them is, @Environment expects a struct with key-value relationship while @EnvironmentObject is expecting a class with ObservableObject conformance.

You can also create your own @Environment value as such:

struct SunshineKey: EnvironmentKey {
    static var defaultValue: Double = 1.02
}
extension EnvironmentValues {
    var sunshine: Double {
        get { self[SunshineKey.self] }
        set { self[SunshineKey.self] = newValue }
    }
}

struct SunshineView: View {
    
    @Environment(\.sunshine) var sunshine
    
    var body: some View {
        Text("Welcome to the sunshine, \(sunshine)")
    }
}

Layout

SwiftUI has a layout system that eases up UIKit’s AutoLayout system. It has some rules:

• Parent view proposes a size
• Child View chooses its own size
• Parent positions the child

Key concepts in Layout

Stacks: HStack, VStack & ZStack are container views that are holding the subviews together. You can use alignment & spacing to manage their positioning.

Modifiers: You would use .frame() & .padding() to assign spacings to any view. The order matters between them, so make sure to place them in the correct order.

Spacer() is a flexible component which fills the available spacing between two items to be placed. Please note that, Spacer() is best used with the stacks & does not fill the available width/height when a vertical/horizontal scrollview exists.

GeometryReader is used to calculate exact size of the screen to run calculations such as let customWidth = geometry.size.width or safeAreaInsets will give you the insets to work with, or geometry.frame(in: .global).minY to get the position.

Identity is Important

SwiftUI wants things to be Identifiable. Whether you’re building a list or defining a view, id is useful to SwiftUI to evaluate which views should be re-rendered vs. which views should be stayed same.

That is why, SwiftUI wants you to define identifiable for ForEach or List blocks. It’s important to make sure the id value is unique, so that no two items should match.

struct Stars: Identifiable {
    
    let id = UUID()
    
    let amount: Int
}

struct StarView: View {
    
    var stars: [Stars] = [
        .init(amount: 2),
        .init(amount: 3),
        .init(amount: 4)
    ]
    
    
    var body: some View {
        ForEach(stars) { star in
            Text("Vote for \(star.id) is \(star.amount)")
        }
    }
}

Navigation

Navigation in SwiftUI can be achieved by using NavigationStack or NavigationSplitView, and provide a NavigationDestination to coordinate. However, programmatic navigation via UIKit is still relevant.

struct ContentView: View {
    enum Route: Hashable {
        case profile
        case settings
        case details(String)
    }

    var body: some View {
        NavigationStack {
            List {
                NavigationLink("Go to Profile", value: Route.profile)
                NavigationLink("Go to Settings", value: Route.settings)
                NavigationLink("Go to Item Details", value: Route.details("SwiftUI Basics Item"))
            }
            .navigationTitle("NavigationStack Demo")
            .navigationDestination(for: Route.self) { route in
                switch route {
                case .profile:
                    VStack(spacing: 12) {
                        Image(systemName: "person.crop.circle.fill")
                            .font(.system(size: 48))
                            .foregroundStyle(.blue)
                        Text("Profile Screen")
                            .font(.title2)
                    }
                case .settings:
                    VStack(spacing: 12) {
                        Image(systemName: "gearshape.fill")
                            .font(.system(size: 48))
                            .foregroundStyle(.orange)
                        Text("Settings Screen")
                            .font(.title2)
                    }
                case .details(let itemName):
                    VStack(spacing: 12) {
                        Text("Details Screen")
                            .font(.title2)
                        Text("Selected item: \(itemName)")
                            .foregroundStyle(.secondary)
                    }
                }
            }
        }
    }
}

Lifecycle

SwiftUI does not have UIKit’s lifecycle, but it still supports:

• onAppear()
• onDisappear()
• onChange()
• task()

to handle lifecycle changes on the view.

Animations

Animations are handled in SwiftUI with two ways.

Either defining an .animation() modifier or with withAnimation{} block. Also, there are modifiers such as .scaleEffect(), .rotationEffect() and even .opacity() works nicely with it.

This article is hopefully opened up many concepts to you on the fundamentals of the SwiftUI and how you code it. If you have any questions, feel free to watch SwiftUI videos on Apple Developer’s website, read more articles on the deep threads and use the comment section down below. Happy coding.

Öncelikle bu uyarıyı önden yapmak istiyorum. Bu bir kişisel blog yazısıdır. Yazılımla alakalı paylaşımlarım için diğer paylaşımlarıma bakabilirsiniz, bu yazı ilginizi çekmeyebilir.

EN: First of all, I want to make the warning that this will be a personal article. If you want to interest software topics only, you may wish to skip this article. Also, this will be in Turkish.

Öncelikle geçen sene kendime koyduğum hedeflerde %20 civarı bir başarıya ulaştığımı söyleyebilirim. Finansal konularda %62.5 civarında bir azalma yaşandı. Bunun mümkün olabileceğine dair o zamanlar kafamda çok soru işareti vardı, fakat üstesinden gelmeyi başardım. Onun dışındaki pek çok hedefte baştan başarısız olup bıraktığımı söyleyebilirim.

2025 benim için nasıl geçti, göz atalım.

Ocak 2025

Ocak ayı güzel bir tatil ile başladı. Eşimle Abu Dhabi, UAE’e giderek Coldplay konseri izleme şansımız oldu. Kışın ortasında yaz tatili gibi gezmek, şehrin kültürünü yaşamak ve Coldplay’in eşsiz tecrübesini yaşamak güzel oldu.

Şubat 2025

Bu ay işlerin yoğunluğu arası bir şehir dışı yapmaya karar verip 2 gün Edirne’yi gezmeye karar verdik. Osmanlı tarihinin önemli bir parçası olan bu şehir, geçmişten taşıdığı sanat eserleri ile bizlere güzel kareler bıraktı.

Mart 2025

Bu ay benim için bir dönüm noktası oldu, çünkü yıllarca sürdürdüğüm kariyerimde gıpta ile baktığım Senior terfimi aldım, ve artık kendime Senior iOS Developer demeye başlayabildim.

Ayrıca yakınımdaki Feshane’yi de gezme fırsatını bulmuş oldum.

Mayıs 2025

Mayıs ayları güzeldir, bu sene de öyle oldu. Eşimle evlilik yıl dönümümüzü ve doğumgünümü(30 kulübüne girdim) kutladık, ve ayın sonunda Fethiye, Kumburnu plajı gibi harika yerleri görebildik.

Haziran 2025

Görece daha sakin bir aydı diyebilirim. Profesyonel fotoğraf çekimi ve F1 film gösterimi ile geçti. Bu dönem, daha çok şirketteki projenin bitirme süresine yaklaşıldığı için ona odaklandığım bir dönem olarak geçti.

Temmuz 2025

Bu ay, biraz daha yazlıkta çalışma modunun açıldığı ve Ağustos’ta yapacağım ilk Almanya Gezisine hazırlanmak ile geçti.

Ağustos 2025

Hallo Berlin, Hallo Hannover. Bu ay, ilk çıkan schengen vizesi ile kısa bir Almanya kaçamağı yaptık. Genel olarak güneşli veya hafif yağışlı geçen bu gezide Döner Kebap yediğimiz en lokal yemek olabilir. (Cidden, Five Guys neden Türkiye’de yok…)

İş olarak bu ay projenin müşteri kaynaklı durduğu bir dönemdi. Özellikle ayın geri kalanında bir sonraki projeme yerleşmeyi bekledim.

Eylül 2025

Bu ay, yeni projenin başladığı, bazı eski iş arkadaşlarımla yeniden bir araya geldiğim keyifli bir ay oldu. Eşimin ve babamın doğumgünlerini kutlarken aylarca gezdikten sonra şehir dışına hiç çıkmadığım bir ay geçmiş olabilir.

Ekim 2025

Ekim ayı da genel olarak sakin geçti. İş ile ilgilenmeye devam ettiğim bu dönemde ayrıca doğa & park yürüyüşleri gerçekleştirme gibi etkinliklerde bulundum. Ayrıca, eşime güzel katlanır bir masa almış olduk, epey kullanışlı bir ürün.

Aralık 2025

Aralık ayı biraz daha hareketliydi. İş gezisi için birkaç gün İzmir’e çıkartma yaptık.

Ardından noel’in gelmesi ile bir Almanya çıkartması daha yapmaya karar verdik, bu sefer rota Münih,

Nürnberg

ve Stuttgart’tı.

2026

2025'i dolu dolu bir yıl olarak geride bıraktığımı söyleyebilirim. Her ne kadar hedefleri tutturamamış olsam da, bu sene bana bir çok deneyim sundu.

Dolma kalem ile defter tutmaya 2024 sonu gibi başlamıştım, 2025'te tam gaz devam ederek haftalarca yaptıklarımı kayda aldım.

Şimdi sıra 2026'da. Bu sene için neler hedefleyeceğim ve neler yapacağım konularında epey düşündüm. Basit bir şekilde geçmiş sene yapamadıklarımı kopyala-yapıştır yapabilirdim. Fakat bunun yerine edindiğim tecrübeler ile daha farklı şeyler başarmaya karar verdim. Bazı hedeflerim geçmişten alma olacak, evet. Ama bazıları 30 yıldır sürdüreceğim bazı trendlere aykırı olarak gelişecek, çünkü artık daha farklı düşünmeye başlıyorum.

Ana maddeleri ile yeni hedeflerim şunlar:

• Kilo ile savaş & daha fazla egzersiz (evet, bu hedefi öyle ya da böyle yapmak istediğimi hepimiz biliyoruz)
• Daha fazla kişisel yazı
• Birikime geçiş
• 10 Kitap Okuma
• Gece Çalışmayı Bırakma

Kilo & Egzersiz

Eğer bu blogu uzun zamandır takip ediyorsan, bu konunun benim için yeni olmadığını biliyorsundur. Yine de, her sene olduğu gibi bu hedefe bu sene de asılmak istiyorum. Geçmiş hataların beni yıldırmasını istemiyorum. Artık bu konuda daha iyi bir Ege olmak istiyorum. Bakalım bu sene, bunu başarabilecek miyim.

Daha Fazla Kişisel Yazı

Bu konuda Medium blogum çok zayıf kalmıştı. Uzun bir süredir, kişisel yazılardan çok yazılım odaklı olmak istediğim için, yazıların sıklığı epey düşüyordu. Kişisel düşüncelerim de geri planda kalıyordu. Bu sebeple kişisel yazılarımı arttırmaya karar verdim. Medium’da artık yazılımın yanısıra, teknolojiye dair daha fazla kişisel görüşümü dile getirmeyi planlıyorum. Ayrıca, kısa yazı formatına da geri dönebilirim. Bu konuda kafamdaki planları netleştirince ortaya güzel şeyler çıkacağına inanıyorum.

Birikime Geçiş

Geçen seneki %60'ı aşkın başarım henüz tamamlanmamış da olsa, artık bu sene için ciddi birikimler yapmaya geçmeyi planlıyorum. Belki başlangıçta ufak adımlar olabilir, fakat sene sonuna kadar iyi bir birikim yapmayı hedefliyorum.

10 Kitap Okuma

Geçtiğimiz sene toplamda 2 kitap ya okudum, ya okuyamadım. Bu konuda kendimi gaza getirmek, ve eşimin 40 kitabı devirdiğini görmek beni motive ediyor, bunu yapmak istiyorum.

Gece Çalışmayı Bırakma

Gece mesaisi, şirketin uyguladığı bir politika değil. Fakat ben bir süredir, gün içi daha boş takılıp akşamları ek çalışma ile onu telafi etmeye yönelik davranışlar sergiliyordum. Bu durum pek hoşuma gitmemeye başladı. Bundan dolayı mesai bitimi bilgisayardan uzak kalarak bu kötü alışkanlığı yenmeyi, ve gün içi işe daha odaklanmayı planlıyorum.

Bu hedefler dışında bazı ufak değişiklikler de yapacağım, bunlardan sizi etkileyecek olanı, blog domain’ini bırakma kararı almamdan geçiyor. 2020'lerden bu yana kullandığım blog . egesucu . com . tr adresini(ve Premium Medium üyeliğini) bırakmaya karar verdim. Bunda faktör aboneliklere harcadığım para konusunda uygulayacağım diyetlerden ötürü oluyor. Medium’da güzel bir kitlem bulunuyor ve blog domain’in olmayışının beni çok derin etkileyeceğini düşünmüyorum(Google search kısmı hariç, ama çoğunuz zaten yapay zeka kullanarak makale arayıp bulur hale geldi). Zamanında yatırım ile aldığım bazı alan adlarını da bırakmayı planlıyorum(com.tr hiçbir yere gitmeyecek)

Bakalım bu hedefleri bu sene tutturabilecek, ve 2025 gibi mükemmel bir yılı 2026'da yaşayabilecek miyim(tahminen daha az hareketli), göreceğiz.

Hepinize Sevdiklerinizle İyi Yıllar

Uzun bir aradan sonra Türk yazılımcı ekosistemine yazacağım için Türkçe kaleme aldığım bir yazı ile karşınızdayım. Bu yazıda sizlere tecrübelerimi aktararak Türkiye’de neden uygulama yazılımı ve yönetiminde sorunlar bulunduğunu anlatmak istiyorum.

Giriş

Türkiye yazılım konusunda epey genç ve dinamik bir ekosisteme sahip. Genç nüfus kaynaklı ciddi bir yazılım kaynağımız var ve pek çok yazılım firmasına sahibiz. Bu firmaların:

• kimisi kendi yazılımını üretiyor
• kimisi başka şirketin yazılımlarına yazılımcı kaynağı sağlıyor
• kimisi de başka şirketin “teknoloji ekibi” adı altında yazılımlar gerçekleştiriyor.
• Ayrıca indie Geliştiricileri de unutmayalım.(Bu yazı sizden ziyade kurumsallar için daha geçerli olacak.)

Geçmişte küçük, orta ve büyük ölçekli projelerde bulundum. Çalıştığım ekiplerde yeteneklerine hayran kaldığım çok insan oldu(sadece benim üst seviyelerim değil) ve kendilerinden çok şey öğrendim.

Kariyerime başladığımdan beri 5 yılı aşkın süredir farklı scrum ekipleriyle çalıştım ve son 3 senedir Adesso ile birlikte yurtdışındaki ekipler ile farklı projeler üzerinde çalışıyorum.

Zamanla fark ettiğim şey, X(eski adıyla Twitter) içerisinde pek çok yazılımcının proje yönetimleri ile, süreçler ile ve yaşadıkları stres ile mücadele etmeleri ile dolmuş vaziyette. Bazı insanlar hala “mühendislik” ve “geliştirici” arasındaki fark üzerinde düşünürken, kimisi(bir dönem benim de yaptığım) hangi mimarinin ötekini döveceği gibi tartışmalara girmiş vaziyette.

Yazılım ekiplerinde süreç yönetimi sadece teknik bir konu değil; kültürel bir olgunluk meselesi. Bu farkı en net şekilde yabancı ekiplerle çalışmaya başladığımda gördüm

Bu yazı ile size yurtdışında yürüyen projelerin nasıl disiplinlerle çalıştığını, neden başarılı olduğunu ve morallerin yerinde olduğunu, kendi tecrübelerimden ve çalıştığım Alman iş arkadaşlarından yola çıkarak yazmak istedim.

Gerçek Scrum

Öncelikle scrum nasıl işleniyor, anlatayım.

Her 3 haftada bir yeni bir sprint koşuluyor. Sprint, bir planlama ile başlayıp, review ile sona eriyor. Ara süreçlerde;

• Her pazartesi bir refinement bulunuyor.
• Her sabah bir daily bulunuyor.

Bunun haricinde sprint review sonrası 2 aşamalı bir Planning süreci ve bir together-session yapılıyor.

• Planning 1: Herkesin sonraki sprint katkıda bulunabileceği günlerin hesabı
• Think-Debate-Code: Alınacak yeniliğin, tartışılarak alt işlere parçalanması seansı
• Planning 2: Hesaplanmış günlere göre iş yükü alınması

Ee, iyi de bu bizde de aynı(benzer) durumda

Önemli olan bu toplantıların organizasyonu. Örneğin bir projede yer alan“proje dökümanında”(kod dökümanından farklı) bütün konsept kuralları yer alıyor. Örneğin:

Refinement

• Süre: 60 dakika
• Yürüten kişi: Scrum Manager (isim: XYZ ABC)
• Konuların İşlenmesi: ( a) hangi konuların tartışılacağı — 5dk, konuları tartışma — 55dk(konu başına 7 dakika maksimum))
• Toplantı Notlarını Tutacak Kişi: XYZ ABC
• Inputs: Değerlendirilmemiş hikayeler
• Çıktılar: Gerekliliklerin belirlenmesi, engelleyici konular, açık sorular, tahminler(Fibonacci ile)

Uygulanması ise yazılana göre ilerliyor.

Toplantının uzayacağı anlaşıldığında devamı için başka bir güne kısa bir toplantı ayarlanıyor.

Ayrıca:

• Bahsedilenler dışı bir konu konuşulmuyor(gereksiz sohbet edilmiyor)
• Herkesin işi belli, kimse başkasının işini üstlenmeye kalkmıyor.
• Toplantıya dair notlar, o gün içerisinde not yazılarak proje dökümanı içindeki yerine XYZ Tarih-Toplantı şeklinde yazılıyor, gelemeyen kişi bilgisiz kalmıyor.

Detaylı Döküman

Evet, bir confluence sayfası ve alt sayfaları olduğunu fark etmiş olabilirsiniz. Peki neler döküman ediliyor?

# Proje Yönetimi Dökümantasyon Yapısı
## 1. Proje Yönetimi
- Takım
- Nasıl Çalışıyoruz
- İlk Aşama Hedef Yolu
- Handover  
  - Kişi tatile çıkma durumunda elindeki işlerin özetini yazar.  
  - Yerine bakacak veya kendisine durum soracak kişiye bilgi verir.
## 2. İhtiyaç Mühendisliği
- Özellikler  
  - Konunun özeti  
  - İstenilenler  
  - Tasarımlar  
  - Tartışma Alanı  
    - Soru-cevap üzerinden konuların netleştiği yorum bölümü
- Arayüz Elemanları  
  - Butonlar, metinler, özel carousel görünümü vb.  
  - Her özellikte bulunan tüm detaylar  
  - İlgili tartışmalar ve yorumlar
## 3. Toplantı Notları
- Örnek: `2025-xy-za Kickoff`
- Her toplantının amacı, katılımcılar, alınan kararlar ve aksiyon maddeleri
## 4. Proje Inputs
- Test kullanıcı hesapları
- Gerekli erişim bilgileri
- Çevresel değişkenler (örn. staging, dev ortam URL’leri)
## 5. Teslimat
- Scrum Yönetimi  
  - Toplantı düzen detayları (daily, review, retrospective vb.)
- Geliştirme Süreçleri  
  - Branch stratejileri  
  - Deployment URL’leri (örn. `xyz.com/releases`)
- Quality Assurance  
  - Testçilerin nasıl test yaptıklarına dair dokümantasyon  
  - Senaryolar, test raporları
- Sprint  
  - Sprint 1  
  - Sprint 2  
  - Sprint 3 …  
- Takımlar  
  - Takım X  
  - Takım Y
## 6. Yeni Takım Üyesini Onboard Etme
- Şirket kültürü ve süreçlere dair genel bilgilendirme  
- Kullanılan araçlar (Jira, GitLab, Slack, Notion vb.)  
- Proje yapısı ve çalışma biçimi  
- İlk görev planı (mentorluk, ilk sprint katılımı)
## 7. Jira Taktikleri
- Etiketleme ve issue kategorileri  
- Sprint planlama ipuçları  
- Story point tahmin yöntemleri  
- Task’lerin parçalanması ve önceliklendirme  
- Workflow kullanım rehberi
## 8. İletişimler
- Slack / Teams kanal kuralları  
- Toplantı frekansları  
- E-posta ve Jira yorumlarında iletişim dili  
- Takım içi ve dışı bilgilendirme süreçleri

Bu yapı içerisinde her türlü dökümanın gideceği konum belli olduğundan karışan bir durum oluşmuyor. Ayrıca bir karara dair referans gösterilmek istendiğinde, burada kolayca bulunabiliyor.

Mesai Kültürü ve Çalışma Disiplini

Yapılan iş için müşteriye fatura kesildiği için ek mesaiyi unutabilirsiniz. Keza kendileri de tercih etmiyor.

Bu saatte online ne işin var, hiç ekstra düşünme, bilgisayarı kapat ve eşinle keyifli bir akşam/hafta sonu geçir.

Bu cümle, gece 4'e kadar mesai yapmış biri olarak kendi isteğimle akşam 8'de Teams’i açınca iş arkadaşım tarafından yollanmış bir mesajdı.

Almanların mesai kültürü standart 9:00–18:00(12:00–13:00 arası ara ile). Bu saatler dışında sizlerden bir beklentisi bulunmuyor.

• Bir iş son güne kadar uzadı mı? — Son günü haftaya erteliyorlar.
• Elindeki iş eklediğinden uzun mu sürüyor? — Yardım etmeyi teklif ediyorlar, olmadığı durumda işi bir sonraki sprint’e atıyorlar, ya da iş ile alakalı arkadaşlarından teknik destek istiyorlar. (Neden yapamadın, geceye kadar otur hallet, konuyu başkasına verelim sen yapma gibi tavırlar bulunmuyor)

Temelinde her işin süresini başında sen belirliyorsun, çok abartı veya çok kısa ise durumuna göre(ekibe yeni girdin ve koda yabancısın örneği) kabul ediyorlar veya daha uzatmanı öneriyorlar.

Bu hafta işlere verdiğim tüm saat önerilerini “android tarafı daha uzun zaman vermiş, sen de uzat” diye arttırmışlardı.

Peki bu uzatmalar ve rahatlık projenin gidişini bozmuyor mu?

Hayır. Bunun en büyük sebebi projenin genel gidişine dair tahminlerde bulunurken her zaman +- 3 haftaya kadar süre koymaları. Keza bir projemizin sürümü, Apple tarafında yaşanan değişikliklerden ötürü 1 ay ertelenmişti.

Müşterilere bu güven nereden geliyor?

Bir müşteri gözünden bakıldığında gecikme süreleri endişe verici olabilir. Buradaki sır Scrum içerisinde yürüyen Review toplantıları ve düzenli raporlama.

Öncelikle çok detaylı olmamakla birlikte günlük yapılan işler saatleri ile sisteme kaydoluyor.

“ABC-202 Dökümana kod kuralları maddesi ekleme” gibi.

Daha sonra bu raporlar aylık olarak sistemden alınıp, müşteriye aktarılıyor ve onaylandığı zaman fatura kesilerek işe devam ediliyor. Ayrıca, bu 1 aylık süre içerisinde 1–2 kez proje yöneticileri(geliştiriciler değil) müşteri firma temsilcileri ile bir araya gelerek gelişmeler, sürecin durumu ve scrum tablosunun durumu gibi bilgileri aktararak müşteriyi düzenli olarak bilgide tutuyor. Bu sayede müşteri, ekibin hangi zamanlarda ne iş yaptığını detaylı olarak biliyor.

Test Eksik Bırakılmıyor

Projelerin çoğu %70 total Unit test oranını şart koşuyor.

Bu koşula uyum sağlamak için yazılan her iş mantık kodu, her yeni özellik ve iyileştirme adına yazılan kodlar, yanlarında unit test de bulundurmak zorunda. Bu yapılan işi ilk etapta uzatıyor olsa da, eksik bırakılmasından doğacak pek çok hatayı önlüyor.

Uygulamaların kontrol edildiği ve deploy edilen beta sürümleri testçilere düzenli gönderiliyor ve uygulama kontrollerden de geçiyor.

Ayrıca pipeline bu testleri düzenli kontrol ederek, açılan PR test yüzdesinden fazla saptığında(yani test yazılmadığında ya da çok az yazıldığında) buna dair uyarıyı dile getiriyor ve bu durumda kod birleştirilmiyor.

Bir PR merge olduğu zaman snapshot build de çıkarılıyor ve testçiler bunun kontrollerini de sağlıyor. İnceleme yaparken emin olamadıkları noktada proje dokümantasyonunda işe dair tanımlanan yükümlülüklere bakarak yerine getirilmeyen noktaları sebep göstererek hata kaydı açabiliyor.

Normal Unit Testlerin yanısıra, projede uyulması gereken kurallara dair ADR(Architecture Design Records) da bulunuyor. Bu kurallar gerektiğinde değişiyor, ve uygulamanın kökünde yazılan Harmonize testleri ile projede bu kodlamaya uyulup uyulmadığına dair test koşuluyor.

Örneğin; `import FeatureToggle` kodu yalnızda `Feature` modüllerinde kullanılabilir, aksinde hata verilir.

Bu süreçler sayesinde uygulamanın develop ortamında bile hatasız bir şekilde ilerlemesi sağlanabiliyor(API istekleri hariç, onlar uygulamayı çökertmeyen türde hata verebilir).

Neden

Bu noktada sıkılıp soracağınız soru şu olabilir?

Neden bütün bunlarla uğraşıyorsunuz, bunlarla uğraşmasanız o uygulama 3 ayda çıkar, kalan zamanda da iyileştirme yaparsınız, ne saçma?!

Haklı olabilirsiniz. Keza bu proje kurulumları ve detayları da zaman alan işler. Fakat, Türkiye’de ortalama geliştirilen projelere bakıp, görmezden geldiğiniz absürd çökmeleri ve hataları umursamadığınızda bu durum doğru oluyor.

Testleri önemsemediğiniz her sürüm günün sonunda testçiye ek yük ve hata yaptırıyor, son kullanıcıya kadar da geliyor.

Mesaileri önemsemediğiniz her çalışma çalışma arkadaşlarınızı uzun periyotta yoruyor, ayrılmasına sebep oluyor ve yerine alacağınız kişinin alışma süresine ödeyeceğiniz ek maliyetler olarak geri dönüyor.

Proje dökümanını önemsemediğiniz her senaryoda, işi bilen insanlar ayrıldığında bir bilgi kaybına uğruyor, yeni gelen kişilerin aylarca bu bilgilere erişememesinden sorumlu oluyorsunuz.

Özetle;

Ben cuma akşamı 5'te açtığım sohbet kanalında keyifle havadan sudan konuşurken, siz aynı saatte açıp geceye kadar kapatamadığınız sohbet gurubunda son dakika çıkan sorunu anlamaya ve çözmeye uğraşıyorsunuz.

Bu yazıda genel olarak Türkiye’deki yazılım geliştirme süreçlerinin yabancılarca nasıl ele alındığını ve bu yöntemin kendilerinde nasıl çıktılar ürettiğini göstererek Türk şirketlerindeki proje yöneticilerine ve yöneticilere açık çek sunmuş, geliştiricilere de her retro toplantısında “biz neden bunu yapamıyoruz” sorusuna binlerce cevap üretmemeniz adına yöneticilerinize sunabileceğiniz bir takım tavsiyelerde bulunmuş oluyorum. Türkiye’de bu süreçleri hala normal bulan kişilere son sözümü söyleyerek kapatıyorum.

• Bir banka uygulamasında 1.234,56 TL yapıştırıldığında 1,23456 olarak işlemeye çalışıp 1,23 olarak kırpmanız kabul edilebilir değil.
• Bir uygulamada “not_translated_yet” metnini son kullanıcıya göstermeniz normal değil.
• Bir projede çalışanları gece 4'e kadar çalıştırıp sonraki gün 9'da beklemeniz normal değil.
• Verimini sömürdüğünüz yazılımcıları verimsizlikle suçlamanız adil değil.
• Yazılımcınız uygulamanın analiz raporlarını, proje sunumunu ve iş planlamasını yürütme görevlerinden sorumlu değil. Proje/Ürün yöneticisi, Testçi ve Analiz görevlerinin bir sebebi var.

I’ve been a follower of Linux way before I became a software developer. I was daily driving Ubuntu, Mint, Pardus(Turkish Linux distro), & Fedora previously. I know Ubuntu all the way from 14.04 up until 25.04. While Linux is progressing year by year, thanks to the open source contributors & passionate Linus Torvalds who still write today, the general progress is a slow one.

What made me convince to write about this is the fact that Linux oriented promotions & advertisements seem to grow more than before. We are hearing that governments implementing Linux conversion, governments trying to rely on open source softwares & EU moving on Open Source Solutions on nation-wise to YouTubers like PewDiePie switching and recommending Linux.

So, let’s discuss the year 2025 and if Linux really can throw some fears into closed systems such as Apple, Microsoft, Adobe and others.

Reason(s)

There are some reasons why individuals and organizations may want to switch into Linux & open source softwares at this point.

• Microsoft increasing its support & subscription services higher than anticipated.
• Windows 11 being more “ad-oriented” than prior releases
• Microsoft forcing users to Windows 11 by deprecating the Windows 10.
• Increased number of AI additions which doesn’t help users but distract and push them into subscriptions.
• Dominated apps such as Adobe softwares, bundles and charges their costs high, also making the cancellation process harder by implementing early cancellation fees.
• Tension over US-based companies and their monopoly on their software standards & support.

As you see, on both sides there are fundamental issues which forwards users to think about the switch. But why now?

On institute side, we hear countries like Denmark ditching Office 365 solutions in favor of LibreOffice & OpenExchange solutions. Or France worked silently to adapt Linux distro on its policing systems.

On personal side, we see that O.G YouTubers like PewDiePie recommending Linux, open source solutions & even De-Google the everyday tool he’s using. Linux forums on Reddit has an increased posts than before, and people have started to talk open source solutions more as centralized solutions have issues for them such as being blocked/suspended/limited/ad-filled solutions.

So, how is Linux?

How’s it going Linux?

During the writing of this article, we have Ubuntu 25.04 released, Gnome 48 is available, KDE Plasma 6.4 is here and Linux Kernel is on 6.15.4 is there. Does this mean anything to you? I don’t think so too.

Linux has been improving since years thanks to the open source contributions from all over the world. It works better on multiple PCs and notebooks.

One weak point is that the arm architecture support is not on all linux distributions and you need to check if your OS supports in case you have an arm notebook.

Apart from that, the memory requirement of the OS is still 4GB, although I will recommend a 8GB or more. Space is still at 25MB approx. a nice 80GB space will be sufficient for basic usage, and these days, computers are more than 128GB anyway if a full installation is considered.

Gaming side, Valve’s contributions have been helpful to make some people switch into Linux and We are not in the level of Wine software on Linux in 2014, it’s been enhanced a lot.

Tools like LibreOffice has been evolved and more compatible with Office file schemas than before. Usability of LibreOffice on all platforms also help people to move their stuff between Operating systems.

Can Linux become the trend in 2025?

Yeah, we came into the question readers could wonder. Can people begin to switch and we call this year “The year of Linux”?

No.

While the OS and the platform grown up so much by bringing favorite apps via new package systems(flatpak, snaps, appimage etc.) people still are not 100% motivated to bother even with the installation process.

You still require to download the ISO file to burn into a USB to use it as a installer and then decide to dual-boot or full install to continue using their systems with an operating system which they are not used to it, will require some terminal work for 20% of the operations(it used to be 80–90%, that’s honestly better).

The problem with a mass is that their daily usage of subscriptions, apps and gestures/keyboard shortcuts are generic, they will not like a complete change.

While I’m expecting some people to switch and increase the overall usage, the trend in the enterprise & personal side will likely stay same for a while. I’m not expecting a massive change in the next 10 years if something big has not happen(something like Apple & Microsoft deciding to put ad on every single pixel of the screen).

Main Reasons people would not bother switching:

• UI is still behind from other platforms
• Setup is still confusing for some(why distro owners are afraid of putting a script to run the usb-image-burning-process)?
• Some frequently-used softwares have no place in Linux, and people would not bother switching that easily(There’s a reason why there are migration tools like Apple Music → Spotify which earns one-time fee)

In conclusion, Linux distributions are still a “power user” operating systems. For a standard user to be frequent with it requires an early education or company policy to switch people into them. I hope for the future that this will be more adapted, have a better place on the OS distrubition charts and motivate the giants to think more of the users rather than their revenues. In the end, software is the bridge between a hardware(product) & person. If you make an AI bloated Spam solutions, user will search for other connections. Remember browser menu bars? That disaster was the end of IE for many users and almost caused Firefox being disaster too… wait, Firefox is having similar issues with Privacy contradictions? Oh well…

While App Store has seen amazing apps over the years, there are also apps which shows issues you as a user should never see. In this article, I’ll show you some aspects of the errors and how you can improve them on your apps when working on.

Handling Errors

You may seen some screens like this, time to time.

When you develop an app, you might expect errors you don’t know how to deal with. This could cause out of:

• Not talking through
• Not planning scenarios
• Depending on another source’s error handling

On those cases, you need to remember that you don’t have to present everything you get from your source. While error.localizedDescription looks good, it wouldn’t give you enough solutions all the time.

Instead, handle your UI to provide the user enough errors they should know, and keep the details to you.

import Foundation
import OSLog

enum KnownErrors: Error, CustomStringConvertible {
    case invalidData
    case serverError
    case networkError
    case unknown(String)
    
    var description: String {
        switch self {
        case .invalidData:
            return "Invalid data received from server"
        case .serverError:
            return "Server returned an error"
        case .networkError:
            return "Network Error"
        case .unknown(let string):
            return string
        }
    }
}

let error = KnownErrors.invalidData
let logger = Logger()

func handleData(_ data: Data) {
    // some handlings here...
    switch error {
    case .invalidData:
        handleError(message: error.localizedDescription)
    case .serverError:
        handleError(message: error.localizedDescription)
    case .networkError:
        handleError(message: error.localizedDescription)
    case .unknown(let string):
        handleError(message: "There is an unexpected error occurred. Please try again later, or send us a feedback at support@example.com.")
        // Notice how I did not show the actual error on UI, but kept in our logging.
        logger.error("Unexpected error occurred: \(string)")
    }
}

func handleError(message: String) {
    // Some UI operations to show Error
}

With this approach, your user will never see an error you did not expect to show, but you can still catch them and get a log(optionally make the users send one to you). This is especially useful if you get your errors from backend and they might introduce a new error type which you:

• implemented but your users from older versions are still going to see them
• not implemented and now your users see this.

If you want to further get help from your users without sharing any logs, you can also create error codes, and only provide error codes(MA324 as MyApp) inside of the “unknown” case, so that your users may contact you without requiring to send/collect a log to indicate which error they got.

Defining the Namings

When you enter a project, it can be tough to get familiar with it. When I joined our scout talent app CUJU, as a not football fan, the most frustrating part of the app was the definitions. What’s a promoter? You might say it’s a role type who manages the young talents. But on the app, it might sometimes mean “Coach”, sometimes “promotee” sometimes “Promoter”. This is not the fault of the previous developers, but something that’s not been discussed enough in the beginning.

This is not only project’s fault either. I’ve seen this ambiguous namings over many apps I’ve worked on before. The problem lies on how namings should be decided. Let’s take an example:

The project is a simple todo app which supports many types of attachments on itself. Your first instinct should be to define what’s a todo:

• A type that has a title
• has an optional description
• has sub-items
• may have a date
• may have a deadline
• may have an attachment

So instantly, your models could look like this:

import Foundation

struct Todo: Identifiable {
    let id = UUID()
    let createdAt: Date
    let title: String
    let content: String?
    let date: Date?
    let attachment: Attachment?
    let deadline: Date?
    let tasks: [SubTasks]
    let priority: Priority = .mid
}

enum Priority {
    case low, mid, high, highest
}

enum Attachment {
    case image(imageData: Data)
    case file(url: URL)
    case video(videoData: Data)
}

struct SubTasks {
    let title: String
}

The point of it is to keep your namings simple but clarified as possible. You may overrate this and name something like “ESTodo”, came from Ege Sucu Todo which is pretty common on indie apps(or PROJTodo on corporate apps), but it doesn’t define the need of it. Why did we create it? Why did we simply not used the default model for it.

In those cases, a short documentation to explain the content and how it’s been used is more useful.

/// This model has been created to support our TODO items to be transformed into desired output easily.
class ESTemple {
    /// Converts the content into PDF by defined operations.
    /// - Parameter desiredFormat: Format type as given, accepted ones are "pdf", "md" & "txt"
    func convertToPDF(
        desiredFormat: String = "PDF"
    ) {
        // Some Convert Logic occurred.
    }
}

While this will create some extra time for you, it will, in return, create less time for your colleague’s onboarding.

Lack of Testing & Documenting

For many projects, documentation lies on the developer who have been worked for the most of the time. Details such as “which architecture should be used”, “which colors do the app contain”, “Which screens do we have” left on the air when that developer is busy, not available or left the company all together. This happened on a banking app where 70% of the devs are left for other companies, leaving the newcomers a big app without any documentation, resulting creation of duplicate view components, mixed architecture choices and non-matching views between pages.

A documentation is both helpful for you and your future colleagues. Lack of the documentation on anywhere(on the code, on documentation places like Confluence) results higher research/onboard process for any devs, and creates unnecessary short meetings between your colleagues, or with the management to ask details.

The worse case for a developer is to be asked about a feature decision which results looking for the code changes, git blame to find devs who did it, and the research of asking wised employees about it. Happens too much.

Testing is another problem. On indie apps, testing might be nowhere and the 1.0 version of the app might upset many users.

The problem is simple. You as a developer have one environment. A 13" M3 Macbook Air, an iPhone 14 Plus on iOS 18.4. But your users are on different environments. There are tons of devices, many sizes, different modes(dark, light, auto, high contrast etc.) If you want your apps to be heard more by people, you need to care about them too. Does your colors look nice together in Dark-light mode? Does your app support dynamic fonts?

Those things can be seen only by one option.

Testing them one by one

Luckily, your working environment has many testing options to show you this, whether it’s Simulator, or a 3rd party testing framework. This even applies to the corporate projects which surprise me whenever I came across them.

There are less unit tests than the amount of app assets.

App security and maintenance are seen as cost for most of the projects, hence the process of unit tests are not cared until some manager turns on the importance of it and creates week long writing process and bashes developers on “how it was never done before”. While 1.0 is a first release of an app, the real big next release is when the app is secured by tests & security measures, not the big changes.

Not following the Software Features

This is my biggest nit on developers. Apple doesn’t create WWDC for the show. There’s a reason why apps like Flighty, Halide, WaterMinder, Carrot, Things 3 & others are successful. Not just because of their UI’s, but also their feature adaption sets. On every iOS release, they release their new versions with using Apple’s latest changes, offering fresh experiences to their users.

While they’re big apps, it doesn’t mean for you as a developer to just implement all new features of iOS. Do you support Swift 6? It’s been one year since Apple made it available. Do you even support Swift Concurrency? That was available since Swift 5.5, which is released in…2021. These little changes help your app to keep in updated.

There are probably many extensions you have written which is already been solved by Swift, like Date.now came in iOS 15, replaced the old static vars written. Or, FormatStyle API which replaced most of your Date/Number/String formatting by dot endpoints like:

let rounded = 123456789.formatted( .number
    .rounded(rule: .down, increment: 1000)
    .locale(Locale(identifier: "fr_FR"))) // "123 456 000"

Measurement extensions, feet to cm converters. Why? We already have an API from Apple for this since iOS 10… These things are not easy to find, but if you are curious, and love to dig deep, you’ll see that a 8 years old project has many obsolete extensions/custom components written and still left.

I like how on every minimum iOS Target increase, we remove one custom SwiftUI view in favor of the introduced with the new iOS version.

While some of those points are known by the developers, but looked upon, these are essentially why your apps, and the apps on the store, are failing. While there are other aspects to take care of such as ASO optimizations, marketing strategies etc., these problems can not hinder the success of those steps, so you still need to care about those points to have an app which can handle non-expected operations like you would like it to be.

Happy coding & see you in the WWDC week 💻

Recently, I’ve promoted as a Senior iOS developer at my job after coding Swift for 8 years. You might say it’s a late promotion, since many expect a shorter term to become senior. The truth is, I had the same mind, but realized other aspects that lacked me to become one. Working with colleagues, and the past colleagues I’ve worked with, I wanted to create this article to guide people to level up in their game. While the advantages might not be only valid for iOS development, I wanted to give a focus on my community over this topic.

If you’re ready, let’s start with the first point.

Rushing without Searching

We all want to earn more, become more knowledgeable, be a TED talker, possibly work at Apple at some point or become an individual, hitting 100M$ MRR…

Right?

While this is a fantastic idea, came on my mind multiple times, people always forget what the title is for.

People often focus on the title where instead, they need to focus what knowledge the title contains.

When I was asking for being Senior, I often stopped myself on points I didn’t know.

I possibly couldn’t become a senior without knowing this.

And I was right. Being senior means that you need to have the knowledge about the aspects of an app.

• How does it send/retrieve the data?
• How much time requests cost, can you minimize that?
• How the security applies on the app?
• How do you test the app, is it automated?
• Do you know about some algorithms to help you out?
• Do you know how the code you’ve written works?

The latter was important even when you’re switching from junior to mid tier developer. Previously, we would see many StackOverflow code was pasted without the developer understanding the code, now it’s AI tools.

While AI tools are very beneficial on solving the problems and essentially helping you(not replacing), it’s important that you need to understand that help to how it solves your problem, how the code proceeds instead of copy-pasta(or auto implementation). It’s not going to solve your problem otherwise, and even it will break your project if you solely rely on copy-paste codes.

Other aspects I have mentioned will have the same step as this, it’s to understand the concepts of the app and how secure/strong your app can be. We have millions of apps on the App Store, many thousands are doing the same. Yet, the ones who took care of these steps carefully can reach the customer and make it stay, while other apps are famous by their 1 star reviews(even after eliminating out-of-value critics). You might think that, in a company, this wouldn’t be important since the value is already present.

You’ll be wrong. That’s what one of the things your manager looks for and you being evaluated.

For the indie developers, those points especially matter. Since it’s the lack of the people that gives indie developers hard time on developing or maintaining an app after the development. Even if you’re a team of one, being organized and checking every aspect of your app matters for the customer retain.

Out of your Scope

When we think of a mobile developer, the concern is usually:

• Be consistent on your code
• Develop features, apply improvements and fix the damn bugs…
• Log your days
• Be happy

While that’s true, sometimes you need to come out of your scope a little to help your teammates on the project to evolve.

• Giving a UI bug to your designer as a feedback is a ➕
• Managing the Pipeline to make sure the app works fine is a ➕if you don’t have a DevOps on the team.
• Suggesting new tasks, improvements on the description and gather with the mobile to plan ahead is a ➕ when working with a product owner since not all of them can understand the tech, or the importance of the job there.
• Suggesting new ideas, features and showing extra bugs you found with the team helps the app become stronger, and so do you.
• Suggesting alternative tools and coding techniques help your team to be innovative.

These suggestions might seem to benefit your team, but those are also tracked by your managers when evaluating you.

Fighting with Issues

It’s important for any developers wanting to level themselves up to face the fact.

We all encounter problems. No developer is perfect, nor they or the system they use can be. And that’s fine.

While this is a general thing everyone has to deal with, the difference between a senior developer and a junior/mid one lies on how-to.

While a junior developer might pass the issue on it’s superiors, or lie through the “non-replication of the problem”, and a mid developer working on multiple days without defining the steps they’ve introduced, a senior developer must look for the root cause of the problem.

• Where is the root cause of the issue?
• Can I fix it via adjustments, or is it a system failure in which I could find a workaround for it?
• Should I ask others opinions?
• Should I make myself vulnerable by asking that?
• Should I rely on ChatGPT solution to apply without thinking much?

Those questions are important to consider and valid for years. People tend to question their ability to fix that, so they hide. However, this doesn’t help anyone, themselves too. There’s a reason why you work with a team and not by yourself as a developer. The reality is:

There is no silly question, but there’s a silly outcome when you don’t ask for it.

This include prolonging a problem with days, undermining a workaround which breaks other part of your code and space between your colleagues when you want to help them later.

So, instead, feel free to ask everything. Discuss the possibilities, ask further when you don’t understand their answers. Every sensible developer is favoring couple minutes with 1–1 to answer questions. It’s not a 8 hour full job logging only.

Even when a problem is occurring on the system level, you can apply a workaround for it, such as warning the user about the inconsistency related to that issue, hiding that view for a time, using alternative components to mimic the approach and such other methods exist on many apps. As an example, SwiftUI did not have good UI components for Alert Controllers for a while(the current solution is still not good), so we wrote custom views instead previously.

Using the AI tools

We all have an AI tool we are using from time to time. It’s important however, how you’re using it. For most of the juniors, you’re using it wrong.

People are relying on the AI tools to write things for themselves, where they don’t bother with how that code constructs. How does it work, why does it work etc.

Before the age of Internet, people used to have Bibliotheca to check for the information. Newspapers were selling those with coupons, libraries obtain them so people were visiting museums to get their answers, help their thesis etc. With the Internet age, people started to get lazy around the knowledge they seek for, while the technology offers them the ease of reaching that.

It’s similar with the AI tools where a ChatGPT command would tell you what’s the code for and why it matters, but people rarely read them in favor of copy-paste. It’s always beneficial to ask further questions to clarify your knowledge on the topic, so you wouldn’t require gpt again for that problem in the future.

Communicating with Other Developers

One thing I see less is that the developer who wants to level up for the senior, and does not understand why they can’t, is also the person who doesn’t talk with senior.

Why would you talk with a senior?

Because he has the idea why you might be not suited for, can give you advices on the improvement, and can lead you to see how they are operating in the same conditions you operate. Also, showing yourself for wanting to be better is a ➕ for your higher ups to see your motivation too.

Creating small Apps

People might assume that in order to make an app, or create an article, you need to be an experienced developer.

When I started to blog about iOS development, I was learning the language fresh, I started blogging in 2018 where I was months old as a personal iOS developer. My app, Pet Reminder was came out in 2018 too and being developed ever since.

Writing small apps and articles, helps you to be better about that topic. It also helps you to understand topics you don’t use at work, for the possibility of using them later.

For example, our work project is not Swift 6, not in async-await fully and only supports iOS 15+, so no NavigationPath, no SwiftData, no Observation really. But my personal app is on iOS 18, have all of them(except a good NavigationPath which I’m thinking off). My work app also has some features that my personal app doesn’t have(modularization, dependency injection etc.), but this is important to understand that, I could be able to have many coding disciplines understood because I worked on it for a big/small app, or wrote a small app for an article on it, to understand better.

You can’t understand combine without learning and creating content about it. You would have no idea about Xcode 16’s enormous amount of warnings of main actor isolation if you don’t start working on a small swift 6 apps with all feature toggles enabled. That’s how every dev learns it.

Conclusion

Becoming a higher level developer is not about having the title. I see some friends where they became app manager in 2 years on a small company without proper management. I see many people who have been working for Swift but did not go further to understand the aspects of the app and only focused on what task they have taken from the sprint, so their information is not different someone with 2 years of iOS experience in that manners.

I used to joke around some of my colleagues that was more experienced than me as a title, but asking me questions about the topics which I used to expect them to know better than me. It’s about being open to learn all the time, improving yourself day by day like productivity gurus do and be the best version of you. And if after all of this, and your company is not recognizing that, there will be other companies to recognize, so you can talk with others to switch too.

I’m wondering your opinions, comments from people wiser than my thoughts, and newbies who applied their own methods to be better. Let’s meet on the comment section below. Happy coding.

An actor is a reference type, like a class, built to manage mutable state safely in a multithreaded environment. Introduced in Swift 5.5, actors help developers write thread-safe and more predictable code when working with asynchronous tasks and shared mutable data.

How Are Actors Different from Classes?

Actors guarantee that their mutable state is accessed by only one thread at a time. This prevents data corruption and ensures integrity.

Wait, what?

Let’s look at a simple example using a class called Dinner. It has one variable and one method, eat(), which increases the counter of dinners made in a month:

class Dinner {
    var value = 0

    func eat() {
        value += 1
    }
}

let dinner = Dinner()

// Simulate concurrent access
Task {
    await withTaskGroup(of: Void.self) { group in
        for i in 0..<30 {
            if i % 2 == 0 { dinner.value -= 1 }
            group.addTask {
                dinner.eat() // ⚠️ Not thread-safe!
            }
        }
    }
    print("Final value (class): \(dinner.value)")
}

Here, I intentionally added a condition to mess with the counter. While this is a simple example, in a real-world app, more complex cases could cause similar issues. Instead of getting 30, you might end up with 15 or even less. That’s because the value is being accessed and modified from multiple threads at the same time.

Even if you make ‎`value` private and only change it through a function, you still can’t prevent race conditions in asynchronous code.

How Actors Solve This

With actors, this problem goes away. You simply can’t access the actor’s internal state directly from outside. The compiler won’t let you

actor SafeMeal {
    var value = 0

    func eat() {
        value += 1
    }

    func getValue() -> Int {
        return value
    }
}

let safeMeal = SafeMeal()

// Safe concurrent access
Task {
    await withTaskGroup(of: Void.self) { group in
        for _ in 0..<30 {
            // if i % 2 == 0 { safeMeal.value = 1 } ⚠️ Not allowed, will cause a compile-time error
            group.addTask {
                await safeMeal.eat() // ✅ Safe access
            }
        }
    }
    let finalValue = await safeMeal.getValue()
    print("Final value (actor): \(finalValue)")
}

If you try to change the value directly, you’ll get an error like:
“Actor-isolated property ‘value’ cannot be mutated from a non-isolated context.”

To modify the value, you must define a method inside the actor, then call it with ‎await:

func reduceCount() {
    value -= 1
}

if i % 2 == 0 {
    await safeMeal.reduceCount()
}

This ensures the actor is accessed safely, one task at a time.

A More Advanced Example: Chat Server

// Define a message model
struct Message {
    let user: String
    let content: String
    let timestamp: Date
}

// Actor to manage chat history
actor ChatServer {
    private var messages: [Message] = []

    func postMessage(from user: String, content: String) {
        let message = Message(user: user, content: content, timestamp: Date())
        messages.append(message)
    }

    func getMessages() -> [Message] {
        return messages.sorted { $0.timestamp < $1.timestamp }
    }
}

struct Main {
    static func chat() async {
        let server = ChatServer()
        let users = ["Alice", "Bob", "Charlie", "Diana"]

        print("Starting to post messages...")

        await withTaskGroup(of: Void.self) { group in
            for user in users {
                group.addTask {
                    for i in 1...5 {
                        print("Posting message \(i) from \(user)")
                        await server.postMessage(from: user, content: "Message \(i) from \(user)")
                        try? await Task.sleep(nanoseconds: UInt64.random(in: 10_000_000...50_000_000))
                    }
                }
            }
        }

        print("Finished posting messages. Retrieving all messages...")

        let allMessages = await server.getMessages()
        for message in allMessages {
            print("[\(message.timestamp)] \(message.user): \(message.content)")
        }

        print("All messages printed.")
    }
}

In this example, the actor ensures that messages are updated safely, even when multiple users are posting at the same time.

Starting to post messages...
Posting message 1 from Alice
Posting message 1 from Bob
Posting message 1 from Charlie
Posting message 1 from Diana
Posting message 2 from Alice
Posting message 2 from Bob
Posting message 2 from Diana
Posting message 2 from Charlie
Posting message 3 from Alice
Posting message 3 from Bob
Posting message 3 from Charlie
Posting message 3 from Diana
Posting message 4 from Charlie
Posting message 4 from Diana
Posting message 4 from Bob
Posting message 4 from Alice
Posting message 5 from Diana
Posting message 5 from Charlie
Posting message 5 from Bob
Posting message 5 from Alice
Finished posting messages. Retrieving all messages...
[2025-04-17 19:14:11 +0000] Alice: Message 1 from Alice
[2025-04-17 19:14:11 +0000] Bob: Message 1 from Bob
[2025-04-17 19:14:11 +0000] Charlie: Message 1 from Charlie
[2025-04-17 19:14:11 +0000] Diana: Message 1 from Diana
[2025-04-17 19:14:11 +0000] Alice: Message 2 from Alice
[2025-04-17 19:14:11 +0000] Bob: Message 2 from Bob
[2025-04-17 19:14:11 +0000] Diana: Message 2 from Diana
[2025-04-17 19:14:11 +0000] Charlie: Message 2 from Charlie
[2025-04-17 19:14:11 +0000] Alice: Message 3 from Alice
[2025-04-17 19:14:11 +0000] Bob: Message 3 from Bob
[2025-04-17 19:14:11 +0000] Charlie: Message 3 from Charlie
[2025-04-17 19:14:11 +0000] Diana: Message 3 from Diana
[2025-04-17 19:14:11 +0000] Charlie: Message 4 from Charlie
[2025-04-17 19:14:11 +0000] Diana: Message 4 from Diana
[2025-04-17 19:14:11 +0000] Bob: Message 4 from Bob
[2025-04-17 19:14:11 +0000] Alice: Message 4 from Alice
[2025-04-17 19:14:11 +0000] Diana: Message 5 from Diana
[2025-04-17 19:14:11 +0000] Charlie: Message 5 from Charlie
[2025-04-17 19:14:11 +0000] Bob: Message 5 from Bob
[2025-04-17 19:14:11 +0000] Alice: Message 5 from Alice
All messages printed.

What If We Used a Class Instead?

Now, imagine doing this with a class instead of an actor. With 100 messages per user, things break down:

// Message model remains the same
class Message {
    let user: String
    let content: String
    let timestamp: Date

    init(user: String, content: String, timestamp: Date) {
        self.user = user
        self.content = content
        self.timestamp = timestamp
    }
}

// Class to manage chat history (NOT thread-safe)
class ChatServer {
    private var messages: [Message] = []

    func postMessage(from user: String, content: String) {
        let message = Message(user: user, content: content, timestamp: Date())
        messages.append(message) // ⚠️ Potential data race
    }

    func getMessages() -> [Message] {
        return messages.sorted { $0.timestamp < $1.timestamp }
    }
}

// Main simulation
struct Main {
    static func chat() async {
        let server = ChatServer()
        let users = ["Alice", "Bob", "Charlie", "Diana"]

        print("Starting to post messages...")

        await withTaskGroup(of: Void.self) { group in
            for user in users {
                group.addTask {
                    for i in 1...100 {
                        print("Posting message \(i) from \(user)")
                        server.postMessage(from: user, content: "Message \(i) from \(user)")
                        try? await Task.sleep(nanoseconds: UInt64.random(in: 10_000_000...50_000_000))
                    }
                }
            }
        }

        print("Finished posting messages. Retrieving all messages...")

        let allMessages = server.getMessages()
        for message in allMessages {
            print("[\(message.timestamp)] \(message.user): \(message.content)")
        }

        print("All messages printed.")
    }
}

You’ll see messages posted out of order, or even missing, because multiple threads are modifying the array at the same time.

…
[2025-04-17 19:20:06 +0000] Bob: Message 98 from Bob
[2025-04-17 19:20:06 +0000] Bob: Message 99 from Bob
[2025-04-17 19:20:06 +0000] Alice: Message 99 from Alice
[2025-04-17 19:20:06 +0000] Diana: Message 94 from Diana
[2025-04-17 19:20:06 +0000] Bob: Message 100 from Bob
[2025-04-17 19:20:06 +0000] Alice: Message 100 from Alice
[2025-04-17 19:20:06 +0000] Diana: Message 95 from Diana
[2025-04-17 19:20:06 +0000] Diana: Message 96 from Diana
[2025-04-17 19:20:06 +0000] Diana: Message 97 from Diana
[2025-04-17 19:20:06 +0000] Diana: Message 98 from Diana
[2025-04-17 19:20:06 +0000] Diana: Message 99 from Diana
[2025-04-17 19:20:06 +0000] Diana: Message 100 from Diana
All messages printed.

When Should You Use Actors?

Use actors when your app needs to handle shared data across multiple concurrent tasks. They’re especially helpful in highly asynchronous environments, where class-based managers can be replaced with actors that safely mutate state.

Why Not Use Structs?

Structs are value types, and copying them avoids shared state. The real concurrency issues happen with reference types like classes. That’s why actors matter.

Are you planning to use actors in your next project? Let me know in the comments. Happy coding!

The Clean architecture came out in 2012 by Robert C. Martin to solve the problem with project designs, where he believed a project should:

• Be independent of frameworks
• Be testable & maintainable
• Separate of concerns-driven
• Highly decoupled

Today, we will dive on how a swift project can be supported by this architecture.

Design

On the foundation, The Clean Architecture separates the project into layers. Each layer is responsible for a specific task & have a clear dependency rule. Inner layers do represent high level business rules, while outer layers represent low level implementation details such as UI, DB and others. Inner layers do not know anything about outer layers. This helps developers to implement new features without breaking the core layer of the app and be able to test things on their own sub packages.

These layers are break down into four parts:

• Interface Adapters → Convert data came by use cases to feed the UI
• Use Cases → App Specific business rules
• Entities → Enterprise-wide business
• Frameworks & Drivers → UI, Database, external frameworks

In SwiftUI’s terms, those will be ViewModel, Classes, Structs & SwiftUI Views/SwiftData(or CoreData) models.

Implementation

For a showcase, I have created a humor app which is responsible to show a random meme and a random joke in the app’s foreground. It also has a search joke by keywords feature in which we can execute a search on the Humor API. Source codes are available on GitHub, and it is written with Swift 6 to showcase current Swift Structure practices with The Clean Architecture.

Entities

With this layer, I have implemented necessary models and enums that will be widely used inside of the app.

struct Joke: Identifiable, Codable {
    let id: Int
    let joke: String
}

enum APIErrors: Error {
    case invalidURL
    case invalidResponse
    case decodingFailed
    case emptySearchQuery
}

extension APIErrors: LocalizedError {
    var errorDescription: String? {
        switch self {
        case .invalidURL:
            "The given URL is invalid"
        case .invalidResponse:
            "The response is not valid."
        case .decodingFailed:
            "Decoding has failed."
        case .emptySearchQuery:
            "The search query is empty."
        }
    }
}

Repositories

This layer covers a repository which handles various functions that we will use. Note that, there is no implementation or a dependency on the repository itself. It will conform into many other use cases.

protocol HumorRepository: Sendable {
    
    func searchJokes(keywords: String, number: Int) async throws -> [Joke]
    
    func randomJoke() async throws -> Joke
    
    func randomMeme() async throws -> Meme
}

Implementations

This is the place where this repository will be conform to. While you could write something like “HumorRepositoryImpl.” or similar, I have opted for “DefaultHumorRepository” which is more clear way to represent the implementation.

final class DefaultHumorRepository: HumorRepository {
    private let apiKey: String?
    private let baseURL: String
    
    init() {
        self.apiKey = Self.loadAPIKey()
        self.baseURL = "https://api.humorapi.com"
    }
    
    /// This is a test case init, which uses apiKey to intentionally make apiKey nil
    init(
        fakeApiKey: String = "",
        fakeBaseURL: String = ""
    ) {
        if fakeApiKey.isNotEmpty {
            self.apiKey = nil
            self.baseURL = "https://api.humorapi.com"
        } else if fakeBaseURL.isNotEmpty {
            self.baseURL = ""
            self.apiKey = Self.loadAPIKey()
        } else {
            self.apiKey = Self.loadAPIKey()
            self.baseURL = "https://api.humorapi.com"
        }
    }
    
    private static func loadAPIKey() -> String? {
            guard let fileURL = Bundle.main.url(forResource: "api_key", withExtension: "txt"),
                  let key = try? String(contentsOf: fileURL, encoding: .utf8).trimmingCharacters(in: .whitespacesAndNewlines),
                  !key.isEmpty else {
                return nil
            }
            return key
        }
    
   
    
    func searchJokes(keywords: String, number: Int) async throws(APIErrors) -> [Joke] {
        guard keywords.trimmingCharacters(in: .whitespacesAndNewlines).isNotEmpty else {
            print("Search query is empty, skipping the search")
            throw .emptySearchQuery
        }
        let searchQuery = keywords.replacingOccurrences(of: " ", with: ",")
        
        guard let apiKey,
              let url = URL(string: "\(baseURL)/jokes/search?api-key=\(apiKey)&number=\(number)&keywords=\(searchQuery)") else {
            throw .invalidURL
        }
        
        do {
            let (data, _) = try await URLSession.shared.data(from: url)
            
            do {
                let searchResponse = try JSONDecoder().decode(SearchResponse.self, from: data)
                return searchResponse.jokes
            } catch {
                print("Decoding has failed: \(error)")
                throw APIErrors.decodingFailed
            }
            
        } catch {
            throw .invalidResponse
        }
    }
    
    func randomJoke() async throws(APIErrors) -> Joke {
        guard let apiKey,
              let url = URL(string: "\(baseURL)/jokes/random?api-key=\(apiKey)") else {
            throw .invalidURL
        }
        
        do {
            let (data, _) = try await URLSession.shared.data(from: url)
            do {
                return try JSONDecoder().decode(Joke.self, from: data)
            } catch {
                print("Decoding has failed: \(error)")
                throw APIErrors.decodingFailed
            }
            
        } catch {
            throw .invalidResponse
        }
    }
    
    func randomMeme() async throws(APIErrors) -> Meme {
        guard let apiKey,
              let url = URL(string: "\(baseURL)/memes/random?api-key=\(apiKey)") else {
            throw .invalidURL
        }
        do {
            let (data, _) = try await URLSession.shared.data(from: url)
            do {
                return try JSONDecoder().decode(Meme.self, from: data)
            } catch {
                print("Decoding has failed: \(error)")
                throw APIErrors.decodingFailed
            }
            
        } catch {
            throw .invalidResponse
        }
    }
}

Use Cases

This layer is supposed to have different scenarios that we use for the repository implementation. We have three cases on this example.

struct SearchJokeUseCase {
    
    private let repository: any HumorRepository
    
    struct Constants {
        static let defaultNumberOfJokes: Int = 10
    }
    
    init(repository: any HumorRepository) {
        self.repository = repository
    }
    
    func execute(searchTerms: String, number: Int = Constants.defaultNumberOfJokes) async throws -> [Joke] {
        try await repository.searchJokes(keywords: searchTerms, number: number)
    }
}

import Foundation

struct RandomJokeUseCase {
    private let repository: any HumorRepository
    
    init(repository: any HumorRepository) {
        self.repository = repository
    }
    
    func execute() async throws -> Joke {
        try await repository.randomJoke()
    }
}

ViewModel

This layer is pretty familiar with SwiftUI developers, as this is the bridge(or ViewController for UIKit devs) between data & UI. What’s different with TCA is, we are not reaching for Repositories, but for use cases which is needed for that specific view model.

import SwiftUI
import Observation

@MainActor
@Observable
class HumorViewModel {
    var searchQuery: String = ""
    var jokes: [Joke] = []
    var joke: Joke? = nil
    var meme: Meme? = nil
    var isLoading: Bool = false
    var errorMessage: String? = nil
    
    private let searchJokeUseCase: SearchJokeUseCase
    private let randomMemeUseCase: RandomMemeUseCase
    private let randomJokeUseCase: RandomJokeUseCase
    
    init(
        randomJokeUseCase: RandomJokeUseCase,
        searchJokeUseCase: SearchJokeUseCase,
        randomMemeUseCase: RandomMemeUseCase
    ) {
        self.randomJokeUseCase = randomJokeUseCase
        self.searchJokeUseCase = searchJokeUseCase
        self.randomMemeUseCase = randomMemeUseCase
    }
    
    func searchJokes() async {
        do {
            async let jokesResult = searchJokeUseCase.execute(searchTerms: searchQuery)
            jokes = try await jokesResult
        } catch {
            print(error.localizedDescription)
            errorMessage = error.localizedDescription
        }
    }
    
    @Sendable func loadRandomData() async {
        isLoading = true
        errorMessage = nil
        do {
            async let jokeResult = randomJokeUseCase.execute()
            async let memeResult = randomMemeUseCase.execute()
            
            joke = try await jokeResult
            meme = try await memeResult
            isLoading = false
        } catch {
            isLoading = false
            errorMessage = error.localizedDescription
        }
    }
}

View

This is the obvious last layer that will be showcased on our app. The point is, the only knowledge of this layer is the VM, and not others.

import SwiftUI
import Observation

struct HumorView: View {
    @State var viewModel = HumorViewModel(
        randomJokeUseCase: RandomJokeUseCase(repository: DefaultHumorRepository()),
        searchJokeUseCase: SearchJokeUseCase(repository: DefaultHumorRepository()),
        randomMemeUseCase: RandomMemeUseCase(repository: DefaultHumorRepository())
    )
    
    var jokeOfDay: some View {
        Group {
            Text("Joke of the Day")
                .font(.title)
            VStack(alignment: .center) {
                if let joke = viewModel.joke?.joke {
                    Text(joke)
                        .jokeStyle()
                } else {
                    Text("No Joke For you :( ")
                        .multilineTextAlignment(.center)
                }
            }
        }
    }
    
    var memeOfDay: some View {
        Group {
            Text("Meme of the Day")
                .font(.title)
            
            if let meme = viewModel.meme,
               let memeURL = meme.url {
                AsyncImage(url: memeURL) { phase in
                    if let image = phase.image {
                        image
                            .resizable()
                            .aspectRatio(contentMode: .fit)
                            .frame(maxHeight: 300)
                            .clipShape(.rect(cornerRadius: 10))
                            .shadow(radius: 4)
                    } else if phase.error != nil {
                        Text("Error loading meme")
                    } else {
                        ProgressView()
                    }
                }
                .padding()
            }
        }
    }
    
    var searchJokeView: some View {
        Group {
            TextField("Enter search query...", text: $viewModel.searchQuery)
                .textFieldStyle(RoundedBorderTextFieldStyle())
                .padding()
            
            Button("Search") {
                Task {
                    await viewModel.searchJokes()
                }
            }
            .buttonStyle(.borderedProminent)
            .padding()
            
            if viewModel.isLoading {
                ProgressView("Loading...")
            } else if let error = viewModel.errorMessage {
                Text("Error: \(error)")
                    .foregroundColor(.red)
            } else {
                ForEach(viewModel.jokes) { joke in
                    VStack(alignment: .center) {
                        Text(joke.joke)
                            .jokeStyle()
                            .padding()
                    }
                }
            }
        }
    }
    
    var body: some View {
        NavigationStack {
            ScrollView {
                VStack(alignment: .leading, spacing: 10) {
                    jokeOfDay
                    
                    memeOfDay
                    
                    searchJokeView
                }
                .padding()
            }
            .navigationTitle("Humors")
        }
        .task(viewModel.loadRandomData)
    }
}

Testability

Since TCA aims to be testable, we can create some mock cases to test for Unit/UI vise.

Here, we can create a MockRepo:

import Foundation

final class MockHumorRepository: HumorRepository {
    
    func searchJokes(keywords: String, number: Int) async throws -> [Joke] {
        return (1...number).map { number in
            Joke(id: number, joke: "Mock joke \(number) for keyword '\(keywords)'")
        }
    }
    
    func randomJoke() async throws -> Joke {
        return Joke(id: 999, joke: "Why don't skeletons fight each other? Because they don't have the guts.")
    }
    
    func randomMeme() async throws -> Meme {
        return Meme(
            id: 123,
            urlString: "https://i.imgflip.com/1bij.jpg", // Sample meme image URL
            type: "meme"
        )
    }
}

And we can use this on our Views via #Preview

#Preview {
    let mockRepo = MockHumorRepository()
    let viewModel = HumorViewModel(
        randomJokeUseCase: RandomJokeUseCase(repository: mockRepo),
        searchJokeUseCase: SearchJokeUseCase(repository: mockRepo),
        randomMemeUseCase: RandomMemeUseCase(repository: mockRepo)
    )
    HumorView(viewModel: viewModel)
}

Also, we can use the Swift Testing framework for Unit Tests

import Testing
@testable import Humor_TCA
import Foundation

struct HumorViewModelTests {
    
    struct MockUseCases {
        struct Success: Sendable {
            let search = SearchJokeUseCase(repository: MockHumorRepository())
            let joke = RandomJokeUseCase(repository: MockHumorRepository())
            let meme = RandomMemeUseCase(repository: MockHumorRepository())
        }
    }

    @Test
    @MainActor
    func testSearchJokesUpdatesJokesArray() async throws {
        let useCases = MockUseCases.Success()
        let vm = HumorViewModel(
            randomJokeUseCase: useCases.joke,
            searchJokeUseCase: useCases.search,
            randomMemeUseCase: useCases.meme
        )

        vm.searchQuery = "test"
        await vm.searchJokes()

        #expect(vm.jokes.count == 10)
        #expect(vm.jokes[0].joke == "Mock joke 1 for keyword 'test'")
    }

    @Test
    func testLoadRandomDataSetsJokeAndMeme() async throws {
        let useCases = MockUseCases.Success()
        let vm = await HumorViewModel(
            randomJokeUseCase: useCases.joke,
            searchJokeUseCase: useCases.search,
            randomMemeUseCase: useCases.meme
        )

        await vm.loadRandomData()

        await #expect(vm.joke?.joke == "Why don't skeletons fight each other? Because they don't have the guts.")
        await #expect(vm.meme?.urlString == "https://i.imgflip.com/1bij.jpg")
        await #expect(vm.isLoading == false)
        await #expect(vm.errorMessage == nil)
    }
}

It’s actually pretty easy when you have a mock repo to test anything, use cases too:

import Testing
import Foundation
@testable import Humor_TCA

struct RandomJokeUseCaseTests {
    struct MockHumorRepository: HumorRepository {
        var jokeToReturn: Joke

        func searchJokes(keywords: String, number: Int) async throws -> [Joke] {
            []
        }

        func randomJoke() async throws -> Joke {
            jokeToReturn
        }

        func randomMeme() async throws -> Meme {
            throw NSError(domain: "Not needed", code: 0)
        }
    }

    @Test
    func returnsJokeFromRepository() async throws {
        // Given
        let expected = Joke(id: 123, joke: "Mocked random joke")
        let repo = MockHumorRepository(jokeToReturn: expected)
        let useCase = RandomJokeUseCase(repository: repo)

        // When
        let result = try await useCase.execute()

        // Then
        #expect(result.id == expected.id)
        #expect(result.joke == expected.joke)
    }

    @Test
    func throwsIfRepositoryFails() async {
        struct FailingRepo: HumorRepository {
            func searchJokes(keywords: String, number: Int) async throws -> [Joke] { [] }
            func randomJoke() async throws -> Joke {
                throw NSError(domain: "test", code: 1)
            }
            func randomMeme() async throws -> Meme {
                throw NSError(domain: "irrelevant", code: 0)
            }
        }

        let useCase = RandomJokeUseCase(repository: FailingRepo())

        await #expect(throws: (any Error).self) {
            try await useCase.execute()
        }
    }
}

We can even test the Default Implementation

import Testing
@testable import Humor_TCA

struct DefaultHumorRepositoryTests {
    @Test
    func searchJokes_withInvalidKeyword_shouldThrowEmptySearchQuery() async {
        let repo = DefaultHumorRepository()
        
        await #expect {
            try await repo.searchJokes(keywords: "   ", number: 3)
        } throws: { error in
            guard let apiError = error as? APIErrors else { return false }
            return apiError == .emptySearchQuery
        }
    }

    @Test
    func searchJokes_withInvalidURL_shouldThrowInvalidURL() async {
        let repo = DefaultHumorRepository(fakeApiKey: "dfds")

        await #expect {
            try await repo.searchJokes(keywords: "funny", number: 3)
        } throws: { error in
            guard let apiError = error as? APIErrors else { return false }
            return apiError == .invalidURL
        }
    }
    
    @Test
    func searchJokes_withInvalidURL_showThrowInvalidResponse() async {
        let repo = DefaultHumorRepository(fakeBaseURL: "https://www.google.com")
        
        await #expect {
            try await repo.searchJokes(keywords: "funny", number: 3)
        } throws: { error in
            guard let apiError = error as? APIErrors else { return false }
            return apiError == .invalidResponse
        }
    }
}

And that’s it. You can download the source code, add your own api key into api_key.txt file you’ll create and test it out!

While The Clean Architecture has a nice way of maintaining the code in layers, it can bother a simple project with so many setups, hence it is usually recommended an already built mid-to-big size projects, although creating one for our example did not take too much time either.

What do you think about the architecture? Would you be interested in to discuss this with your team, or do you have another opinion on it. Feel free to discuss down below. Happy coding.

Short answer first: MVVM stands in combination of Model, View, ViewModel. Which means we have 3 layer in the project:

• Model — Handling the models
• View — Handles the UI
• ViewModel — Handles the connection between View and Model, hence the name.

With that short introduction done, I would like to detail how the code looks like in practice.

View

struct UserListView: View {
        
    @StateObject private var viewModel = UserListViewModel(service: UserService.shared)
    
    var body: some View {
        NavigationStack {
            List(viewModel.users) { user in
                NavigationLink {
                    UserDetailView(user: user, service: UserService.shared)
                        .onDisappear {
                            viewModel.loadUsers()
                        }
                } label: {
                    HStack {
                        Text(user.name)
                            .font(.headline)
                        Spacer()
                        Text(viewModel.provideUserAge(age: user.age))
                            .foregroundStyle(.gray)
                    }
                }
            }
            .navigationTitle(Text("Users"))
            .onAppear {
                viewModel.loadUsers()
            }
        }
    }
}

The View contains the viewModel it is getting the data and operations from. It shows the data and manages the navigation.

ViewModel

ViewModels job is to fetch/save data into the model layer, modify the content in behalf of the view and provides its actions to the view. While ViewModels are good to go, it can lead to big viewModels, and many duplication codes when the project go big, so a protocol layer like UserService used to manage calls which can be shared between multiple viewModels.

protocol UserServiceProtocol {
    func fetchUsers() -> [User]
    func update(user: User)
}

class UserService: UserServiceProtocol {
    
    static let shared = UserService()
    
    private var users: [User] = [
        User(name: "Ali", age: 25),
        User(name: "Ege", age: 29),
        User(name: "Öykü", age: 28)
    ]
    
    func fetchUsers() -> [User] {
        // I did not lean on persistence in this topic.
        return users
    }
    
    func update(user: User) {
        if let index = users.firstIndex(where: { $0.id == user.id }) {
            users[index] = user
        }
    }
}

And then, we can provide our ViewModel.

import Foundation

class UserListViewModel: ObservableObject {
    
    private let service: UserServiceProtocol
    
    @Published var users: [User] = []
    
    init(service: UserServiceProtocol) {
        self.service = service
        Task {
            await loadUsers()
        }
    }
    
    func provideUserAge(age: Int) -> String {
        service.provideAgeText(age: age)
    }
    
    @MainActor
    func loadUsers() {
        users = service.fetchUsers()
    }
}

Model

Model is responsible for the handling of variables. While A struct is recommended for models, for this example, I went for class for it’s reference type being useful to update data on my non-persistent example.

class User: Identifiable {
    let id = UUID()
    var name: String
    var age: Int
    
    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }
}

While these are the basics of a MVVM project, let’s dive in into the real reasons why we use MVVM with SwiftUI projects.

Testability

Testing is important to make sure your app will work more robust and error-prune than before. With the approach like having a service layer, it helps us to write mock models and services to communicate with the viewModels.

import Foundation
@testable import Swift_MVVM_Example

class MockUserService: UserServiceProtocol {
    
    var mockUsers: [User] = [
        User(name: "Test User 1", age: 28),
        User(name: "Test User 2", age: 35)
    ]

    func fetchUsers() -> [User] {
        return mockUsers
    }
    
    func update(user: User) {
        if let index = mockUsers.firstIndex(where: { $0.id == user.id }) {
            mockUsers[index] = user
        }
    }
}

This helps us to work on the service implementations easier. Here is an example of using Swift Testing with Mock Service to test operations.

import Testing
@testable import Swift_MVVM_Example

struct UserDetailViewModelTests {
    
    var viewModel: UserDetailViewModel
    var mockService: MockUserService
    
    init() {
        self.mockService = MockUserService()
        self.viewModel = UserDetailViewModel(user: mockService.mockUsers[0], service: mockService)
    }
    
    @Test
    func userInitialization() throws {
        #expect(viewModel.user.name == "Test User 1")
        #expect(viewModel.user.age == 28)
    }
    
    @Test
    func saveChanges() throws {
        viewModel.user.name = "New Name"
        viewModel.user.age = 50
        
        viewModel.saveChanges()
        
        #expect(mockService.mockUsers[0].name == "New Name")
        #expect(mockService.mockUsers[0].age == 50)
    }
    
}

This is another example on how we fetch the mock data.

import Testing
@testable import Swift_MVVM_Example

struct UserListViewModelTests {
    
    var viewModel: UserListViewModel
    var mockService: MockUserService
    
    init() {
        self.mockService = MockUserService()
        self.viewModel = UserListViewModel(service: mockService)
    }

    @Test func fetchUsers() async throws {
        await viewModel.loadUsers()
        #expect(viewModel.users.count == 2)
        #expect(viewModel.users.first?.name == "Test User 1")
    }

}

Same Mocking data can also be used with SwiftUI Previews to test them on the Xcode Preview Panel.

Now, let’s look at what we must be carefull to comply with the architecture.

Clear Separation of Concerns

The model must be independent from view.

Example: We moved the age text out from the View into the ViewModel.

The ViewModel Should Be UI-Agnostic

Sometimes, we tend to import UIKit, SwiftUI etc. into the ViewModel. This is simply wrong. Those frameworks should be used within the View files. You have @ Published with the Foundation Framework when you conform the class into ObservableObject, or if you use Observable Framework, you don’t even need to use @ Published or any @ File.

Sometimes, you might be tempting to add UIImage, or Image into the Model, which is also not the correct way to do on MVVM. You could simply have the data as Data, and do the conversion inside of the View on a function.

Dependency Injection for Testability

Instead of initializing the service with UserService(), we injected it into the initializer of the ViewModel, so that we can use the mock service on Unit Tests.

protocol UserService {
    func fetchUser() -> User
}

class UserViewModel: ObservableObject {
    private let service: UserService

    init(service: UserService) {
        self.service = service
    }

    func loadUser() {
        _ = service.fetchUser()
    }
}

// Mock Data Creation
class MockUserService: UserService {
    func fetchUser() -> User {
        return User(name: "Test User")
    }
}

// On Testing
let viewModel = UserViewModel(service: MockUserService())

Use Combine for Reactive Data Flow

Although you can use Async-await and it’s the recommended logic to use for most operations, Combine offers more reactive oriented functional programming. Swift Concurrency has AsyncStreams, but those are only providing new values to update the view, while Combine Publishers/Subscribers can share more.

Example of a Data Fetch with

class UserViewModel: ObservableObject {
    @Published var username: String = ""

    private var cancellables = Set<AnyCancellable>()

    func startListening() {
        NotificationCenter.default.publisher(for: NSNotification.Name("UserUpdated"))
            .compactMap { $0.object as? String }
            .assign(to: &$username)
    }
}

While AsyncStream has:

ViewModel Should Handle Business Logic, Not Views

Handling of the business logic belongs to ViewModel. Hence we moved out the age text from View to our ViewModel.

Here’s a good example:

class ContentViewModel: ObservableObject {
    @Published var formattedDate: String = ""

    private let formatter: DateFormatter = {
        let formatter = DateFormatter()
        formatter.dateStyle = .long
        return formatter
    }()

    func loadDate() {
        formattedDate = formatter.string(from: Date())
    }
}

And the Bad One:

struct ContentView: View {
    let date = Date()

    var body: some View {
        Text(dateFormatter.string(from: date)) // ❌ View handles formatting
    }

    private var dateFormatter: DateFormatter {
        let formatter = DateFormatter()
        formatter.dateStyle = .long
        return formatter
    }
}

Views Should Be Stateless Whenever Possible

We need to avoid having too much state on the View to handle View logics, but move them over to the ViewModel layer. There are 3 ways for this:

• For ViewModels that should be owned by a View, we use StateObject
• For ViewModels passed from a parent View, we use ObservedObject .
• For app-wide dependencies, we use EnvironmentObject.

struct ParentView: View {
    @StateObject private var viewModel = UserViewModel()

    var body: some View {
        ChildView(viewModel: viewModel)
    }
}

struct ChildView: View {
    @ObservedObject var viewModel: UserViewModel

    var body: some View {
        Text(viewModel.username)
    }
}

You can find the final project here.

GitHub - egesucu/Swift-MVVM-Example

While SwiftUI talks a lot on the MVVM architecture, some developers and projects are shifted into another architectures to use more Async-await orientation then the old reactive MVVM approaches. MVVM has it’s own con’s and pro’s in the end. Here’s a table gpt friend:

Overall, Swift 6 looks like to be more oriented into Actor Based MV and Clean Architecture which you can find articles/examples online. Do you have any questions? Feel free to comment down below.

Bu yazı geçen sene yazdığım yazının yıllık serisine aittir. Geçen seneki yazıya bu bağlantıdan erişebilirsiniz.

Geçtiğimiz seneki yazıda odaklandığım belirli noktalar, ve bu sene içinde kendimi görmek istediğim belirli noktalar vardı. Peki bu sonuçlar ne oldu?

• 90 kiloya ulaşma ❌
• Her gün en az 45 dakika yürüyüş/spor yapma ❌
• Ayda en az 1 Medium Yazısı Yazma ❌ (Mayıs, Haziran ve Ekim eksik)
• 1 yeni mobil uygulama yazma — Yetenek ❌

Evet, epey tutarsız bir şekilde devam ettim.

Peki bu süreçte neler yaşandı?

Mayıs’ta nişanlım ile evlendik.👰🏻‍♀️🤵🏻

Aradan geçen onca ay sonunda hayatımda olduğumdan çok daha keyif aldığım, ve adeta en büyük hedefimi gerçekleştirmiş gibi hissettiğim bir dönem oluyor. Doğru kişiyi seçtiğimi çok iyi biliyorum.

Ağustos’ta araba ile ilk uzun yola çıkarak; Troya, Cunda, Bergama, Efes ve Şirince gibi pek çok tarihi yerleri gezdik.

Eylül’de ilk defa Formula 1 yarışını yakından ve gerçekten tecrübe etme şansını buldum. (#CS55)

Aralık ayında ailecek Sırbistan’a giderek Belgrad’ı gezdik.

Bu süreçte hedeflerimde aksamalar oldu. Kimi hedefim ilk ayda, kimisi dördüncü ayda hata verdi. Hedeflerin büyük bir kısmını zor olmayacak şekilde belirtmeme rağmen, tutarsızlık ve iş hayatı/evlilik hazırlığı sırasında yaşadığım sıkıntıların da bunda rol oynadığını belirtmem gerekiyor. Bu süreçte en tutarlı olduğum kısım Medium olurken, en tutarsız olduğum kısım mobil uygulama oldu.

Neden hata yaptım?

Bu süreçte yaptığım hatalar, bana epey çıktı sağladı. Bunları öğrendiğimi umuyorum ve birkaçına değinmek isterim.

Kilo

Her ne kadar evlilik sonrası 7 kiloya kadar zayıflamış olsam da, bu kaybın bir kısmını geri aldım ve hiçbir zaman 90 kiloya ulaşamadım. Dışarıda yediğim yemekleri bırakmam ev içi atıştırmalıkları arttırdı. Bahsettiğim bel ağrıları ve iş uğraşları sporumu kesti ve bu da çok yardımcı olmadı. Ama 90 kilo hedefi de iddialıydı. Ayda düzenli olarak 4 kilo vermemden geçiyordu ki, o düzen pek olmadı.

Uygulama

Bu beni üzen başka bir konu oldu. Girişte bir fikir olmasına ve bunun üzerinde başlamama rağmen iş kısmındaki gelişmeler bu projeyi çok erken bir süreçte çöpe attı. Her ne kadar yazılıma dair ufak projeler yapmış olsam da, hiçbir zaman bir uygulama çıkaramadım, hatta kendime dair kullanabileceğim küçük bir PoC(Proof of Concept) bile yapamadım. Bu konuda uygulama yaparken kafamda kurmaya çalıştığım “mükemmeliyetçi” düşünce ve “eşsiz fikir bulamama” konuları çok etkili oldu.

Öyle ki tasarım değişikliğindeki kararsızlığım sebebiyle bu sene uzun yıllardır güncellemesini yaptığım “Pet Reminder” uygulamasını da etkiledi, güncellemeyi yapamadım. Bu konuda çok sorun yaşadım.

Yürüyüş

Bu alanda %100 hata yaptığımı söyleyemem. Evet, dışarıda yürüyüşler yapıyorum, fakat hedeflediğimden epey az şekilde. Bu süreçte akıllı saati bırakıp klasik saate geçmem pek bir şeyi değiştirmedi. Ancak dışarı çıkmaya ve yürümeye dair motivasyonu sene başından beri nadiren bulabiliyorum ve bu da hedefe yakından uzaktan geçemememe neden oldu.

2024'ü bu şekilde kapatıyorum. İlişkide maksimum mutluluk ve iş/kariyer alanında verimsiz ve keyifsiz bir dönem olarak.

2025'te Odaklandığım Hedefler Neler?

Bu sene 4 hedef koyuyorum.

• Güzel bir Miktar Kilo verme(sayısız — Eşimle ortak hedefimiz)
• Fiziksel Yaşama Odaklanma(Az ekran süresi, bol fiziksel çıktılar)
• Telefonumda Günlük Kullanacağım Bir Log Uygulaması
• Finansalları Düzene Çekme

Bu hedefler üzerinde bu sene nasıl ilerlediğimi de ayrıca kaydetmeyi düşünüyorum(dijital değil).

Fiziksel yaşama odaklanmaya dair, daha öncesinde Lamy’nin dolma kalemini almış ve bir süredir kullanmaya başlıyordum. Klasik saat geçişi sonrası gündelik aktivitelerimde 2 dijital noktayı çıkardıktan sonra geriye en büyük meselelerimden biri kaldı.

Telefon

Bu konuda da kullanımı epey azaltmayı planlıyorum. Bakalım bunu başarabilecek miyim…

Günlük kullanacağım Log uygulamasında başlangıç düzeyine geldim. Bunu ilerletip telefonumda kullanacağım ve sonra yayınlayabilirim de. Bu sene kendime GPT’lerin de katkılarıyla daha verimli bir kod süreci yaşatmak istiyorum.

Finansal konularda da daha birikim, az kart bol kredi skoru derecelerinde kendimi ilerletmek istiyorum. Harcamaları kontrol edip çekidüzen vermek de bunun alt hedefleri arasında yer alıyor.

Bakalım, bu sefer daha istikrarlı olacak mı.