DEV Community: Gamya

The Crash That Only Happened Sometimes — A SwiftUI Bug

Gamya — Sat, 25 Jul 2026 07:45:27 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

I spent three hours debugging a SwiftUI crash that felt completely random. It wasn't random at all. It was me, a force unwrap, and a fundamental misunderstanding of when SwiftUI renders its views.

Okay gather round because I need to tell you about the three hours I spent convinced I had found a bug in SwiftUI itself. I had not found a bug in SwiftUI. I had found a bug in my own assumptions, which is both more embarrassing and more educational, and I am sharing it here so you don't have to go through the same thing.

The Setup

I was building a list-to-detail navigation flow. Classic stuff. You tap an item in a list, it navigates to a detail screen, the detail screen fetches and displays the selected item's full data. Nothing fancy. The kind of thing you've probably built or seen a dozen times.

I had a view model managing the selected item state, and because I was moving fast and feeling a little overconfident, I declared it like this:

@Published var selectedItem: Item!

That ! at the end. That little exclamation mark. That tiny, innocent-looking, completely catastrophic punctuation.

For those who haven't encountered this particular flavour of Swift danger: that's an implicitly unwrapped optional. It means the variable can technically be nil, but you're telling Swift "trust me, it won't be." Swift says "okay" and doesn't make you check. Until it is nil. And then your app explodes.

My reasoning at the time was: by the time the detail view renders, I'll have set selectedItem. It's fine. It'll be fine.

Reader, it was not fine.

The Crime Scene

The crash started showing up in testing. But here's the thing that made it so maddening: it didn't happen every time.

Sometimes I'd tap an item, the detail screen would appear, everything would be perfect. Sometimes I'd tap an item and the app would crash immediately with a cryptic EXC_BAD_INSTRUCTION on a line inside the view's body. No useful stack trace. No clear reproduction steps. Just: sometimes crash, sometimes not.

My first instinct was device-specific. Tested on different simulators. Nope.

My second instinct was data-specific. Tested with different items. Nope.

My third instinct, I am slightly embarrassed to admit, was that SwiftUI was doing something weird with navigation timing. I spent a genuinely non-trivial amount of time reading about NavigationStack rendering behaviour and convincing myself the framework had an edge case.

It did not have an edge case. I had an edge case.

The Investigation

What finally broke it open was slowing down and actually tracing the execution order instead of staring at the crash line.

Here's what I thought was happening:

User taps item
selectedItem gets set in the view model
SwiftUI navigates to detail view
Detail view renders using selectedItem

Here's what was actually happening:

User taps item
SwiftUI begins evaluating and rendering the destination view
selectedItem is still nil during this initial render pass
The force unwrap fires
Crash

SwiftUI doesn't wait politely for your async state to be ready before it starts rendering. It evaluates the view body, and if your view body contains a force-unwrapped optional that isn't set yet, it will crash during that evaluation. The "sometimes" quality of the bug came from timing — on faster devices or with cached data, selectedItem was set fast enough that the render pass caught it in time. On slower paths, it didn't.

The crash wasn't random. It was a race condition I had created with an exclamation mark.

The Fix

Once I understood the actual problem, the fix was straightforward. I replaced the implicitly unwrapped optional with a safe optional:

// Before — ticking time bomb
@Published var selectedItem: Item!

// After — honest about what this can be
@Published var selectedItem: Item?

And updated the SwiftUI view to handle every state the data could actually be in:

// Before — assumes selectedItem is always there
var body: some View {
    ItemDetailView(item: viewModel.selectedItem)
}

// After — handles every intermediate state explicitly
var body: some View {
    if viewModel.isLoading {
        ProgressView()
    } else if let item = viewModel.selectedItem {
        ItemDetailView(item: item)
    } else {
        Text("Something went wrong.")
    }
}

The crash vanished immediately. The fix took about ten minutes. The debugging took three hours.

What I Actually Learned

The technical lesson is: in SwiftUI, your UI must be able to render safely for every intermediate state. SwiftUI is declarative and reactive — it can and will evaluate your view body at any point, including before your async operations complete. If your view assumes state that hasn't arrived yet, it will fail exactly when that assumption turns out to be wrong.

The deeper lesson is: implicitly unwrapped optionals are almost never the right call in a SwiftUI view model. They exist for situations where initialization order makes it genuinely impossible to set a value at declaration time — like @IBOutlet connections in UIKit. They are not a way to skip handling states you find inconvenient. Every time you write ! to avoid dealing with an optional, you're writing a crash that just hasn't happened yet.

The thing that still makes me a little sheepish: I knew this, in the abstract. I'd read about IUOs. I understood optionals. I just got lazy in a moment of "this will clearly be set by the time it matters."

SwiftUI disagreed. SwiftUI was right.

AI tools were used to help with grammar and structure.

Swift Classes — The Four Ways Variables and Constants Can Combine 🎭

Gamya — Thu, 23 Jul 2026 08:44:00 +0000

A constant class can have its properties changed. A constant struct can't. This sounds inconsistent until you remember the signpost — and then it makes perfect sense.

There's a moment when you're learning Swift where something happens that makes absolutely no sense on the surface. You create a constant class instance — a let — and then you change one of its properties. And it works. Swift lets you do it without complaint.

Meanwhile, you try the same thing with a constant struct and Swift immediately shuts you down.

Same keyword. Different behavior. What's going on?

The answer, as with most things in the classes chapter, comes back to the signpost. 🍥

A Quick Reminder About Signposts

When you create a class instance and assign it to a variable, what you're actually holding is a signpost pointing to the data — not the data itself. The class instance lives somewhere in memory, and your variable just tells Swift where to find it.

This is the fundamental difference between classes and structs. Structs hold their data directly. Classes hold a reference to their data.

Keep that in mind, because it explains everything that follows.

The Constant That Isn't Constant

Here's the thing that trips people up:

class Ninja {
    var name: String
    var powerLevel: Int

    init(name: String, powerLevel: Int) {
        self.name = name
        self.powerLevel = powerLevel
    }
}

let naruto = Ninja(name: "Naruto", powerLevel: 9000)
naruto.powerLevel = 9001 // ✅ This works fine

Wait. naruto is a let. How is this allowed?

Because let naruto doesn't mean "the Ninja named Naruto is frozen forever." It means "the signpost called naruto is locked in place — it will always point to this specific Ninja instance."

The signpost is constant. The data it points to is not.

Changing naruto.powerLevel doesn't move the signpost. It doesn't replace the Ninja with a different Ninja. It just walks to the end of the signpost and changes a value there. The signpost itself didn't go anywhere.

What `let` Actually Locks

So what would let naruto prevent?

This:

let naruto = Ninja(name: "Naruto", powerLevel: 9000)
naruto = Ninja(name: "Sasuke", powerLevel: 8500) // ❌ Not allowed

That's what you can't do. You can't point naruto at a completely different Ninja. The signpost is locked — you can't turn it to face a new direction. But you can absolutely change things at the end of the signpost.

Why Structs Work Differently

Now here's why constant structs don't allow property changes:

struct AnimeCharacter {
    var name: String
    var powerLevel: Int
}

let goku = AnimeCharacter(name: "Goku", powerLevel: 9001)
goku.powerLevel = 9002 // ❌ This won't compile

Structs don't use signposts. They hold their data directly. So let goku means "the value stored here is constant" — and that value includes everything inside it.

Think of it this way: a struct is like the number 5. When you write let x = 5, you're saying x is 5, permanently. You can't say "well, I'll keep x but just change one digit of the 5." The 5 is the whole thing. Changing any part of a struct means replacing the entire struct — and you can't replace a constant.

So with structs:

var goku = AnimeCharacter(name: "Goku", powerLevel: 9001)
goku.powerLevel = 9002 // ✅ Works — goku is a var, so the whole struct can be replaced

With var goku, Swift can swap out the entire struct value for a new one with the updated property. With let goku, it can't, because that would mean destroying and recreating a constant.

The Four Combinations

This gives us four different situations, and they're all worth understanding:

1. Constant class, constant property

let naruto = Ninja(name: "Naruto", powerLevel: 9000)
// naruto.powerLevel = 9001 ❌ — can't change a let property
// naruto = Ninja(...) ❌ — can't reassign the signpost

The signpost is locked, and the name tag is written in permanent ink. Nothing changes.

2. Constant class, variable property

