DEV Community: Vinayak G Hejib

# Unstructured Concurrency in iOS

Vinayak G Hejib — Thu, 12 Mar 2026 17:13:29 +0000

A few months ago, I started noticing something strange in my app.

Nothing was crashing.
Nothing obvious was broken.

But occasionally:

users saw stale data appear briefly
network requests were triggered twice
UI updates happened after a screen had already disappeared

Naturally, we checked the usual suspects:

race conditions
caching bugs
API inconsistencies

Everything looked fine.

Until we started tracing the execution paths.

That's when we found them.

Not one.
Not two.

But dozens of tiny Task {} blocks scattered across the codebase.

Each one looked harmless during code review.
Each one worked perfectly in isolation.

But together they created something far more subtle:

unstructured concurrency.

And once we looked deeper, we discovered something even more
interesting.

Many of those tasks were also interacting with @MainActor-isolated
code in ways that quietly turned the UI thread into a traffic
bottleneck.

No crashes.
No compiler warnings.

Just strange behavior that only appeared under real user
interaction.

The kind of bugs that make you stare at logs for hours.

This article is about those bugs.

And more importantly:

why unstructured concurrency often causes them
how @MainActor can accidentally amplify them
and how a few simple patterns can make Swift concurrency behave the way it was actually designed to.

The Promise of Structured Concurrency

Swift's concurrency model is built around a simple but powerful idea:

Tasks should have a clear parent--child relationship.

When a parent task is cancelled, its children cancel automatically.

func loadProduct() async throws -> Product {
    async let details = api.fetchDetails()
    async let reviews = api.fetchReviews()

    return try await Product(
        details: details,
        reviews: reviews
    )
}

Here:

both child tasks belong to loadProduct
if the parent cancels → children cancel
errors propagate cleanly
lifetimes are predictable

This is structured concurrency.

Think of it like a well-managed engineering team: everyone knows who
they report to.

Then Someone Writes This

Sooner or later, someone writes:

Task {
    await api.fetchProducts()
}

Looks harmless.
Feels convenient.

But this is unstructured concurrency.

That task:

has no parent
has no ownership
has no automatic cancellation

It's basically a free‑roaming asynchronous creature.

Once created, it just... keeps living its life.

The Ghost Task Problem

Let's look at a SwiftUI example.

struct ProductView: View {

    var body: some View {
        Text("Products")
            .onAppear {
                Task {
                    await viewModel.loadProducts()
                }
            }
    }
}

User opens the screen → task starts.

User navigates away immediately → view disappears.

But the task?

Still running.

Because that Task {} has no relationship with the view lifecycle.

Congratulations.

You just created a ghost task.

Eventually it might finish and update state for a view that no longer
exists.

These bugs are subtle, unpredictable, and extremely hard to trace.

The Accidental Parallelism Problem

Unstructured tasks also create hidden duplication.

func refresh() {
    Task {
        await repository.loadData()
    }
}

User taps refresh twice quickly.

Now you have two independent tasks fetching the same data.

Possible outcomes:

duplicated requests
racing state updates
overwritten results
inflated analytics metrics

And during code review, nobody notices because:

"It's just a Task {}."

The Uncancelled Work Problem

A very common example appears in view models.

class ProductViewModel: ObservableObject {

    func loadProducts() {
        Task {
            let products = await api.fetchProducts()
            self.products = products
        }
    }
}

Looks perfectly normal.

But the view model cannot cancel this task.

If:

the screen disappears
the user logs out
the view model is recreated

...the task keeps running anyway.

You've effectively lost control over your concurrency.

The Structured Alternative

SwiftUI actually gives us a much better option.

.task {
    await viewModel.loadProducts()
}

The .task modifier automatically ties the task to the view
lifecycle.

When the view disappears:

the task is cancelled automatically.

Now Enter `@MainActor`

And Why `@MainActor` Is Both a Blessing... and a Trap

If Task {} is the most casually abused API in Swift concurrency,
@MainActor might be a close second.

Before Swift concurrency, UI updates looked like this:

DispatchQueue.main.async {
    self.titleLabel.text = title
}

Swift improved this with:

@MainActor
class ProductViewModel: ObservableObject {
    @Published var products: [Product] = []
}

Now UI updates are automatically safe.

Clean.
Elegant.
Predictable.

But like many convenient tools in software engineering...

it's also easy to misuse.

The "Just Add @MainActor" Fix

Soon someone sees a concurrency warning and writes:

@MainActor
func loadProducts() async {
    let products = await api.fetchProducts()
    self.products = products
}

Looks harmless.

But now the entire function executes on the main actor.

Which means orchestration begins on the UI executor.

Multiply this across several view models and suddenly:

UI work
async orchestration
state mutation

...all compete on the same actor.

Your main thread becomes a traffic intersection at rush hour.

The MainActor ViewModel Trap

Another common pattern:

@MainActor
class FeedViewModel: ObservableObject {

    func loadFeed() async {
        let posts = await api.fetchFeed()
        self.posts = posts
    }
}

Now every method in the class runs on the main actor.

Including things that shouldn't:

JSON parsing
sorting large datasets
heavy data transformations

The UI thread quietly becomes your data processing engine.

Scrolling performance will eventually protest.

The Better Mental Model

Think of @MainActor as UI state protection, not a concurrency
shortcut.

class FeedViewModel: ObservableObject {

    @MainActor
    @Published var posts: [Post] = []

    func loadFeed() async {
        let posts = await api.fetchFeed()

        await MainActor.run {
            self.posts = posts
        }
    }
}

Here:

networking happens off the main actor
computation happens off the main actor
only UI state touches the main actor

Exactly what we want.

When Both Problems Meet

The most interesting bugs appear when unstructured tasks meet careless
@MainActor usage.

Task {
    await viewModel.loadFeed()
}

If loadFeed() is @MainActor, you now have:

an unstructured task
executing on the main actor
doing work that might not belong there

Perfect recipe for:

UI hiccups
mysterious delays
hard‑to‑reproduce bugs

The kind that only appear in production.

A Simple Rule I Follow

Whenever I see:

Task { ... }

I ask:

Who owns this task?

And whenever I see:

@MainActor
class Something

I ask:

Is this truly UI state, or just convenient isolation?

Those two questions alone catch a surprising number of concurrency
bugs.

Final Thoughts

Structured concurrency gives us:

predictable task lifetimes
automatic cancellation
safe error propagation
clear ownership

Unstructured concurrency gives us:

invisible background work
duplicated tasks
uncancellable operations
unpredictable behavior

And careless @MainActor usage can quietly turn the UI thread into a
bottleneck.

Or as I like to think about it:

Structured concurrency is like a well‑run orchestra.
Unstructured concurrency is everyone playing instruments whenever they
feel like it.

Sometimes it still sounds okay.

Until it suddenly doesn't.

Memory Leaks Are Architecture Problems

Vinayak G Hejib — Mon, 05 Jan 2026 09:09:45 +0000

Audience: Majority iOS Engineers

Written for engineers who debug systems not syntax.

Context: Large, modular, long-lived production apps

The Comfortable Lie We All Learned

(Why [weak self] Is Not the Fix You Think It Is (UIKit + SwiftUI))

For years, most of us, iOS developers have been told:

“If you have a memory leak, just add [weak self].”

It sounds reasonable.

It sounds technical.

And it’s fundamentally incomplete.

In real-world iOS applications especially those with multiple teams, modules, coordinators, and long-lived services, memory leaks are rarely caused by missing weak keywords.

They are caused by architecture.

The Core Truth

Memory leaks are not language problems.

They are ownership problems.

Swift is memory-safe. ARC works.
What fails is our understanding of who owns what and for how long.

Once an app grows beyond a few screens, memory management stops being about syntax and becomes a systems design concern.

The `[weak self]` Myth

Most teams follow this pattern:

App starts leaking
Instruments shows retained objects
Someone adds [weak self]
Leak “goes away”
Six weeks (or may be 2-3 sprints) later, it’s back!!!

Why?

Because [weak self] does not define ownership.

It only avoids one specific retain cycle.

[weak self] hides the symptom, it does not fix the cause.

If your architecture is wrong, the leak will resurface elsewhere.

