DEV Community: Vinayak G Hejib

I Let AI Build an Entire Mobile App Feature. Then I Had to Debug It.

Vinayak G Hejib — Fri, 21 Aug 2026 16:34:06 +0000

What happens when you stop writing the code and let an AI coding agent build a real mobile feature? I put it to the test, with most of the experiment focused on Swift and iOS.

I've been using AI-assisted development for quite some time now.

Like many developers, I've gone from using AI to explain code, to generating boilerplate, to debugging errors, to asking it to refactor code, write tests, and increasingly, to letting coding agents work across multiple files.

And that got me thinking about a slightly uncomfortable question:

What happens if I stop telling the AI how to implement a feature and simply ask it to build one?

Not a toy application.

Not a "Hello World" example.

Not a screen with a button and a network call.

A reasonably realistic mobile feature with asynchronous work, caching, cancellation, UI state, error handling, and tests.

So I decided to try an experiment.

I would give an AI coding agent a specification.

I would let it make the implementation decisions.

And then I would review the result like I would review a pull request from another engineer.

The interesting part wasn't whether the AI could produce code.

I already knew it could.

The interesting part was:

Could it produce code that I would actually be comfortable maintaining?

And that's where things got interesting.

The experiment

I'm framing this as a mobile development experiment, but most of the implementation and debugging examples are deliberately focused on iOS and Swift.

The reason is simple: that's where I spend most of my engineering time, and Swift's concurrency and SwiftUI model provide some particularly interesting places for AI-generated code to go wrong.

The experiment has a simple structure:

The goal isn't to prove that AI is bad at programming.

Quite the opposite.

The goal is to understand where AI is genuinely useful and where engineering judgment still matters.

The rules

To make the experiment meaningful, I wanted to remove as much hand-holding as possible.

The AI gets:

a feature specification
the existing project structure
access to the relevant codebase
the ability to create and modify files
the ability to run tests
the ability to build the application

But I deliberately don't give it the implementation.

In other words, I don't say:

"Use an actor here."

I don't say:

"Use MVVM."

I don't say:

"Use an async image loader."

I don't say:

"Use a dictionary to deduplicate requests."

Instead, I give it the problem.

That distinction matters.

Because otherwise I'm not really testing the AI's engineering ability.

I'm testing its ability to follow my instructions.

The feature

I wanted something small enough to understand but complex enough to expose engineering problems.

So let's build a product search feature.

The requirements are:

Functional requirements

The application should:

Allow the user to enter a search query.
Fetch products from a remote API.
Display results in a scrolling list.
Load product images asynchronously.
Cache previously loaded images.
Avoid duplicate image downloads.
Support pagination.
Cancel unnecessary requests.
Show loading, empty, and error states.
Retry failed requests.
Work correctly when the user rapidly changes the search query.

Non-functional requirements

The implementation should:

use Swift concurrency
be testable
avoid unnecessary network calls
avoid obvious memory leaks
handle cancellation correctly
maintain a responsive UI
separate UI concerns from networking
avoid putting business logic directly into the SwiftUI view

That's enough.

I don't tell the AI how to achieve any of it.

The first prompt

The actual prompt can be surprisingly simple.

Build a production-quality product search feature for this iOS application.

Requirements:

- Search products using a remote API.
- Display results in a SwiftUI list.
- Support pagination.
- Load product images asynchronously.
- Cache images.
- Deduplicate simultaneous requests for the same image URL.
- Cancel obsolete network requests.
- Handle loading, empty, error and retry states.
- Rapidly changing search queries must not result in stale results being displayed.
- The implementation must be testable.
- Follow the existing project's architecture and conventions.
- Use Swift concurrency.
- Do not introduce unnecessary dependencies.

First inspect the existing project structure and identify the appropriate place for this feature.

Implement the feature completely.

Run the relevant tests and fix compilation/test failures.

And then I stepped back.

First surprise: AI is really good at the first 80%

The first thing that's easy to underestimate is how much code an AI coding agent can produce very quickly.

Within a relatively short amount of time, you can get:

SearchView
SearchViewModel
ProductRepository
APIClient
ImageLoader
ImageCache
Models
Tests

It can wire the pieces together.

It can generate models.

It can create async networking code.

It can write SwiftUI.

It can generate tests.

It can run the compiler.

It can fix obvious compiler errors.

And this is where the AI experience feels almost magical.

You go from:

"Here's the requirement."

to:

"Here's a working implementation."

much faster than traditional development.

But "working" and "production-ready" are very different things.

The first code review

This is where I stopped looking at the AI as a code generator.

I started looking at it as an engineer submitting a pull request.

And I asked the same questions I would ask during any serious code review:

What are the invariants?
Where is state owned?
What happens when requests overlap?
What happens when work is cancelled?
What happens when an async operation suspends?
Can stale data overwrite fresh data?
Can two callers trigger the same network request?
What happens when the view disappears?
What happens under memory pressure?
Are the tests testing behavior or implementation?
What happens when the network fails halfway through pagination?

And suddenly, the amount of code wasn't the interesting part anymore.

The interesting part was the reasoning behind the code.

Problem #1: "But it's an actor, so we're thread-safe... right?"

This is one of the most interesting places where Swift concurrency can fool you.

Suppose the AI creates an image loader:

actor ImageLoader {

    private var tasks: [URL: Task<Data, Error>] = [:]

    func load(_ url: URL) async throws -> Data {
        if let existingTask = tasks[url] {
            return try await existingTask.value
        }

        let task = Task {
            try await download(url)
        }

        tasks[url] = task

        return try await task.value
    }
}

At first glance, this looks pretty good.

It's an actor.

The dictionary is protected.

Concurrent access is isolated.