let naruto = Ninja(name: "Naruto", powerLevel: 9000)
naruto.powerLevel = 9001 // ✅ — can change the var property
// naruto = Ninja(...) ❌ — still can't reassign the signpost

The signpost is locked, but the data at the end of it can still be updated. This is the one that surprises people.

3. Variable class, constant property

var naruto = Ninja(name: "Naruto", powerLevel: 9000)
// naruto.powerLevel = 9001 ❌ — can't change a let property
naruto = Ninja(name: "Sasuke", powerLevel: 8500) // ✅ — can point at a new Ninja

You can swing the signpost to point at a completely different ninja, but once you're there, their permanent ink properties can't be changed.

4. Variable class, variable property

var naruto = Ninja(name: "Naruto", powerLevel: 9000)
naruto.powerLevel = 9001 // ✅
naruto = Ninja(name: "Sasuke", powerLevel: 8500) // ✅

Maximum flexibility. The signpost can move, and the data can change. This is the most permissive option.

One Nice Bonus: No `mutating` Needed

Remember from the structs chapter how methods that changed properties had to be marked mutating? Classes don't have that requirement.

The reason structs need mutating is so Swift can protect you from calling a property-changing method on a constant struct — it can check at compile time whether the method would be allowed. With classes, the check is simpler: just look at whether the property itself is var or let. Swift doesn't need the mutating label to know what's allowed, because the class instance's own constancy doesn't affect its properties the same way.

The One Thing To Hold Onto

A let on a class locks the signpost, not the data. You can still change variable properties on a constant class — you just can't point that constant at a different instance entirely.

A let on a struct locks everything, because the struct is the data. There's no signpost to separate the container from the contents.

Once that distinction is clear, the four combinations stop feeling arbitrary and start feeling like exactly the right behavior for each type. 🌸

This article was written by me; AI was used to improve grammar and readability.

Swift Classes — Deinitializers and How Swift Cleans Up After Itself 🧹

Gamya — Wed, 22 Jul 2026 08:44:00 +0000

Every class instance is eventually destroyed. Swift gives you a way to know exactly when that happens — and the story of how it decides when to pull the trigger is surprisingly interesting.

Here's something you've probably never thought about: what happens to your objects when you're done with them?

With structs, the answer is simple. A struct lives as long as whatever owns it. Create a struct inside a function, the function ends, the struct is gone. Clean, predictable, boring in the best way.

Classes are messier. Remember — when you "copy" a class, you're not copying the data, you're copying a signpost pointing to the data. That means multiple parts of your code might be holding onto a reference to the same class instance. So when does that instance actually get destroyed? When the first reference goes away? The last?

The answer is: the last one. And Swift has a whole system behind the scenes to track it. 🍥

Automatic Reference Counting — The Invisible Accountant

Behind every class instance in Swift, there's a hidden counter. Every time you create a new reference to a class instance — by assigning it to a variable, passing it to a function, storing it in an array — Swift adds 1 to that counter. Every time one of those references goes away, Swift subtracts 1.

When the counter hits zero, Swift knows: nobody is looking at this anymore. It's safe to destroy it.

This system is called Automatic Reference Counting, or ARC. You never have to manage it yourself — Swift handles it invisibly, continuously, for every class instance in your app.

Structs don't need ARC because each copy of a struct is its own independent piece of data. When a struct variable goes away, the data goes with it. Simple. No counting needed.

Classes need ARC precisely because the signpost system means multiple variables can point at the same data. Without counting references, Swift would have no way to know when the last one was gone.

Enter the Deinitializer

When Swift's reference counter hits zero and a class instance is about to be destroyed, Swift will call a special method called the deinitializer — written as deinit.

It's the counterpart to init. Where init runs when an instance is created, deinit runs when the last reference to it disappears.

Let's see it in action with an anime training camp:

class TrainingCamp {
    let name: String

    init(name: String) {
        self.name = name
        print("\(name) has opened! 🏕️")
    }

    deinit {
        print("\(name) has been abandoned. Training is over.")
    }
}

Now let's create some camps and watch them get destroyed:

var camp1: TrainingCamp? = TrainingCamp(name: "Konoha Training Grounds")
var camp2: TrainingCamp? = TrainingCamp(name: "Sand Village Camp")
var camp3: TrainingCamp? = camp1 // camp1 and camp3 now point to the same camp

camp1 = nil // reference count for Konoha drops to 1 (camp3 still holds it)
camp2 = nil // reference count for Sand Village drops to 0 — deinit fires!
camp3 = nil // reference count for Konoha drops to 0 — deinit fires!

Output:

Konoha Training Grounds has opened! 🏕️
Sand Village Camp has opened! 🏕️
Sand Village Camp has been abandoned. Training is over.
Konoha Training Grounds has been abandoned. Training is over.

Notice: camp2 fires its deinitializer as soon as camp2 = nil because that was the only reference. Konoha's deinitializer doesn't fire until camp3 = nil, because even after camp1 was set to nil, camp3 was still keeping the count at 1.

A Few Things Worth Knowing About `deinit`

You can't call it yourself. deinit is called by Swift automatically when the reference count hits zero. You can define it, but you can't trigger it manually.

It takes no parameters. Unlike init, deinit doesn't accept any arguments. It runs with no input — it just gets told "you're being destroyed, do whatever you need to do."

Where to put it? Technically anywhere in the class. But there's a lovely convention: put it at the end of the class body. Code should read like a chapter in a book, and deinit is the final scene — the fin.

The Other Thing About Variables in Classes

While we're on the topic of classes behaving differently from structs, there's one more quirk worth naming.

Remember from the structs chapter: if you create a let constant struct, nothing about it can change — not its properties, not anything.

Classes don't work that way. A let class means "this variable will always point to the same instance." It does not mean "the instance can't change."

class Ninja {
    var powerLevel: Int

    init(powerLevel: Int) {
        self.powerLevel = powerLevel
    }
}

let naruto = Ninja(powerLevel: 9000)
naruto.powerLevel = 9001 // ✅ This is fine!
naruto = Ninja(powerLevel: 1) // ❌ This isn't — you can't reassign the signpost

let naruto means naruto's signpost is locked — it will always point to the same Ninja instance. But the data at the end of that signpost? Completely free to change.

This makes sense once you think about the signpost analogy. let locks the signpost in place. It says nothing about what the signpost points to.

Why This Matters in Real iOS Development

ARC and deinitializers matter most when:

You're managing resources that need explicit cleanup — network connections, file handles, observers, timers
You need to debug memory issues and want to know exactly when objects are being created and destroyed
You're working with complex object graphs where multiple things hold references to the same data

For everyday SwiftUI development you won't write deinit constantly. But understanding that it exists — and understanding why it exists (because ARC needs a hook for cleanup) — helps you understand the memory model of your app rather than just hoping things work out.

The One Thing To Hold Onto

Swift counts how many things are pointing at each class instance. When the count hits zero, it calls deinit and destroys the object. That's ARC in a nutshell.

And let on a class means the signpost is constant — not the data it points to. That's the quirk that trips people up until the signpost analogy finally clicks. 🌸

This article was written by me; AI was used to improve grammar and readability.

Swift Classes — Why Copying a Class Isn't What You Think 📋

Gamya — Tue, 21 Jul 2026 08:44:00 +0000

Okay. This one is going to feel weird at first. I'm going to warn you in advance so you don't think something is broken when you try it.

Here's what's going to happen: you're going to create a class, make a copy of it, change something in the copy, and then discover that the original changed too.

And you're going to say: "That's not how copying works."

And I'm going to say: "You're right. But for classes, that's exactly how it works. Sit down. Let's talk." 🍥

The Moment That Breaks Your Brain

Let's create a simple class for a ninja character:

class Ninja {
    var name: String
    var powerLevel: Int

    init(name: String, powerLevel: Int) {
        self.name = name
        self.powerLevel = powerLevel
    }
}

Now let's create an instance, copy it, and change something in the copy:

var naruto = Ninja(name: "Naruto", powerLevel: 9000)
var naruto2 = naruto

naruto2.name = "Sasuke"

print(naruto.name)  // "Sasuke" 😱
print(naruto2.name) // "Sasuke"

Wait. We changed naruto2, but naruto changed too?

Yes. That's not a bug. That's how classes work.

The Signpost Analogy

Here's the mental model that makes this click.