Real-World Leak #1: ViewModels Without a Lifetime / ViewModel as a God Object

The most common production leak.

How it starts

A ViewModel is created to:

Hold state
Handle user actions

How it grows

Soon it owns:

Network calls
Navigation
Analytics
Feature flags
Deep links

Eventually you get:

ViewController → ViewModel → Services → Closures → ViewController

Root cause:

The ViewModel has no clearly defined lifetime.

Should it:

Should it die with the screen?
Should it live across navigation?
Be shared across flows?

When the answer is unclear, ARC cannot help you.

Learning: When an object owns “everything”, nothing can release it safely.

Real-World Leak #2: Long-Lived Objects Owning Short-Lived Ones

This is subtle and extremely destructive.

Common examples

AppCoordinator retaining screen callbacks
Singleton managers holding ViewModels
Global caches storing closures/callbacks

AnalyticsManager.shared.track {
    viewModel.handleResult()
}

Even if viewModel is weak, the manager’s lifetime outlives the screen.

Rule:

A long-lived object must never own a short-lived one.

If it does, leaks are guaranteed.

Learning: A long-lived object must never own a short-lived one, directly or indirectly.

Combine: When Ownership Is Ignored

I would say, Combine didn’t introduce leaks.
It exposed architectural mistakes(or may be it just amplified bad architecture)!!!

For example, the culprit

publisher
    .sink { value in
        self.updateUI(value)
    }
    .store(in: &cancellables)

The leak depends on where cancellables lives:

ViewController → usually safe
ViewModel → depends on lifetime
Singleton / Coordinator → leak

Learning: Combine pipelines must obey the same lifetime rules as views or they leak quietly.

`NotificationCenter` Is Not the Villain

NotificationCenter leaks are usually symptoms, not causes.

If deinit isn’t called, ask:

Who is retaining this object?
Why does it live longer than expected?
⚠️ NotificationCenter is rarely the root cause, it’s the first visible symptom of bad ownership.

Timers & DisplayLinks: Perfect Leak Multipliers

Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { _ in
    self.refresh()
}

Even with [weak self], this leaks if:

The timer isn’t invalidated
The run loop outlives the screen

Learning: Repeating resources must be explicitly tied to lifecycle; architecture decides that, not syntax.

SwiftUI: Memory Leaks Hidden Behind Simplicity

SwiftUI didn’t remove memory management.

It made it implicit.

That makes ownership mistakes easier and harder to detect.

SwiftUI Leak Pattern #1: `@StateObject` in the Wrong Place

struct ScreenView: View {
    @StateObject var viewModel = ScreenViewModel()
}

If ScreenView is recreated:

The ViewModel may survive longer than expected
Or be recreated repeatedly

If you don’t control where an object is created,
you don’t control when it dies.

@StateObject doesn’t manage memory, it declares ownership.
And ownership must match lifecycle.

SwiftUI Leak Pattern #2: EnvironmentObjects With No Exit

EnvironmentObjects are effectively global ownership.

If they:

Hold services
Retain closures
Reference UI state

They will live far longer than the UI expects.

Environment ≠ lifecycle.

SwiftUI Leak Pattern #3: View Identity Mistakes

Incorrect id usage causes:

View recreation
Object graph duplication
State retention bugs

List(items, id: \.self) { item in
    RowView(item: item)
}

If identity is unstable, memory behavior is unpredictable.

SwiftUI Leak Pattern #4: Navigation Retains State

Navigation stacks can:

Retain views
Retain ViewModels
Retain closures

Even when UI disappears.

Navigation is ownership.
Treat it as such.

Architecture Smells That Predict Leaks

If you see these, leaks are inevitable:

ViewModels doing navigation
Singletons coordinating flows
Managers with no lifecycle
Extensions as dumping grounds
“Convenience” APIs growing endlessly

These are not style issues.
They are runtime memory failures waiting to happen.

How "Good" Engineers Debug Leaks

Not by guessing!!!

Actual workflow

Instruments → Allocations
Memory Graph Debugger
Identify retention chains
Ask one question:

Should this object still be alive?

If the answer is no, the architecture is wrong.

You don’t hunt leaks.
You prove ownership is invalid.

The Architectural Fix(Not a tiplist)

Strong apps have:

Explicit lifetimes
Directional ownership
Short-lived objects owned by short-lived parents
Long-lived objects that never retain UI

This applies equally to:

UIKit
SwiftUI
Combine
Coordinators
Dependency graphs

Final Truth

Memory leaks are not Swift problems.

They are architectural lies revealed by runtime.

Fix ownership.

Define lifetimes.

Leaks disappear naturally.

Memory Leaks in SwiftUI(Real-World Examples)

Vinayak G Hejib — Thu, 20 Nov 2025 09:46:27 +0000

Memory Leaks in SwiftUI - Where They Hide & How to Catch Them!!

SwiftUI makes UI feel effortles, some SwiftUI views exit the screen. but others cling to RAM like it’s the last samosa 😉

Have you ever observed something highly interactive customization flow—started behaving oddly? Nothing crashes, Nothing obviously lags, but each time we navigate through the flow, the app feels heavier. Not slow… just “sticky,” like the UI was dragging unseen baggage behind it.

I has a similar situation and after 10–15 navigations, Instruments confirmed my suspicion:

A whole family of views, view models, timers, and async tasks were still alive.

Not one or two.

All of them.

It wasn’t a Combine pipeline gone rogue.

It wasn’t AVPlayer.

It wasn’t some UIKit weirdness.

It was a single misused @StateObject buried inside a child view.

The Real Leak That Triggered the Investigation

Inside the main customization screen:

@StateObject var viewModel = BigViewModel()

Perfect.

But deep within a child view:

@StateObject var viewModel: BigViewModel

instead of:

@ObservedObject var viewModel: BigViewModel

That tiny slip created a permanent retention cycle.

Every navigation pushed a new BigViewModel into memory.

None ever left.
The leak was silent until the user repeated the flow enough times for the app to feel heavier.

Real world. Hard to catch. Easy to create.

Where SwiftUI Actually Hides Leaks (Real Examples from Real Apps)

1. Wrong property wrapper (`@StateObject` vs `@ObservedObject`)

This is the #1 cause I’ve seen in large SwiftUI codebases.

SwiftUI assumes @StateObject owns the lifecycle.

Child views often live longer than expected (transitions, animations, NavigationStack caching).

One wrong wrapper → immortal view model.

2. Async Tasks that silently retain `self`

I ran into a bug where a discount recalculation fired on every color change:

.onChange(of: selectedColor) { _ in
    Task {
        await viewModel.recomputeDiscount()
    }
}

Harmless-looking, but Task captures strongly by default.

The recalculation job kept the entire view model—and its whole dependency graph—alive.

The fix:

Task { [weak viewModel] in
    await viewModel?.recomputeDiscount()
}

3. Timers that were never cancelled

A carousel featured an auto-scroll timer:

Timer.publish(every: 3, on: .main, in: .common)
    .autoconnect()
    .sink { _ in self.next() }

Nobody cancelled it.

Every “dead” carousel screen stayed… well… very much alive.

You don’t notice until you have 20 of them.

4. NavigationPath captured in a ViewModel

This one surprised even senior devs:

class NavVM {
    var path: NavigationPath
}

The minute you capture the entire NavigationPath, SwiftUI may never free the views, because the path retains every element in it.

If you must observe navigation, observe tokens / IDs, never the full path object.

5. EnvironmentObjects retaining everything

Shared state is great—until it becomes a black hole.

A global theme object held references to:

feature view models
child store objects
even closures that referenced views indirectly

EnvironmentObjects should be pure app state, not dependency containers.

How I Catch Leaks Today (and Sleep Better)

1. Add `deinit` logs to every ViewModel

deinit { print("deinit: BigViewModel") }

If you don’t see this when popping a screen → it’s leaking.

2. Make `[weak self]` a reflex

Tasks, closures, timers, Combine pipelines — treat them all as suspects.

3. Audit property wrapper changes during code reviews

Catch wrong wrappers early.

4. Stress-test navigation

Push/pull a flow 20–30 times.