Requests for the same URL are deduplicated.

Done?

Not quite.

The important thing about actors is not simply:

"Only one thing can access this data."

The more important concept is:

An actor can suspend, and when it resumes, the state may no longer be what it was before the suspension.

That's actor reentrancy.

Imagine:

func load(_ url: URL) async throws -> Data {

    if let existingTask = tasks[url] {
        return try await existingTask.value
    }

    let task = Task {
        try await download(url)
    }

    tasks[url] = task

    return try await task.value
}

There is an await.

The actor can process other messages while this operation is suspended.

That means the mental model:

enter actor
↓
nothing else can happen
↓
leave actor

is incorrect.

The better mental model is:

enter actor
↓
read state
↓
await
↓
release actor
↓
other work can execute
↓
resume
↓
state may have changed

This distinction is subtle.

And it is exactly the sort of thing that can slip through an AI-generated implementation because the code looks perfectly reasonable.

Why this matters outside image loading

This isn't just an image-loader problem.

The same reasoning applies to:

token refresh
request deduplication
authentication state
database operations
pagination
task registries
cache updates
connection managers
download managers

Whenever you have:

actor Something {
    var state: State

    func operation() async {
        // read state

        await something()

        // assume state is unchanged
    }
}

you should ask:

What could have changed while I was suspended?

That question is often more valuable than asking:

"Is this code using actors?"

Problem #2: Cancellation that doesn't actually cancel the work

Another common AI-generated pattern looks like this:

func search(query: String) async {
    isLoading = true

    do {
        let products = try await repository.search(query)
        self.products = products
    } catch {
        self.error = error
    }

    isLoading = false
}

Then somewhere in the UI:

searchTask?.cancel()

searchTask = Task {
    await viewModel.search(query: query)
}

Looks reasonable.

The old task gets cancelled.

The new task starts.

But cancellation in Swift is cooperative.

Calling:

task.cancel()

doesn't magically terminate every operation inside that task.

The work has to observe cancellation.

For example:

try Task.checkCancellation()

or:

if Task.isCancelled {
    return
}

And importantly, the underlying operation also needs to behave correctly when cancellation occurs.

This becomes particularly important with:

User types:
"i"
 ↓
request A

"ip"
 ↓
request B

"iph"
 ↓
request C

"iphone"
 ↓
request D

If requests A, B and C don't actually stop, you can have multiple operations running unnecessarily.

Even worse:

Request A ────────────────┐
                          ↓
Request D ──────────→ UI
                          ↑
Request A ────────────────┘

Now an old request can potentially interfere with newer state if the architecture isn't careful.

Problem #3: The stale response problem

This is one of those bugs that looks fine during normal testing.

Suppose the user searches:

shoes

Then immediately:

jackets

The requests execute concurrently.

But network timing isn't deterministic.

You could get:

Search "shoes"
       │
       ├───────────────→ Server
       │
Search "jackets"
       │
       ├──────→ Server
       │
       │
       │       jackets response
       │              ↓
       │             UI
       │
       │       shoes response
       │              ↓
       │             UI   ❌

The UI now shows shoes even though the current query is jackets.

The AI can write perfectly valid asynchronous code and still miss the semantic race.

One solution is to associate requests with a generation/token:

let requestID = UUID()
currentRequestID = requestID

let results = try await repository.search(query)

guard requestID == currentRequestID else {
    return
}

products = results

Another is to structure the task lifecycle so obsolete tasks are cancelled and stale results cannot be committed.

The exact implementation depends on the architecture.

The important lesson is:

Concurrency correctness is not the same thing as compiler correctness.

The compiler can verify that your code respects actor isolation.

It cannot tell you that your application displayed the results for the wrong search query.

Problem #4: The cache looked correct

The AI also generated a cache.

Something along the lines of:

final class ImageCache {

    private var cache: [URL: Data] = [:]

    func image(for url: URL) -> Data? {
        cache[url]
    }

    func insert(_ data: Data, for url: URL) {
        cache[url] = data
    }
}

Again:

Perfectly understandable.

But a production cache isn't just:

Dictionary<URL, Data>

You immediately have questions:

How large can it become?

What happens if the application displays thousands of images?

What happens under memory pressure?

Should everything remain in memory?

Is this memory cache or disk cache?

What is the eviction policy?

What happens if two requests arrive simultaneously?

Do we cache failed requests?

What about HTTP cache headers?

What happens when a low-resolution image is replaced by a high-resolution image?

What happens if the same URL is requested by 20 cells at the same time?

That last question brings us back to request deduplication.

The real system looks more like:

                 Image Request
                       │
                       ▼
                 Memory Cache
                    │     │
                 hit│     │miss
                    │     ▼
                    │  In-flight
                    │   Request
                    │     │
                    │     ▼
                    │   Disk/HTTP
                    │     │
                    │     ▼
                    │   Network
                    │
                    ▼
                  Image

The code isn't necessarily difficult.

The state machine is.

Problem #5: The tests looked impressive

This was perhaps one of the more interesting observations.

AI is extremely good at generating tests that look like tests.

For example:

func testSearchReturnsProducts() async throws {
    let products = try await sut.search(query: "shoes")

    XCTAssertEqual(products.count, 3)
}

Great.

But what behavior does this actually protect?

Not much.

The important tests are often the uncomfortable ones:

✓ successful request

✓ empty response

✓ network failure

✓ retry

✓ cancellation

✓ rapid query changes

✓ stale response

✓ duplicate image requests

✓ concurrent image requests

✓ pagination failure

✓ pagination cancellation

✓ view disappears during request

✓ request completes after cancellation

✓ cache hit

✓ cache miss

✓ cache eviction

And suddenly the test suite becomes a lot more interesting.