When you create a struct, Swift stores the actual data directly in the variable. Copying a struct is like photocopying a document — you get two completely separate pieces of paper. Change one, the other is untouched.

When you create a class, Swift stores the data somewhere in memory and gives your variable a signpost pointing to that location. Copying a class doesn't copy the data — it copies the signpost. Now you have two signposts pointing at the same piece of data.

var naruto = Ninja(name: "Naruto", powerLevel: 9000)
// naruto is a signpost pointing to data: {name: "Naruto", powerLevel: 9000}

var naruto2 = naruto
// naruto2 is a SECOND signpost pointing to the SAME data

naruto2.name = "Sasuke"
// You followed naruto2's signpost and changed the data it points to
// naruto's signpost points to the SAME data, so naruto.name is also "Sasuke"

There's only one piece of data. Both variables are just different ways of pointing at it.

Why Would Swift Do This On Purpose?

This isn't a mistake or an oversight. It's a deliberate design decision, and it's actually useful.

Think about a real iOS app. Say you have a user profile that shows up on a settings screen, a home screen, and a notification. If all three screens have their own independent copy of the user data, and the user changes their username — now you have to update three separate copies. Miss one and you have inconsistent data showing in different parts of your app.

With a class, all three screens are looking at the same piece of data through their own signpost. Change the username once, and every screen that holds a reference to that user sees the updated value automatically. That's exactly what you want for shared state.

This is why Swift calls classes reference types — you're passing around references (signposts) to data, not copies of the data itself. Structs are value types — the value is the data, and copying creates a fresh independent copy.

So How Do You Make a True Copy?

Sometimes you genuinely do want a separate copy — two independent ninjas that can change without affecting each other. Swift doesn't give you that automatically for classes, but you can create it yourself by writing a copy() method that creates a fresh instance with the same values:

class Ninja {
    var name: String
    var powerLevel: Int

    init(name: String, powerLevel: Int) {
        self.name = name
        self.powerLevel = powerLevel
    }

    func copy() -> Ninja {
        Ninja(name: name, powerLevel: powerLevel)
    }
}

Now when you want a true independent copy, you call copy() explicitly:

var naruto = Ninja(name: "Naruto", powerLevel: 9000)
var naruto2 = naruto.copy()

naruto2.name = "Sasuke"

print(naruto.name)  // "Naruto" — unchanged ✅
print(naruto2.name) // "Sasuke" — only this one changed ✅

Two signposts, two separate pieces of data. The copy() method creates a brand new Ninja instance in memory with the same starting values — so now each variable has its own data to work with.

Choosing a Class Sends a Message

Here's something worth holding onto that goes beyond the technical mechanics:

When you choose to use a class instead of a struct, you're making a statement about how you expect the data to be used. You're saying: "I want multiple parts of my code to share and observe the same piece of data."

When you choose a struct, you're saying: "Each owner should get their own independent copy."

Most Swift developers lean toward structs by default precisely because the copy-is-a-copy behavior is simpler and easier to reason about. You reach for a class when shared, synchronized data is exactly what you need — like a data model that needs to be observed and updated across multiple views in a SwiftUI app.

The signpost is a feature, not a bug. You just have to know it's there.

The One Thing To Hold Onto

Copying a class copies the signpost, not the data. Both copies end up pointing at the same underlying object, so changing one changes what the other sees too.

If you want a true independent copy, write a copy() method that creates a new instance. Swift won't do it for you automatically — which is intentional, because it forces you to be explicit about something that matters. 🌸

This article was written by me; AI was used to improve grammar and readability.

Swift Classes — Initializers and the super.init() Rule 🏗️

Gamya — Mon, 20 Jul 2026 08:44:00 +0000

Class initializers in Swift come with one golden rule that catches everyone out the first time. Let's talk about what it is, why it exists, and how to stop forgetting it.

Okay so we need to talk about initializers again. I know, I know — we covered them in the structs chapter. But classes have a twist that trips people up the first time they hit it, and it's worth slowing down on before you run into it at 11pm debugging something that seems like it should be obvious.

Here's the short version of what we're going to learn today:

When a child class has its own initializer, it must call the parent's initializer — and it has to do it after setting up its own stuff first.

That's it. That's the rule. But let's actually understand why, because "just do it" is a terrible way to remember something. 🍥

Setting the Scene

Let's build a ninja academy system. Every person in the ninja world has a chakraType — whether they use fire, wind, water, earth, or lightning chakra. That's a property that belongs to everyone, so it lives in the parent class:

class NinjaAcademy {
    let chakraType: String

    init(chakraType: String) {
        self.chakraType = chakraType
    }
}

Simple enough. Now let's say we want a StudentNinja that inherits from NinjaAcademy but also has a rank — like Genin, Chunin, or Jonin:

class StudentNinja: NinjaAcademy {
    let rank: String

    init(rank: String) {
        self.rank = rank
    }
}

This looks reasonable. But Swift will refuse to build it. And the error message will say something like: "Super.init isn't called on all paths before returning from initializer."

Why Swift is Refusing

Here's the problem. NinjaAcademy has a property called chakraType. It's required — there's no default value, and Swift's golden rule for initializers is every property must have a value by the time initialization is done.

When StudentNinja is created, it inherits chakraType from NinjaAcademy. But who sets it? StudentNinja's initializer doesn't mention it. And if nobody sets it, chakraType ends up without a value — which Swift will not allow.

The solution is to accept chakraType in StudentNinja's initializer too, and then pass it up to NinjaAcademy using super.init():

class StudentNinja: NinjaAcademy {
    let rank: String

    init(chakraType: String, rank: String) {
        self.rank = rank
        super.init(chakraType: chakraType)
    }
}

Now it works. Let's break down what's happening on those two critical lines.

The Order Matters: Your Stuff First, Then Super

Notice the order:

self.rank = rank           // 1. Set your own properties first
super.init(chakraType: chakraType) // 2. Then call the parent's initializer

This order is not optional. Swift enforces it. If you try to call super.init() before setting self.rank, Swift will refuse:

// ❌ This won't work — wrong order
init(chakraType: String, rank: String) {
    super.init(chakraType: chakraType)
    self.rank = rank // too late — super.init already ran
}

The reason is safety. Swift wants to make sure the current class's own properties are fully set up before it hands control to the parent class. If something went wrong during super.init(), you'd at least know your own class's properties were in a valid state.

Think of it like building a house. You have to finish your own floor before you can ask the architect to come check the whole building. The architect (super.init) needs to know the floor they're standing on is solid.

Using the Finished Class

With the initializers in place, you can now create a StudentNinja like this:

let sakura = StudentNinja(chakraType: "Fire", rank: "Genin")
print(sakura.chakraType) // "Fire" — inherited from NinjaAcademy
print(sakura.rank)       // "Genin" — defined in StudentNinja

Both properties are accessible, both are set correctly. sakura is a StudentNinja, but she also has everything NinjaAcademy defined because that's what inheritance gives you.

What If the Subclass Has No Custom Initializer?

Here's the good news: if your subclass doesn't add any new properties that need setting, you don't need to write an initializer at all. Swift will just inherit the parent's automatically:

class EliteNinja: NinjaAcademy {
    func specialMove() {
        print("Using \(chakraType) chakra for a special attack!")
    }
}

let kakashi = EliteNinja(chakraType: "Lightning")
kakashi.specialMove() // "Using Lightning chakra for a special attack!"

EliteNinja adds a method but no new properties — so it inherits NinjaAcademy's initializer for free and you don't have to write anything. More precisely: the super.init() requirement kicks in whenever your subclass defines its own designated initializer — even if it adds no new properties. The common case is adding properties (like rank above), but the rule is really about the initializer chain, not the properties themselves.

`super` Is Not Just for Initializers

While we're here — super isn't limited to init. You can use it to call any method from the parent class, which is useful when you're overriding a method but still want to run the parent's version too.

For this to work, the method needs to exist on the parent class first. Let's add one to NinjaAcademy:

class NinjaAcademy {
    let chakraType: String

    init(chakraType: String) {
        self.chakraType = chakraType
    }

    func train() {
        print("Training with \(chakraType) chakra...")
    }
}

Now Hokage can override it and call the parent's version using super:

class Hokage: NinjaAcademy {
    let title: String

    init(chakraType: String, title: String) {
        self.title = title
        super.init(chakraType: chakraType)
    }