Leaks reveal themselves through repetition.

Final Thought

SwiftUI’s power comes from its declarative nature.

But the lifecycle behind it is not always intuitive—and sometimes, a single misplaced wrapper or async closure can keep entire view trees alive.

Once you know where leaks hide, you’ll start seeing them every week.

And trust me:

Crushing a stubborn leak feels ridiculously satisfying.

The Essentials of Unit Testing in iOS - A Quick Guide

Vinayak G Hejib — Tue, 09 Sep 2025 15:19:26 +0000

Unit testing is the backbone of robust, maintainable iOS apps. Think of it like having a safety net under a tightrope, it won’t stop you from writing risky code, but it will catch you if things go wrong. Writing reliable tests ensures your code behaves as expected, prevents regressions, and gives developers confidence when refactoring (without that dreaded “did I just break production?” moment).

In this post, we’ll take a practical (and slightly fun) tour of unit testing in iOS. We’ll cover:

TDD (Test-Driven Development)
Dependency Injection for testability
The world of Test Doubles : Dummy, Stub, Fake, Mock, Spy (yes, they sound like a crime thriller cast)
Testing strategies for legacy codebases with missing test coverage
Practical testing standards and best practices

And to make it concrete, we’ll walk through everything with a Login flow example, because if there’s one thing every app has, it’s a login screen (and if it fails, your users won’t stick around).

1. Why Unit Testing Matters in iOS

Unit tests verify individual components of your app in isolation. In iOS, this could be:

A ViewModel in SwiftUI or UIKit (MVVM)
A network layer that authenticates users
A utility or business logic class

Benefits:

Detect regressions early
Make refactoring safer
Enable Test-Driven Development (TDD)
Document expected behavior

By testing individual units, you ensure your app behaves as expected even as the codebase grows or changes.

2. Test-Driven Development (TDD)

TDD is a disciplined approach to building software:

Write a failing test
Write minimal code to make it pass
Refactor for readability and efficiency

LoginViewModel Example:

struct User {
    let username: String
    let token: String
}

protocol AuthServiceProtocol {
    func login(username: String, password: String) -> User?
}

class LoginViewModel {
    private let authService: AuthServiceProtocol
    private(set) var loggedInUser: User?

    init(authService: AuthServiceProtocol) {
        self.authService = authService
    }

    func login(username: String, password: String) {
        loggedInUser = authService.login(username: username, password: password)
    }
}

This setup allows TDD to guide your design while keeping the code testable and maintainable.

3. Test Doubles: Dummy, Stub, Fake, Mock, Spy

Test doubles allow you to isolate the unit under test from dependencies. Each type has a specific role:

Type	Purpose	Example in iOS
Dummy	Passed but never used	Placeholder AuthService to satisfy method signature
Stub	Returns fixed responses	AuthServiceStub returning predetermined login results
Fake	Lightweight working implementation	In-memory login service for testing
Mock	Records method calls, allows verification	Verify that login() is called exactly once
Spy	Records calls and behavior	Ensure delegate methods or callbacks are triggered

Examples with Login Flow

Dummy – used just to satisfy dependency injection, not actually used by the test.

class AuthServiceDummy: AuthServiceProtocol {
    func login(username: String, password: String) -> User? {
        return nil // Not used in this test
    }
}
// Example: Passing this to LoginViewModel ensures the constructor compiles, 
// even though we won’t call login().

Stub – provides predefined outputs so tests can run deterministically.

class AuthServiceStub: AuthServiceProtocol {
    func login(username: String, password: String) -> User? {
        if username == "test" && password == "1234" {
            return User(username: username, token: "abc123")
        }
        return nil
    }
}
// Example: Ensures LoginViewModel always gets a known response for given inputs.

Fake – a simplified but working implementation (e.g., in-memory user store).

class AuthServiceFake: AuthServiceProtocol {
    private var users: [String: String] = ["test": "1234"]

    func login(username: String, password: String) -> User? {
        guard let storedPassword = users[username], storedPassword == password else { return nil }
        return User(username: username, token: "fakeToken123")
    }
}
// Example: Acts like a real auth service without network calls.

Mock – verifies that specific methods are invoked.

class AuthServiceMock: AuthServiceProtocol {
    var loginCalled = false

    func login(username: String, password: String) -> User? {
        loginCalled = true
        return nil
    }
}
// Example: Lets us check if LoginViewModel actually triggered login().

Spy – tracks how many times or with what data a method is called.

class AuthServiceSpy: AuthServiceProtocol {
    private(set) var loginCallCount = 0

    func login(username: String, password: String) -> User? {
        loginCallCount += 1
        return User(username: username, token: "spyToken")
    }
}
// Example: Useful for verifying multiple login attempts are handled.

4. Dependency Injection (DI)

Hard-coded dependencies make testing difficult. DI allows injecting stubs, fakes, or mocks:

let stubService = AuthServiceStub()
let viewModel = LoginViewModel(authService: stubService)

This makes your tests deterministic and independent of network or database services.

5. Legacy Code and Incremental Testing

Testing legacy apps requires careful planning:

Identify critical flows (e.g., login success/failure)
Introduce protocols and DI to decouple code
Write unit tests incrementally
Use test doubles to isolate untestable parts
Focus on core logic over 100% coverage initially

Refactoring Example:

protocol AuthFetcherProtocol {
    func login(username: String, password: String) -> User?
}

class LegacyLoginManager {
    private let fetcher: AuthFetcherProtocol

    init(fetcher: AuthFetcherProtocol) {
        self.fetcher = fetcher
    }

    func login(username: String, password: String) -> User? {
        fetcher.login(username: username, password: password)
    }
}

class AuthFetcherStub: AuthFetcherProtocol {
    func login(username: String, password: String) -> User? {
        return User(username: username, token: "legacyToken")
    }
}

Test:

func testLegacyManagerLogin() {
    let stub = AuthFetcherStub()
    let manager = LegacyLoginManager(fetcher: stub)
    XCTAssertEqual(manager.login(username: "any", password: "any")?.token, "legacyToken")
}

6. Testing Standards and Best Practices

For effective unit testing in iOS:

AAA Pattern (Arrange-Act-Assert): Structure tests clearly.
Keep tests independent: No shared state between tests.
Name tests descriptively: testLoginSucceedsWithValidCredentials > testLogin1.
Test behavior, not implementation: Verify outcomes, not internal details.
Use coverage as a guide, not a goal: Focus on meaningful tests.
Fast feedback: Unit tests should run in seconds.

7. Efficient Testing Strategies

Start with small units: ViewModels, services, utilities
Use DI and test doubles to avoid network/db dependencies
Separate functional vs. unit tests: Logic vs. UI interactions
Leverage XCTest features: XCTAssert, XCTestExpectation, measure
Incrementally cover legacy code: Test core flows first

Key Takeaways

Unit testing ensures maintainable, bug-free apps
TDD, DI, and test doubles make testing fast and isolated
Use Dummy, Stub, Fake, Mock, and Spy for different testing scenarios
Legacy code can be incrementally tested and refactored
Follow standards and best practices for clarity and reliability

LLMs in Xcode: How AI Will Change iOS Development Forever

Vinayak G Hejib — Mon, 01 Sep 2025 09:54:40 +0000

🎯 Artificial Intelligence (AI) isn’t just knocking on the door of iOS development....it’s already in the room!!!

With Large Language Models (LLMs) becoming more deeply integrated into developer tools, Xcode itself is on the brink of an AI-powered revolution. The shift won’t just make coding faster—it will fundamentally transform how iOS apps are built, tested, and shipped.

Let’s dive into how LLMs will reshape iOS development, why this change is inevitable, and what it means for developers like us.

💻 From Autocomplete to "Auto-Engineer"

For years, Xcode has had autocomplete and code snippets. Useful? Yes. But LLMs take this to another level. Instead of just suggesting the next token, AI can understand your intent. Imagine:

Writing func fetchUsers and AI scaffolds the entire URLSession code with error handling and decoding.
Building a SwiftUI view where AI not only completes your layout but suggests accessibility improvements or performance tweaks.

This is no longer autocomplete, it’s auto-engineering.

Architecture as Code, Not Afterthought