The difference between code coverage and confidence

This is an important distinction.

You can have:

95% code coverage

and still have a broken application.

Coverage answers:

"Did this code execute?"

It doesn't necessarily answer:

"Did this system behave correctly under adverse conditions?"

For concurrent systems, that's a huge distinction.

You want tests around state transitions, not just lines of code.

For example:

idle
  ↓
loading
  ↓
success

is one path.

But:

idle
  ↓
loading
  ↓
cancelled

is another.

And:

loading
  ↓
new search
  ↓
old request completes
  ↓
stale response discarded

is another.

The second category is where a lot of real bugs live.

What the AI did surprisingly well

This experiment isn't about proving that AI is bad.

There were plenty of things it did extremely well.

AI is particularly powerful at:

1. Boilerplate

Models, DTOs, initial views, protocols, test scaffolding.

2. Repetitive transformations

Renaming, moving code, extracting types, updating call sites.

3. First-pass implementations

Getting from zero to something compilable is dramatically faster.

4. API exploration

It can quickly suggest different approaches and explain unfamiliar APIs.

5. Test scaffolding

It can generate a large amount of initial test structure.

6. Debugging compiler errors

This is one of the areas where AI feels almost unfairly good.

Give it:

error: Main actor-isolated property cannot be mutated

and it can often get you surprisingly close to the solution.

7. Documentation

Turning implementation details into readable documentation is another excellent use.

Where I still wanted a human engineer

The interesting gap wasn't syntax.

It was judgment.

Consider these questions:

Should this state be owned by the ViewModel?

Should this operation be cancellable?

Is this cache global or feature-scoped?

Is this actor actually solving the problem?

What happens if the user changes the query 10 times in one second?

Should this request be retried?

What happens when the app goes into the background?

What happens under memory pressure?

Is this architecture appropriate for a 5-year-old production application?

These aren't simply code-generation questions.

They are system-design questions.

AI is very good at local reasoning

This is perhaps the biggest lesson from the experiment.

AI can look at:

func loadImage(url: URL)

and produce a reasonable implementation.

But the real question is:

What does this function mean to the rest of the system?

That requires broader context.

For example:

ImageLoader
     │
     ├── ProductCell
     │
     ├── SearchResults
     │
     ├── ProductDetails
     │
     ├── Recommendations
     │
     └── Wishlist

Now the question isn't:

"Can I load an image?"

It becomes:

"Who owns image loading?"

"Who owns caching?"

"Can these features share requests?"

"What is the lifetime of the cache?"

"What happens when the user logs out?"

"What happens when the CDN changes the image?"

That is a very different level of reasoning.

The AI doesn't need to be perfect to be incredibly useful

And this is where I think the conversation around AI coding often becomes unnecessarily binary.

The choices aren't:

AI replaces developers

or:

AI is useless

There is a much more interesting middle ground.

I increasingly think about AI coding agents like this:

                    Human
                      │
          ┌───────────┴───────────┐
          │                       │
      Judgment                Direction
          │                       │
          ▼                       ▼
       AI Agent ───────────→ Implementation
          │
          ▼
       Validation
          │
          ▼
        Human

The human doesn't necessarily need to write every line.

But the human needs to know:

Which lines should exist in the first place.

The role of the senior engineer changes

This is probably the bigger question behind the whole experiment.

If AI becomes capable of producing:

models
views
networking
tests
boilerplate
refactors
documentation

then the value of an engineer increasingly shifts toward:

Problem definition
       ↓
System design
       ↓
Constraints
       ↓
Trade-offs
       ↓
Validation
       ↓
Debugging
       ↓
Observability
       ↓
Product judgment

In other words:

The scarce skill may no longer be producing code. It may be knowing whether the code should exist.

AI-generated code needs a stronger definition of "done"

Traditionally, "done" might mean:

✓ Compiles
✓ Tests pass
✓ Feature works

For AI-assisted development, I think we need a more demanding definition:

✓ Compiles
✓ Tests pass
✓ Correct under concurrency
✓ Handles cancellation
✓ Handles failure
✓ Doesn't leak resources
✓ Doesn't introduce unnecessary complexity
✓ Meets architectural boundaries
✓ Has acceptable performance
✓ Is observable
✓ Is maintainable
✓ Doesn't violate security/privacy requirements

And perhaps most importantly:

✓ I understand why this code exists

That last check becomes incredibly important when the code wasn't written manually.

The uncomfortable question

Here's the part I've been thinking about the most.

If an AI agent can generate 80% of a feature...

What happens to the engineer?

I don't think the answer is:

"The engineer disappears."

I think the answer is:

The engineer moves up the abstraction stack.

Instead of spending most of the time typing:

struct ProductViewModel {
    ...
}

we may spend more time deciding:

What should ProductViewModel own?

What should it not own?

Where does intelligence belong?

What are the concurrency invariants?

What are the failure modes?

How do we know this system is correct?

And ironically, that could make deep engineering knowledge more valuable, not less.

Because if AI can write the obvious code, the differentiator becomes understanding the non-obvious code.

What I would do differently next time

After going through this exercise, I wouldn't simply ask an AI:

"Build this feature."

I'd give it a stronger engineering contract.

Something like:

ENGINEERING CONSTRAINTS

1. Use structured concurrency.
2. Cancellation must propagate correctly.
3. Do not use unstructured concurrency unless justified.
4. UI mutations must respect actor isolation.
5. Do not assume actor isolation eliminates logical races.
6. Network requests must be testable through dependency injection.
7. Duplicate requests for the same resource must be deduplicated.
8. Stale responses must never overwrite newer state.
9. Tests must cover failure and cancellation paths.
10. Do not introduce dependencies without justification.
11. Do not invent APIs.
12. Preserve existing architectural boundaries.
13. Explain architectural decisions before making large changes.