    override func train() {
        super.train() // runs NinjaAcademy's version first
        print("\(title) also reviews mission reports after training.")
    }
}

let naruto = Hokage(chakraType: "Wind", title: "Seventh Hokage")
naruto.train()
// "Training with Wind chakra..."
// "Seventh Hokage also reviews mission reports after training."

Same pattern: super gives you access to the parent, whether you're in an initializer or a regular method.

The One Thing To Hold Onto

The rule that catches everyone: when your child class has its own initializer, set your own properties first, then call super.init().

Get that order right and everything works. Get it backwards and Swift will stop you immediately. It feels pedantic until you understand why — Swift is making sure every single property has a value before initialization completes, no matter how deep the inheritance chain goes. That's not pedantry, that's safety. 🌸

This article was written by me; AI was used to improve grammar and readability.

Swift Classes — Inheritance, Override, and the final Keyword 🧬

Gamya — Sun, 19 Jul 2026 08:44:00 +0000

What if you could take an existing class and say "I want everything this already does, plus a few things of my own"? That's inheritance. Let's talk about it.

Okay so here's a thought experiment.

Imagine you're building an anime RPG. You need a Ninja class. You create it, give it a name, a village, and a method called fight(). Great. Done.

Then you realise you also need a Hokage class. A Hokage is still a ninja — they have a name, they belong to a village, they can fight. But they also have extra responsibilities. They lead. They make speeches. They sign off on missions.

Now you have a choice. You could copy and paste everything from Ninja into Hokage. But that's a nightmare — every time you update Ninja, you'd have to update Hokage too, and if you forget, the two drift apart and weird bugs show up.

Or you could use inheritance. Which is Swift saying: "Just tell me what's the same and what's different, and I'll handle the rest." 🍥

How Inheritance Works

Here's the base class — the parent (or "superclass"):

class Ninja {
    let name: String
    let village: String

    init(name: String, village: String) {
        self.name = name
        self.village = village
    }

    func fight() {
        print("\(name) engages in battle!")
    }

    func printSummary() {
        print("\(name) is a ninja from \(village).")
    }
}

Now here's a child class (or "subclass") that inherits from it:

class Hokage: Ninja {
    var title: "String"

    init(name: String, village: String, title: "String) {"
        self.title = title
        super.init(name: name, village: village)
    }

    func giveOrder() {
        print("\(title) \(name) commands: protect the village!")
    }
}

The : Ninja after Hokage is what makes it a subclass. That one colon gives Hokage everything Ninja has — name, village, fight(), printSummary() — for free, without copying a single line.