Most teams struggle with consistency across modules. With LLMs, architecture decisions won’t live only in design docs—they’ll manifest directly in code.

Want MVVM with Combine in one feature and Redux-style in another? AI can enforce architectural boundaries automatically.
Boilerplate ViewModels, Coordinators, and Dependency Injection setups will no longer consume engineering hours.

This allows developers to spend less time reinventing the wheel and more time focusing on business logic and user experience.

AI-Powered Testing: From Fragile to Smart

Unit testing is often treated like a chore. But what if Xcode’s AI assistant could:

Generate unit tests automatically for every new function.
Suggest edge cases you forgot about (like offline mode, invalid tokens, or failed JSON decoding).
Highlight flaky tests and rewrite them for stability.

Even better, LLMs could analyze test coverage gaps and propose new tests—something most teams don’t have the time to do rigorously.

Debugging with Context, Not Guesswork

Debugging is often about piecing together logs and stack traces. LLMs can flip this process:

You paste a crash log, and AI explains in plain English why it happened.
Instead of just stopping at the line of code, AI correlates it with recent PRs, API contract changes, or even dependency upgrades.
AI could even simulate fixes and let you preview the impact before you change anything.

That’s not just debugging, that’s proactive problem solving.

Security and Performance as Defaults

Performance and security are usually afterthoughts until a bottleneck or breach appears. With AI in Xcode:

AI can flag potential security risks like storing tokens in UserDefaults or weak SSL handling.
It can recommend performance optimizations—like caching strategies, async handling improvements, or reducing unnecessary SwiftUI view recompositions.
AI could act as a real-time reviewer, catching issues before they ever make it to PR.

Collaboration Reimagined

Xcode projects often have a steep onboarding curve. Imagine a new developer joining your team:

Instead of reading endless Confluence pages, they can chat with Xcode’s AI assistant: “How does networking work in this project?” “Where are payments handled?” “What does this feature flag control?”

The AI doesn’t just search files—it understands project architecture, speeding up onboarding and reducing reliance on tribal knowledge.

The Developer’s New Role

Some fear AI will replace developers. But in reality, AI will act more like a supercharged pair programmer. The developer’s role will evolve from typing code to:

Defining intent: what the app should achieve, not how every line looks.
Reviewing AI output: ensuring correctness, architecture alignment, and edge-case handling.
Elevating creativity: focusing on user experience, design, and innovation instead of boilerplate.

Instead of replacing us, LLMs will amplify us.

The Road Ahead

It’s not science fiction—GitHub Copilot is already integrated with Xcode, and Apple is quietly investing in its own AI tooling. In the next few years, expect:

Built-in AI code generation in Xcode (beyond Copilot).
AI-assisted SwiftUI previews that optimize performance automatically.
Test-first workflows where AI generates tests before you even write the implementation.
AI refactor engines that can migrate legacy Objective-C code to Swift or convert Combine-based code to async/await seamlessly.

Prompt Engineering for iOS Developers: Speaking the AI’s Language

While Xcode may soon integrate AI into our workflows, the real productivity boost depends on how well we communicate with LLMs. That’s where prompt engineering comes in.

Be Specific, Not Vague

Instead of asking:

“Fix this bug”

Try:

“Fix the retain cycle in this SwiftUI View that uses @StateObject incorrectly.”

The more context you give, the better the response.

Show, Don’t Tell

Always paste the relevant code snippet rather than describing it.

LLMs respond far better to actual code than vague summaries.

Set the Role

Start prompts with roles like:

“You are an expert iOS architect”
“You are an Apple-style API designer”

This frames the answer in the style you want.

Chain of Thought with Guidance

Break a request into steps:

“First explain the bug, then suggest fixes, then show corrected code.”

This leads to more structured, usable responses.

Iterative Refinement

Don’t settle for the first reply. Instead, ask the AI to:

“Optimize further”
“Make it Swifty”
“Reduce complexity”

Iteration sharpens the results.

Combine AI + Human Review

AI suggestions should never be merged blindly into production code.

Treat AI as a pair programmer — helpful, fast, but still in need of human review.

💡 Final Thoughts

The rise of LLMs in Xcode will make iOS development faster, smarter, and more consistent. But the real winners won’t be developers who just “use AI”—they’ll be developers who guide AI. The ones who can blend architectural thinking, product vision, and creativity with AI’s raw coding power.

The future isn’t about developers vs AI.

It’s about developers with AI and together, we’ll build apps at a scale and quality that was once impossible.

The Secret Life of @State in SwiftUI: Where Does My Data Actually Live?

Vinayak G Hejib — Wed, 13 Aug 2025 10:39:31 +0000

Understanding the truth behind SwiftUI’s most misunderstood property wrapper.

Why This Matters

Every SwiftUI developer uses @State. It’s the “magic” that makes your UI update when data changes.

But here’s the problem:

Most devs don’t actually know where that data is stored, how it survives view reloads, or why it sometimes behaves unexpectedly.

Misunderstanding @State leads to:

❌ Views not updating
❌ Data unexpectedly resetting
❌ Performance hits from unnecessary re-renders

Let’s lift the hood.

The Basics — What You Think Happens

struct CounterView: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Text("\(count)")
            Button("Increment") { count += 1 }
        }
    }
}

It feels like:

count is just a normal property on the CounterView struct.
When count changes, SwiftUI magically re-renders the view.

But… that’s not the whole story.

1. First Misconception — “@State is just a stored property”

Nope. It’s not stored inside your View struct.

SwiftUI views are value types — they get recreated all the time.

If @State lived directly in your struct, you’d lose its value every time your view re-rendered.

Instead, @State is a property wrapper that stores your data outside the view, in a special SwiftUI-managed heap storage.

Think of it like this:

Your View struct is the blueprint.
The @State storage is the hidden container SwiftUI manages.
The two are connected by an ID SwiftUI assigns when the view hierarchy is built.

2. What Really Happens When You Declare `@State`

When SwiftUI first creates your view:

It allocates a hidden storage object (a “State box”).
This object lives for as long as the view identity stays the same in the hierarchy.
Your view gets a reference to that box through the wrappedValue.

Key point: View identity.

Change the identity (like swapping one .id for another in a List), and the storage disappears — @State resets to its initial value.

3. The Lifecycle in Real Time

Let’s track it:

Initialization → SwiftUI allocates storage outside the struct.
Mutation → You update the value, SwiftUI schedules a re-render.
Recreation → Your struct is replaced, but the @State box is reattached.
Destruction → Identity changes → storage is destroyed.

💡 Real-world pitfall: if you’re building complex UIs with multiple conditional branches, you can accidentally reset state when toggling between branches.

The Reality — SwiftUI’s View Identity

SwiftUI views are structs. That means they are value types — new copies get created constantly.

So if @State really lived inside your view struct, you’d lose your data every time the view refreshed.

The trick?

@State stores your data outside the view — in SwiftUI’s internal storage system — and links it to your view via identity.

How Identity Works

When SwiftUI renders a view:

It checks if the “new” view is the same identity as the previous one.
If yes, it reuses the same @State storage.
If no, it throws away the old storage and starts fresh.

Identity is determined by:

View type
Position in the view hierarchy
Any explicit .id(...) you set

Why It Matters for View Identity
State storage is tied to the identity of the view in the view hierarchy, not the variable name.
If SwiftUI thinks your view is different (e.g., changes id, order in the hierarchy, or parent view type), it will:

Tear down the old storage

Create new storage (resetting your @State)
Example:

if toggle {
    MyView() // gets a new @State storage when toggle changes
} else {
    MyView() // different identity => state resets
}

Fix: Give views a stable identity with .id(someStableValue) if you want state to persist.

That’s why reordering, wrapping in new containers, or changing .id can reset your @State.------

4. Where Does It Physically Live in Memory?

The @State wrapper conforms to DynamicProperty.

When compiled, SwiftUI injects a hidden _State struct that references a StateStorage object in the heap. That storage is owned and tracked by the SwiftUI runtime.

Your View struct → on the stack
Your @State data → on the heap (safe from constant view re-creations)

5. Real-Time Issues You’ll Actually Hit

1️⃣ Data Reset on Navigation