Notice what happened.

I didn't give the AI the implementation.

I gave it the engineering principles.

That's a much more interesting way of working with AI.

The future isn't "AI writes code"

I think that framing is already becoming too simplistic.

The more interesting future looks like:

                 Human
                   │
            Requirements
                   │
                   ▼
             Specification
                   │
                   ▼
               AI Agent
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
       Design     Code     Tests
          │        │        │
          └────────┼────────┘
                   ▼
               Validation
                   │
                   ▼
              Human review
                   │
                   ▼
              Production

The engineer becomes the person who establishes the boundaries within which the agent operates.

And that's a very different skill from simply knowing how to type Swift.

Final thoughts

So, can AI build a mobile application feature?

Absolutely.

Can it produce surprisingly good code?

Yes.

Can it save a developer a huge amount of time?

Without a doubt.

But can I look at a generated feature, see that it compiles, see that the tests pass, and immediately assume it is production-ready?

No.

And that's not necessarily a criticism of AI.

It's a reminder that software engineering has never really been about writing code.

Code is the output.

The difficult part has always been understanding the system.

Understanding state.

Understanding failure.

Understanding concurrency.

Understanding trade-offs.

Understanding what happens when the happy path disappears.

And perhaps most importantly:

Knowing what questions to ask before the bug happens.

That's the part I'm not ready to outsource.

Not yet.

One last thought

Maybe the future senior engineer isn't the person who can write the most code.

Maybe it's the person who can look at 10,000 lines generated by an AI agent and know which 10 lines are going to hurt you six months from now.

And if that's true, then learning how to work with AI isn't about becoming better at prompting.

It's about becoming a better engineer.

The Next Evolution of App Architecture: AI Just Introduced a New Orchestrator.

Vinayak G Hejib — Tue, 04 Aug 2026 16:19:18 +0000

Your architecture may not be dead but remember AI just introduced a new orchestrator

TL;DR: AI doesn't replace MVVM or anything compliant to it.
It introduces a new orchestration layer. ViewModels still excel at managing UI state, but when your app needs to reason, plan, use tools, and maintain context, an Agent becomes a natural addition to your architecture.

The Shift We Didn't See Coming

For over a decade, mobile architecture has focused on making UI code predictable and maintainable. Whether you follow MVC, MVP, VIPER, Clean Architecture, MVVM, or The Composable Architecture, the core idea has remained the same:

Separate concerns.
Keep business logic out of views.
Make data flow predictable.
Keep the UI reactive.

A typical modern iOS application looks something like this:

SwiftUI View
      │
      ▼
 ViewModel
      │
      ▼
 Repository
      │
      ▼
API / Database

The ViewModel receives user intent. The Repository fetches data. The View updates. Everything is deterministic, a button tap follows a predefined execution path.

This architecture has served us incredibly well. But AI-powered experiences are fundamentally different.

Traditional Apps Execute

Traditional applications execute instructions. For example, a user taps:

Search "Blue Jacket"

The flow is straightforward:

View → ViewModel → Repository → Search API → Products

Every component knows exactly what to do. There is almost no ambiguity.

AI Applications Need to Think Before They Act

Now consider a modern shopping experience. Instead of typing keywords, the user says:

"Find me a blue waterproof jacket under ₹5,000 that's suitable for a rainy trip to Scotland next week."

Notice something interesting: the app cannot immediately call an API. It first needs to understand what the user actually means. It must infer:

Waterproof
Suitable for cold weather
Budget constraint
Destination
Travel dates
Product availability
Ranking preferences

Before any API is called, reasoning has already begun.

One Request Can Become Multiple Tasks

Internally, that single sentence may become:

Understand intent
      ↓
Break problem into tasks
      ↓
Search products
      ↓
Check weather
      ↓
Understand destination climate
      ↓
Filter inventory
      ↓
Rank recommendations
      ↓
Generate explanation

That isn't something a traditional ViewModel was designed to orchestrate.

The ViewModel's Responsibility Hasn't Changed

Many developers immediately ask:

"Isn't an Agent just another ViewModel?"

It's a fair question. The answer is not quite.

A ViewModel's primary responsibility is still:

Manage screen state
Transform models into UI
Handle user interactions
Coordinate presentation logic

Those responsibilities remain exactly the same even in AI-powered applications. What changes is who coordinates reasoning.

Enter the Agent

Think of an Agent as an orchestration layer. Instead of simply forwarding requests, it decides how a request should be solved.

User Request
      ↓
   Agent
      ↓
  Reason
      ↓
   Plan
      ↓
Choose tools
      ↓
Execute tools
      ↓
Combine results
      ↓
Return response

The Agent isn't replacing your networking layer. It isn't replacing repositories. It isn't replacing MVVM. It is coordinating them.

A Better Mental Model

Instead of thinking:

ViewModel → Repository

Think:

View → ViewModel → Agent → Tools → Repositories → Backend → LLM

The ViewModel still owns UI state. The Agent owns intelligence.

What Exactly Does an Agent Do?

1. Understand Intent

The user's words are rarely explicit. Example:

"Something comfortable for office meetings."

The Agent converts vague language into structured requirements.

2. Planning

Complex requests are broken into multiple smaller tasks. Instead of:

Call API

It becomes:

Search products → Compare options → Remove unavailable items → Rank → Summarize

3. Tool Calling

Modern LLMs don't perform every action themselves instead, they invoke tools. Examples:

Product Search
Weather API
Calendar
Maps
Payment
Database
Inventory Service
Recommendation Engine

The Agent decides which tools should be executed and in what order.

4. Memory