let naruto = Hokage(name: "Naruto", village: "Konoha", title: "\"Seventh Hokage\")"
naruto.fight()        // "Naruto engages in battle!" — inherited from Ninja
naruto.giveOrder()    // "Seventh Hokage Naruto commands: protect the village!"
naruto.printSummary() // "Naruto is a ninja from Konoha." — also inherited

naruto is a Hokage, but Swift knows he's also a Ninja, so all the Ninja methods work on him without any extra effort.

What Happens When You Want to Change an Inherited Method?

Here's where it gets interesting. What if Hokage's version of printSummary() should say something different from Ninja's version? After all, "Naruto is a ninja from Konoha" is technically accurate but undersells the situation a bit.

This is called overriding — replacing a parent's method with your own version. And Swift makes you be very explicit about it by requiring the override keyword:

class Hokage: Ninja {
    var title: String

    init(name: String, village: String, title: String) {
        self.title = title
        super.init(name: name, village: village)
    }

    func giveOrder() {
        print("\(title) \(name) commands: protect the village!")
    }

    override func printSummary() {
        print("\(name) is the \(title) of \(village) — show some respect.")
    }
}

Now when you call printSummary() on a Hokage, you get the Hokage version. Call it on a plain Ninja, you get the Ninja version. Swift figures out which one to use based on what the object actually is.

Why Does Swift Force You to Write `override`?

This might seem like extra typing for no reason, but override is actually doing two important jobs at once.

Job 1 — It stops accidental overrides.

Imagine you create a method in your subclass called printSummary() not realising the parent already has one. Without override, you'd silently replace the parent's behaviour and wonder why things stopped working. With override required, Swift stops you: "Hey, you're replacing something that exists. Was that on purpose?"

Job 2 — It stops override typos.

Imagine you meant to override printSummary() but you accidentally typed printSumary() (one m). Without the override check, Swift would just create a brand new method with a typo in the name and your override would silently do nothing. With override, Swift goes: "You said override, but there's nothing in the parent called printSumary. Check your spelling."

It's one keyword that catches two completely different categories of mistakes. Not bad.

What About Adding to an Inherited Method Instead of Replacing It?

Sometimes you don't want to completely replace the parent's method — you just want to run the parent's version and then add something on top. You can do that with super:

override func printSummary() {
    super.printSummary() // runs Ninja's version first
    print("...and also the \(title) of \(village).")
}

super refers to the parent class. Calling super.printSummary() runs whatever Ninja defined, and then you can add your own lines after it.

The `final` Keyword — "Nobody Inherits From This"

Sometimes you build a class and you know, very firmly, that nobody should ever subclass it. Maybe it does something critical where overriding the wrong method would cause weird, hard-to-debug behavior. Maybe you just don't want to support that level of customization.

That's what final is for:

final class Akatsuki {
    var name: String

    init(name: String) {
        self.name = name
    }

    func revealPlan() {
        print("The plan... is Pain's.")
    }
}

Mark a class as final and Swift will refuse to let anyone inherit from it. Try it and you'll get a compile error immediately.

Apple uses this in their own frameworks. There's a class called AVPlayerViewController — for playing videos — where Apple's documentation essentially says "do not subclass this, things will break in undefined ways." In older Objective-C code they had to say that in plain English and hope developers read it. In Swift, final enforces it in the compiler.

Think of final as documentation you can't ignore. It doesn't just tell future developers not to subclass — it makes it physically impossible.

A Quick Recap

Concept	What It Means
Inheritance	A child class gets all properties and methods from its parent
`: ParentClass`	The syntax that makes one class inherit from another
`override`	Required when replacing a parent's method with your own version
`super`	Calls the parent class's version of a method
`final`	Prevents anyone from inheriting from this class

The One Thing To Hold Onto

Inheritance is powerful, but it's also easy to over-use. The guideline most Swift developers follow is: only inherit when the child genuinely is a more specific version of the parent. A Hokage is a Ninja — that's genuine. A Village is not a Ninja — that would be strange and wrong.

If you're not sure whether inheritance is the right tool, it probably isn't. Composition (putting objects inside other objects) is usually cleaner. But when inheritance is the right call, override and final are there to make sure it doesn't quietly go sideways on you. 🌸

This article was written by me; AI was used to improve grammar and readability.

Swift Classes — Everything You Knew About Structs Just Got More Complicated

Gamya — Sat, 18 Jul 2026 08:44:00 +0000

Okay so. We need to talk about classes.

If you've been following along with this series, you're probably feeling pretty comfortable with structs at this point. You've got properties, methods, initializers, computed properties, access control, the whole thing. You feel good. You feel ready.

And then Swift says: "Great. Now meet classes."

And you go: "...are those just structs with a different name?"

And Swift goes: "No."

And you go: "They look exactly like structs."

And Swift goes: "They are not exactly like structs. Sit down."

So. Let's sit down. 🍥

On the Surface, Classes Look Identical

Here's a class:

class AnimeCharacter {
    var name: String
    var powerLevel: Int

    init(name: String, powerLevel: Int) {
        self.name = name
        self.powerLevel = powerLevel
    }

    func describe() {
        print("\(name) — Power Level: \(powerLevel)")
    }
}

And here's a struct doing the exact same thing:

struct AnimeCharacter {
    var name: String
    var powerLevel: Int

    func describe() {
        print("\(name) — Power Level: \(powerLevel)")
    }
}

Spot the difference? One says class, one says struct. The struct doesn't need a custom init because Swift generates one automatically. Everything else looks basically the same.

So why do both exist? Why not just pick one and call it a day?

Because they behave completely differently in five important ways. And those five differences are not trivia — they're the reason you'll choose one over the other throughout your entire career as an iOS developer.

The Five Ways Classes Are Different From Structs

Let me walk through them one by one, because each one matters.

1. Classes Don't Get a Free Initializer

Remember how structs automatically generate a memberwise initializer? You define the properties and Swift quietly creates AnimeCharacter(name:powerLevel:) for you — no extra work required.

Classes don't get that.

With a class, you write the initializer yourself. Every time. Which at first sounds annoying, but there's a very good reason for it — and it connects to the next point.

2. Classes Can Inherit From Other Classes

This is the big one. The headline feature. The thing that makes classes genuinely different from structs rather than just structurally similar.

Inheritance means one class can be built on top of another class, automatically getting all its properties and methods as a starting point:

class Ninja {
    var name: String
    var village: String

    init(name: String, village: String) {
        self.name = name
        self.village = village
    }

    func introduce() {
        print("I am \(name) from \(village).")
    }
}

class Hokage: Ninja {
    var title: String

    init(name: String, village: String, title: String) {
        self.title = title
        super.init(name: name, village: village)
    }

    func announce() {
        print("I am \(title) \(name), leader of \(village)!")
    }
}

Hokage inherits everything from Ninja — name, village, and introduce() — and adds its own stuff on top. You can create a Hokage and call introduce() on it even though Hokage never defined that method itself.

This is why classes don't get a free initializer. If they did, and you later added a property to Ninja, every Hokage initializer would silently break. Swift decided it's better to make you write your own, so you're always fully aware of what your initializer is doing and what it affects.

3. Copies of Classes Share the Same Data

This is the one that surprises people most, and it's genuinely important for understanding how SwiftUI works.

With a struct, every copy is independent:

var naruto = AnimeCharacterStruct(name: "Naruto", powerLevel: 9000)
var naruto2 = naruto
naruto2.powerLevel = 9001

print(naruto.powerLevel)  // 9000 — unchanged
print(naruto2.powerLevel) // 9001 — only this one changed

With a class, copies point to the same underlying data:

var naruto = AnimeCharacterClass(name: "Naruto", powerLevel: 9000)
var naruto2 = naruto
naruto2.powerLevel = 9001

print(naruto.powerLevel)  // 9001 — ALSO changed!
print(naruto2.powerLevel) // 9001

naruto and naruto2 aren't two separate characters — they're two names for the same character. Change one, you change both.

This sounds alarming, but it's actually exactly what you want for shared state in an app. If a user updates their profile name on one screen, you want every other screen showing that name to update automatically — not to be stuck showing the old version from their own private copy. Classes make that kind of shared, synchronized data easy.

4. Classes Have Deinitializers

When the very last reference to a class instance goes away, Swift can run a special function called a deinitializer — written as deinit:

class NinjaSchool {
    var name: String

    init(name: String) {
        self.name = name
        print("\(name) opened!")
    }

    deinit {
        print("\(name) closed forever.")
    }
}

Structs don't have this because each copy of a struct is independent — there's no "last copy" to track. Classes have it because when multiple things point to the same instance, Swift needs to know when truly nobody is using it anymore.

5. You Can Change Properties on a Constant Class

This one is subtle but important. With structs, a constant instance means nothing can change:

let naruto = AnimeCharacterStruct(name: "Naruto", powerLevel: 9000)
naruto.powerLevel = 9001 // ❌ can't change — it's a let

With classes, a constant instance just means you can't point it at a different instance — but the data inside can still change:

let naruto = AnimeCharacterClass(name: "Naruto", powerLevel: 9000)
naruto.powerLevel = 9001 // ✅ this is fine!

let naruto means "naruto always refers to this specific character." It doesn't mean "this character's properties can never change."

So When Do You Use a Class vs a Struct?

Most Swift developers default to structs. They're simpler, safer (because copies are independent), and Swift's standard library is built almost entirely on structs.

You reach for a class when you specifically want one of those five behaviors — most often the shared data one. In SwiftUI, your UI components are structs, but your data models that need to be shared across multiple views are classes. That's the pattern you'll see again and again as you build real apps.

The short version:

Use a Struct when...	Use a Class when...
Each copy should be independent	Multiple things should share the same data
You want the free memberwise initializer	You need inheritance
You're building UI in SwiftUI	You're building data models in SwiftUI
Simple, contained data	Data that needs to be observed and shared

The One Thing To Hold Onto

If everything above felt like a lot — and honestly, it is a lot for one sitting — the single most important thing to remember is this:

Structs give every copy its own data. Classes make all copies share the same data.

Everything else about classes (inheritance, deinit, constant mutability) flows from that fundamental difference. Once that clicks, the rest starts to make sense.

We'll go deeper on inheritance, deinitializers, and how all of this connects to SwiftUI in the next few articles. For now, just sit with the idea that structs and classes aren't interchangeable — they're different tools for different jobs, and knowing which one to reach for is one of the most important instincts you'll build as a Swift developer. 🌸

This article was written by me; AI was used to improve grammar and readability.

I Deleted 200 Lines of Code I Didn't Write and Learned More Than When I Wrote It...

Gamya — Thu, 09 Jul 2026 08:44:00 +0000

Quick note before we dive in — I know I've been off track from the iOS/Swift series lately. I just have so many thoughts I need to get out of my head first. The series is coming back with the next article, I promise. Okay. Now. Story time.

I was thinking to tell you all about the afternoon I spent deleting code and accidentally learned more than I had in the entire month I spent generating it.

This is not the story I expected to be telling. I went in thinking I was doing a quick cleanup. I came out a different person. Slightly humbled, deeply caffeinated, and with 200 fewer lines of Swift in a file that somehow works better now. Let me explain.

The Part Where I Confess Something

A few weeks ago I was moving fast on a project. Like, embarrassingly fast. Generate, test, accept, move on. Generate, test, accept, move on. The AI was producing stuff that compiled and did the thing I asked and I was just... letting it. Not reading carefully. Not asking questions. Just vibing my way through feature after feature like someone who is definitely not going to regret this later.

Reader, I regretted it later.

Not because it broke. That's the genuinely annoying part — the code was fine. It ran. The features worked. Nobody was complaining. But every time I opened that file I got this low-level anxiety I couldn't quite name, like walking into a room you cleaned by shoving everything into the closet. Technically tidy. Spiritually wrong.

So one afternoon I just... started deleting things. No plan. Just me, a delete key, and a growing sense that I had accepted a lot of code I did not actually understand.

The First Thing That Happened Was I Got Scared

This surprised me. I'm not easily scared by code. But I kept hovering over things going "okay but what if this is the thing holding everything together and I just don't know it yet."

That feeling? That is the exact feeling I never have when I write code myself. When you write something, you carry the map in your head. You remember the night you added that defensive nil check because something exploded in testing. You remember why the function is structured the way it is because you restructured it twice. You have context.

With generated code, the code arrived and the context didn't come with it. The AI made decisions — some of them genuinely good decisions — and I accepted them without understanding why they were the decisions. So now I'm standing here six weeks later, looking at my own project like a stranger, trying to figure out which parts are load-bearing and which are just decoration.

This is exactly as uncomfortable as it sounds.

So I Started Making Predictions

Before I deleted anything, I started asking myself: okay, if I remove this, what do I think breaks? Not what could break in theory. What do I think will happen, specifically.

Some of my predictions were correct and deleting the thing confirmed it was redundant. Good. Simple.

Some of my predictions were wrong in interesting ways. There was a function I was absolutely certain was doing nothing useful — looked like a model just added it out of habit — and when I deleted it, a very specific edge case in a flow I'd half forgotten about quietly fell apart. Turns out the function was handling a nil that could only show up under a particular sequence of user actions I didn't immediately remember building.

That function taught me something I did not know I didn't know. Which is the most annoying kind of learning, but also the most useful.

The Final Score

200 lines gone. Some of it was genuinely redundant — duplicated logic, defensive checks for situations that couldn't actually happen, a helper function called exactly once that could have just been one line where it was used. The kind of thing that gets added by something being thorough, not by something that knows what your specific project actually needs.

Some of it I rewrote from scratch. Not because the original was wrong. Because rewriting it meant I finally owned it. There's a difference between code you're managing and code you understand, and I needed to close that gap before I could trust myself to work on it properly.

Some of it I kept exactly as it was. Because staring at the empty space after I tried to delete it made me realize it was doing something I actually needed, and I just hadn't been paying enough attention to appreciate it. Those were the most useful deletions of all, actually — the ones where I tried to get rid of something and the project said "no, you need that, let me show you why."

What I Learned That I Didn't Expect to Learn

Here's the thing nobody tells you about generating code quickly: the velocity is real but it has a price that doesn't show up on the day you shipped the feature. It shows up later. It shows up when you need to change something, or debug something weird, or explain the thing to someone else, or just open the file six weeks later and feel that closet-full-of-junk anxiety.

Every line you accept without understanding is a small loan. The interest compounds quietly until you need to touch the thing again.

Deleting code — actually reading it carefully enough to have an opinion about whether it should exist — is one of the weirdest and most effective ways to pay that debt down. You can't delete something without understanding it well enough to argue for or against it. Which means by the time you're done, you've been forced to actually learn the codebase you thought you already knew.

I came in for a cleanup. I got an education. Slightly against my will, but still.

The Part Where I Tell You What I'm Actually Doing Differently Now

I haven't stopped using AI to generate code. That would be a dramatic overreaction and also I have deadlines. But I've started treating accepted suggestions like debt I'm choosing to take on, not like code I wrote. Because the moment I need to touch it again, I need to understand it — and if I never read it carefully, that understanding isn't there just because I was in the room when it was generated.

So now, every once in a while, I open a file I generated fast and haven't looked at closely since. I read it like it's someone else's code. I try to delete things. I make predictions about what I think will break, and then I see if I'm right.

Sometimes I am. Sometimes I'm wrong in exactly the ways that teach me something.

Either way, I come out knowing the codebase better than I did going in.

Which is, genuinely, more than I can say for the afternoon I generated it.

AI tools were used to help with grammar and structure.

I Started Writing My Prediction Before Reading the AI's Answer. Here's What Happened.

Gamya — Wed, 08 Jul 2026 03:58:48 +0000

So a few days ago I was in a comment thread arguing about whether AI is quietly ruining junior developers' ability to develop actual judgment, and someone dropped a phrase that's been rattling around in my skull ever since: predict-then-diff.

The idea, roughly: before you even look at what the AI generated, you write down what you expect it to look like. Then you compare your prediction against the actual output. The gap between the two is the lesson. It's basically forcing yourself to have a hypothesis before you're allowed to see the answer, instead of just reading the answer and nodding along like it's gospel.

I decided to actually try it for a week instead of just intellectually agreeing with it in a comment section like a coward. Here's what happened.

Day One: Immediate, Mild Suffering

First task, I needed a function to paginate through a list in SwiftUI. Normally I'd just prompt it and glance at the output, mentally file it under "looks fine," and move on with my day like a functioning member of society.

Instead, I sat there and actually wrote out what I expected: probably some kind of LazyVStack, maybe an onAppear trigger near the bottom of the list to load more, some state variable tracking the current page.

Then I looked at the actual output. It used .task instead of onAppear, which, fine, reasonable, slightly more modern. But it also introduced a Task.detached I did not predict, was not expecting, and did not understand the reasoning behind at all.

And this is the part nobody warns you about: the gap didn't feel satisfying. It felt like being wrong on a pop quiz. My brain, used to just accepting whatever compiled, was mildly betrayed by being asked to have an opinion first.

Immediately understood why nobody does this voluntarily. It's uncomfortable in a very specific, very unfamiliar way.

Day Three: The Frieren Moment

Okay hear me out. There's this bit in Frieren where she's spent so long assuming magic works one specific way, based on centuries of pattern, that she genuinely doesn't notice when something breaks the pattern right in front of her, because she stopped predicting and started just recognizing shapes.

That's what "just reading the diff and moving on" had quietly turned me into. I wasn't evaluating AI output anymore. I was pattern-matching "looks like code I've seen before" and calling that comprehension. Predict-then-diff was the first thing in months that actually made me stop and go "wait, do I actually know why this works, or do I just recognize the shape of it."

Turns out, for a genuinely humbling number of things, it was the second one.

By day three I caught myself predicting a force-unwrap in a spot where the AI instead used a guard clause with a proper early return. My prediction was the worse code. The gap taught me something real, and it wasn't even about the AI being smart — it was about me finally noticing my own instinct was rustier than I thought.

Day Five: When the Method Actually Paid Off

Here's the one that made the whole experiment worth it. I was reviewing some networking code, predicted the error handling would use a simple do-catch with a generic error message, standard stuff. The actual output silently swallowed a specific network timeout case and returned a cached value instead, with zero comment explaining why.

If I'd just read it top to bottom without predicting first, I'm being honest with myself, I probably would've accepted it. It compiled. It looked plausible. Looked exactly like the kind of "smart caching fallback" pattern I've seen in real code before.

But because I'd already committed to a prediction that didn't include silent fallback behavior, the gap actually stopped me. I asked why. Turned out the fallback was masking an actual bug in how the timeout was being detected upstream. Would've shipped a caching bug pretending to be a feature. The prediction is what made me suspicious enough to dig, instead of just vibing my way past it.

That's the whole argument for this technique in one story, honestly. The catch didn't come from being smarter than the AI. It came from having a committed hypothesis on record that the actual output failed to match.

What I Actually Think Now

I'm not going to pretend this is sustainable for every single line of code, every single day, forever. Some things are genuinely trivial and predicting them first is just theater. Nobody needs to write down their hypothesis for a getter.

But for anything with actual logic, anything where a wrong call could compound into a real bug later, I think the method is legitimately doing what it claims: it's relocating the reps. It's manufacturing the exact moment of "wait, is this actually right" that used to only show up naturally after you'd already been burned by your own mistake in production. Except now it shows up before shipping, on purpose, for free, if you're willing to sit in the mildly annoying feeling of being wrong on a pop quiz a few times a week.

The posture really is the whole thing. Reading a diff and nodding treats the output as an answer. Predicting first treats it as a hypothesis you're allowed to be wrong about. Only one of those postures actually builds anything.

Your Turn

Has anyone else actually tried something like this, on purpose, instead of just agreeing it's a good idea in the comments and never doing it? Did it stick for you, or did you quietly drop it after day two like every other good habit I've ever attempted?

And be honest: last time you accepted AI-generated code, did you have any prediction at all going in, or did you just read it once and go "yeah that tracks"?

Disclaimer: This article was written based on my own experiences and opinions. AI tools were used to help with grammar and structure, but the story, ideas, and voice are entirely my own.

What Happens When Everyone Can Build Apps But Nobody Understands Them?

Gamya — Mon, 06 Jul 2026 17:03:56 +0000

Alright, real talk moment. Last week I watched someone with zero coding background build a fully functional app in an afternoon. Working auth, a database, a halfway decent UI. Prompt in, app out. They were thrilled. I was thrilled for them. And also, if I'm honest, quietly having a small existential crisis in the corner of the room.

Not because I felt threatened exactly. More like — I spent actual years learning why guard let exists, why force-unwrapping an optional is basically playing production Russian roulette, why you don't just slap @State on everything and hope. And now that entire chunk of hard-won suffering can apparently be skipped with a well-worded prompt and a bit of patience. Cool. Cool cool cool. Love that for me.

The New Skill Isn't Coding. It's Knowing What You Don't Know.

Here's the thing that's been sitting weird with me: the app that person built works. It runs. It does the thing. But if it breaks in a weird edge case at 2am, they have no idea why, because they never had to build the mental model that would let them find out. They have the output without the map.

It's giving major "I summoned a shadow clone but I don't actually know ninjutsu" vibes. The clone can absolutely fight for you. It looks exactly like you. It even talks like you. But the second something goes wrong that the clone wasn't built to handle, you're standing there with zero chakra and zero idea what just happened, because you never did the training that would let you improvise.

That's the real shift, I think. It's not "can you build the thing." It's "when the thing inevitably breaks in a way nobody predicted, do you have literally any framework for figuring out why." AI is extremely good at producing working code. It is much less good at producing a person who understands why it's working, which is a completely different skill that doesn't transfer just because you were in the room when it happened.

The Uncomfortable Part Nobody Wants to Say Out Loud

Here's where it gets messier though, and I want to be fair about this instead of just being smug about my years of suffering like it was some kind of noble sacrifice.

A huge amount of what "understanding code" used to gatekeep wasn't actually that valuable in itself. Knowing the exact syntax for a for loop in three different languages was never the point — it was a costly proxy for the thing that actually mattered, which was being able to reason about logic and structure. If AI genuinely lets more people skip the costly proxy and get straight to building useful things, that's not automatically bad. Loads of us gatekept a skill that was mostly just "memorized enough incantations to get the compiler to stop yelling," and dressed it up as deep expertise.

So I don't think the honest question is "is it bad that people can build without understanding." I think it's "what happens to the people who only ever build without understanding, the moment something needs actual understanding to fix." Those are very different problems, and I think a lot of the online discourse conveniently blurs them together because "everyone's fine, don't worry about it" and "everyone's cooked, we're all doomed" are both easier takes than the actually annoying, nuanced middle one.

My Honest, Slightly Nervous Take

I think we're heading toward two very different kinds of app-builders, and the split isn't going to be "used AI" vs "didn't use AI," because basically everyone's going to use it. The split is going to be between people who used AI as a shortcut through understanding, versus people who used it as a scaffold toward understanding — same tool, completely different relationship to it.

The scaffold group asks why, even when the thing already works. They read the generated code like it's a stranger's PR, not a magic box. They break things on purpose in a sandbox just to see what the error actually looks like, so next time it happens for real they're not starting from zero. The shortcut group ships the working thing and moves on, and I get it, deadlines are real, but eventually the bill comes due, usually at the worst possible time, usually in production, usually on a Friday.

I want to be in the scaffold group. Some days I actually am. Other days I catch myself accepting a suggestion because it compiled and I had somewhere to be, and I have to go back later and actually sit with what it did, like eating my vegetables after I already had the dessert.

Okay, Your Turn, Don't Leave Me Hanging Here

So genuinely — where do you land on this? Do you think "understanding the code" is going to matter less over time, the same way most of us don't understand assembly anymore and it's completely fine? Or is this different, because the failure modes of AI-generated logic are weirder and less predictable than the failure modes of a compiler?

And be honest: when's the last time you accepted a suggestion, watched it work, and never actually went back to ask why?

Asking for a friend. The friend is, once again, me. I contain multitudes and also several unexamined, accepted suggestions.

This article was written based on my own experiences and opinions. AI tools were used to help with grammar and structure, but the story, ideas, and voice are entirely my own.

Who Else Has Inherited a Codebase With Zero Comments and a Prayer?

Gamya — Sun, 05 Jul 2026 13:23:33 +0000

Okay so. Story time. Grab a coffee; this one's got a body count.

A few months back I got assigned a "small fix" on a payment reconciliation service. Small fix. That's what the ticket said. I need that on record before I tell you what happened next, because I want you to fully feel how personally I take that betrayal.

First file I open has a function called handlePayment2. Not handlePaymentV2. Not handlePaymentUpdated. Just 2. Like someone typed it out, looked at it, and thought, "Yeah, that's a professional software artifact," and then went to lunch. And it's sitting right next to handlePayment, which is STILL being called in three other places. Nobody deleted the original. It's just there. Both of them. Living together. Co-parenting the payment flow like a divorced couple who still share a group chat.

Zero comments anywhere in the file. Not one. I scrolled 400 lines and found exactly one piece of human text in the whole thing: // TODO fix this, dated 2022. Fix what. FIX WHAT, my guy. That's not a comment, that's a cry for help mailed to nobody.

This is when I realized the whole ordeal was giving me full Death Note energy — except instead of L calmly deducing a serial killer's identity from crumbs of evidence, it was just me, at 11pm, trying to deduce why a boolean exists using nothing but vibes and rage.

The Investigation Begins (Send Help)

Naturally I did the thing we all do when betrayed by silence: I opened git blame like it owed me money.

git blame on a codebase like this is a treasure map where X marks the spot, except the X is a commit from a user called temp-fix-do-not-merge who does not exist anymore, possibly never existed, possibly ascended. The treasure itself was a config flag called useNewLogic, which — plot twist — is neither new, nor optional, nor logic anyone currently understands. I spent two hours confirming the "old" path had been fully dead since 2023. Nobody deleted it. It's just sitting there, radioactive, feared by all, touched by none.

Big Frieren energy, honestly. A thousand-year-old elf mage carrying memories nobody else is even alive to share anymore. That's useNewLogic. It has seen wars. It remembers the Great Migration of 2023 that literally no one currently employed was present for.

The commit messages offered zero comfort. Real messages, paraphrased slightly so I don't doxx my former coworkers: "fix bug." "update per request." "changes." And then one, glorious, unhinged entry that just said: "idk." Lowercase. No period. A confession dressed up as documentation.

You inherit the code. You do not inherit the two Slack threads and one hallway conversation where the actual reasoning lived and died. That context left the building the day the original dev did, and there is no jutsu, no summoning scroll, no Dragon Ball wish that brings it back. I checked. I would not lie to you about something this important.

Why This Happens to Literally Everyone, Not Just Cursed People

I used to think uncommented codebases were a "lazy dev" problem. Wrong. I've met genuinely sharp, careful engineers who still leave behind absolute crime scenes, because it was never about laziness. It's about:

The deadline was real, the comment was not. Three hours before launch, nobody's thinking "how will this read to a confused stranger in 2026." They're thinking "please, for the love of god, just work." Comments die first in every crunch, on every team, in every universe including several I haven't worked on yet.

It felt obvious while you were inside it. The sneakiest one. Deep in a problem, your brain holds the whole context loaded, so everything looks self-explanatory — right up until that context evaporates and future-you is left staring at your own code like it's written in a language you almost speak.

Nobody ever got promoted for a great docstring. Ship the feature, get the Slack praise emoji. Explain the tradeoff clearly for whoever comes next? Silence. Not even future-you says thank you, and future-you is the one who needed it most.

Deleting dead code takes more nerve than writing new code. handlePayment2 exists because deleting handlePayment means someone has to be SURE, professionally, put-your-name-on-the-commit sure, that nothing depends on it. Way easier to slap a 2 on it and back away slowly. I say this with love: I have also been the guy who added the 2. We contain multitudes.

What Actually Changed For Me After This

I'm not going to pretend I became a documentation monk overnight, glowing with the wisdom of a thousand clean commits. But a few things genuinely stuck:

I started writing down the archaeology as I did it, not after, because "after" never comes. The second I confirmed something was dead, I left a comment saying so — confirmed dead as of this date, verified via logs, here's exactly how. Whoever comes next doesn't have to redo my two hours of suffering. Let my pain be their shortcut.

I stopped refactoring and understanding at the same time, because that's how you delete the one line holding the entire building up. Understand first, in a throwaway branch. Refactor second, once you actually know what's load-bearing and what's decorative.

I started assuming every "temporary" fix is permanent, because it always, always is. If it's survived longer than a sprint, it has tenure now. Respect the tenure.

And weirdly, I got a lot more sympathetic to whoever wrote the original mess. They weren't careless — they were a person, under a deadline, doing their best with the time they had. Same as me right now, quietly leaving behind my own future crime scene for someone else to git blame in 2027.

Your Turn, Don't Be Shy

I refuse to believe I'm the only one with a story like this. So:

What's the worst codebase you've ever inherited? What's the most deranged commit message you've personally witnessed with your own two eyes? And — deep breath — if a stranger opened your code from a year ago right now, zero context, cold read, would they curse your name, or would you actually be fine?

Asking for a friend. The friend is me. I already know the answer and I am choosing to grow from it.

This article was written based on my own experiences and opinions. AI tools were used to help with grammar and structure, but the story, ideas, and voice are entirely my own.

Swift Structs — Static Properties and Methods 🏛️

Gamya — Sat, 04 Jul 2026 08:44:00 +0000

Sometimes you want data or functionality to belong to a struct itself, not to any individual instance. That's what static properties and methods are for—let's break them down with some examples!

Every property and method we've added to our structs so far has belonged to instances — each Ninja you create has its own name, each Guild has its own gold. But sometimes you need data or functionality that belongs to the struct itself, shared across everything. That's where static comes in. 🍥

The Problem Static Solves

Imagine we're building an anime series tracker app and we want to keep a count of how many series have been registered — not on any one series, but across all of them:

struct AnimeSeries {
    static var totalRegistered = 0

    static func register(title: "String) {"
        print("\(title) has been added to the tracker!")
        totalRegistered += 1
    }
}

Notice the static keyword on both the property and the method. This means they belong to AnimeSeries the type itself — not to any specific instance.

Here's how you use them:

AnimeSeries.register(title: "\"Naruto\")"
AnimeSeries.register(title: "\"One Piece\")"
AnimeSeries.register(title: "\"Attack on Titan\")"

print(AnimeSeries.totalRegistered) // 3

No instance needed — you call directly on AnimeSeries. That's the key difference: regular properties need an instance (var series = AnimeSeries()), static properties belong to the struct itself.

Why No `mutating` Keyword?

You might have noticed that register() modifies totalRegistered but isn't marked as mutating. That's because mutating is only needed for regular instance methods, to handle cases where the struct instance was created as a constant.

Static properties and methods don't belong to any instance, so there's no instance to be constant or variable — mutating simply doesn't apply here.

self vs Self — Two Different Things

Now that we have static members, there are two similar-looking keywords that mean very different things:

self (lowercase) — refers to the current instance of the struct
Self (uppercase) — refers to the current type itself

struct Ninja {
    var name: String

    func introduce() {
        print("I am \(self.name)") // self = this specific ninja
    }

    static func describe() {
        print("We are all \(Self.self)s") // Self = the Ninja type
    }
}

A helpful way to remember: Swift types always start with a capital letter (Int, String, Bool) — and Self follows that same convention because it is a type.

Two Main Uses for Static

Use 1 — Storing Shared App Data

Static properties are perfect for storing data that's the same everywhere in your app — configuration, constants, shared settings:

struct AppConfig {
    static let appVersion = "1.0.0"
    static let maxEpisodesPerDay = 10
    static let animeAPIBaseURL = "https://api.animelist.com"
}

Now anywhere in your app you need the version number or API URL, you just write AppConfig.appVersion or AppConfig.animeAPIBaseURL. No need to create an instance — you just read it directly from the type.

This is cleaner and safer than defining these as loose global constants floating around your codebase.

Use 2 — Example Instances for SwiftUI Previews

This one is especially useful in SwiftUI. When you're building a screen that displays a Ninja or an AnimeCharacter, SwiftUI lets you preview it in Xcode — but you need some sample data to fill it with.

The cleanest way to provide that is with a static let example property:

struct AnimeCharacter {
    let name: String
    let show: String
    let powerLevel: Int

    static let example = AnimeCharacter(
        name: "Goku",
        show: "Dragon Ball Z",
        powerLevel: 9001
    )
}

Now whenever you need a sample character to pass into a SwiftUI preview, you just write AnimeCharacter.example. It's always available, always consistent, and you didn't need to create a new instance just to test your UI.

Mixing Static and Non-Static

You can have both static and regular members in the same struct — but there are rules about how they interact:

From static code, you can't access non-static members:

struct AnimeSeries {
    var title: String
    static var totalRegistered = 0

    static func showTitle() {
        print(title) // ❌ Can't access — which instance's title would this be?
    }
}

This makes sense: if you're in static code, there's no specific instance to read from.

From non-static code, you can access static members using the type name:

struct AnimeSeries {
    var title: String
    static var totalRegistered = 0

    func describe() {
        print("\(title) — Series #\(AnimeSeries.totalRegistered)") // ✅
    }
}

Combining Static with Private

You can also combine static with access control from the last article. For example, if you want a counter that's shared across all instances but can only be changed through a controlled method:

struct AnimeEpisodeTracker {
    private static var episodesWatched = 0

    static func watch() {
        episodesWatched += 1
        print("Episodes watched today: \(episodesWatched)")
    }

    static func totalWatched() -> Int {
        episodesWatched
    }
}

AnimeEpisodeTracker.watch() // "Episodes watched today: 1"
AnimeEpisodeTracker.watch() // "Episodes watched today: 2"
print(AnimeEpisodeTracker.totalWatched()) // 2
// AnimeEpisodeTracker.episodesWatched // ❌ private — not accessible

The episodesWatched counter is shared across the entire app, but it's private so it can only be changed through watch().

A Quick Note on When to Use Static

Static properties and methods aren't something you'll reach for constantly — most of the time, regular instance properties and methods are what you need. But they shine in a handful of situations:

App-wide constants — version numbers, API endpoints, configuration values
Shared counters or state — something that tracks across all instances
SwiftUI preview data — static let example for sample instances
Utility methods — helper functions that don't need any instance data

Wrap Up

Concept	What It Means
`static`	Belongs to the struct type itself, not to any instance
Static property	Shared across all instances — accessed via the type name
Static method	Called on the type directly, no instance needed
`self`	The current instance
`Self`	The current type
Common uses	Shared app data, SwiftUI preview examples, utility methods

This article was written by me; AI was used to improve grammar and readability.

DEV Community: Gamya

The Crash That Only Happened Sometimes — A SwiftUI Bug

I spent three hours debugging a SwiftUI crash that felt completely random. It wasn't random at all. It was me, a force unwrap, and a fundamental misunderstanding of when SwiftUI renders its views.

The Setup

The Crime Scene

The Investigation

The Fix

What I Actually Learned

Swift Classes — The Four Ways Variables and Constants Can Combine 🎭

A Quick Reminder About Signposts

The Constant That Isn't Constant

What let Actually Locks

Why Structs Work Differently

The Four Combinations

One Nice Bonus: No mutating Needed

The One Thing To Hold Onto

Swift Classes — Deinitializers and How Swift Cleans Up After Itself 🧹

Every class instance is eventually destroyed. Swift gives you a way to know exactly when that happens — and the story of how it decides when to pull the trigger is surprisingly interesting.

Automatic Reference Counting — The Invisible Accountant

Enter the Deinitializer

A Few Things Worth Knowing About deinit

The Other Thing About Variables in Classes

Why This Matters in Real iOS Development

The One Thing To Hold Onto

Swift Classes — Why Copying a Class Isn't What You Think 📋

The Moment That Breaks Your Brain

The Signpost Analogy

Why Would Swift Do This On Purpose?

So How Do You Make a True Copy?

Choosing a Class Sends a Message

The One Thing To Hold Onto

Swift Classes — Initializers and the super.init() Rule 🏗️

Class initializers in Swift come with one golden rule that catches everyone out the first time. Let's talk about what it is, why it exists, and how to stop forgetting it.

Setting the Scene

Why Swift is Refusing

The Order Matters: Your Stuff First, Then Super

Using the Finished Class

What If the Subclass Has No Custom Initializer?

super Is Not Just for Initializers

The One Thing To Hold Onto

Swift Classes — Inheritance, Override, and the final Keyword 🧬

How Inheritance Works

What Happens When You Want to Change an Inherited Method?

Why Does Swift Force You to Write override?

What About Adding to an Inherited Method Instead of Replacing It?

The final Keyword — "Nobody Inherits From This"

A Quick Recap

The One Thing To Hold Onto

Swift Classes — Everything You Knew About Structs Just Got More Complicated

On the Surface, Classes Look Identical

The Five Ways Classes Are Different From Structs

1. Classes Don't Get a Free Initializer

2. Classes Can Inherit From Other Classes

3. Copies of Classes Share the Same Data

4. Classes Have Deinitializers

5. You Can Change Properties on a Constant Class

So When Do You Use a Class vs a Struct?

The One Thing To Hold Onto

I Deleted 200 Lines of Code I Didn't Write and Learned More Than When I Wrote It...

The Part Where I Confess Something

The First Thing That Happened Was I Got Scared

So I Started Making Predictions

The Final Score

What I Learned That I Didn't Expect to Learn

The Part Where I Tell You What I'm Actually Doing Differently Now

I Started Writing My Prediction Before Reading the AI's Answer. Here's What Happened.

Day One: Immediate, Mild Suffering

Day Three: The Frieren Moment

Day Five: When the Method Actually Paid Off

What I Actually Think Now

Your Turn

What Happens When Everyone Can Build Apps But Nobody Understands Them?

The New Skill Isn't Coding. It's Knowing What You Don't Know.

The Uncomfortable Part Nobody Wants to Say Out Loud

My Honest, Slightly Nervous Take

Okay, Your Turn, Don't Leave Me Hanging Here

Who Else Has Inherited a Codebase With Zero Comments and a Prayer?

The Investigation Begins (Send Help)

Why This Happens to Literally Everyone, Not Just Cursed People

What Actually Changed For Me After This

What `let` Actually Locks

One Nice Bonus: No `mutating` Needed

A Few Things Worth Knowing About `deinit`

`super` Is Not Just for Initializers

Why Does Swift Force You to Write `override`?

The `final` Keyword — "Nobody Inherits From This"

Why No `mutating` Keyword?