NavigationLink("Open Detail", destination: DetailView())

If DetailView has @State and you navigate away & back — boom, your data resets.

Why? New view identity each time.

Fix: Use @StateObject or pass the data from a higher-level view.

2️⃣ State Not Updating

If your state depends on something that changes but your view identity stays constant, SwiftUI won’t refresh.

Sometimes you need .id(someValue) to force identity change.

3️⃣ Multiple Copies of State

Put a view with @State inside a List? Each row gets its own copy of state, tied to its own identity.

Reordering rows? State might shuffle or reset.

6. How to Think About `@State`

If UIKit was:

“I’ll hold onto this reference until you tell me otherwise,”

SwiftUI with @State is:

“I’ll keep this value alive for as long as your view’s identity stays in the tree — but break that link, and I’m tossing it.”

Key Takeaways

Rules of Thumb

Use @State for simple, view-local, short-lived data
If data must survive view re-creations, lift it up or use @StateObject
Be careful with .id(...) — it can reset your state
Remember: position in the view tree matters

@State is not a normal property — it’s SwiftUI’s way of outsourcing your data to an identity-bound container.

If your view’s identity changes, your @State starts fresh.

Once you truly understand that, you’ll stop fighting SwiftUI and start making it work for you.

What Really Happens When You Call an async Function in Swift?

Vinayak G Hejib — Tue, 29 Jul 2025 11:16:11 +0000

"Calling await in Swift feels like casting a spell — except Swift is the sorcerer and you're just waving a wand.
And like any good spell, there's a secret potion brewing underneath.
We’ve all been there — late-night debugging, coffee in hand, watching your async function freeze and unfreeze like some kind of dark magic!!"

Swift’s async/await model makes asynchronous code elegant, readable, and non-blocking. But if you've ever paused mid-debug and wondered:

“Wait... where did my function actually go after I hit await?”

—you’re in the right place.

This blog post takes you behind the scenes of Swift's async functions, demystifying what really happens when you call them; underneath that calm, elegant surface is a full-blown circus of continuations, task schedulers, and a meticulously crafted state machine — all generated for you by the Swift compiler.

Let us consider as an example:

When you write something like await fetchItems(), it feels like magic. But behind the curtain, Swift is doing a whole lot of heavy lifting to make async/await feel seamless — while keeping your app smooth and responsive. Let’s dive into how async functions really work in Swift, what makes them efficient, and why they’re much more than just syntactic sugar over callbacks.

At first glance, async functions look like ordinary sequential code:

let user = await fetchUser()
let posts = await fetchPosts(for: user)

To you, the developer, it reads top-to-bottom — just like synchronous code.

But in reality, every time you hit an await, Swift pauses the function, hands over control to something else (like the main run loop), and resumes it later when the awaited value becomes available. This is more like a theatrical intermission than a simple pause.

Continuations: The Brain 🧠 Behind `await`

Swift uses a powerful concept called continuations. Think of a continuation as a "bookmark" for the current point in a function — it stores:

The function's local variables,
The point where execution left off,
And the next instruction to run when the awaited task completes.

So when you write:

let profile = await fetchUserProfile()

Swift compiles this into a state machine that can:

Suspend itself,
Store context,
And resume from exactly where it left off.

In lower-level terms, Swift transforms your async function into something like this:

enum FetchState {
    case start
    case waitingForProfile
    case done
}

This machinery is automatically generated during compilation — so your async function becomes a state machine under the hood, but you don’t have to manage that complexity manually.

Under the Hood: Swift’s Task System

Behind all of this is Swift’s structured concurrency model, built on top of a cooperative task system.

When you create a new async task:

Task {
    await loadData()
}

Swift:

Allocates memory for a new task object,
Schedules it for execution on a global executor,
Executes its body until the first await,
Then suspends it — saving its continuation.

Later, when the awaited result is ready, the continuation is resumed on the appropriate executor (often the main actor if you're on the UI thread).

This model is non-blocking, so multiple async tasks can be scheduled and paused concurrently — all without spawning heavyweight threads.

Async/await ≠ Threads

This is worth highlighting: calling an async function does NOT create a new thread.

If you call await fetchData() from the main thread, the function suspends itself without blocking — freeing up the thread to keep UI rendering smooth. When the awaited result is available, Swift resumes the function on the appropriate thread or executor.

This makes async/await an extremely lightweight and efficient model — far better than the GCD + callbacks spaghetti many iOS developers had to deal with in the past.

The Magic of `await` in SwiftUI

If you’re using SwiftUI and structured concurrency, all of this allows you to write elegant code like:

@MainActor
func load() async {
    self.isLoading = true
    let result = await networkService.fetchData()
    self.data = result
    self.isLoading = false
}

Thanks to the underlying continuation-based machinery, you don’t have to think about:

Dispatch queues,
Completion handlers,
Thread safety.

Swift takes care of it. But knowing how it works under the hood can help you reason about bugs, optimize performance, and understand suspension points better.

Bonus: Checked Continuations

Sometimes you need to bridge old completion-based APIs with Swift concurrency. That’s where checked continuations come in:

func legacyLogin() async throws -> User {
    try await withCheckedThrowingContinuation { continuation in
        legacyAuthService.login { result in
            switch result {
            case .success(let user):
                continuation.resume(returning: user)
            case .failure(let error):
                continuation.resume(throwing: error)
            }
        }
    }
}

This allows you to “manually” capture and resume the continuation — but it also includes safety checks to prevent misuse (e.g., multiple resumes, never-resumed bugs).

🧵 Wrapping Up: Async as State Machines

To recap, when you write an async function in Swift:

✅ It’s compiled into a state machine that can suspend and resume.

✅ Suspension happens via continuations stored in memory.

✅ Async functions don’t block threads — they’re suspended cooperatively.

✅ Swift’s structured concurrency handles lifecycle, error propagation, and cancellation for you.

Knowing this helps you appreciate the performance, safety, and elegance Swift offers — and gives you the tools to write more thoughtful concurrent code.

The image visualizes key concepts like:

Suspension points as space stations where the function can pause and resume
The main thread continuing to handle other tasks (like UI updates)
Task bubbles representing concurrent work happening in the background
Swift's cooperative nature where async functions play nicely with the system

💡 Final Thought

Next time you type await, remember: you’re not pausing the universe — you’re crafting a finely orchestrated performance of mini-intermissions, backstage crew (executors), and set changes (continuations) that bring modern concurrency to life.

Thanks for reading :)

The Art of Dependency Injection in SwiftUI

Vinayak G Hejib — Mon, 21 Jul 2025 10:46:15 +0000

How I Stopped Worrying and Learned to Love Passing Stuff Around*

If SwiftUI had a motto, it might be: “Less is more, but good luck injecting that API client.”

In the world of SwiftUI, dependency injection is like dating: you want clarity, low maintenance, and definitely no surprises. Whether you're passing view models, shared state, or static configuration, how you inject those dependencies can make or break your architecture — and your sanity.

In this post, we’ll explore three elegant ways to inject dependencies into SwiftUI views and when to use (or avoid) each:

Constructor-based injection
@Environment-based injection with custom keys
@EnvironmentObject for shared observable state

We’ll use a fun example: a theme-aware counter screen. No analytics, no token managers — just a beautiful button and a splash of color.

1️⃣ Constructor-based Injection: The “Polite Guest” Approach

struct Theme {
    let background: Color
    let textColor: Color
}

struct CounterView: View {
    @State private var count = 0
    let theme: Theme

    var body: some View {
        VStack {
            Text("Count: \(count)")
                .foregroundColor(theme.textColor)
            Button("Increment") {
                count += 1
            }
        }
        .padding()
        .background(theme.background)
        .cornerRadius(12)
    }
}

When to use it??:

You value clarity and control
You love previews and unit testing without wizardry
Your theme shouldn't mysteriously change mid-scroll

2️⃣ Environment Injection: The Magical Air You Breathe

Step 1: Define a Custom Environment Key

private struct ThemeKey: EnvironmentKey {
    static let defaultValue = Theme(background: .white, textColor: .black)
}

extension EnvironmentValues {
    var theme: Theme {
        get { self[ThemeKey.self] }
        set { self[ThemeKey.self] = newValue }
    }
}