Traditional apps remember UI state. Agents remember conversations. Example:

"Show me another one."

Another what? The Agent knows, because it remembers previous context.

5. Reasoning

Instead of returning raw API results:

Product A
Product B
Product C

It may produce:

"Product B is slightly more expensive, but it offers significantly better waterproofing, making it more suitable for your upcoming trip to Scotland."

That's reasoning.

Comparing Responsibilities

Traditional MVVM	AI-Native Architecture
ViewModel manages UI	ViewModel still manages UI
Repository fetches data	Repositories still fetch data
Business logic	Business logic still exists
API calls	APIs still exist
Static flow	Agent orchestrates dynamic workflows
Screen state	Conversation state
UI events	User intent
Deterministic execution	Planning and reasoning

Notice how almost everything remains. We're simply introducing another orchestration layer.

Where Should the Agent Live?

This is probably the most interesting architectural discussion. One possible design looks like this:

SwiftUI View
      ↓
  ViewModel
      ↓
    Agent
   ├── Memory
   ├── Planner
   ├── Tool Registry
   ├── Prompt Builder
   └── LLM Client
      ↓
 Repositories
      ↓
Backend APIs

This keeps concerns well separated. The ViewModel doesn't suddenly become responsible for prompts, memory, or tool execution.

What About Clean Architecture?

If you're using Clean Architecture, the Agent naturally belongs in the domain layer; think of it as another domain service. Your ViewModel simply delegates complex AI tasks:

ViewModel → AgentService → Repositories → Tools → LLM

Repositories continue to own data access. The Agent owns orchestration.

Why This Matters

As AI features become more common, we're moving beyond simple request-response interactions. Applications are beginning to:

Think
Plan
Reason
Remember
Decide
Explain

That introduces responsibilities that traditional UI architectures were never intended to handle. Trying to push all of that into a ViewModel eventually leads to massive classes with mixed responsibilities. Adding an Agent layer keeps each component focused on what it does best.

A Practical Example

Imagine building an AI-powered travel assistant. The user asks:

"Plan my weekend trip to Coorg with good vegetarian restaurants, pleasant weather, and hotels under ₹6,000."

An Agent might:

Understand the destination.
Fetch weather forecasts.
Search hotels.
Search restaurants.
Rank options.
Remove unavailable hotels.
Generate an itinerary.
Explain why each recommendation was chosen.

Your ViewModel doesn't need to know how those eight steps happen. It simply receives a structured response and updates the UI. That's a much cleaner separation of responsibilities.

Looking Ahead

Just as networking logic gradually moved out of ViewControllers and into repositories and services, AI orchestration deserves its own home.

The ViewModel remains responsible for presentation.
The Repository remains responsible for data.
The Backend remains responsible for persistence.
The LLM remains responsible for reasoning.
The Agent becomes responsible for coordinating the entire workflow.

Final Thoughts

I don't believe MVVM is becoming obsolete. In fact, it's still one of the best ways to manage presentation logic in SwiftUI.

What is changing isn't the UI architecture, it's the layer above it.

The future of intelligent applications isn't about replacing ViewModels. It's about introducing an orchestration layer capable of understanding intent, planning workflows, invoking tools, maintaining context, and delivering intelligent experiences.

The apps we build tomorrow won't just respond to user actions. They'll collaborate with users to accomplish goals. And that requires more than another ViewModel -> it requires an Agent.

What do you think?

If you were designing an AI-first iOS application today:

Would you extend your existing ViewModel?
Would you introduce a dedicated Agent layer?
Or do you see another architectural pattern emerging?

I'd love to hear how you're approaching AI-native application architecture.

Beyond Portrait and Landscape: Building Truly Resizable iOS Apps

Vinayak G Hejib — Fri, 03 Jul 2026 09:56:33 +0000

Apple: "Your app supports Portrait and Landscape, right?"

Also Apple: "Cute. Now make it work at literally any window size."

_
Why every iOS developer needs to rethink layout architecture in the era of adaptive windows.

Introduction

You've spent months perfecting your iPhone application.

It looks fantastic on the iPhone SE, the iPhone 16, the Pro Max, and iPad. You ship. Everything works.

Then Apple pushes the interaction model further freeform resizing, Stage Manager, external displays, floating windows and users start dragging your app's window to whatever size fits their workflow.

Suddenly, it becomes like in image below:

Nothing technically breaks. No crash, no constraint warning in the console. But everything feels broken because the layout was designed for screens, not windows, and that distinction is about to matter a lot more than it used to.

For over fifteen years, iOS developers have thought in terms of devices: iPhone, iPad, portrait, landscape. The next era of Apple platforms demands a different mental model one built around available space, not device identity.

This article walks through that mindset shift and builds a production-ready, adaptive product detail page (PDP) that gracefully reflows as its window changes size including a custom SwiftUI Layout implementation you can drop straight into a real app.

Why This Matters Now

For most of iOS history, your app's canvas was effectively fixed at runtime. Rotation gave you two known layouts, and that was the extent of your "adaptive" surface area.

That assumption is breaking down. Modern Apple platforms increasingly embrace:

Split View and Slide Over on iPad
Stage Manager, with genuinely freeform window sizing
External and wireless displays
Multiwindow scenes on iPadOS and visionOS
Continuously variable widths, not two or three fixed states

Users don't think about which device they're on. They think about whether your app behaves naturally in whatever space they've given it. Supporting "smaller widths" as an edge case isn't enough anymore the goal is continuous adaptation across the entire width spectrum, not just graceful degradation at the extremes.

The Biggest Mistake Most Apps Make

Here's the pattern nearly every app reaches for first:

if horizontalSizeClass == .compact {
    ProductMobileView()
} else {
    ProductTabletView()
}