Step 2: Inject It Once, Use It Anywhere

struct CounterView: View {
    @Environment(\.theme) private var theme
    @State private var count = 0

    var body: some View {
        VStack {
            Text("Count: \(count)")
                .foregroundColor(theme.textColor)
            Button("Increment") {
                count += 1
            }
        }
        .padding()
        .background(theme.background)
        .cornerRadius(12)
    }
}

Step 3: Set the Theme from a Parent

struct RootView: View {
    var body: some View {
        CounterView()
            .environment(\.theme, Theme(background: .mint, textColor: .indigo))
    }
}

When to use it??:

Your dependency is lightweight and stable
You don't want to manually pass values 10 levels deep
You love magic that comes with a fallback value

3️⃣ `@EnvironmentObject`: The Loud Roommate

final class ThemeSettings: ObservableObject {
    @Published var theme = Theme(background: .white, textColor: .black)
}

struct CounterView: View {
    @EnvironmentObject var settings: ThemeSettings
    @State private var count = 0

    var body: some View {
        VStack {
            Text("Count: \(count)")
                .foregroundColor(settings.theme.textColor)
            Button("Increment") {
                count += 1
            }
        }
        .padding()
        .background(settings.theme.background)
        .cornerRadius(12)
    }
}

Inject it globally:

@main
struct MyApp: App {
    @StateObject var themeSettings = ThemeSettings()

    var body: some Scene {
        WindowGroup {
            CounterView()
                .environmentObject(themeSettings)
        }
    }
}

When to use it??:

You need observable shared state
You don’t mind runtime crashes when someone forgets .environmentObject(...)
You like living on the edge

⚖️ Environment Key vs EnvironmentObject: Explained with Snacks

You have a 🍪 (biscuit)	Use `@Environment`	Use `@EnvironmentObject`
The 🍪 never changes and can be safely shared	✅	❌
The 🍪 might change (someone might take a bite)	❌	✅
You want a default fallback 🍪	✅	❌
You forget to bring a 🍪 and the app crashes	❌	✅

Summary: Which Flavor to Choose?

Technique	Best For	Avoid If...
Constructor Injection	Explicit, testable setup	You hate writing initializers
`@Environment` + Key	Global/static dependencies (themes)	You need reactivity
`@EnvironmentObject`	Shared state that updates views	You need compile-time guarantees

Final Thought

SwiftUI gives you powerful, expressive tools for managing dependencies — just enough structure to keep your code clean, and just enough magic to feel ✨Swifty✨.

So the next time you’re passing a Theme, a Settings object, or even a metaphorical biscuit 🍪, ask yourself:

Does this need to be shared?
Does it change?
Do I want control or convenience?

Because dependency injection in SwiftUI is like parenting: it’s all about boundaries, visibility, and who gets to press the increment button. 😉

iOS Apps That Don’t Crash: Myth or Method?

Vinayak G Hejib — Tue, 08 Jul 2025 10:00:08 +0000

💥

“An app crash is the loudest silence your user will ever hear.”
— Every iOS engineer, at some point (At-least I am!!).

Nothing frustrates users more than an unexpected crash. That moment when your app just… disappears. It’s not just bad UX — it’s a trust breaker. While some crashes are inevitable, many are preventable, especially with the power of modern Swift, improved tooling, and a proactive mindset.

In this post, we’ll walk through the types of iOS crashes, how to prevent them with Swift features, and how to detect and fix them — ideally before your code hits production.

⚙️ Why Apps Crash on iOS: Common Culprits

1. Nil Optionals (Force Unwrapping Gone Rogue)

let name: String? = nil
print(name!) // 💥 crash: Unexpectedly found nil

2. Out-of-Bounds Access

let items = ["Apple", "Banana"]
let item = items[5] // 💥 crash: Index out of range

3. Uncaught Exceptions (NSException)

Some Apple APIs (e.g., KVO, CoreData) throw Objective-C-style exceptions — which Swift doesn't catch.

4. Memory Issues / Retain Cycles

Retain cycles in closures or view models can cause memory bloat → crashes.

5. Main Thread Violations

Doing UI updates off the main thread can lead to subtle and dangerous bugs:

DispatchQueue.global().async {
    someUILabel.text = "Oops" // 💥 boom on a bad day
}

🛡️ Prevention: Write Crash-Resistant Swift

1. Safe Optional Handling

if let name = getUserName() {
    print(name)
} else {
    print("Name not available")
}

Or:

print(getUserName() ?? "Guest")

2. `guard` For Early Exit

func showUserProfile(_ profile: User?) {
    guard let profile = profile else {
        print("Invalid profile")
        return
    }
    print(profile.name)
}

3. Use `@MainActor` to Protect UI Updates

@MainActor
func updateUI() {
    label.text = "Updated safely"
}

Or:

await MainActor.run {
    label.text = "Updated safely"
}

4. Weak Self in Closures

fetchData { [weak self] result in
    guard let self else { return }
    self.updateUI(with: result)
}

5. Use Value Types (Structs) Where Possible

Classes can lead to retain cycles. Structs don't. Think in value semantics when you can.

🔍 Detecting Crashes Before They Happen

1. Xcode Runtime Sanitizers

Enable these under:
Scheme > Diagnostics > Enable Undefined Behavior Sanitizer / Thread Sanitizer / Address Sanitizer

2. Unit & UI Testing with XCTExpectFailure

func testInvalidIndexAccess() {
    let array = [1, 2, 3]
    XCTExpectFailure("Array index out of bounds") {
        _ = array[10]
    }
}

3. Use Static Analyzers & Linting

SwiftLint: Catch unsafe force unwraps and patterns
SwiftFormat: Enforces code style that avoids dangerous patterns
Xcode Analyzer: Shift + Cmd + B = your crash prevention friend

4. Crash Monitoring in QA

Use tools like:

Firebase Crashlytics
Instabug
Sentry
BugSnag

Deploy to internal TestFlight groups or dogfood builds with crash tracking enabled.

📦 Diagnosing Production Crashes

🔹 Use Symbolicated Stack Traces

Without dSYMs, crash reports are useless. Xcode, Bitrise, or Firebase can automate dSYM upload.

🔹 Add Custom Logs & Breadcrumbs

Crashlytics.crashlytics().log("User tapped Submit on Login")

🔹 Detect and Auto-Recover

do {
    try riskyOperation()
} catch {
    showAlert("Something went wrong. Please try again.")
}

✨ Bonus: Crash Prevention Design Patterns

Pattern	What it Helps Prevent
MVVM / Clean Architecture	Logic separation reduces side-effects
Dependency Injection	Easier testing and mocking prevents runtime surprises
Result Type over Throw	Encourages developers to handle errors explicitly
Combine / async-await	Replaces callback pyramids and reduces state explosion

Real-World Pro Tips

Use assertion failures in dev builds to make bugs visible early.
Treat force-unwrapping (!) as a code smell.
Add crash reproducer tests for every known crash postmortem.
Schedule crash triage sessions for new releases.
Don't ignore "minor" crashes — they're often just the tip of the iceberg.

🌐 Bonus: Integrate Crash Analytics Proactively

Example: Firebase Crashlytics Integration

import FirebaseCrashlytics

Crashlytics.crashlytics().log("Login button tapped")
Crashlytics.crashlytics().setCustomValue(user.email, forKey: "email")
Crashlytics.crashlytics().record(error: MyAppError.someUnexpectedError)

📘 Useful Swift Tips to Remember

Pattern	Tip
`!` (force unwrap)	Avoid unless you guarantee non-nil
`try!` or `as!`	Use only in tests or tightly controlled code
`assert(Thread.isMainThread)`	Ensure main-thread-only execution
`guard let self else { return }`	Better in async closures than forced `self!`
Use `struct` over `class`	Value types reduce shared state crashes

🚨 Real-World Anti-Patterns That Lead to Crashes

❌ The Overconfident Optional

let image = UIImage(named: config["iconName"]!)

❌ The Zombie Delegate

delegate?.didTapButton() // crash if delegate was deallocated

❌ Thread Roulette

DispatchQueue.global().async {
    self.tableView.reloadData()
}

🔺 Wrapping Up: Build With Crashes in Mind

Key Takeaways:

Modern Swift lets you write defensive, crash-resistant code.
Use runtime tools, sanitizers, and test coverage to catch crashes early.
Crash reporting is not optional in production-grade apps.
Your users won’t always leave reviews, but they will remember a crash.

Write code like you're the one waking up at 3AM to fix the crash report.

Your Crash Audit Checklist should look like:

Are all optionals safely unwrapped?
Are UI updates happening only on the main thread?
Are closures using [weak self] properly?
Are crash reporting tools integrated and tested?
Do you have test coverage for both happy and failure paths?
Are your crash logs symbolicated and actionable?
Did you simulate edge cases like low memory, network unavailability, and nil values?

If you’ve made it this far, you truly care about app’s reliability. Thanks for reading.. :)

Modernizing a Legacy Modular iOS Codebase

Vinayak G Hejib — Mon, 23 Jun 2025 13:46:03 +0000

SwiftUI Migration, Scalable Architecture & Seamless Testability

"You don’t rewrite a legacy codebase. You rearchitect it, one module at a time."

In this guide, we break down how we can transform a large-scale, UIKit-based modular monolith into a SwiftUI-driven, testable, maintainable codebase with a clean architecture. The transformation touched every part of the stack: from UI to API, from navigation to build systems.

The Problem

Lets say, over time, your iOS app evolved into a monolithic modular architecture:

Organized by feature folders (e.g., Home, Profile, Login).
Common modules like Networking, Models, Storage.
Heavy reliance on UIKit, Storyboards, and XIBs.

Pain Points:

Bloated ViewControllers: Handling UI, navigation, API, caching all at once.
Tight Coupling: Feature modules often depended on each other directly.
Unscalable Navigation: Navigation logic spread across multiple layers.
Poor Testability: Difficult to write unit or integration tests due to side effects.
Inconsistent Architecture: Teams used different patterns (MVC, MVVM, Singleton-based flows).
Slow Build Times: Everything compiled in one target; CI times increased.

We need a modern, scalable, testable, and maintainable solution.

🛠 Step 1: Choosing the Right Architecture

After reviewing several architecture styles (VIPER, RIBs, Clean, TCA), I would prefer:

✅ MVVM + Coordinators + Dependency Injection

Why?

Fits SwiftUI's declarative nature
ViewModels hold business logic and state
Coordinators isolate navigation, making it reusable and testable
Dependency Injection enables test mocking and clear boundaries

Swift Package Manager (SPM) for Modularization

Use SPM to break our app into independently buildable, testable components.

📂 Step 2: Modularization Strategy

Inspired by vbat.dev, we defined modules by feature and responsibility.

Types of Modules:

Layer	Modules	Examples
Feature	HomeFeature, SearchFeature, CartFeature	Business logic + UI
Core	CoreNetworking, CoreModels, CoreStorage	Reusable low-level components
UI	SharedUI, DesignSystem	Custom buttons, theme, reusable views
Infra	Analytics, CrashReporting	Services, APIs, Gateways

Rule: Feature modules should only depend on Core or Infra. Never on each other.

Structure Example:

/Packages
  /Features
    /HomeFeature
  /Core
    /CoreNetworking
    /CoreModels
  /UI
    /SharedUI

Step 3: Refactor the Core First

Before migrating UI or adding SwiftUI, we started with refactoring our core modules, especially CoreNetworking and CoreModels.

Why Start with Core?

Core defines how features interact with data and services
Consistent APIs and dependency rules enable scalable adoption
Core is reused across all features — enforcing good practices here radiates out
Encourages a decoupled, protocol-first design supporting testability and flexibility

CoreNetworking Redesign Goals:

Define API requests using protocols (APIRequest, APIClientProtocol)
Use Result-based decoding pipelines
Make all requests async and testable
Provide mockable interfaces for all networking services

Example:

protocol APIRequest {
    associatedtype Response: Decodable
    var path: String { get }
    var method: HTTPMethod { get }
}

protocol APIClientProtocol {
    func send<T: APIRequest>(_ request: T) async throws -> T.Response
}

final class APIClient: APIClientProtocol {
    func send<T>(_ request: T) async throws -> T.Response where T: APIRequest {
        // Build URLRequest, perform, decode
    }
}

Result:

ViewModels across features now depend only on APIClientProtocol
Services (e.g., HomeService) use these APIs internally and are easy to stub in tests
Unified patterns help enforce clean architecture across teams

📈 Enhancing CoreModels and CoreStorage

DTO vs. Domain Model

To maintain separation between networking layers and domain logic, we used the DTO → DomainModel transformation pattern:

This allows our ViewModels and business logic to work with clean, decoupled domain objects while networking remains isolated.

Beyond Networking, we standardized CoreModels and CoreStorage:

Models conform to Codable and are shared across modules.
Use of DomainModel vs DTO separation helped decouple layers.
Abstracted UserDefaults, Keychain, and FileStorage under unified protocols:

protocol KeyValueStoring {
    func get<T: Decodable>(_ key: String) -> T?
    func set<T: Encodable>(_ value: T, for key: String)
}

Concrete implementations (e.g., UserDefaultsStore, MockStorage) live inside Core or TestTargets
This made it easy to mock persistence during unit testing and eliminate side effects.

Tooling: Enforcing Architecture Contracts

To scale this approach across teams, we adopted tools to enforce boundaries and consistency:

SwiftLint

Custom rules to restrict module imports
Enforce naming conventions (*ViewModel.swift, *Coordinator.swift, etc.)

Sourcery

Auto-generate mocks for protocols using // sourcery: AutoMockable
Prevents writing tedious boilerplate for DI testing

Tuist (or Bazel)

Automate SPM graph generation
Validate dependency rules
Scales well for large modular workspaces

Step 4: Refactoring a Real Module - `HomeFeature`

Feature Module Dependency Graph

This diagram illustrates how each feature module (e.g., Home, Profile, Search) depends only on shared Core modules and not on each other, enforcing clean separation and reusability.

Original State:

600+ LOC in HomeViewController
UICollectionView + network fetches in the controller
Logic for loading, caching, refresh, navigation all tightly coupled
Hard to test; lots of UI-state bugs

Goals:

Move UI to SwiftUI
Extract logic to ViewModel
Use Coordinator for navigation
Inject dependencies (no singletons)

🔁 Step 5: Architecture in Action

`HomeViewModel.swift`

@MainActor
final class HomeViewModel: ObservableObject {
    @Published var items: [HomeItem] = []
    @Published var isLoading = false
    @Published var error: Error?

    private let service: HomeServiceProtocol

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

    func fetchItems() async {
        isLoading = true
        do {
            items = try await service.fetchItems()
        } catch {
            self.error = error
        }
        isLoading = false
    }
}

`HomeView.swift`

struct HomeView: View {
    @ObservedObject var viewModel: HomeViewModel

    var body: some View {
        NavigationStack {
            Group {
                if viewModel.isLoading {
                    ProgressView()
                } else if let error = viewModel.error {
                    Text("Error: \(error.localizedDescription)")
                } else {
                    List(viewModel.items) { item in
                        HomeRow(item: item)
                    }
                }
            }
            .navigationTitle("Home")
        }
        .onAppear {
            Task { await viewModel.fetchItems() }
        }
    }
}

`HomeCoordinator.swift`

final class HomeCoordinator: ObservableObject {
    @Published var path = NavigationPath()

    func start() -> some View {
        let vm = HomeViewModel(service: HomeService())
        return HomeView(viewModel: vm).environmentObject(self)
    }

    func goToDetail(for item: HomeItem) {
        path.append(item)
    }
}

Step 6: Improving Testability

By adopting dependency injection, protocol-first design, and clear ViewModel boundaries, our modules became much more testable.

Unit Test Example

final class HomeViewModelTests: XCTestCase {
    func testFetchItemsSuccess() async {
        let mockService = MockHomeService()
        mockService.stubbedItems = [.mock(), .mock()]

        let vm = HomeViewModel(service: mockService)
        await vm.fetchItems()

        XCTAssertEqual(vm.items.count, 2)
        XCTAssertNil(vm.error)
    }
}