It works until it doesn't. horizontalSizeClass collapses an enormous range of real widths into exactly two buckets. But picture a window resizing continuously:

390 → 410 → 455 → 512 → 575 → 612 → 640 → 700 → 790 → 850

Your UI doesn't have two states. It has hundreds. Binary size-class branching leaves a massive, awkward gap between "phone" and "tablet" where the layout is neither optimized nor intentional it's just whichever of the two views got picked, stretched or squeezed to fit.

The fix isn't a third if branch. It's abandoning device-based branching as the primary layout mechanism altogether.

The Example We'll Build

We'll design a realistic e-commerce Product Detail Page (PDP) the kind you'd find in any modern retail app containing:

Gallery
Product name, brand, rating
Price
Colour picker / size picker
Wishlist action
Delivery information
Description
Reviews
Recommended products

This isn't a toy example. It's representative of the layout complexity retail apps deal with daily, where imagery, metadata, actions, and recommendation carousels all have to coexist and reflow together.

Starting Point: The Naïve Layout

Most implementations look like this:

ScrollView {
    VStack(spacing: 24) {
        ProductGallery()
        ProductInformation()
        SizeSelector()
        ColorSelector()
        AddToBagButton()
        Description()
        Reviews()
        Recommendations()
    }
}

This is fine on a phone. But as available width grows, it becomes wasteful long single-column scrolling, oceans of whitespace on either side, and a gallery that never gets to breathe next to the content it's describing.

Thinking in Layout Zones, Not Devices

Instead of asking "Am I on an iPhone?", ask "How much horizontal space do I actually have right now?"

This is the fundamental shift. Rather than branching on device identity, define logical width ranges that describe how content should be organized:

Width Range	Experience
Narrow (< ~600pt)	Single-column layout optimized for constrained space
Medium (~600–900pt)	Two-column layout gallery and details side by side
Wide (> ~900pt)	Multi-pane layout introducing recommendations or supplemental panes

These are guidelines, not hard device categories the interface adapts continuously as the window changes, and the breakpoints themselves should be tuned against real content, not memorized from a spec sheet.

Visual Evolution

Notice what doesn't change: the content. Only its organization shifts. That's the tell of a well-architected adaptive layout the data and view models stay identical; only composition changes.

Architecture Before Code

A common anti-pattern is embedding layout decisions directly inside views:

if width > 700 {
    HStack { /* ... */ }
} else {
    VStack { /* ... */ }
}

This works initially but rots fast every screen ends up with its own bespoke breakpoint logic, and nobody remembers why 700 was chosen versus 680.

A more scalable approach separates layout decision-making from presentation:

enum LayoutStyle {
    case narrow
    case medium
    case wide

    init(width: CGFloat) {
        switch width {
        case ..<600:   self = .narrow
        case 600..<900: self = .medium
        default:       self = .wide
        }
    }
}

A single source of truth determines the current LayoutStyle from available width; the view hierarchy simply reacts to that style. This keeps your UI declarative, testable, and far easier to evolve you can unit test LayoutStyle(width:) in isolation without spinning up a single view.

Reading Width the Right Way: GeometryReader vs. Container Values

GeometryReader is the classic tool here, but it's a blunt instrument it greedily fills its parent and ignores the natural sizing of its children, which can quietly break layouts that worked fine before you added it.

struct AdaptiveProductPage: View {
    var body: some View {
        GeometryReader { proxy in
            let style = LayoutStyle(width: proxy.size.width)
            ProductPageContent(style: style)
        }
    }
}

For most PDP-style screens this is perfectly adequate, since the page is already the root of its own scroll context. But if you're nesting adaptive components inside other adaptive components, prefer reading size via .onGeometryChange(for:of:action:) (iOS 18+) or a PreferenceKey-based width reporter, so children don't accidentally force their parents to expand:

struct WidthReader<Content: View>: View {
    @State private var width: CGFloat = 0
    let content: (CGFloat) -> Content

    var body: some View {
        content(width)
            .background {
                GeometryReader { proxy in
                    Color.clear
                        .preference(key: WidthKey.self, value: proxy.size.width)
                }
            }
            .onPreferenceChange(WidthKey.self) { width = $0 }
    }
}

private struct WidthKey: PreferenceKey {
    static var defaultValue: CGFloat = 0
    static func reduce(value: inout CGFloat, nextValue: () -> CGFloat) {
        value = nextValue()
    }
}

Composing the Layout

With LayoutStyle established, the top-level view becomes a simple switch over composition, not appearance:

struct ProductPageContent: View {
    let style: LayoutStyle

    var body: some View {
        ScrollView {
            switch style {
            case .narrow:
                narrowLayout
            case .medium:
                mediumLayout
            case .wide:
                wideLayout
            }
        }
    }

    private var narrowLayout: some View {
        VStack(spacing: 24) {
            ProductGallery()
            ProductInformation()
            SizeSelector()
            AddToBagButton()
            Description()
            Reviews()
            Recommendations()
        }
    }

    private var mediumLayout: some View {
        VStack(spacing: 24) {
            HStack(alignment: .top, spacing: 20) {
                ProductGallery()
                VStack(alignment: .leading, spacing: 16) {
                    ProductInformation()
                    SizeSelector()
                    AddToBagButton()
                }
            }
            Description()
            Reviews()
        }
    }

    private var wideLayout: some View {
        VStack(spacing: 24) {
            HStack(alignment: .top, spacing: 24) {
                ProductGallery()
                    .frame(maxWidth: .infinity)
                VStack(alignment: .leading, spacing: 16) {
                    ProductInformation()
                    SizeSelector()
                    AddToBagButton()
                }
                .frame(maxWidth: 340)
                Recommendations()
                    .frame(maxWidth: 280)
            }
            Reviews()
        }
    }
}