SwiftUI Testing

Use .accessibilityIdentifier() to enable UI automation
Leverage ViewInspector for unit testing SwiftUI views
Snapshot testing using iOSSnapshotTestCase or SwiftSnapshotTesting

Step 7: CI, Build Times & Developer Experience

Update CI pipelines and local builds to benefit from modularization:

SPM made incremental builds faster (~40% improvement)
CI workflows ran unit tests per package
Pre-commit linting and type checks prevented regressions

Tooling Summary

Tool	Use
SPM	Modularized features and core logic
SwiftLint	Enforced import boundaries and naming rules

Add on:

Centralized Feature Initialization via a Builder Pattern

In a modular SwiftUI codebase, it's essential to cleanly instantiate feature modules with their dependencies. Instead of creating each module inline or in scattered views, we can define a FeatureModuleBuilder that:

Step 1: Define Core Services

// CoreNetwork / CoreStorage
protocol APIClientProtocol {
    func fetch<T: Decodable>(_ endpoint: Endpoint) async throws -> T
}

protocol CacheManagerProtocol {
    func get(_ key: String) -> Data?
    func save(_ data: Data, for key: String)
}

Step 2: Define Feature Modules with Dependency Structs

// HomeFeature/HomeDependencies.swift
struct HomeDependencies {
    let apiClient: APIClientProtocol
    let cacheManager: CacheManagerProtocol
}

// HomeFeature/HomeView.swift
struct HomeView: View {
    @StateObject private var viewModel: HomeViewModel

    init(dependencies: HomeDependencies) {
        _viewModel = StateObject(wrappedValue: HomeViewModel(
            apiClient: dependencies.apiClient,
            cacheManager: dependencies.cacheManager
        ))
    }

    var body: some View {
        List(viewModel.items, id: \.id) {
            Text($0.title)
        }
        .task {
            await viewModel.loadItems()
        }
    }
}

Step 3: Feature Module Builder

// MainApp/FeatureModuleBuilder.swift
struct FeatureModuleBuilder {
    private let apiClient: APIClientProtocol
    private let cacheManager: CacheManagerProtocol

    init(apiClient: APIClientProtocol, cacheManager: CacheManagerProtocol) {
        self.apiClient = apiClient
        self.cacheManager = cacheManager
    }

    func makeHomeView() -> some View {
        let deps = HomeDependencies(apiClient: apiClient, cacheManager: cacheManager)
        return HomeView(dependencies: deps)
    }

    // Add more feature modules here
    // func makeProfileView() -> some View { ... }
    // func makeSearchView() -> some View { ... }
}

Step 4: RootCoordinator Using the Builder

// MainApp/RootCoordinator.swift
struct RootCoordinator: View {
    private let builder: FeatureModuleBuilder

    init(builder: FeatureModuleBuilder) {
        self.builder = builder
    }

    var body: some View {
        builder.makeHomeView()
    }
}

Step 5: Final Entry Point

// MainApp/MainApp.swift
@main
struct MainApp: App {
    var body: some Scene {
        let apiClient = DefaultAPIClient()
        let cacheManager = InMemoryCacheManager()

        let builder = FeatureModuleBuilder(
            apiClient: apiClient,
            cacheManager: cacheManager
        )

        WindowGroup {
            RootCoordinator(builder: builder)
        }
    }
}

Benefits of the Builder Pattern

Centralized wiring of feature modules and dependencies
Easy to extend when adding new modules
Keeps SwiftUI views clean and declarative
Test-friendly structure — builder can inject mocks during testing

Lives in the main app target
Knows how to wire each feature with its required services
Keeps dependency composition clean and maintainable

🛤 What’s Next?

Expand SwiftUI adoption across remaining modules
Build cross-platform foundations (macOS, visionOS)
Define shared state management (e.g., Combine, ObservableDomain)
Explore performance gains with SwiftData + Swift Macros

🔗 References & Resources

Migrating to SwiftUI and modular architecture isn't just about code. It's about empowering teams to move faster, test better, and scale fearlessly.

DEV Community: Vinayak G Hejib

# Unstructured Concurrency in iOS

The Promise of Structured Concurrency

Then Someone Writes This

The Ghost Task Problem

The Accidental Parallelism Problem

The Uncancelled Work Problem

The Structured Alternative

Now Enter @MainActor

And Why @MainActor Is Both a Blessing... and a Trap

The "Just Add @MainActor" Fix

The MainActor ViewModel Trap

The Better Mental Model

When Both Problems Meet

A Simple Rule I Follow

Final Thoughts

Memory Leaks Are Architecture Problems

The Comfortable Lie We All Learned

The Core Truth

The [weak self] Myth

Real-World Leak #1: ViewModels Without a Lifetime / ViewModel as a God Object

How it starts

How it grows

Real-World Leak #2: Long-Lived Objects Owning Short-Lived Ones

Common examples

Combine: When Ownership Is Ignored

NotificationCenter Is Not the Villain

Timers & DisplayLinks: Perfect Leak Multipliers

SwiftUI: Memory Leaks Hidden Behind Simplicity

SwiftUI Leak Pattern #1: @StateObject in the Wrong Place

SwiftUI Leak Pattern #2: EnvironmentObjects With No Exit

SwiftUI Leak Pattern #3: View Identity Mistakes

SwiftUI Leak Pattern #4: Navigation Retains State

Architecture Smells That Predict Leaks

How "Good" Engineers Debug Leaks

Actual workflow

The Architectural Fix(Not a tiplist)

Final Truth

Memory Leaks in SwiftUI(Real-World Examples)

The Real Leak That Triggered the Investigation

Where SwiftUI Actually Hides Leaks (Real Examples from Real Apps)

1. Wrong property wrapper (@StateObject vs @ObservedObject)

One wrong wrapper → immortal view model.

2. Async Tasks that silently retain self

3. Timers that were never cancelled

You don’t notice until you have 20 of them.

4. NavigationPath captured in a ViewModel

If you must observe navigation, observe tokens / IDs, never the full path object.

5. EnvironmentObjects retaining everything

How I Catch Leaks Today (and Sleep Better)

1. Add deinit logs to every ViewModel

2. Make [weak self] a reflex

3. Audit property wrapper changes during code reviews

4. Stress-test navigation

Final Thought

The Essentials of Unit Testing in iOS - A Quick Guide

1. Why Unit Testing Matters in iOS

2. Test-Driven Development (TDD)

3. Test Doubles: Dummy, Stub, Fake, Mock, Spy

Examples with Login Flow

4. Dependency Injection (DI)

5. Legacy Code and Incremental Testing

6. Testing Standards and Best Practices

7. Efficient Testing Strategies

Key Takeaways

LLMs in Xcode: How AI Will Change iOS Development Forever

🎯 Artificial Intelligence (AI) isn’t just knocking on the door of iOS development....it’s already in the room!!!

💻 From Autocomplete to "Auto-Engineer"

Architecture as Code, Not Afterthought

AI-Powered Testing: From Fragile to Smart

Debugging with Context, Not Guesswork

Security and Performance as Defaults

Collaboration Reimagined

The Developer’s New Role

The Road Ahead

Prompt Engineering for iOS Developers: Speaking the AI’s Language

Be Specific, Not Vague

Show, Don’t Tell

Set the Role

Chain of Thought with Guidance

Now Enter `@MainActor`

And Why `@MainActor` Is Both a Blessing... and a Trap

The `[weak self]` Myth

`NotificationCenter` Is Not the Villain

SwiftUI Leak Pattern #1: `@StateObject` in the Wrong Place

1. Wrong property wrapper (`@StateObject` vs `@ObservedObject`)

2. Async Tasks that silently retain `self`

1. Add `deinit` logs to every ViewModel

2. Make `[weak self]` a reflex

2. What Really Happens When You Declare `@State`

Tear down the old storage

6. How to Think About `@State`

Continuations: The Brain 🧠 Behind `await`

The Magic of `await` in SwiftUI

3️⃣ `@EnvironmentObject`: The Loud Roommate

2. `guard` For Early Exit

3. Use `@MainActor` to Protect UI Updates