Each component ProductGallery, ProductInformation, SizeSelector, Recommendations knows nothing about where it will be placed. It only renders its own content. The composition layer decides arrangement. This separation of concerns means you can reorder, add, or remove regions without touching business logic or view models.

Bonus: A Custom `Layout` for True Fluidity

Discrete breakpoints (narrow / medium / wide) are a huge improvement over size-class branching, but they're still steps, not a continuum. For cases where you want genuinely fluid reflow say, a tag list or a filter chip row that should wrap based on exact available width SwiftUI's Layout protocol (iOS 16+) is the right tool:

struct FlowLayout: Layout {
    var spacing: CGFloat = 8

    func sizeThatFits(
        proposal: ProposedViewSize,
        subviews: Subviews,
        cache: inout ()
    ) -> CGSize {
        let width = proposal.width ?? .infinity
        var rowWidth: CGFloat = 0
        var totalHeight: CGFloat = 0
        var rowHeight: CGFloat = 0

        for subview in subviews {
            let size = subview.sizeThatFits(.unspecified)
            if rowWidth + size.width > width {
                totalHeight += rowHeight + spacing
                rowWidth = 0
                rowHeight = 0
            }
            rowWidth += size.width + spacing
            rowHeight = max(rowHeight, size.height)
        }
        totalHeight += rowHeight
        return CGSize(width: width, height: totalHeight)
    }

    func placeSubviews(
        in bounds: CGRect,
        proposal: ProposedViewSize,
        subviews: Subviews,
        cache: inout ()
    ) {
        var x = bounds.minX
        var y = bounds.minY
        var rowHeight: CGFloat = 0

        for subview in subviews {
            let size = subview.sizeThatFits(.unspecified)
            if x + size.width > bounds.maxX {
                x = bounds.minX
                y += rowHeight + spacing
                rowHeight = 0
            }
            subview.place(at: CGPoint(x: x, y: y), proposal: .unspecified)
            x += size.width + spacing
            rowHeight = max(rowHeight, size.height)
        }
    }
}

Drop this in for size pickers, filter chips, or delivery-option badges, and they'll wrap naturally at any width no breakpoint table required. Layout is also cheap: unlike GeometryReader, it participates properly in SwiftUI's normal sizing negotiation instead of overriding it.

Don't Forget `ViewThatFits`

For simpler cases swapping a compact control for a full one when space runs out ViewThatFits (iOS 16+) is often all you need, and it's far less code than manual width math:

ViewThatFits(in: .horizontal) {
    HStack { Text("Add to Bag"); Image(systemName: "bag") }
    Image(systemName: "bag")
}

SwiftUI tries each option in order and renders the first one that fits genuinely elegant for toolbar-style controls and buttons that need to shed content before they shed usefulness.

Preparing an Existing App

If your app already ships to production, a full rewrite isn't necessary. A gradual migration tends to work best:

Audit every place layout branches on device checks or orientation.
Replace those checks with width-driven LayoutStyle decisions.
Extract reusable UI sections (gallery, info block, recommendations) into standalone components with no layout opinions of their own.
Introduce an adaptive composition layer that arranges those components differently per LayoutStyle.
Test by resizing continuously not just by toggling portrait/landscape in the simulator.

This incremental path minimizes risk while steadily raising the ceiling on how well your app handles space it wasn't originally designed for.

Testing Adaptive Layouts Properly

A layout that "works" only at the exact widths you happened to test isn't adaptive it's coincidentally correct. A few practices that catch real issues early:

Xcode Previews at multiple fixed widths. Use .previewLayout(.fixed(width:height:)) across a spread of values (e.g. 320, 428, 600, 834, 1194) rather than relying on device presets alone.
Resize the simulator window live rather than only rotating it this is the one Split View and Stage Manager actually exercise.
Snapshot tests at breakpoint boundaries, not just breakpoint centers bugs cluster at the transition points (599pt vs. 601pt), not in the middle of a range.
Dynamic Type + resizing together. A layout that survives resizing but breaks under XXL Dynamic Type isn't done test both axes simultaneously, since real users combine them.

Accessibility Benefits

Designing for resizing pays off beyond windowing scenarios. Users who increase Dynamic Type, enable Display Zoom, or work in Split View are already changing the effective space available to your app from your layout code's perspective, that's indistinguishable from a user resizing a window.

An interface built to gracefully reorganize itself across widths is, almost as a side effect, more resilient to larger text, alternative input methods, and whatever form factor Apple ships next. Adaptive design and accessible design reinforce each other; you rarely get one without the other.

Conclusion

For years, iOS development revolved around screens. We memorized device dimensions, size classes, and orientation pairs.

The next evolution asks for a different habit of mind not devices, but space; not portrait versus landscape, but fluid layouts that reorganize themselves intelligently as the width beneath them changes.

Build from adaptable, layout-agnostic components rather than fixed screen assumptions, and your app becomes resilient not just to today's device lineup, but to whatever Apple introduces next.

The question is no longer "Does my app support iPhone and iPad?"

It's "Can my interface make the best use of whatever space it's given?"

That shift is what separates an app that merely runs everywhere from one that actually feels at home everywhere.

Building an AI-Powered Git Commit & PR Assistant

Vinayak G Hejib — Fri, 15 May 2026 12:31:11 +0000

Every engineer loves writing code(On a good note, I believe 😉).

Not every engineer loves writing:

commit messages
PR descriptions
testing notes
release summaries
sprint updates

In fast-moving teams, these things usually become an afterthought.

And honestly, it shows.

We’ve all seen commits like:

fixed the bug 
changes into MyView file
final-final-fix
ui updates on list view

Or some PR descriptions that simply say:

“Please review.”

The bigger the codebase gets, the worse this problem becomes.

In modular enterprise applications with multiple teams working in parallel, poor PR communication slows reviews, increases confusion, and creates release risks.

So I started building something for myself:

An AI-powered Git assistant that could understand code changes and automatically generate:

meaningful commit messages
structured PR summaries
testing notes
risk indicators
release notes

And I wanted it to work offline.

Why I Built It

Initially, this started as a tiny productivity experiment.

I simply wanted:

cleaner commit messages
less repetitive writing
faster PR creation

But after using it for a few weeks, I realized something interesting:

The real value wasn’t automation.

It was reducing cognitive overhead.

After spending hours solving architectural or UI problems, context-switching into documentation mode becomes mentally expensive.

The assistant helped bridge that gap.

High-Level Architecture

The workflow is actually pretty straightforward.

Git Diff
   ↓
File Analysis
   ↓
Context Extraction
   ↓
Prompt Generation
   ↓
Local LLM
   ↓
Commit + PR Output

The difficult part was making the outputs:

concise
trustworthy
reviewer-friendly
non-robotic

Extracting Git Changes

The first version simply passed the raw git diff directly into the model.

That worked terribly.

Large diffs:

exceeded context windows
produced noisy summaries
generated inaccurate PR descriptions

So I added preprocessing layers.

Example:

import subprocess

diff = subprocess.check_output(
    ["git", "diff", "--cached"],
    text=True
)

print(diff[:1000])

But raw diffs were too noisy.

So the assistant started:

grouping changes by module
ignoring formatting-only modifications
detecting API changes
identifying added vs removed logic

Filtering Noise

One surprisingly important improvement was removing low-signal changes.

For example:

def should_ignore(line):
    ignored_patterns = [
        "import ",
        "swiftlint",
        "whitespace"
    ]

    return any(p in line for p in ignored_patterns)

This dramatically improved the quality of generated summaries.

Prompt Engineering Was Harder Than Expected

One thing I underestimated was how sensitive outputs were to prompting.

A vague prompt generated vague PRs.

An overly detailed prompt generated essays nobody wanted to read.

Eventually I settled on prompts focused on:

behavioral changes
architectural impact
reviewer clarity
testing implications

Example:

prompt = f"""
You are an experienced software engineer reviewing a pull request.

Generate:
1. concise commit message
2. PR summary
3. testing notes
4. possible risks

Ignore formatting-only changes.

Git Diff:
{processed_diff}
"""

The single line:

Ignore formatting-only changes

improved results massively.

Running AI Offline

This became the most interesting part of the project.

I specifically wanted:

local-first workflows
zero cloud dependency
privacy for enterprise repositories
low latency
no API costs

Sending proprietary diffs to external APIs was something I wanted to avoid entirely.

So I experimented with:

Ollama
llama.cpp
quantized local models
Apple Silicon optimizations

Calling the local model was surprisingly simple:

import requests

response = requests.post(
    "http://localhost:11434/api/generate",
    json={
        "model": "mistral",
        "prompt": prompt,
        "stream": False
    }
)

print(response.json()["response"])

For commit generation and PR summaries, smaller local models were often more than sufficient.

The Most Difficult Problems

The difficult part wasn’t generating text.

It was generating trustworthy text.

Hallucinated Features

Sometimes the model inferred functionality that didn’t exist.

Especially when refactors looked similar to feature additions.

To reduce this:

prompts became shorter
context became more constrained
diffs were chunked intelligently

Huge Enterprise Diffs

Large modular repositories create massive PRs.

Passing entire diffs into the model quickly became inefficient.

So I added:

chunking
module prioritization
high-signal file detection

Example:

MAX_CHUNK_SIZE = 4000

chunks = [
    diff[i:i + MAX_CHUNK_SIZE]
    for i in range(0, len(diff), MAX_CHUNK_SIZE)
]

Robotic Language

Early outputs sounded overly AI-generated.

Too many phrases like:

“enhanced functionality”
“optimized architecture”
“improved user experience”

Real engineers don’t write like that.

So prompts were tuned toward:

concise engineering tone
direct wording
reviewer readability

Features That Became Surprisingly Useful

The project slowly evolved beyond commit generation.

PR Risk Detection

The assistant flags:

shared module changes
navigation flow modifications
authentication updates
API contract changes

Automatic Testing Notes

Example output:

Tested:
- Login flow
- Session recovery
- Token refresh handling
- Deep link navigation

This alone ended up saving a surprising amount of time.

Release Notes Generation

The assistant can summarize:

bug fixes
user-facing improvements
technical refactors

directly from merged commits.

Example Output

Before

fixed auth issue

After

Refactor authentication recovery flow to support token refresh handling during session expiration

What I Learned

The biggest realization from this project was:

AI works best when augmenting engineering workflows, not replacing engineering decisions.

The assistant is not writing code for me.

It is removing repetitive cognitive work around:

communication
formatting
summarization
workflow overhead

And that turns out to be incredibly valuable.

Future Improvements

There’s still a lot I want to explore:

Xcode integration
Git hook automation
reviewer suggestions
Jira linking
architecture drift detection
PR quality scoring
Slack release summaries

I also want to experiment with embedding-based code understanding for better long-term context awareness.

Final Thoughts

Building AI tooling for toy projects is easy.

Building AI tooling that works reliably in large modular enterprise repositories is a completely different challenge.

But that’s also what makes it exciting.

What started as a small commit-message helper slowly evolved into a developer workflow copilot that now saves me time almost every day.

And honestly, this feels like just the beginning of what local AI can do for software engineering workflows.

# 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. 😉