When I first started building apps with SwiftUI, navigation felt almost too easy. Add a NavigationLink, use a .sheet, throw in a fullScreenCover, and the next screen appears. For a small project, that simplicity is one of SwiftUI’s biggest strengths. You can move quickly without creating navigation controllers, delegates, or a lot of setup code.

The problem usually appears later.

As the app grows, one view starts managing a navigation path, another view controls a sheet, a login screen decides when the entire app should switch to the main flow, and a checkout screen knows exactly which step comes next. Before long, navigation logic is scattered across views, Boolean properties, tab selections, and conditionals.

The app still works, but it becomes harder to answer a simple question: where is the flow actually controlled?

This article is part of my ongoing iOS development notes where I write about problems I run into while building apps, so other developers can avoid repeating the same mistakes. I previously wrote SwiftUI State in iOS: A Practical Guide, where I explained how state ownership can either keep a SwiftUI app clean or make it confusing. I also wrote SwiftUI Navigation in iOS: A Practical Guide, which covers NavigationStack, programmatic navigation, sheets, and navigation destinations. Another related article is 10 Common Mistakes Every iOS Developer Should Avoid: Learned the Hard Way. If I had to add one more mistake to that list, it would be letting every SwiftUI view control its own part of the app flow.

That is where a coordinator, or router, becomes useful.

The Problem With Navigation Inside Views

Imagine we are building a shopping app. It starts with a product list, and tapping a product opens a detail screen.

struct ProductListView: View {
    let products: [Product]

var body: some View {
        List(products) { product in
            NavigationLink(value: product) {
                Text(product.name)
            }
        }
        .navigationTitle("Products")
    }
}

There is nothing wrong with this. For simple navigation, NavigationLink is often exactly what we need.

Now the product list also needs to open the cart, show filters, present login, and start checkout.

struct ProductListView: View {
    let products: [Product]

@State private var showingCart = false
    @State private var showingFilters = false
    @State private var showingLogin = false
    @State private var showingCheckout = false
    var body: some View {
        List(products) { product in
            NavigationLink(value: product) {
                Text(product.name)
            }
        }
        .toolbar {
            Button("Cart") {
                showingCart = true
            }
        }
        .sheet(isPresented: $showingCart) {
            CartView()
        }
        .sheet(isPresented: $showingFilters) {
            FilterView()
        }
        .sheet(isPresented: $showingLogin) {
            LoginView()
        }
        .fullScreenCover(isPresented: $showingCheckout) {
            CheckoutView()
        }
    }
}

The view is now doing much more than displaying products. It knows which screens exist, how they should be presented, and which part of the app should appear next. If checkout requires login, the view may also start checking authentication state. If the same cart screen can be opened from the home tab, product detail screen, and profile screen, the same navigation decision gets repeated in several places.

A SwiftUI view should usually be responsible for showing the interface and reporting what the user did. It should not need to understand the entire journey through the application.

Coordinator or Router?

The Coordinator Pattern is commonly associated with UIKit, where a coordinator creates view controllers and pushes them onto a navigation controller. SwiftUI works differently because navigation is driven by state.

In SwiftUI, a coordinator often looks more like a router. It owns navigation state such as the current path, the presented sheet, the selected tab, or the active app flow. Views report actions, the router updates the navigation state, and SwiftUI renders the correct destination.

Some developers call this object a coordinator. Others call it a router or navigation store. I do not think the name matters as much as the responsibility.

The main idea is simple:

Views describe the interface. The router owns navigation decisions.

Creating Typed Routes

A clean way to begin is by defining the destinations that can appear in the app.

import Foundation

struct Product: Identifiable, Hashable {
    let id: UUID
    let name: String
    let price: Decimal
}
enum AppRoute: Hashable {
    case productDetail(productID: UUID)
    case cart
    case settings
}

I prefer typed routes because they make the navigation structure easy to understand. Instead of pushing random values into a NavigationPath, the app has a clear list of supported destinations.

Notice that the product detail route stores the product ID instead of the full product. This keeps the route lightweight and allows the destination to load fresh data when it appears.

Building the Router

For an app supporting iOS 17 or later, we can use the Observation framework.

import Observation

@MainActor
@Observable
final class AppRouter {
    var path: [AppRoute] = []
    func showProduct(_ product: Product) {
        path.append(.productDetail(productID: product.id))
    }
    func showCart() {
        path.append(.cart)
    }
    func showSettings() {
        path.append(.settings)
    }
    func goBack() {
        guard !path.isEmpty else { return }
        path.removeLast()
    }
    func popToRoot() {
        path.removeAll()
    }
}

The router now owns the navigation path. A view no longer needs to know how the destination is created or how the stack should be changed. It only calls the appropriate action.

router.showCart()

That may look like a small abstraction, but it gives us one place to change the behavior later. For example, if opening the cart should require login, we can add that rule inside the navigation layer instead of updating every button that opens the cart.

Connecting the Router to NavigationStack

The root view owns the router and maps each route to a destination.

import SwiftUI

struct AppRootView: View {
    @State private var router = AppRouter()
    let products: [Product]
    let productService: ProductServiceProtocol
    var body: some View {
        @Bindable var router = router
        NavigationStack(path: $router.path) {
            ProductListView(products: products)
                .navigationDestination(for: AppRoute.self) { route in
                    switch route {
                    case .productDetail(let productID):
                        ProductDetailView(
                            viewModel: ProductDetailViewModel(
                                productID: productID,
                                productService: productService
                            )
                        )
                    case .cart:
                        CartView()
                    case .settings:
                        SettingsView()
                    }
                }
        }
        .environment(router)
    }
}

This root view becomes the place where destinations are built and dependencies are passed. The product list does not need to know that ProductDetailView uses a view model or that the view model needs a service. It only needs to report which product the user selected.

The product list becomes much simpler.

struct ProductListView: View {
    @Environment(AppRouter.self) private var router

    let products: [Product]
    var body: some View {
        List(products) { product in
            Button {
                router.showProduct(product)
            } label: {
                HStack {
                    Text(product.name)
                    Spacer()
                    Image(systemName: "chevron.right")
                        .foregroundStyle(.secondary)
                }
            }
        }
        .navigationTitle("Products")
        .toolbar {
            Button {
                router.showCart()
            } label: {
                Image(systemName: "cart")
            }
        }
    }
}

The view handles the user action. The router handles what that action means for navigation.

That separation is the real value of the pattern.

Managing Sheets Without Many Boolean Properties

One of the first warning signs in a SwiftUI view is a growing collection of Boolean presentation properties.

@State private var showingLogin = false
@State private var showingFilters = false
@State private var showingProfile = false
@State private var showingSettings = false

This works, but it becomes difficult to manage as the number of sheets grows. It also allows multiple values to become true even though only one sheet should normally be visible.

A typed sheet route is usually cleaner.

enum SheetRoute: Identifiable {
    case login
    case filters
    case profile
    case settings
    var id: String {
        String(describing: self)
    }
}

The router can own one optional presentation.

@MainActor
@Observable
final class AppRouter {
    var path: [AppRoute] = []
    var presentedSheet: SheetRoute?

    func showProduct(_ product: Product) {
        path.append(.productDetail(productID: product.id))
    }
    func showCart() {
        path.append(.cart)
    }
    func showLogin() {
        presentedSheet = .login
    }
    func showFilters() {
        presentedSheet = .filters
    }
    func dismissSheet() {
        presentedSheet = nil
    }
}

The root view handles sheet destinations in one place.

.sheet(item: $router.presentedSheet) { sheet in
    switch sheet {
    case .login:
        LoginView()
    case .filters:
        FilterView()
    case .profile:
        ProfileView()
    case .settings:
        SettingsView()
    }
}

Now the app has one source of truth for sheet presentation instead of several unrelated Boolean values.

Coordinating Authentication

The pattern becomes even more useful when the app has major flows such as loading, onboarding, authentication, and the main interface.

enum AppFlow {
    case loading
    case onboarding
    case authentication
    case main
}

An app coordinator can own the current flow.

@MainActor
@Observable
final class AppCoordinator {
    var flow: AppFlow = .loading
    private let sessionService: SessionServiceProtocol
    private let onboardingService: OnboardingServiceProtocol
    init(
        sessionService: SessionServiceProtocol,
        onboardingService: OnboardingServiceProtocol
    ) {
        self.sessionService = sessionService
        self.onboardingService = onboardingService
    }
    func start() {
        if !onboardingService.hasCompletedOnboarding {
            flow = .onboarding
        } else if sessionService.isLoggedIn {
            flow = .main
        } else {
            flow = .authentication
        }
    }
    func didCompleteOnboarding() {
        flow = sessionService.isLoggedIn ? .main : .authentication
    }
    func didLogin() {
        flow = .main
    }
    func didLogout() {
        flow = .authentication
    }
}

The app container displays the correct root based on that flow.

struct AppContainerView: View {
    @State private var coordinator: AppCoordinator

init(
        sessionService: SessionServiceProtocol,
        onboardingService: OnboardingServiceProtocol
    ) {
        _coordinator = State(
            initialValue: AppCoordinator(
                sessionService: sessionService,
                onboardingService: onboardingService
            )
        )
    }
    var body: some View {
        Group {
            switch coordinator.flow {
            case .loading:
                ProgressView()
            case .onboarding:
                OnboardingView {
                    coordinator.didCompleteOnboarding()
                }
            case .authentication:
                LoginView {
                    coordinator.didLogin()
                }
            case .main:
                MainTabView {
                    coordinator.didLogout()
                }
            }
        }
        .task {
            coordinator.start()
        }
    }
}

The login view does not replace the root interface itself. It reports that login succeeded. The coordinator decides that the main flow should now appear.

This keeps authentication flow out of individual screens and gives the application one clear place where root-level transitions happen.

Using a Separate Coordinator for Checkout

A multi-step flow is another good use case.

A checkout process may include address, payment, review, and confirmation. Without a coordinator, each screen may start knowing which screen comes next. The address view opens payment, payment opens review, and review opens confirmation.

A separate checkout coordinator keeps that journey together.

enum CheckoutRoute: Hashable {
    case address
    case payment
    case review
    case confirmation
}

@MainActor
@Observable
final class CheckoutCoordinator {
    var path: [CheckoutRoute] = []



private(set) var address: ShippingAddress?
    private(set) var paymentMethod: PaymentMethod?
    func start() {
        path = [.address]
    }
    func didEnterAddress(_ address: ShippingAddress) {
        self.address = address
        path.append(.payment)
    }
    func didSelectPayment(_ paymentMethod: PaymentMethod) {
        self.paymentMethod = paymentMethod
        path.append(.review)
    }
    func didConfirmOrder() {
        path.append(.confirmation)
    }
}

Each screen reports what the user completed, and the coordinator moves the flow forward.

struct CheckoutContainerView: View {
    @State private var coordinator = CheckoutCoordinator()

    var body: some View {
          @Bindable var coordinator = coordinator
          NavigationStack(path: $coordinator.path) {
              Color.clear
                  .navigationDestination(for: CheckoutRoute.self) { route in
                      switch route {
                      case .address:
                          AddressView { address in
                              coordinator.didEnterAddress(address)
                          }
                      case .payment:
                          PaymentView { paymentMethod in
                              coordinator.didSelectPayment(paymentMethod)
                          }
                      case .review:
                          if let address = coordinator.address,
                             let paymentMethod = coordinator.paymentMethod {
                              ReviewOrderView(
                                  address: address,
                                  paymentMethod: paymentMethod
                              ) {
                                  coordinator.didConfirmOrder()
                              }
                          }
                      case .confirmation:
                          OrderConfirmationView()
                      }
                  }
          }
          .task {
              coordinator.start()
          }
      }
}

If we later add a coupon screen between address and payment, the checkout coordinator changes. The individual views do not need to understand the new order of the flow.

Coordinator Pattern With MVVM

The Coordinator Pattern works well with MVVM because each layer has a clear job.

The view displays state and reports user actions. The view model handles screen-specific logic and data loading. Services or repositories handle external data. The router handles navigation.

For example, a product detail view model may load the product.

@MainActor
@Observable
final class ProductDetailViewModel {
    private let productID: UUID
    private let productService: ProductServiceProtocol

private(set) var product: Product?
    private(set) var isLoading = false
    private(set) var errorMessage: String?
    init(
        productID: UUID,
        productService: ProductServiceProtocol
    ) {
        self.productID = productID
        self.productService = productService
    }
    func loadProduct() async {
        isLoading = true
        defer { isLoading = false }
        do {
            product = try await productService.product(withID: productID)
        } catch {
            errorMessage = error.localizedDescription
        }
    }
}

The view uses the view model for data and the router for navigation.

struct ProductDetailView: View {
    @State private var viewModel: ProductDetailViewModel
    @Environment(AppRouter.self) private var router

    init(viewModel: ProductDetailViewModel) {
        _viewModel = State(initialValue: viewModel)
    }
    var body: some View {
        Group {
            if viewModel.isLoading {
                ProgressView()
            } else if let product = viewModel.product {
                VStack(spacing: 16) {
                    Text(product.name)
                        .font(.title)
                    Text(
                        product.price,
                        format: .currency(code: "USD")
                    )
                    Button("Open Cart") {
                        router.showCart()
                    }
                }
            } else if let errorMessage = viewModel.errorMessage {
                Text(errorMessage)
            }
        }
        .task {
            await viewModel.loadProduct()
        }
    }
}

The view model does not control navigation, and the router does not load product data. That separation keeps both objects focused.

Testing Navigation Becomes Easier

Because navigation is stored as state, it can be tested without rendering the full SwiftUI hierarchy.

import XCTest

@MainActor
final class AppRouterTests: XCTestCase {
    func testShowProductAddsProductRoute() {
        let router = AppRouter()
        let product = Product(
            id: UUID(),
            name: "iPhone Case",
            price: 29.99
        )
        router.showProduct(product)
        XCTAssertEqual(
            router.path,
            [.productDetail(productID: product.id)]
        )
    }
    func testPopToRootClearsNavigation() {
        let router = AppRouter()
        let product = Product(
            id: UUID(),
            name: "MacBook Sleeve",
            price: 49.99
        )
        router.showProduct(product)
        router.showCart()
        router.popToRoot()
        XCTAssertTrue(router.path.isEmpty)
    }
}

The test focuses on the navigation decision itself. It does not need to inspect a private Boolean property or simulate a complete interface.

Common Mistakes

The Coordinator Pattern can help, but it can also be overdone.

The first mistake is creating one enormous global router that controls every stack, sheet, tab, alert, and feature. That router eventually becomes the SwiftUI version of a massive view controller. Major flows should usually have their own navigation owner, such as an app coordinator, a main-tab coordinator, and a checkout coordinator.

The second mistake is putting business logic inside the router. A router can decide where the app goes, but it should not perform network requests, validate forms, calculate prices, or transform API responses. That work belongs in view models and services.

The third mistake is using a global singleton such as AppRouter.shared. It is convenient, but it creates hidden dependencies and shared mutable state that make previews and tests harder. Passing the router through the environment usually keeps ownership clearer.

The fourth mistake is creating a coordinator for every screen. A simple static page may only need a NavigationLink. Use the pattern when it removes actual complexity, not because every view must follow the same architecture.

When Should You Use It?

I would consider a coordinator or router when navigation is repeated across several views, the app has authentication or onboarding, a feature has multiple steps, destinations require several dependencies, tabs need separate navigation histories, or deep links must reach specific screens.

I would not force it into a small app with two or three simple destinations. Direct SwiftUI navigation is often cleaner in that situation.

The pattern becomes valuable when the navigation logic starts becoming harder to follow than the screens themselves.

Final Thoughts

The Coordinator Pattern in SwiftUI is not exactly the same as the UIKit version. Instead of pushing view controllers, we update navigation state using NavigationStack, typed routes, sheets, tab selection, and root-flow state.

The goal, however, is the same.

Views should not need to understand the entire application journey.

A product view can say that the user selected a product. A login view can say that authentication succeeded. An address view can say that the user finished entering an address.

The coordinator decides what happens next.

For me, this pattern started making sense only after navigation logic became scattered across several views. That is usually how architecture concepts become useful. They feel unnecessary until the code starts showing you the problem they were designed to solve.

Start small. Move one growing navigation stack into a router. Move one multi-step checkout or onboarding flow into its own coordinator. Keep the parts that make the app easier to understand, and avoid adding structure that does not solve a real problem.

The goal is not more architecture. The goal is cleaner navigation.

If this article helped you understand how the Coordinator Pattern fits into SwiftUI, please clap for the article and follow me for more iOS development notes. I am continuing to write about the problems I run into while building apps, so hopefully you can learn from them without having to make every mistake yourself.

Coordinator Pattern in SwiftUI: Keeping Navigation Logic Out of Your Views was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have been writing more articles around full-stack development lately, mostly because I keep running into real issues while building things. Some of them are small issues, like a confusing config error that wastes an entire evening. Some of them are bigger decisions, like choosing between React and Next.js, structuring a project properly, or figuring out how to keep frontend and backend code clean as the app grows. Writing these articles has become my way of tracking what I learn, what confused me, and what I wish I had understood earlier, so other developers do not have to repeat the same mistakes.

In one of my previous articles, From React to Next.js: Why I Finally Switched and What I Learned, I wrote about why I finally started seeing Next.js as more than just “React with routing.” It was more about how projects change when they become real. In another article, Building a Live GitHub Portfolio with React, Next.js, Tailwind — Part 2, I went deeper into a practical project and explained how React, Next.js, Tailwind, and GitHub APIs can come together in something useful. This article continues that same full-stack journey, but this time I want to talk about something that quietly affects almost every modern JavaScript project: TypeScript.

For a long time, I treated TypeScript as one of those tools that just sits in the background. You create a Next.js app, and TypeScript is there. You build a Node.js API, and TypeScript is there. You create shared types between frontend and backend, and TypeScript is there. At first, everything feels great because the project is small, the editor is fast, and type errors are easy to understand. But once the project grows, you start noticing the pain. Auto-complete becomes slower. Type checking takes longer. CI spends more time on tsc --noEmit. Your editor sometimes feels like it is thinking too hard before telling you something obvious.

That is why the new TypeScript caught my attention. TypeScript 7 is not just another version with a few small language changes. The big story is that the TypeScript team has been working on a native compiler and language service, written in Go, with the goal of making TypeScript much faster while keeping the language familiar. In simple words, TypeScript is not trying to become a different language. It is trying to become the same TypeScript we already use, but much faster and more pleasant in larger projects.

Why This Matters for Full-Stack Developers

Speed may not sound exciting when you are working on a tiny demo project. If your app has five components and one API route, TypeScript usually feels instant. But full-stack projects rarely stay tiny. You start with a simple componentsfolder, then you add lib, server, api, types, hooks, services, db, and maybe some generated types from an ORM or API client. After a while, TypeScript is no longer checking a few files. It is checking your entire application world.

A typical full-stack project can quickly start looking like this:

src/
  app/
  components/
  hooks/
  lib/
  server/
  services/
  db/
  types/
  schemas/
  api/

Then you add shared request and response types. Then Zod schemas. Then test files. Then database models. Then maybe a monorepo with frontend and backend packages. At that point, TypeScript speed really starts to matter because it affects your everyday flow. It affects how quickly you get errors in the editor, how fast “go to definition” works, how painful refactors feel, and how long your CI checks take before you can merge code.

That is why I think TypeScript 7 is important. It is not only about faster builds. It is about making the developer experience smoother in projects that have grown past the tutorial stage.

TypeScript 6 and TypeScript 7: What Is Actually New?

The transition can be a little confusing, so the way I think about it is this: TypeScript 6 is the stable step forward, while TypeScript 7 is the big native compiler preview. TypeScript 6 prepares the ecosystem and removes or tightens certain older behaviors. TypeScript 7 is where the native implementation becomes the headline.

For production apps, I would not immediately replace everything with TypeScript 7 and hope for the best. I would first make sure the project works cleanly on the latest stable TypeScript version. Then I would try TypeScript 7 side by side. This gives you a safer migration path and helps you understand whether a problem is coming from your project configuration, the TypeScript 6 upgrade, or the TypeScript 7 native preview.

For a normal project, you can install the stable TypeScript package like this:

npm install -D typescript

Then check the version:

npx tsc --version

I usually like having a dedicated type-check script in package.json:

{
  "scripts": {
    "typecheck": "tsc --noEmit"
  }
}

Then I can run:

npm run typecheck

This may sound basic, but I like keeping type checking separate from the build step. In a Next.js project, for example, next build already does many things. When something fails, it is easier to debug if I can run TypeScript separately.

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "typecheck": "tsc --noEmit",
    "lint": "next lint"
  }
}

With this setup, I can run things in a cleaner order:

npm run typecheck
npm run lint
npm run build

If typecheck fails, I fix TypeScript first. If lint fails, I clean up lint issues. If the build fails after that, I know it is probably related to bundling, runtime code, framework config, or something outside plain type checking.

Trying the TypeScript 7 Native Preview

The nice thing about the TypeScript 7 preview is that you do not have to throw away your existing TypeScript setup just to experiment with it. You can install the native preview separately:

npm install -D @typescript/native-preview@beta

Then you can check the native TypeScript version with:

npx tsgo --version

The command is tsgo, not tsc, which is actually helpful because it lets you compare both compilers without immediately replacing your existing workflow.

For example, you can run the normal TypeScript compiler:

npx tsc --noEmit

Then run the native preview:

npx tsgo --noEmit

In package.json, I would keep both scripts instead of replacing typecheck immediately:

{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "typecheck:native": "tsgo --noEmit"
  },
  "devDependencies": {
    "typescript": "^6.0.0",
    "@typescript/native-preview": "beta"
  }
}

Now you can run:

npm run typecheck
npm run typecheck:native

This is the kind of upgrade style I prefer because it is safe. You are not betting the whole project on a preview compiler. You are comparing behavior, checking errors, and seeing whether the faster compiler fits into your workflow.

The Real Problem TypeScript Solves

Before going deeper into configuration, I want to talk about something I had to learn the hard way: TypeScript is not runtime validation. It helps you before your code runs, but it does not magically protect you from bad data coming from an API, database, or third-party service.

Let’s say we have a simple backend function that returns a user:

// server/users.ts

export type User = {
  id: string;
  name: string;
  email: string;
  role: "admin" | "user";
  createdAt: string;
};

export async function getUserById(id: string): Promise<User> {
  return {
    id,
    name: "Sanjay",
    email: "sanjay@example.com",
    role: "admin",
    createdAt: new Date().toISOString()
  };
}

On the frontend, we may write something like this:

// lib/api.ts

import type { User } from "@/server/users";

export async function fetchUser(id: string): Promise<User> {
  const response = await fetch(`/api/users/${id}`);

  if (!response.ok) {
    throw new Error("Failed to fetch user");
  }

  return response.json();
}

This looks clean, but there is a problem. response.json() returns any, which means TypeScript is trusting us more than it should. If the backend accidentally returns this:

{
  "id": "123",
  "name": "Sanjay",
  "email": "sanjay@example.com",
  "role": "super-admin",
  "createdAt": "2026-06-15T12:00:00.000Z"
}

TypeScript will not automatically stop that at runtime. Our type says role should be "admin" or "user", but the API returned "super-admin". The compiler cannot protect us from data that arrives while the app is running.

This is why I now prefer combining TypeScript with runtime validation for important boundaries. A good example is using Zod:

// lib/user-schema.ts

import { z } from "zod";

export const UserSchema = z.object({
  id: z.string(),
  name: z.string(),
  email: z.string().email(),
  role: z.enum(["admin", "user"]),
  createdAt: z.string()
});

export type User = z.infer<typeof UserSchema>;

Then the API call becomes safer:

// lib/api.ts

import { UserSchema, type User } from "./user-schema";

export async function fetchUser(id: string): Promise<User> {
  const response = await fetch(`/api/users/${id}`);

  if (!response.ok) {
    throw new Error("Failed to fetch user");
  }

  const data: unknown = await response.json();

  return UserSchema.parse(data);
}

This is a much better pattern. TypeScript gives us compile-time safety, and Zod gives us runtime validation. In full-stack apps, this combination matters a lot because bugs usually happen at boundaries: frontend to API, API to database, database to external service, and external service back to UI.

A More Practical Next.js Example

Let’s make this more realistic with a simple product API. Imagine we have this route in a Next.js app:

// app/api/products/route.ts

import { NextResponse } from "next/server";

type Product = {
  id: string;
  name: string;
  price: number;
  inStock: boolean;
};

const products: Product[] = [
  {
    id: "1",
    name: "Keyboard",
    price: 99,
    inStock: true
  },
  {
    id: "2",
    name: "Mouse",
    price: 49,
    inStock: false
  }
];

export async function GET() {
  return NextResponse.json(products);
}

Then on the client side, we may fetch products like this:

// lib/products.ts

type Product = {
  id: string;
  name: string;
  price: number;
  inStock: boolean;
};

export async function getProducts(): Promise<Product[]> {
  const response = await fetch("/api/products");

  if (!response.ok) {
    throw new Error("Failed to fetch products");
  }

  return response.json();
}

Again, this works, but it is a little too trusting. I prefer moving the schema to a shared place:

// lib/schemas/product.ts

import { z } from "zod";

export const ProductSchema = z.object({
  id: z.string(),
  name: z.string(),
  price: z.number(),
  inStock: z.boolean()
});

export const ProductListSchema = z.array(ProductSchema);

export type Product = z.infer<typeof ProductSchema>;

Now the API can use the shared type:

// app/api/products/route.ts

import { NextResponse } from "next/server";
import type { Product } from "@/lib/schemas/product";

const products: Product[] = [
  {
    id: "1",
    name: "Keyboard",
    price: 99,
    inStock: true
  },
  {
    id: "2",
    name: "Mouse",
    price: 49,
    inStock: false
  }
];

export async function GET() {
  return NextResponse.json(products);
}

And the client can validate the response:

// lib/products.ts

import {
  ProductListSchema,
  type Product
} from "@/lib/schemas/product";

export async function getProducts(): Promise<Product[]> {
  const response = await fetch("/api/products");

  if (!response.ok) {
    throw new Error("Failed to fetch products");
  }

  const data: unknown = await response.json();

  return ProductListSchema.parse(data);
}

This is the kind of full-stack TypeScript pattern I like now. I do not want types just for decoration. I want types that actually help me build safer features.

Why Strict TypeScript Is Annoying but Worth It

Strict TypeScript can be annoying, especially when you are moving fast. There are times when you just want to build the feature and TypeScript keeps complaining. But most of the time, when TypeScript complains, it is pointing at something that could become a real bug later.

Here is a simple example:

type User = {
  name: string;
  email?: string;
};

function sendWelcomeEmail(user: User) {
  console.log(user.email.toLowerCase());
}

At first glance, this looks fine. But email is optional, so this can crash:

sendWelcomeEmail({ name: "Sanjay" });

With strict checks enabled, TypeScript forces us to deal with that case:

function sendWelcomeEmail(user: User) {
  if (!user.email) {
    console.log("No email found for user");
    return;
  }

  console.log(user.email.toLowerCase());
}

Or, if the email is truly required, we should change the type:

type User = {
  name: string;
  email: string;
};

This is a small example, but these small things add up in a real app. A lot of bugs are not dramatic. They come from one optional field, one API response that changed shape, one missing null check, or one wrong assumption. Strict TypeScript helps catch those mistakes earlier.

Config Changes That Can Surprise You

One thing I have learned with TypeScript is that the language itself is usually not the problem. The config is where people get stuck. A small tsconfig.json change can make the difference between a project that feels clean and a project that constantly throws confusing errors.

For example, many projects use path aliases like this:

import { Button } from "@/components/Button";

Older configs often look like this:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

A cleaner approach is to make the path mapping explicit:

{
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

Your import stays the same:

import { Button } from "@/components/Button";

But the config is clearer because the alias directly points to ./src/*.

Another setting I like being explicit about is rootDir. If your project looks like this:

my-app/
  tsconfig.json
  src/
    index.ts
    api/
      users.ts

Your config may work without rootDir, but I still prefer writing it clearly:

{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist",
    "module": "esnext",
    "target": "es2022"
  },
  "include": ["src"]
}

This helps future you understand the project faster. And honestly, future me always appreciates when past me took five extra minutes to make config readable.

Side-Effect Imports and CSS Files

Another stricter area to watch is side-effect imports. These are imports where you are not importing a value, but you still want the file to run or load.

A common example is CSS:

import "./globals.css";

This is normal in many frontend projects. But imagine you accidentally type:

import "./gloabls.css";

That typo can be annoying to debug, especially if your tooling does not catch it where you expect. Stricter TypeScript behavior around side-effect imports helps catch issues like this earlier.

If TypeScript complains about importing CSS files, you may need a declaration file:

// global.d.ts

declare module "*.css";

For CSS modules, you can use:

// global.d.ts

declare module "*.module.css" {
  const classes: Record<string, string>;
  export default classes;
}

This is one of those things that feels irritating the first time you see it, but it makes sense. TypeScript is basically saying, “I do not know what this file type is. Please tell me.” Once you tell it, the project becomes cleaner.

Import Attributes Instead of Import Assertions

Another migration detail worth knowing is the move from import assertions to import attributes. Older code may look like this:

import config from "./config.json" assert { type: "json" };

The newer syntax uses with:

import config from "./config.json" with { type: "json" };

For example, if you have a JSON config file:

{
  "appName": "Portfolio",
  "version": "1.0.0"
}

You can import it like this:

import appConfig from "./app-config.json" with { type: "json" };

console.log(appConfig.appName);
console.log(appConfig.version);

This is not something that will affect every project, but if your app imports JSON modules directly, it is worth checking. These small syntax changes are the kind of things that can randomly break a build during an upgrade if you are not expecting them.

Be Explicit With Global Types

Testing is another place where TypeScript config can surprise you. If you are using Vitest or Jest, your test files may use globals like describe, it, and expect:

describe("sum", () => {
  it("adds two numbers", () => {
    expect(1 + 2).toBe(3);
  });
});

If TypeScript does not know about those globals, you may see errors like:

Cannot find name 'describe'
Cannot find name 'it'
Cannot find name 'expect'

The fix is usually to explicitly tell TypeScript which global types your project uses. For Vitest:

{
  "compilerOptions": {
    "types": ["node", "vitest"]
  }
}

For Jest:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

I actually like this direction because it makes the project more predictable. Instead of TypeScript pulling in whatever types happen to exist in node_modules, you are telling it exactly what environment the project expects.

Using satisfies for Safer Config Objects

One TypeScript pattern I use more often now is satisfies. It is useful when you want TypeScript to check that an object follows a certain shape without losing the specific details of the object.

Imagine you have app routes:

type AppRoute = {
  label: string;
  href: string;
  protected: boolean;
};

const routes = {
  home: {
    label: "Home",
    href: "/",
    protected: false
  },
  dashboard: {
    label: "Dashboard",
    href: "/dashboard",
    protected: true
  }
} satisfies Record<string, AppRoute>;

Now TypeScript checks that every route follows the AppRoute structure. If I accidentally write url instead of href, TypeScript catches it:

const routes = {
  home: {
    label: "Home",
    href: "/",
    protected: false
  },
  dashboard: {
    label: "Dashboard",
    url: "/dashboard",
    protected: true
  }
} satisfies Record<string, AppRoute>;

The correct version should use href:

const routes = {
  home: {
    label: "Home",
    href: "/",
    protected: false
  },
  dashboard: {
    label: "Dashboard",
    href: "/dashboard",
    protected: true
  }
} satisfies Record<string, AppRoute>;

This is not only about TypeScript 7, but it is part of the modern TypeScript style I like using in full-stack apps. You get safer config, better autocomplete, and fewer silly mistakes.

Running the Native Compiler With More Control

One interesting thing about the TypeScript 7 native preview is that it gives you control over how much parallel work it does. For example, you can run:

npx tsgo --noEmit --checkers 4

This tells the compiler how many type-checking workers to use. For larger projects, this may help. For smaller machines or CI runners with limited memory, you may want to lower the number.

You can also run it in single-threaded mode:

npx tsgo --noEmit --singleThreaded

For monorepos using project references, there is also builder parallelization:

npx tsgo -b --builders 2

You can combine these options, but I would be careful:

npx tsgo -b --checkers 4 --builders 4

That may be faster, but it can also use more memory. I would not blindly increase every number just because it looks powerful. I would test it properly:

time npx tsc --noEmit
time npx tsgo --noEmit
time npx tsgo --noEmit --checkers 2
time npx tsgo --noEmit --checkers 4

Final Thoughts

TypeScript 7 feels like a big deal because it improves something we deal with every single day as developers: feedback speed. Faster type checking, a faster language service, and a native compiler may not sound flashy from the outside, but when you are inside a real project with frontend code, backend code, shared types, schemas, tests, and CI checks, these improvements can make the whole development experience feel lighter.

But I also think this is the important part: TypeScript 7 does not change the basics of writing good TypeScript. We still need clean types. We still need strict checks. We still need runtime validation at API boundaries. We still need readable tsconfig files. And we still need to be careful when trying preview tools in production projects. The native compiler is exciting, but I would treat it as something to test side by side first, not something to blindly switch on and hope everything works.

For me, the biggest takeaway is that TypeScript is becoming even more important for full-stack development. It is no longer just a nice extra layer on top of JavaScript. It is part of how we design safer APIs, cleaner frontend code, better shared contracts, and more maintainable applications. And with TypeScript 7 focusing so much on speed, it feels like the tooling is finally catching up to the size of the projects we are building today.

As always, I am writing these articles while learning and building in public, mostly to document the things that confused me, slowed me down, or helped me write better code. Hopefully this article gave you a practical way to think about TypeScript 7, how to try it safely, and how to use TypeScript more effectively in real full-stack projects.

If this helped you, please clap for the article, share it with another developer, and follow me for more practical full-stack and iOS/Android development articles. I will keep documenting the things I learn along the way so we can all avoid the same mistakes and build better projects together.

I Tried the New TypeScript: Why TypeScript 7 Actually Feels Like a Big Deal was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I first started learning iOS development, delegates confused me more than I expected. The code itself did not look too hard. You create a protocol, add a delegate property, set it somewhere else, and call a method when something happens. But for a long time, I did not fully understand why this pattern existed or when I should use it instead of closures, NotificationCenter, SwiftUI state, or just calling another object directly.

That is one of the reasons I have been writing more iOS articles recently. I use these articles to track the issues I personally faced while building apps, especially the concepts that seemed simple at first but became more important as the app grew. I like documenting these lessons because if I struggled with something, there is a good chance someone else will run into the same confusion too. Hopefully, by sharing the mistakes and patterns that helped me, other developers can avoid repeating the same issues and get to the “aha” moment faster.

In some of my previous articles, I wrote about practical iOS topics from a similar angle. In SwiftUI State in iOS: A Practical Guide, I talked about how state drives the UI and why understanding state makes SwiftUI much easier to reason about. In MVVM in SwiftUI: Build an iOS App That Stays Organized as It Grows, I focused on keeping code organized when an app starts becoming more than just a few screens. I also wrote about trying Apple VisionKit and building a simple document scanner in SwiftUI, which was a good reminder that even in SwiftUI, many Apple frameworks still rely heavily on delegate-based APIs.

This article is about delegates and events in iOS. More importantly, it is about how objects communicate with each other without everything becoming tightly coupled and messy.

The Real Problem Delegates Solve

Before talking about delegates, it helps to understand the problem they are solving. Imagine we have a screen that displays a list of notes. When the user taps a note, we want to open the detail screen. The easiest way is to make the list screen directly call the detail screen.

final class NotesListViewController: UIViewController {

    private let detailViewController = NoteDetailViewController()

    func userDidTapNote(_ note: Note) {
        detailViewController.show(note)
    }
}

This works, and honestly, in a very small app it might feel completely fine. But the problem is that NotesListViewControllernow knows too much. It knows who handles the selected note, how the next screen works, and what should happen after the tap. That is okay when the app has two screens, but it starts becoming painful when the app grows.

What if tapping a note sometimes opens a detail screen, sometimes triggers an edit flow, and sometimes just informs a parent coordinator? What if this list component should be reused somewhere else? What if we want to track analytics when a note is selected, but we do not want the list view controller to know anything about analytics? This is where delegates become useful because they allow an object to say, “Something happened here,” without needing to know exactly who is handling it or what happens next.

A delegate is basically a way for one object to communicate events to another object through a clearly defined contract. In Swift, that contract is usually a protocol.

struct Note {
    let id: Int
    let title: String
}

protocol NotesListViewControllerDelegate: AnyObject {
    func notesListViewController(
        _ controller: NotesListViewController,
        didSelect note: Note
    )
}

Now the list screen can expose a delegate property.

final class NotesListViewController: UIViewController {

    weak var delegate: NotesListViewControllerDelegate?

    private let notes: [Note] = [
        Note(id: 1, title: "SwiftUI State"),
        Note(id: 2, title: "MVVM"),
        Note(id: 3, title: "Delegates and Events")
    ]

    func userDidTapNote(at index: Int) {
        let selectedNote = notes[index]

        delegate?.notesListViewController(
            self,
            didSelect: selectedNote
        )
    }
}

The important part here is that NotesListViewController does not decide what happens after the note is selected. It simply reports the event. Another object can become the delegate and decide what to do.

final class NotesCoordinator: NotesListViewControllerDelegate {

    func notesListViewController(
        _ controller: NotesListViewController,
        didSelect note: Note
    ) {
        print("User selected note: \(note.title)")

        // Open detail screen
        // Track analytics
        // Update app state
        // Start another flow
    }
}

This is the part that finally made delegates click for me. A delegate is not just extra syntax. It is a way to keep one object reusable and focused while letting another object handle the decision-making.

Why Delegates Are Usually Weak

One thing you will see a lot in delegate-based code is this:

weak var delegate: NotesListViewControllerDelegate?

At first, this can feel like one of those Swift details that people mention without explaining properly. But it matters because delegates often point back to an object that already owns the original object. For example, a parent view controller may own a child view controller, and then the child view controller may use the parent as its delegate.

final class ParentViewController: UIViewController {

    private let notesListViewController = NotesListViewController()

    override func viewDidLoad() {
        super.viewDidLoad()

        notesListViewController.delegate = self
    }
}

extension ParentViewController: NotesListViewControllerDelegate {

    func notesListViewController(
        _ controller: NotesListViewController,
        didSelect note: Note
    ) {
        print("Selected note: \(note.title)")
    }
}

If the parent strongly owns the child, and the child strongly owns the parent through the delegate, both objects can keep each other alive. That is called a retain cycle. To avoid this, delegate references are usually weak.

For a delegate to be weak, the protocol needs to be limited to class types. That is why we write AnyObject in the protocol declaration.

protocol NotesListViewControllerDelegate: AnyObject {
    func notesListViewController(
        _ controller: NotesListViewController,
        didSelect note: Note
    )
}

This is a small detail, but it is one of those details that becomes very important in real apps. If a view controller is not getting released from memory, a strong delegate reference is one of the first things I would check.

A Practical UIKit Example

Let’s use a more realistic example. Imagine we are building a reusable rating view. It shows buttons from 1 to 5, and when the user selects a rating, the parent screen needs to know. The rating view itself should not save the rating, call an API, show an alert, or navigate anywhere. Its job is only to display the buttons and report what the user selected.

First, we define the delegate protocol.

protocol RatingViewDelegate: AnyObject {
    func ratingView(_ ratingView: RatingView, didSelectRating rating: Int)
}

Now we can create the custom view.

import UIKit

final class RatingView: UIView {

    weak var delegate: RatingViewDelegate?

    private let stackView = UIStackView()

    override init(frame: CGRect) {
        super.init(frame: frame)
        setupView()
        setupButtons()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        setupView()
        setupButtons()
    }

    private func setupView() {
        stackView.axis = .horizontal
        stackView.spacing = 8
        stackView.distribution = .fillEqually

        addSubview(stackView)
        stackView.translatesAutoresizingMaskIntoConstraints = false

        NSLayoutConstraint.activate([
            stackView.leadingAnchor.constraint(equalTo: leadingAnchor),
            stackView.trailingAnchor.constraint(equalTo: trailingAnchor),
            stackView.topAnchor.constraint(equalTo: topAnchor),
            stackView.bottomAnchor.constraint(equalTo: bottomAnchor)
        ])
    }

    private func setupButtons() {
        for rating in 1...5 {
            let button = UIButton(type: .system)
            button.setTitle("\(rating)", for: .normal)
            button.tag = rating

            button.addTarget(
                self,
                action: #selector(ratingButtonTapped(_:)),
                for: .touchUpInside
            )

            stackView.addArrangedSubview(button)
        }
    }

    @objc private func ratingButtonTapped(_ sender: UIButton) {
        let rating = sender.tag
        delegate?.ratingView(self, didSelectRating: rating)
    }
}

Then a view controller can use this rating view and decide what should happen when the rating is selected.

final class ReviewViewController: UIViewController {

    private let ratingView = RatingView()

    override func viewDidLoad() {
        super.viewDidLoad()

        view.backgroundColor = .systemBackground
        ratingView.delegate = self

        view.addSubview(ratingView)
        ratingView.translatesAutoresizingMaskIntoConstraints = false

        NSLayoutConstraint.activate([
            ratingView.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            ratingView.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            ratingView.widthAnchor.constraint(equalToConstant: 250),
            ratingView.heightAnchor.constraint(equalToConstant: 44)
        ])
    }
}

extension ReviewViewController: RatingViewDelegate {

    func ratingView(_ ratingView: RatingView, didSelectRating rating: Int) {
        print("Selected rating: \(rating)")

        // Save rating
        // Update UI
        // Send event to ViewModel
        // Track analytics
    }
}

This is a clean separation of responsibility. The RatingView only knows that a rating was tapped. The ReviewViewControllerdecides what that rating means in the context of the screen. This is the kind of separation that feels unnecessary in tiny examples, but becomes very valuable when you are building real screens that keep changing over time.

Delegates and Events Are Related, But Not Exactly the Same

An event is simply something that happened. A button was tapped. A text field changed. A scroll view moved. A network request finished. A document scanner completed scanning. A Bluetooth device disconnected. iOS apps are basically a long chain of events being handled in different ways.

Delegates are one way to handle events, but they are not the only way. UIKit and Swift give us several patterns, and this is where things can get confusing. You might see target-action for button taps, delegates for table views, closures for small callbacks, NotificationCenter for broadcasts, Combine publishers for streams, and SwiftUI modifiers like .onAppear and .onChange.

// Target-action
button.addTarget(
    self,
    action: #selector(buttonTapped),
    for: .touchUpInside
)

// Delegate
tableView.delegate = self

// Closure callback
view.onRetryTapped = { [weak self] in
    self?.reloadData()
}

// NotificationCenter
NotificationCenter.default.post(
    name: .userDidLogout,
    object: nil
)

// SwiftUI event modifier
.onAppear {
    loadData()
}

The trick is not to memorize every pattern as a separate thing. The better mental model is to ask: who needs to know that this happened, and how closely related are these objects? Once you answer that, the right pattern usually becomes easier to choose.

Target-Action Is Great for Simple UI Events

Target-action is very common in UIKit, especially with controls like UIButton, UISwitch, UISlider, and UITextField. If a user taps a button, you usually do not need a delegate protocol just for that one tap. Target-action is simple and direct.

final class LoginViewController: UIViewController {

    private let loginButton = UIButton(type: .system)

    override func viewDidLoad() {
        super.viewDidLoad()

        loginButton.setTitle("Login", for: .normal)

        loginButton.addTarget(
            self,
            action: #selector(loginButtonTapped),
            for: .touchUpInside
        )
    }

    @objc private func loginButtonTapped() {
        print("Login button tapped")
    }
}

This is perfect for simple UI interactions. The button sends an event, and the view controller handles it. You will commonly see events like .touchUpInside, .editingChanged, .valueChanged, and .primaryActionTriggered.

textField.addTarget(
    self,
    action: #selector(textDidChange(_:)),
    for: .editingChanged
)

switchControl.addTarget(
    self,
    action: #selector(switchValueChanged(_:)),
    for: .valueChanged
)

My rule is simple: if it is a direct UIKit control event, target-action is usually fine. I only start thinking about delegates or closures when I am building a custom component or when the communication becomes more structured.

Delegates Are Better for Structured Communication

Delegates are especially useful when one object needs to communicate multiple related events or decisions to another object. This is why UITableViewDelegate, UITableViewDataSource, UITextFieldDelegate, UIScrollViewDelegate, and many Apple framework APIs use delegates.

Take UITableView as an example. A table view does not only need to say “a row was tapped.” It may also need to ask how many rows exist, what each cell should look like, how tall a row should be, whether a row can be edited, and what should happen when a row is selected.

final class NotesViewController: UIViewController {

    private let tableView = UITableView()
    private let notes = ["SwiftUI State", "MVVM", "Delegates"]

    override func viewDidLoad() {
        super.viewDidLoad()

        tableView.dataSource = self
        tableView.delegate = self
    }
}

extension NotesViewController: UITableViewDataSource {

    func tableView(
        _ tableView: UITableView,
        numberOfRowsInSection section: Int
    ) -> Int {
        notes.count
    }

    func tableView(
        _ tableView: UITableView,
        cellForRowAt indexPath: IndexPath
    ) -> UITableViewCell {
        let cell = UITableViewCell(style: .default, reuseIdentifier: nil)
        cell.textLabel?.text = notes[indexPath.row]
        return cell
    }
}

extension NotesViewController: UITableViewDelegate {

    func tableView(
        _ tableView: UITableView,
        didSelectRowAt indexPath: IndexPath
    ) {
        print("Selected note: \(notes[indexPath.row])")
    }
}

This is where delegates shine. The table view has a clear relationship with the object that manages it. The delegate and data source define that relationship in a structured way. This is much cleaner than giving the table view many random closures for every possible behavior.

UITextFieldDelegate is another good example because the text field sometimes needs to ask questions before doing something.

final class ProfileViewController: UIViewController {

    private let nameTextField = UITextField()

    override func viewDidLoad() {
        super.viewDidLoad()

        nameTextField.delegate = self
    }
}

extension ProfileViewController: UITextFieldDelegate {

    func textFieldShouldReturn(_ textField: UITextField) -> Bool {
        textField.resignFirstResponder()
        return true
    }

    func textFieldDidEndEditing(_ textField: UITextField) {
        print("User entered name: \(textField.text ?? "")")
    }
}

This is not just an event callback. The text field is asking the delegate how it should behave. That is another reason delegates are useful: they are not only for reporting events, but also for letting another object customize behavior.

Closures Are Great for Small Custom Events

While delegates are useful, I do not think every custom view needs a delegate. Sometimes a closure is simpler and more readable. For example, imagine we have an empty state view with a retry button. If the only thing the view needs to report is “retry was tapped,” a closure works nicely.

final class EmptyStateView: UIView {

    var onRetryTapped: (() -> Void)?

    private let retryButton = UIButton(type: .system)

    override init(frame: CGRect) {
        super.init(frame: frame)
        setupButton()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        setupButton()
    }

    private func setupButton() {
        retryButton.setTitle("Try Again", for: .normal)

        retryButton.addTarget(
            self,
            action: #selector(retryButtonTapped),
            for: .touchUpInside
        )

        addSubview(retryButton)
    }

    @objc private func retryButtonTapped() {
        onRetryTapped?()
    }
}

Then the view controller can handle the callback like this:

final class ErrorViewController: UIViewController {

    private let emptyStateView = EmptyStateView()

    override func viewDidLoad() {
        super.viewDidLoad()

        emptyStateView.onRetryTapped = { [weak self] in
            self?.reloadData()
        }
    }

    private func reloadData() {
        print("Reloading data...")
    }
}

The important thing with closures is memory management. If a view owns a closure, and that closure strongly captures the view controller, you can accidentally create a retain cycle. That is why you often see [weak self] inside UIKit callbacks.

emptyStateView.onRetryTapped = { [weak self] in
    self?.reloadData()
}

My personal rule is that closures are great when there are one or two simple events. If the custom view starts exposing many callbacks, I usually move to a delegate because the API becomes easier to organize and understand.

NotificationCenter Is for Broadcast Events

NotificationCenter is another event pattern, but I try to use it carefully. It is useful when multiple unrelated parts of the app need to know about the same event. A common example is logout. When the user logs out, the profile screen may need to reset, the root screen may need to return to login, cached data may need to clear, and other parts of the app may need to react.

First, define a notification name.

extension Notification.Name {
    static let userDidLogout = Notification.Name("userDidLogout")
}

Then post the event when logout happens.

final class SessionManager {

    func logout() {
        // Clear tokens
        // Reset user session
        // Remove cached data

        NotificationCenter.default.post(
            name: .userDidLogout,
            object: nil
        )
    }
}

Any object that cares about logout can listen for it.

final class HomeViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()

        NotificationCenter.default.addObserver(
            self,
            selector: #selector(handleLogout),
            name: .userDidLogout,
            object: nil
        )
    }

    @objc private func handleLogout() {
        print("User logged out. Return to login screen.")
    }

    deinit {
        NotificationCenter.default.removeObserver(self)
    }
}

This is powerful, but it can also make the app harder to trace if overused. With delegates, you can usually see the relationship clearly. With notifications, the event is broadcast, and any object can listen from anywhere. That is useful for app-wide events, but I would not use it for every button tap or small component callback.

SwiftUI Handles Events Differently

In SwiftUI, we usually do not write delegates for basic view interactions. SwiftUI gives us event-style modifiers and closures instead. A button tap is just a closure.

struct LoginView: View {

    var body: some View {
        Button("Login") {
            print("Login tapped")
        }
    }
}

Text changes can be handled with .onChange.

struct SearchView: View {

    @State private var searchText = ""

    var body: some View {
        TextField("Search", text: $searchText)
            .onChange(of: searchText) { oldValue, newValue in
                print("Search changed to: \(newValue)")
            }
    }
}

View lifecycle events can be handled with .onAppear and .onDisappear.

struct ProfileView: View {

    var body: some View {
        Text("Profile")
            .onAppear {
                print("Profile appeared")
            }
            .onDisappear {
                print("Profile disappeared")
            }
    }
}

This connects nicely with the SwiftUI state idea. In UIKit, we often think, “When this event happens, update this label or push this screen.” In SwiftUI, we usually think, “When this event happens, update the state, and the UI will reflect that state.”

struct LoginFormView: View {

    @State private var email = ""
    @State private var password = ""
    @State private var errorMessage: String?

    var body: some View {
        VStack(spacing: 12) {
            TextField("Email", text: $email)
                .textFieldStyle(.roundedBorder)

            SecureField("Password", text: $password)
                .textFieldStyle(.roundedBorder)

            Button("Login") {
                login()
            }

            if let errorMessage {
                Text(errorMessage)
                    .foregroundStyle(.red)
            }
        }
        .padding()
    }

    private func login() {
        guard !email.isEmpty else {
            errorMessage = "Email is required"
            return
        }

        guard !password.isEmpty else {
            errorMessage = "Password is required"
            return
        }

        errorMessage = nil
        print("Perform login")
    }
}

Here, the button tap is the event, and errorMessage is the state. Once the state changes, SwiftUI updates the UI. This is why understanding events and state together is so helpful.

Bridging UIKit Delegates Into SwiftUI

Even if you are mainly writing SwiftUI, delegates still matter because many Apple frameworks are built around them. UIImagePickerController, VNDocumentCameraViewController, CLLocationManager, CBCentralManager, WKWebView, and many other APIs use delegates. This is exactly why delegates came back into the picture when I was working with VisionKit.

When you wrap UIKit inside SwiftUI, you usually use UIViewControllerRepresentable or UIViewRepresentable. Since UIKit expects a delegate object, SwiftUI gives us a Coordinator to bridge that delegate communication back into SwiftUI.

Here is an example using UIImagePickerController.

import SwiftUI
import UIKit

struct ImagePicker: UIViewControllerRepresentable {

    @Binding var selectedImage: UIImage?
    @Environment(\.dismiss) private var dismiss

    func makeUIViewController(context: Context) -> UIImagePickerController {
        let picker = UIImagePickerController()
        picker.delegate = context.coordinator
        picker.sourceType = .photoLibrary
        return picker
    }

    func updateUIViewController(
        _ uiViewController: UIImagePickerController,
        context: Context
    ) {
        // No update needed for this example
    }

    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }

    final class Coordinator: NSObject,
                             UIImagePickerControllerDelegate,
                             UINavigationControllerDelegate {

        private let parent: ImagePicker

        init(_ parent: ImagePicker) {
            self.parent = parent
        }

        func imagePickerController(
            _ picker: UIImagePickerController,
            didFinishPickingMediaWithInfo info: [UIImagePickerController.InfoKey : Any]
        ) {
            if let image = info[.originalImage] as? UIImage {
                parent.selectedImage = image
            }

            parent.dismiss()
        }

        func imagePickerControllerDidCancel(_ picker: UIImagePickerController) {
            parent.dismiss()
        }
    }
}

Now the SwiftUI view can use the image picker with a binding.

struct ProfilePhotoView: View {

    @State private var selectedImage: UIImage?
    @State private var isShowingImagePicker = false

    var body: some View {
        VStack(spacing: 16) {
            if let selectedImage {
                Image(uiImage: selectedImage)
                    .resizable()
                    .scaledToFit()
                    .frame(height: 200)
            } else {
                Text("No image selected")
            }

            Button("Choose Photo") {
                isShowingImagePicker = true
            }
        }
        .sheet(isPresented: $isShowingImagePicker) {
            ImagePicker(selectedImage: $selectedImage)
        }
    }
}

This pattern is very common. UIKit reports events through a delegate. The coordinator receives those delegate events. Then the coordinator updates SwiftUI state through a binding. Once I understood this flow, wrapping UIKit controllers in SwiftUI became much less mysterious.

Delegate vs Closure: A Practical Decision

Let’s say we are building a reusable login form view in UIKit. The form has an email field, password field, login button, and forgot password button. We could expose two closures like this.

final class LoginFormView: UIView {

    var onLoginTapped: ((_ email: String, _ password: String) -> Void)?
    var onForgotPasswordTapped: (() -> Void)?

    private let emailTextField = UITextField()
    private let passwordTextField = UITextField()
    private let loginButton = UIButton(type: .system)
    private let forgotPasswordButton = UIButton(type: .system)

    override init(frame: CGRect) {
        super.init(frame: frame)
        setupActions()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        setupActions()
    }

    private func setupActions() {
        loginButton.addTarget(
            self,
            action: #selector(loginButtonTapped),
            for: .touchUpInside
        )

        forgotPasswordButton.addTarget(
            self,
            action: #selector(forgotPasswordButtonTapped),
            for: .touchUpInside
        )
    }

    @objc private func loginButtonTapped() {
        onLoginTapped?(
            emailTextField.text ?? "",
            passwordTextField.text ?? ""
        )
    }

    @objc private func forgotPasswordButtonTapped() {
        onForgotPasswordTapped?()
    }
}

This is perfectly fine for a small component. But if the form starts growing with more related behavior, a delegate can make the API feel cleaner.

protocol LoginFormViewDelegate: AnyObject {
    func loginFormView(
        _ view: LoginFormView,
        didTapLoginWithEmail email: String,
        password: String
    )

    func loginFormViewDidTapForgotPassword(_ view: LoginFormView)
}

Then the form view can communicate through the delegate.

final class LoginFormView: UIView {

    weak var delegate: LoginFormViewDelegate?

    private let emailTextField = UITextField()
    private let passwordTextField = UITextField()
    private let loginButton = UIButton(type: .system)
    private let forgotPasswordButton = UIButton(type: .system)

    override init(frame: CGRect) {
        super.init(frame: frame)
        setupActions()
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        setupActions()
    }

    private func setupActions() {
        loginButton.addTarget(
            self,
            action: #selector(loginButtonTapped),
            for: .touchUpInside
        )

        forgotPasswordButton.addTarget(
            self,
            action: #selector(forgotPasswordButtonTapped),
            for: .touchUpInside
        )
    }

    @objc private func loginButtonTapped() {
        delegate?.loginFormView(
            self,
            didTapLoginWithEmail: emailTextField.text ?? "",
            password: passwordTextField.text ?? ""
        )
    }

    @objc private func forgotPasswordButtonTapped() {
        delegate?.loginFormViewDidTapForgotPassword(self)
    }
}

And the view controller handles the behavior.

final class LoginViewController: UIViewController {

    private let loginFormView = LoginFormView()
    private let viewModel = LoginViewModel()

    override func viewDidLoad() {
        super.viewDidLoad()

        loginFormView.delegate = self
    }
}

extension LoginViewController: LoginFormViewDelegate {

    func loginFormView(
        _ view: LoginFormView,
        didTapLoginWithEmail email: String,
        password: String
    ) {
        Task {
            do {
                try await viewModel.login(email: email, password: password)
                print("Navigate to home")
            } catch {
                print("Show error: \(error)")
            }
        }
    }

    func loginFormViewDidTapForgotPassword(_ view: LoginFormView) {
        print("Navigate to forgot password")
    }
}

The view model can stay focused on business logic.

final class LoginViewModel {

    func login(email: String, password: String) async throws {
        guard !email.isEmpty else {
            throw LoginError.missingEmail
        }

        guard !password.isEmpty else {
            throw LoginError.missingPassword
        }

        // Call login API here
    }
}

enum LoginError: Error {
    case missingEmail
    case missingPassword
}

This connects directly with MVVM. The view reports the event, the view controller receives it, and the view model handles the logic. The login form does not need to know about networking, navigation, alerts, or authentication rules. That separation is what keeps the code easier to change later.

Naming Delegate Methods Clearly

One thing I appreciate more now is good delegate method naming. Apple’s APIs usually follow a pattern that makes the method read almost like a sentence.

func tableView(
    _ tableView: UITableView,
    didSelectRowAt indexPath: IndexPath
)

That method name tells us which object triggered the event, what happened, and what extra information is being passed. I try to follow the same style in my own code.

func scannerViewController(
    _ controller: ScannerViewController,
    didFinishScanning pages: [UIImage]
)

func scannerViewControllerDidCancel(
    _ controller: ScannerViewController
)

func loginFormView(
    _ view: LoginFormView,
    didTapLoginWithEmail email: String,
    password: String
)

This may look verbose, but it helps a lot when the codebase grows. A vague method like login() or done() may look cleaner today, but six months later you may not remember who called it, why it was called, or what context it belongs to. Clear delegate names make the code easier to scan and easier to debug.

Common Mistakes I Try to Avoid Now

The first mistake is forgetting to set the delegate. This is such a simple mistake, but it can waste a lot of time because the app compiles and runs, but nothing happens when the event is triggered.

loginFormView.delegate = self

The second mistake is forgetting to make the delegate weak. This can cause memory leaks, especially when a child object points back to its parent. If the delegate is a class-based relationship, I usually expect to see weak.

weak var delegate: LoginFormViewDelegate?

The third mistake is using delegates for everything. Not every event needs a protocol. If it is a simple button tap inside a view controller, target-action is enough. If it is one small custom callback, a closure may be cleaner. If it is a SwiftUI interaction, state and closures are usually the natural choice.

The fourth mistake is letting a view do too much. A custom view should usually report user actions, not decide the entire app flow. For example, I would avoid putting API calls, navigation, analytics, and alert handling directly inside a reusable form view.

final class LoginFormView: UIView {

    @objc private func loginButtonTapped() {
        // This is too much responsibility for a reusable view.
        // Validate input
        // Call API
        // Navigate to home screen
        // Show alert
        // Track analytics
    }
}

A cleaner approach is to let the view report the event and let another layer decide what to do.

@objc private func loginButtonTapped() {
    delegate?.loginFormView(
        self,
        didTapLoginWithEmail: emailTextField.text ?? "",
        password: passwordTextField.text ?? ""
    )
}

This is a small shift in thinking, but it makes components much easier to reuse.

The Mental Model I Use Now

The easiest way I think about delegates and events is this: something happens in one object, and another object needs to know about it. That is really the core idea. The pattern you choose depends on the relationship between those objects.

If it is a simple UIKit control event, I use target-action. If it is one small custom callback, I usually use a closure. If it is a structured relationship with multiple related events, I use a delegate. If many unrelated parts of the app need to know about the same thing, I consider NotificationCenter. If I am in SwiftUI, I usually think in terms of closures, bindings, state, and modifiers like .onAppear, .onChange, and .task.

The question that helps me most is: “Who needs to know this happened?” If only the parent view needs to know, a closure or delegate may be enough. If the object needs to ask its owner multiple things, a delegate is probably better. If the whole app needs to react, a broadcast-style event may make sense.

Final Thoughts

Delegates can feel like an older iOS concept, especially when working with SwiftUI, async/await, and modern closure-based APIs. But they are still everywhere in iOS development. UIKit uses them heavily. Many Apple frameworks use them. SwiftUI wrappers often need coordinators because the UIKit controller underneath still communicates through delegates.

For me, the concept became much easier once I stopped thinking of delegates as just boilerplate. A delegate is simply a way for an object to say, “Something happened here, and I want someone else to decide what to do.” That is a powerful idea because it keeps objects focused, reusable, and less tightly connected.

I am continuing to write these iOS articles as a way to document the concepts and issues I run into while building apps. Some topics look simple in sample code, but they become much more meaningful when you start building real features. Delegates and events are exactly that kind of topic.

If this article helped you, please clap for it and follow me for more practical iOS development articles. It really helps and also motivates me to keep sharing what I learn while building.

Delegates and Events in iOS: The Concept That Finally Made App Communication Click for Me was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have been writing quite a bit about iOS development recently.

A while back, I wrote about SwiftUI state management in my article SwiftUI State in iOS: A Practical Guide. After that, I wrote another article on MVVM in SwiftUI, where I talked about keeping an iOS app organized as it grows.

Both of those articles came from a very practical place. I was not trying to explain iOS development from a perfect textbook point of view. I was trying to explain the things that actually help when you are building real apps.

Recently, I heard about Apple’s VisionKit again and thought, “Why have I not properly tried this yet?”

I had used Apple’s Vision framework before in smaller ways, but VisionKit felt different. It is one of those frameworks that sounds advanced at first, but once you understand what it is trying to do, it becomes very practical.

You can use VisionKit to scan documents, detect text, scan QR codes, read barcodes, and work with camera-based data. In simple words, VisionKit helps your app understand useful information from the real world using the camera.

That immediately gave me an idea.

What if I build a simple SwiftUI app that lets the user scan a document, preview the scanned pages, and maybe later extract text from it?

That is what this article is about.

We are going to build a simple VisionKit-powered document scanner using SwiftUI.

What Is VisionKit?

VisionKit is an Apple framework that helps developers add camera-based scanning features to iOS apps.

Instead of building a full camera pipeline yourself, handling edge detection, document boundaries, perspective correction, and scanning UI, VisionKit gives you ready-made tools for common scanning use cases.

You can use VisionKit for things like:

• Scanning paper documents
• Capturing receipts
• Scanning handwritten notes
• Detecting live text from the camera
• Scanning QR codes and barcodes
• Building lightweight scanner-style apps

This is useful because many apps eventually need to deal with real-world information.

Maybe you are building an expense app and want to scan receipts.

Maybe you are building a notes app and want to scan handwritten notes.

Maybe you are building an inventory app and want to scan barcodes.

Or maybe you are like me and just curious enough to try the framework and see what it can do.

\VisionKit vs Vision

Before writing code, it helps to understand the difference between VisionKit and Vision.

The Vision framework is more focused on image analysis. It gives you APIs for things like text recognition, face detection, barcode detection, object tracking, and image classification.

VisionKit is more user-facing. It gives you ready-made UI components for scanning documents and data using the camera.

A simple way to think about it:

Vision is the engine.

VisionKit is the scanner experience.

For example, if you want to recognize text from an image manually, you may use Vision with VNRecognizeTextRequest.

But if you want to present a document scanner UI to the user, capture pages, and get scanned images back, VisionKit makes that much easier.

In this article, we will start with VisionKit document scanning.

What We Are Building

We will build a small SwiftUI app with the following features:

• A button to open the document scanner
• A VisionKit wrapper for VNDocumentCameraViewController
• A SwiftUI view to display scanned pages
• A simple model to store scanned images
• Optional text recognition using Vision

This is not a full production scanner app yet. But it gives us the foundation.

Once this works, you can extend it into:

• A receipt scanner
• A handwritten notes scanner
• A PDF scanner
• A business card scanner
• A document archive app

That is what I like about frameworks like this. You start with one simple demo, and suddenly you can see many product ideas around it.

Step 1: Create a New SwiftUI Project

Create a new iOS app in Xcode.

Use:

Interface: SwiftUI
Language: Swift

Then import VisionKit where needed:

import VisionKit

One important thing to remember is that VNDocumentCameraViewController is a UIKit controller. Since we are working in SwiftUI, we need to wrap it using UIViewControllerRepresentable.

This is a common pattern in SwiftUI when Apple gives us a UIKit API but we want to use it inside a SwiftUI app.

Step 2: Add Camera Permission

Because we are using the camera, we need to add camera permission in Info.plist.

Add this key:

<key>NSCameraUsageDescription</key>
<string>This app needs camera access to scan documents.</string>

Without this, your app will crash when trying to access the camera.

This is one of those small things that is easy to forget, especially when you are excited to test the scanner.

Step 3: Create a Scanned Document Model

Let us create a simple model to hold the scanned pages.

import SwiftUI

struct ScannedDocument: Identifiable {
    let id = UUID()
    var title: String
    var pages: [UIImage]
    var createdAt: Date
}

For now, we are keeping things simple.

Each scanned document has:

• A title
• A list of scanned page images
• A created date

Later, you could add more fields like:

• Folder name
• PDF URL
• OCR text
• Tags
• Last updated date

But for this article, images are enough.

Step 4: Create the VisionKit Scanner Wrapper

Now we need to wrap VNDocumentCameraViewController so it can be used in SwiftUI.

Create a new file called DocumentScannerView.swift.

import SwiftUI
import VisionKit

struct DocumentScannerView: UIViewControllerRepresentable {
    var onScanComplete: ([UIImage]) -> Void
    var onCancel: () -> Void
    func makeUIViewController(context: Context) -> VNDocumentCameraViewController {
        let scannerViewController = VNDocumentCameraViewController()
        scannerViewController.delegate = context.coordinator
        return scannerViewController
    }
    func updateUIViewController(
        _ uiViewController: VNDocumentCameraViewController,
        context: Context
    ) {
        // No update needed for this example
    }
    func makeCoordinator() -> Coordinator {
        Coordinator(
            onScanComplete: onScanComplete,
            onCancel: onCancel
        )
    }
    final class Coordinator: NSObject, VNDocumentCameraViewControllerDelegate {
        private let onScanComplete: ([UIImage]) -> Void
        private let onCancel: () -> Void
        init(
            onScanComplete: @escaping ([UIImage]) -> Void,
            onCancel: @escaping () -> Void
        ) {
            self.onScanComplete = onScanComplete
            self.onCancel = onCancel
        }
        func documentCameraViewController(
            _ controller: VNDocumentCameraViewController,
            didFinishWith scan: VNDocumentCameraScan
        ) {
            var scannedPages: [UIImage] = []
            for pageIndex in 0..<scan.pageCount {
                let image = scan.imageOfPage(at: pageIndex)
                scannedPages.append(image)
            }
            controller.dismiss(animated: true) {
                self.onScanComplete(scannedPages)
            }
        }
        func documentCameraViewControllerDidCancel(
            _ controller: VNDocumentCameraViewController
        ) {
            controller.dismiss(animated: true) {
                self.onCancel()
            }
        }
        func documentCameraViewController(
            _ controller: VNDocumentCameraViewController,
            didFailWithError error: Error
        ) {
            print("Document scanner failed: \(error.localizedDescription)")
            controller.dismiss(animated: true) {
                self.onCancel()
            }
        }
    }
}

There is quite a bit happening here, so let us break it down.

DocumentScannerView conforms to UIViewControllerRepresentable. This is what allows us to use a UIKit view controller inside SwiftUI.

Inside makeUIViewController, we create a VNDocumentCameraViewController.

Then we assign its delegate to the coordinator.

The coordinator receives scanner events.

When scanning finishes, this method is called:

func documentCameraViewController(
    _ controller: VNDocumentCameraViewController,
    didFinishWith scan: VNDocumentCameraScan
)

The scan object contains all the scanned pages. We loop through each page and convert it into a UIImage.

for pageIndex in 0..<scan.pageCount {
    let image = scan.imageOfPage(at: pageIndex)
    scannedPages.append(image)
}

Then we send those images back to SwiftUI using the onScanComplete closure.

This is one of my favorite parts of mixing UIKit and SwiftUI. UIKit still handles the scanner experience, but SwiftUI controls the app state.

Step 5: Build the Main SwiftUI Screen

Now let us create the main view.

import SwiftUI

struct ContentView: View {
    @State private var documents: [ScannedDocument] = []
    @State private var isShowingScanner = false
    var body: some View {
        NavigationStack {
            VStack {
                if documents.isEmpty {
                    ContentUnavailableView(
                        "No Scans Yet",
                        systemImage: "doc.viewfinder",
                        description: Text("Tap Scan Document to create your first scan.")
                    )
                } else {
                    List {
                        ForEach(documents) { document in
                            NavigationLink {
                                ScanDetailView(document: document)
                            } label: {
                                VStack(alignment: .leading, spacing: 6) {
                                    Text(document.title)
                                        .font(.headline)
                                    Text("\(document.pages.count) page(s)")
                                        .font(.subheadline)
                                        .foregroundStyle(.secondary)
                                    Text(document.createdAt.formatted())
                                        .font(.caption)
                                        .foregroundStyle(.secondary)
                                }
                                .padding(.vertical, 4)
                            }
                        }
                    }
                }
            }
            .navigationTitle("VisionKit Scanner")
            .toolbar {
                ToolbarItem(placement: .topBarTrailing) {
                    Button {
                        isShowingScanner = true
                    } label: {
                        Label("Scan", systemImage: "camera.viewfinder")
                    }
                }
            }
            .sheet(isPresented: $isShowingScanner) {
                DocumentScannerView(
                    onScanComplete: { images in
                        let newDocument = ScannedDocument(
                            title: "Scan \(documents.count + 1)",
                            pages: images,
                            createdAt: Date()
                        )
                        documents.append(newDocument)
                        isShowingScanner = false
                    },
                    onCancel: {
                        isShowingScanner = false
                    }
                )
            }
        }
    }
}

This gives us a simple scanner home screen.

If there are no scanned documents, we show an empty state.

If documents exist, we show them in a list.

When the user taps the scan button, we present the VisionKit scanner as a sheet.

.sheet(isPresented: $isShowingScanner) {
    DocumentScannerView(
        onScanComplete: { images in
            let newDocument = ScannedDocument(
                title: "Scan \(documents.count + 1)",
                pages: images,
                createdAt: Date()
            )

        documents.append(newDocument)
                    isShowingScanner = false
                },
                onCancel: {
                    isShowingScanner = false
                }
            )
        }

This connects nicely with the SwiftUI state concepts I wrote about before.

The scanner produces images.

SwiftUI stores those images in @State.

The UI updates automatically.

This is exactly why understanding state is so important in SwiftUI. Frameworks like VisionKit give you the feature, but SwiftUI state decides how your app reacts to it.

Step 6: Create a Detail View for Scanned Pages

Now let us create a view to preview the scanned pages.

import SwiftUI

struct ScanDetailView: View {
    let document: ScannedDocument
    var body: some View {
        ScrollView {
            LazyVStack(spacing: 20) {
                ForEach(Array(document.pages.enumerated()), id: \.offset) { index, image in
                    VStack(alignment: .leading, spacing: 8) {
                        Text("Page \(index + 1)")
                            .font(.headline)
                            .padding(.horizontal)
                        Image(uiImage: image)
                            .resizable()
                            .scaledToFit()
                            .clipShape(RoundedRectangle(cornerRadius: 12))
                            .shadow(radius: 4)
                            .padding(.horizontal)
                    }
                }
            }
            .padding(.vertical)
        }
        .navigationTitle(document.title)
        .navigationBarTitleDisplayMode(.inline)
    }
}

Now when the user scans a document, they can tap it and see all scanned pages.

This is already a useful little app.

It does not save anything permanently yet. It does not generate a PDF yet. It does not run OCR yet.

But the core scanning flow works.

That is usually how I like to build features.

First, make the core path work.

Then improve it.

Step 7: Add OCR Using Vision

VisionKit helps us scan the document, but what if we want to extract text from the scanned page?

For that, we can use Apple’s Vision framework.

Create a new file called TextRecognizer.swift.

import UIKit
import Vision

final class TextRecognizer {
    func recognizeText(from image: UIImage) async throws -> String {
        guard let cgImage = image.cgImage else {
            return ""
        }
        return try await withCheckedThrowingContinuation { continuation in
            let request = VNRecognizeTextRequest { request, error in
                if let error {
                    continuation.resume(throwing: error)
                    return
                }
                guard let observations = request.results as? [VNRecognizedTextObservation] else {
                    continuation.resume(returning: "")
                    return
                }
                let recognizedStrings = observations.compactMap { observation in
                    observation.topCandidates(1).first?.string
                }
                continuation.resume(returning: recognizedStrings.joined(separator: "\n"))
            }
            request.recognitionLevel = .accurate
            request.usesLanguageCorrection = true
            let handler = VNImageRequestHandler(cgImage: cgImage)
            do {
                try handler.perform([request])
            } catch {
                continuation.resume(throwing: error)
            }
        }
    }
}

This class takes a UIImage and returns recognized text.

The important part is this request:

let request = VNRecognizeTextRequest { request, error in
    // Handle OCR result
}

Then we configure it:

request.recognitionLevel = .accurate
request.usesLanguageCorrection = true

For many document scanning use cases, .accurate is a good starting point. If you need faster recognition, you can explore other options later.

Step 8: Show Recognized Text in the Detail View

Now let us update our detail view so it can run OCR on the first page.

import SwiftUI

struct ScanDetailView: View {
    let document: ScannedDocument
    @State private var recognizedText = ""
    @State private var isRecognizingText = false
    @State private var errorMessage: String?
    private let textRecognizer = TextRecognizer()
    var body: some View {
        ScrollView {
            LazyVStack(spacing: 20) {
                ForEach(Array(document.pages.enumerated()), id: \.offset) { index, image in
                    VStack(alignment: .leading, spacing: 8) {
                        Text("Page \(index + 1)")
                            .font(.headline)
                            .padding(.horizontal)
                        Image(uiImage: image)
                            .resizable()
                            .scaledToFit()
                            .clipShape(RoundedRectangle(cornerRadius: 12))
                            .shadow(radius: 4)
                            .padding(.horizontal)
                    }
                }
                Divider()
                    .padding(.horizontal)
                VStack(alignment: .leading, spacing: 12) {
                    Button {
                        Task {
                            await recognizeTextFromFirstPage()
                        }
                    } label: {
                        if isRecognizingText {
                            ProgressView()
                        } else {
                            Label("Recognize Text", systemImage: "text.viewfinder")
                        }
                    }
                    .buttonStyle(.borderedProminent)
                    .disabled(isRecognizingText || document.pages.isEmpty)
                    if let errorMessage {
                        Text(errorMessage)
                            .foregroundStyle(.red)
                            .font(.footnote)
                    }
                    if !recognizedText.isEmpty {
                        Text("Recognized Text")
                            .font(.headline)
                        Text(recognizedText)
                            .font(.body)
                            .textSelection(.enabled)
                            .padding()
                            .frame(maxWidth: .infinity, alignment: .leading)
                            .background(Color(.secondarySystemBackground))
                            .clipShape(RoundedRectangle(cornerRadius: 12))
                    }
                }
                .padding(.horizontal)
            }
            .padding(.vertical)
        }
        .navigationTitle(document.title)
        .navigationBarTitleDisplayMode(.inline)
    }
    private func recognizeTextFromFirstPage() async {
        guard let firstPage = document.pages.first else {
            return
        }
        isRecognizingText = true
        errorMessage = nil
        do {
            recognizedText = try await textRecognizer.recognizeText(from: firstPage)
        } catch {
            errorMessage = "Failed to recognize text: \(error.localizedDescription)"
        }
        isRecognizingText = false
    }
}

Now the app can scan a document and recognize text from the first page.

Again, this is not a production OCR pipeline yet, but it is enough to understand the flow.

The user scans a document.

VisionKit gives us images.

Vision extracts text from those images.

SwiftUI displays the result.

That is a pretty powerful combination.

Step 9: Move Logic Toward MVVM

In my MVVM article, I talked about why moving logic away from views helps as the app grows.

This scanner example is a perfect case where MVVM starts to make sense.

Right now, ContentView owns the scanned documents directly:

@State private var documents: [ScannedDocument] = []

That is fine for a small demo.

But if this app grows, we may want a view model.

Create a file called ScannerViewModel.swift.

import SwiftUI

@MainActor
final class ScannerViewModel: ObservableObject {
    @Published private(set) var documents: [ScannedDocument] = []
    @Published var isShowingScanner = false
    func addScannedImages(_ images: [UIImage]) {
        let document = ScannedDocument(
            title: "Scan \(documents.count + 1)",
            pages: images,
            createdAt: Date()
        )
        documents.append(document)
    }
    func showScanner() {
        isShowingScanner = true
    }
    func hideScanner() {
        isShowingScanner = false
    }
}

Then update ContentView:

import SwiftUI

struct ContentView: View {
    @StateObject private var viewModel = ScannerViewModel()
    var body: some View {
        NavigationStack {
            VStack {
                if viewModel.documents.isEmpty {
                    ContentUnavailableView(
                        "No Scans Yet",
                        systemImage: "doc.viewfinder",
                        description: Text("Tap Scan Document to create your first scan.")
                    )
                } else {
                    List {
                        ForEach(viewModel.documents) { document in
                            NavigationLink {
                                ScanDetailView(document: document)
                            } label: {
                                VStack(alignment: .leading, spacing: 6) {
                                    Text(document.title)
                                        .font(.headline)
                                    Text("\(document.pages.count) page(s)")
                                        .font(.subheadline)
                                        .foregroundStyle(.secondary)
                                    Text(document.createdAt.formatted())
                                        .font(.caption)
                                        .foregroundStyle(.secondary)
                                }
                                .padding(.vertical, 4)
                            }
                        }
                    }
                }
            }
            .navigationTitle("VisionKit Scanner")
            .toolbar {
                ToolbarItem(placement: .topBarTrailing) {
                    Button {
                        viewModel.showScanner()
                    } label: {
                        Label("Scan", systemImage: "camera.viewfinder")
                    }
                }
            }
            .sheet(isPresented: $viewModel.isShowingScanner) {
                DocumentScannerView(
                    onScanComplete: { images in
                        viewModel.addScannedImages(images)
                        viewModel.hideScanner()
                    },
                    onCancel: {
                        viewModel.hideScanner()
                    }
                )
            }
        }
    }
}

This version feels cleaner.

The view is mostly responsible for UI.

The view model handles scanner-related state.

This is where the concepts from SwiftUI state and MVVM start connecting with real frameworks.

It is one thing to learn @State, @StateObject, and ObservableObject in isolation. It is another thing to use them while integrating a real Apple framework like VisionKit.

Step 10: What About Live Text and QR Scanning?

So far, we used VisionKit for document scanning.

But VisionKit also has DataScannerViewController, which can scan live data from the camera.

This is useful when you want the user to point the camera at text, QR codes, barcodes, phone numbers, links, or other supported content.

A simple example looks like this:

import SwiftUI
import VisionKit

struct LiveDataScannerView: UIViewControllerRepresentable {
    var onRecognizedText: (String) -> Void
    func makeUIViewController(context: Context) -> DataScannerViewController {
        let scanner = DataScannerViewController(
            recognizedDataTypes: [
                .text(languages: ["en-US"])
            ],
            qualityLevel: .balanced,
            recognizesMultipleItems: true,
            isHighFrameRateTrackingEnabled: true,
            isHighlightingEnabled: true
        )
        scanner.delegate = context.coordinator
        do {
            try scanner.startScanning()
        } catch {
            print("Failed to start scanning: \(error.localizedDescription)")
        }
        return scanner
    }
    func updateUIViewController(
        _ uiViewController: DataScannerViewController,
        context: Context
    ) {
        // No update needed for this example
    }
    func makeCoordinator() -> Coordinator {
        Coordinator(onRecognizedText: onRecognizedText)
    }
    final class Coordinator: NSObject, DataScannerViewControllerDelegate {
        private let onRecognizedText: (String) -> Void
        init(onRecognizedText: @escaping (String) -> Void) {
            self.onRecognizedText = onRecognizedText
        }
        func dataScanner(
            _ dataScanner: DataScannerViewController,
            didTapOn item: RecognizedItem
        ) {
            switch item {
            case .text(let text):
                onRecognizedText(text.transcript)
            case .barcode(let barcode):
                if let payload = barcode.payloadStringValue {
                    onRecognizedText(payload)
                }
            @unknown default:
                break
            }
        }
    }
}

This is a different experience from document scanning.

With document scanning, the user captures pages.

With live data scanning, the camera is continuously looking for useful information.

You could use this for:

• QR code scanning
• Barcode scanning
• Extracting a phone number from a business card
• Detecting URLs
• Reading labels
• Scanning short pieces of text

If you are building real-world iOS tools, this opens up a lot of possibilities.

A Few Practical Notes

There are a few things I would keep in mind before using VisionKit in a production app.

First, always test on a real device. Camera-based APIs are not something you should fully trust from the simulator.

Second, design for failure. The user may cancel scanning. Camera permission may be denied. Text recognition may fail. The scanned image may be blurry.

Third, keep the first version simple. It is very tempting to add PDF export, OCR, folders, cloud sync, search, tags, and sharing immediately. But the better approach is to first make scanning feel good.

Fourth, think about privacy. If you are scanning receipts, IDs, documents, or notes, users care about where that data goes. If everything stays local, say that clearly. If you upload files to a server, explain why and how.

Where This Can Go Next

This little demo can become much more useful.

The next features I would add are:

• Save scanned documents locally
• Export scanned pages as PDF
• Add OCR for all pages
• Add search across recognized text
• Add folders
• Add rename and delete
• Add share sheet support
• Add basic image cleanup filters
• Add iCloud sync later if needed

This is how I usually like learning a new framework.

Not by reading every API first.

Not by trying to build a perfect app immediately.

But by building one small useful flow, then improving it piece by piece.

VisionKit is a good framework for that style of learning because you can get something working quickly, but there is still enough depth to build a real app from it.

I have also uploaded the complete sample project to GitHub here:
https://github.com/sanjaynela/visionkit-scanner-ios

Feel free to clone it, try it on a real iPhone, and modify it for your own scanner-style app. If you build something interesting with VisionKit, I would love to hear about it.

Final Thoughts

Trying VisionKit reminded me why I enjoy iOS development.

Apple gives us these powerful native frameworks, but the real learning happens when we connect them to actual app ideas.

A document scanner sounds simple at first. But once you build it, you start thinking about OCR, PDFs, local storage, search, folders, privacy, and user experience.

That is when a small demo becomes a real product idea.

If you already understand SwiftUI state and MVVM, VisionKit is a nice next framework to explore because it gives you something practical to build. You can use SwiftUI for the app structure, MVVM for organization, VisionKit for scanning, and Vision for text recognition.

That combination is powerful.

And honestly, this is the kind of framework I wish I had tried earlier.

Sometimes the best way to learn a new Apple framework is not to wait until you need it at work. It is to build a small personal app, break a few things, fix them, and slowly understand where the framework fits.

That is exactly what I wanted to do with VisionKit.

And now I can already see a few app ideas coming from it.

I Finally Tried Apple VisionKit: Building a Simple Document Scanner in SwiftUI was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

A while back, I wrote an article on Jetpack Compose navigation where I walked through routes, arguments, nested graphs, and real-world flows. That article came from a very real place, just like my earlier SwiftUI pieces. I had revisited older code, noticed patterns that didn’t scale well, and wanted to document what finally clicked for me.

That article is still useful. In fact, I think it works well as a beginner-friendly guide or for apps with a handful of screens. If you have a home screen, a settings screen, maybe a details page, the approach there is more than enough.

But after working on larger apps, I realized something important.

That approach is not enough once your app grows.

It does not fully answer how to structure navigation when you have 20, 30, or 50 screens. It also does not address how navigation interacts with state, which is where most real-world complexity actually comes from.

So this article is the follow-up I wish I had written earlier.

This is not about learning the API. It is about how to structure navigation so it does not fall apart as your app grows.

When navigation stops being simple

Navigation looks easy in demos.

You create a NavHost, define a few composable destinations, and call navigate(). Everything works. You feel like you understand it.

Then the app starts becoming real.

You add login flows. You add onboarding. You introduce bottom tabs. You need to navigate after an API call succeeds. You need to clear the back stack after authentication. You need deep links. You have multiple features linking to each other.

And suddenly, navigation is not just moving between screens anymore. It becomes architecture.

That is the point where most apps start getting messy.

The mental model still holds

Even for large apps, the core mental model does not change.

• A route identifies a destination
• NavHost defines the map
• NavController moves through that map

What changes is how you organize that map.

In small apps, a single NavHost with a few routes is fine.

In larger apps, that same approach turns into a giant file that is hard to reason about, hard to maintain, and easy to break.

The mistake I made early on

The biggest mistake I made when I first used Compose Navigation in a real project was this:

I kept everything in one place.

One NavHost. Dozens of composable() blocks. Routes defined inline. Navigation logic scattered across screens.

It worked, but it did not scale.

Over time:

• The file became too large to navigate mentally
• Different flows started interfering with each other
• Back stack behavior became harder to reason about
• Refactoring became risky

The fix was not learning new APIs. The fix was changing how I structured navigation.

How to structure navigation in a real app

If your app has many screens, the goal is not to centralize everything into one file.

The goal is to centralize ownership, while splitting structure.

A pattern that has worked well for me looks like this:

• One root NavHost
• Separate navigation graphs per feature or flow
• Centralized route definitions
• Navigation handled at the route or container level

In practice, that looks like this.

Root navigation

@Composable
fun App() {
    val navController = rememberNavController()
    AppNavHost(navController)
}

@Composable
fun AppNavHost(navController: NavHostController) {
    NavHost(
        navController = navController,
        startDestination = Graph.AUTH,
        route = Graph.ROOT
    ) {
        authNavGraph(navController)
        mainNavGraph(navController)
    }
}

The root graph only answers one question:

What are the major flows in the app?

Not every screen.

Feature graphs

Each flow gets its own navigation graph.

For example, authentication:

fun NavGraphBuilder.authNavGraph(navController: NavHostController) {
    navigation(
        startDestination = "login",
        route = Graph.AUTH
    ) {
        composable("login") {
            LoginScreen(
                onLoginSuccess = {
                    navController.navigate(Graph.MAIN) {
                        popUpTo(Graph.AUTH) { inclusive = true }
                    }
                }
            )
        }
composable("signup") {
            SignupScreen()
        }
    }
}

And your main app flow:

fun NavGraphBuilder.mainNavGraph(navController: NavHostController) {
    navigation(
        startDestination = "home",
        route = Graph.MAIN
    ) {
        composable("home") {
            HomeRoute(navController)
        }
composable("settings") {
            SettingsScreen()
        }
    }
}

This keeps related screens together and prevents your navigation from becoming one giant flat graph.

Routes should still be structured

Even in large apps, the rule from the previous article still applies.

Do not scatter route strings everywhere.

Use helpers.

sealed class AppScreen(val route: String) {
    data object Home : AppScreen("home")
    data object UserDetails : AppScreen("user/{userId}") {
      fun createRoute(userId: Long) = "user/$userId"
    }
}

This small habit saves you from a surprising number of bugs later.

Where state actually lives (this is the missing piece)

This is the part I did not cover well in my previous article. Navigation does not own your data. It only moves you between screens. In real apps, state should live in one of three places.

1. Navigation arguments

Only pass small, stable values:

• IDs n- filters
• simple flags

Example:

navController.navigate(UserDetails.createRoute(userId))

2. ViewModel (screen state)

Each screen should have a ViewModel that loads and holds business data.

class UserDetailsViewModel(
    savedStateHandle: SavedStateHandle
) : ViewModel() {

private val userId: Long =
        checkNotNull(savedStateHandle["userId"])
    val uiState = MutableStateFlow(UserDetailsUiState())
}

This is where:

• API calls happen
• loading and error states live
• business logic is handled

3. Composable state

UI-only state stays in the composable.

var text by rememberSaveable { mutableStateOf("") }

This includes:

• text fields
• toggles
• temporary UI selections

Why this separation matters

If you try to push state through navigation, things break quickly.

• Objects become hard to serialize
• Data becomes stale
• Navigation becomes fragile

Passing IDs and loading data in the destination keeps things predictable.

Linking many screens cleanly

When multiple screens link to each other, the temptation is to call NavController everywhere.

That works, but it spreads navigation logic across the UI.

A cleaner approach is to keep navigation at the route level.

@Composable
fun HomeRoute(navController: NavHostController) {
    HomeScreen(
        onOpenSettings = {
            navController.navigate("settings")
        },
        onOpenUser = { id ->
            navController.navigate("user/$id")
        }
    )
}

@Composable
fun HomeScreen(
    onOpenSettings: () -> Unit,
    onOpenUser: (Long) -> Unit
) {
    Column {
        Button(onClick = onOpenSettings) {
            Text("Settings")
        }
        Button(onClick = { onOpenUser(42) }) {
            Text("Open User")
        }
    }
}

Now your UI stays reusable and easier to test.

Bottom navigation and multiple flows

For apps with tabs, navigation needs to handle multiple sections cleanly.

A common pattern is:

navController.navigate(route) {
    popUpTo(navController.graph.startDestinationId) {
        saveState = true
    }
    launchSingleTop = true
    restoreState = true
}

This:

• avoids duplicate screens
• preserves tab state
• restores state when returning to a tab

This is one of those small details that makes a big difference in how polished your app feels.

The structure that scales

If I had to summarize the approach that works for large apps, it would be this:

• One root NavHost
• Nested graphs per feature
• Centralized route helpers
• ViewModels for screen state
• Composables focused on UI only

This keeps navigation understandable even months later.

Putting it all together (MainActivity + graphs + routes + state)

To make this concrete, here’s a minimal but realistic wiring of everything together: a thin MainActivity, a root App, the AppNavHost, feature graphs, route helpers, and a screen with a ViewModel.

MainActivity

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            App()
        }
    }
}

App entry

@Composable
fun App() {
    val navController = rememberNavController()
    AppNavHost(navController = navController)
}

Graph constants

object Graph {
    const val ROOT = "root"
    const val AUTH = "auth"
    const val MAIN = "main"
}

Route helpers

sealed interface Destination { val route: String }

sealed interface AuthDest : Destination {
    data object Login : AuthDest { override val route = "login" }
    data object Signup : AuthDest { override val route = "signup" }
}
sealed interface MainDest : Destination {
    data object Home : MainDest { override val route = "home" }
    data object Settings : MainDest { override val route = "settings" }
    data object UserDetails : MainDest {
        override val route = "user/{userId}"
        const val ARG = "userId"
        fun create(userId: Long) = "user/$userId"
    }
}

Root NavHost

@Composable
fun AppNavHost(navController: NavHostController) {
    NavHost(
        navController = navController,
        startDestination = Graph.AUTH,
        route = Graph.ROOT
    ) {
        authNavGraph(navController)
        mainNavGraph(navController)
    }
}

Auth graph

fun NavGraphBuilder.authNavGraph(navController: NavHostController) {
    navigation(startDestination = AuthDest.Login.route, route = Graph.AUTH) {
        composable(AuthDest.Login.route) {
            LoginRoute(
                onLoginSuccess = {
                    navController.navigate(Graph.MAIN) {
                        popUpTo(Graph.AUTH) { inclusive = true }
                    }
                },
                onSignup = { navController.navigate(AuthDest.Signup.route) }
            )
        }

composable(AuthDest.Signup.route) {
            SignupRoute(onDone = { navController.popBackStack() })
        }
    }
}

Main graph (with arguments)

fun NavGraphBuilder.mainNavGraph(navController: NavHostController) {
    navigation(startDestination = MainDest.Home.route, route = Graph.MAIN) {
        composable(MainDest.Home.route) {
            HomeRoute(
                onOpenSettings = { navController.navigate(MainDest.Settings.route) },
                onOpenUser = { id -> navController.navigate(MainDest.UserDetails.create(id)) }
            )
        }
composable(MainDest.Settings.route) {
            SettingsRoute()
        }
        composable(
            route = MainDest.UserDetails.route,
            arguments = listOf(navArgument(MainDest.UserDetails.ARG) {
                type = NavType.LongType
            })
        ) { entry ->
            val userId = entry.arguments?.getLong(MainDest.UserDetails.ARG)
                ?: return@composable
            UserDetailsRoute(userId = userId)
        }
    }
}

Route vs UI (keeping NavController out of leaf UI)

@Composable
fun HomeRoute(
    onOpenSettings: () -> Unit,
    onOpenUser: (Long) -> Unit
) {
    HomeScreen(
        onOpenSettings = onOpenSettings,
        onOpenUser = onOpenUser
    )
}

@Composable
fun HomeScreen(
    onOpenSettings: () -> Unit,
    onOpenUser: (Long) -> Unit
) {
    Column {
        Button(onClick = onOpenSettings) { Text("Settings") }
        Button(onClick = { onOpenUser(42L) }) { Text("Open User") }
    }
}

ViewModel-backed state on a destination

data class UserDetailsUiState(
    val isLoading: Boolean = true,
    val name: String = "",
    val error: String? = null
)

class UserDetailsViewModel(
    savedStateHandle: SavedStateHandle
) : ViewModel() {
    private val userId: Long = checkNotNull(savedStateHandle[MainDest.UserDetails.ARG])
    private val _uiState = MutableStateFlow(UserDetailsUiState())
    val uiState: StateFlow<UserDetailsUiState> = _uiState
    init {
        // fake load
        viewModelScope.launch {
            delay(300)
            _uiState.value = UserDetailsUiState(isLoading = false, name = "User #$userId")
        }
    }
}
@Composable
fun UserDetailsRoute(
    userId: Long,
    viewModel: UserDetailsViewModel = viewModel()
) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()
    UserDetailsScreen(uiState = uiState)
}
@Composable
fun UserDetailsScreen(uiState: UserDetailsUiState) {
    when {
        uiState.isLoading -> Text("Loading...")
        uiState.error != null -> Text("Error: ${uiState.error}")
        else -> Text("Hello ${uiState.name}")
    }
}

This is the full loop:

• MainActivity hosts the app
• App owns the NavController
• AppNavHost defines the root graph
• Feature graphs group related flows
• Route helpers define destinations and arguments
• Route composables handle navigation wiring
• ViewModels own screen state
• UI composables render state and emit events

If you follow this structure, you can keep adding screens, flows, and features without your navigation turning into a giant, fragile file.

Conclusion

My previous article focused on helping Compose navigation click. This one is about making it scale.

For small apps, a single NavHost and a few routes are enough. But once your app grows, navigation is no longer just about moving between screens. It becomes part of your architecture. The biggest shift for me was realizing this:

Navigation should stay simple. Structure is what makes it powerful.

Once you separate graphs, routes, and state properly, everything becomes easier to reason about.

And more importantly, easier to maintain when your app inevitably grows.

If this helped, I would really appreciate a clap so more developers can find it, a follow if you want more practical mobile engineering write-ups, or a comment with how you are currently structuring navigation in your app.

That is usually where the most interesting discussions happen.

Scaling Navigation in Jetpack Compose: From Simple Apps to Real-World Architecture was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

For the last few months, my AI coding workflow has been all over the place, but mostly in a good way. I have been using Cursor heavily, I have been using the Codex extension inside the IDE, and I have also been bouncing between Claude Code and Codex depending on the kind of work I am doing.

Claude Code became one of those tools I genuinely enjoyed because it made me think more clearly about planning, reusable workflows, skills, and how to make AI coding feel less random. I even wrote about that journey before in my Claude Code article, Claude Code Skills 2.0: The Workflow Upgrade That Made Claude Click for Me.

I also recently wrote about Codex 5.4 after hearing that it could control the computer and getting curious enough to try it myself: I Heard Codex 5.4 Could Control the Computer, So I Had to Try It. So I was already familiar with Codex. At least I thought I was.

Until recently, my setup was still very IDE-centered. Cursor was my main editor, the Codex extension sat on the side, the terminal lived at the bottom, Git was somewhere nearby, and I had the usual developer mess of open tabs, half-read files, and temporary debugging thoughts scattered across the workspace.

That worked well for a while, but recently Cursor started feeling laggy for me. Not unusable, but enough that I started noticing the friction. Opening files felt slower, switching context felt heavier, and sometimes the editor felt like it was trying to do too many things at once.

So I did something I had not done seriously in a while: I moved back to Visual Studio Code. And honestly, VS Code felt refreshing again. It felt lighter, familiar, and predictable.

Then I realized something else. Codex had a dedicated app. Not just an extension, not just something inside ChatGPT, and not just a terminal workflow. A real Codex app.

So I tried it, and I was surprised by how quickly it clicked. At first, I assumed it would just be another wrapper around the same coding agent, but the experience felt different because it was not trying to be a full IDE in the traditional sense. It felt more like a focused workspace for supervising coding tasks.

That distinction became important once I started using it on an actual project instead of just poking around. The first thing that surprised me was simple: I could actually see the code files inside the Codex app. That may sound small, but it changed how I felt while using it.

With many AI coding tools, I sometimes feel like I am sending prompts into a black box. The assistant says it changed a file, then I jump back to the IDE, open the file, check the diff, run tests, inspect the changes, and decide whether I trust it. That workflow is fine, but it creates constant switching.

In the Codex app, I could stay inside the same place longer. I could ask Codex to make a change, inspect what it touched, review the diff, and continue the conversation without immediately jumping back into my editor.

For example, one of the first prompts I like using in a project is not a coding prompt at all. I might say:

Review the authentication flow and explain where the app decides whether to show the login screen or the dashboard.

Do not change code yet. Just explain the current flow and mention the files involved.

This is the kind of prompt I now use before making changes because it gives me confidence in the agent’s understanding. Instead of immediately asking the AI to “fix” something, I first ask it to map the codebase.

If it identifies the wrong files, I know I need to correct it before it starts editing. If it explains the flow correctly, then I can move forward. Codex came back with an explanation of the relevant files and logic, and I could inspect those files directly in the app.

That was the first moment where it did not feel like a chat assistant floating outside my codebase. It felt closer to a coding workspace.

Why This Felt Different From an IDE Extension

IDE extensions are great, and I still like them, but they usually live inside the mental model of an IDE. You open your editor, ask for a change, the assistant edits files, and you review everything from there.

The Codex app made me think differently. Instead of “I am coding and AI is helping me,” it felt more like “I am supervising coding tasks.” When I am actively implementing something myself, I still like an IDE because I want autocomplete, tabs, terminal, debugger, Git panel, and all the normal muscle memory.

But when I am exploring a codebase, planning a refactor, asking for a feature, reviewing changes, or running multiple ideas in parallel, the Codex app feels more natural. It changes the center of gravity from typing code to guiding work.

For example, instead of opening my IDE and manually jumping across files, I can start with something like:

I want to add a settings screen where users can toggle dark mode.

First, inspect the current navigation and state management structure.
Then propose a plan.
Do not edit files yet.

This is not really an “edit this line” task. It is a thinking task. And that is where the Codex app started to become useful for me.

One thing I have learned from using Claude Code and Codex is that I should not always start by asking the agent to code. That sounds obvious, but it is very easy to forget. When we see a coding agent, our first instinct is usually to say, “Build this feature.”

But for anything beyond a small change, I prefer plan mode first. My typical planning prompt looks like this:

I want to add automatic retry logic when an API request fails due to a network issue.

Before writing code:
1. Inspect the current API client.
2. Find where errors are handled.
3. Suggest a minimal implementation plan.
4. Mention risks or edge cases.
5. Do not edit files yet.

This kind of prompt gives me a much better result than immediately asking Codex to implement retry logic. I want to see how it understands the codebase before it starts editing.

If it identifies the wrong files, I can stop early. If it suggests a huge refactor for a simple task, I can push back. If it misses an important edge case, I can add that requirement before any code changes happen.

For me, plan mode is not about slowing down productivity. It is about avoiding messy productivity, and there is a big difference between the two.

Why I Still Like Chat Mode for Ideas

When I am just exploring ideas, I prefer chat mode. Plan mode is great when I already know what I want to build, but sometimes I do not. Sometimes I am just thinking through tradeoffs.

For example, I might say:

I am thinking of adding a local cache for this app, but I am not sure if it should be SQLite, file-based JSON, or UserDefaults.

Look at the current project and help me think through the tradeoffs.

That is not a coding task yet. That is a conversation. This is where I prefer chat mode because I want to go back and forth.

I want to ask whether the approach would make testing harder, whether there is a simpler first version, whether it becomes a problem if I add sync later, or how it compares to what I would do in a production app. I have noticed that when I separate thinking from coding, I get much better results.

Chat mode is where I explore, plan mode is where I structure, and implementation is where I execute. That small separation has made my AI coding workflow much cleaner.

Reviewing Changes Is Where the App Really Helps

One of my favorite parts of the Codex app is reviewing changes. I did not appreciate this enough until I started using it. When an AI coding tool modifies files, the quality of the experience depends heavily on how easy it is to review what changed.

If reviewing is painful, you either blindly trust the AI or waste time jumping between tools. Neither is good. In the Codex app, the review experience makes the workflow feel more complete because I can inspect file changes closer to the conversation that created them.

For example, if I ask Codex to refactor a user profile screen so network loading logic moves into a view model, I do not want to simply accept everything. I want to check whether it moved only the network logic, whether it accidentally changed the UI, whether it renamed things unnecessarily, and whether it added too much abstraction.

I also want to know whether tests still make sense and whether the pattern matches the rest of the app. That is why one of my personal rules now is simple: never accept big changes without reading the diff.

If Codex changes one small file, I can review quickly. But if it touches five, ten, or fifteen files, I slow down. I ask:

Summarize the changes by file.
Mention why each file was changed.
Call out any behavior changes separately from refactoring changes.

This gives me a clean review summary before I inspect the diff myself. Then I often ask:

Are there any changes here that are not strictly required for the original task?

That question is surprisingly useful because AI agents sometimes make “helpful” changes that are not really necessary. They might rename variables, move code around, add helper functions, or slightly restructure things because it looks cleaner.

Sometimes that is good, but sometimes it creates extra review burden. So I like to force Codex to separate required changes from optional cleanup. Another prompt I use is:

Before I accept this, separate the changes into:
1. Required for the feature
2. Nice-to-have cleanup
3. Potentially risky changes

This makes the review process feel much more controlled. It also reminds me that AI coding is not just about generating code. It is about safely accepting code.

The prompt matters, but the review matters even more.

Git Inside Codex Is More Useful Than I Expected

Another feature I did not expect to care about much was Git support. At first, I thought, “Okay, Git is Git. I can do that in VS Code or terminal.” But having Git actions close to the Codex workflow makes sense.

If Codex made the change, explained the change, and I reviewed the diff there, then committing from that same flow feels natural. The more useful part for me is not just committing. It is using Codex to help create better commits.

A lazy commit message looks like this:

git commit -m "fix stuff"

We have all done it. But with Codex, I can ask:

Based on the diff, suggest a clear commit message.

Use this format:
<type>: <short summary>

Then include 3 bullet points explaining the main changes.

For example, if I moved profile loading logic into a view model, a better commit message might be:

refactor: move profile loading logic into view model

- Moved API request handling out of ProfileScreen
- Added ProfileViewModel state for loading, success, and error
- Preserved existing UI behavior while improving testability

That is much better than “fix stuff.” If the change is small, I may use a single-line commit like:

fix: prevent duplicate API retry after timeout

If the change is larger, I prefer a commit body:

feat: add settings screen for notification preferences

- Added SettingsScreen with notification toggle UI
- Wired settings route into the navigation graph
- Persisted notification preference locally
- Added basic state handling for initial preference loading

This is one of those tiny habits that compounds over time. Good commit messages make future debugging easier. Bad commit messages make your future self angry.

My current Git workflow with Codex is becoming pretty simple. First, I ask Codex to inspect and plan. Then I approve the plan and let it code. Then I ask it to summarize the diff by file.

After that, I inspect the diff myself. Then I ask what I should manually test before committing. Finally, I ask for a commit message and either commit from the flow or open the project in VS Code if I want deeper control.

A typical sequence might look like this:

Inspect the current project structure and propose the smallest safe change to add this feature. Do not edit files yet.

Then:

Implement the plan. Keep the change minimal. Do not refactor unrelated files.

Then:

Summarize the diff by file and call out any behavior changes.

Then:

What should I manually test before committing this?

And finally:

Write a commit message for this diff using conventional commit style.
Keep the subject under 72 characters.
Add a short bullet list for the body.

That workflow feels clean because it keeps me in control. The Codex app does not need to replace the IDE completely. It can become the place where the agent does the work and I supervise the work.

That is a different workflow, and I like it more than I expected.

Prompts I Keep Reusing

If you are trying the Codex app, the best advice I can give is to start with exploration before implementation. Ask Codex to inspect the codebase and explain the relevant files before changing anything.

Use plan mode when the task has multiple steps, especially if you are touching architecture, navigation, state management, API logic, or persistence. Use chat mode when you are still thinking and comparing approaches.

Be strict about scope by saying things like “do not refactor unrelated files,” “keep this change minimal,” and “preserve existing behavior.” Review every diff because the diff is where you decide whether the work is actually good.

Ask for risk summaries, ask for manual testing steps, and use Codex to improve your commit messages. Here are a few prompts I find especially useful.

For understanding a new codebase, I use:

Give me a guided tour of this codebase.

Focus on:
- Entry points
- Main modules
- State management
- API layer
- Where I should make changes for a new feature

Do not edit files.

For making a safe change, I use:

I want to add [feature].

Before editing:
1. Find the relevant files.
2. Explain the current behavior.
3. Suggest the smallest safe implementation.
4. Wait for my approval.

For reducing unnecessary refactors, I use:

Implement this with minimal changes.

Do not rename existing functions unless required.
Do not move files unless required.
Do not introduce a new architecture pattern.
Preserve existing behavior.

For reviewing a diff, I use:

Review your changes like a senior engineer.

Tell me:
- What changed
- Why it changed
- Any risks
- What I should test manually
- Whether any change is unrelated to the request

For Git commit messages, I use:

Generate a commit message from the current diff.

Use conventional commit style.
Keep the title short.
Add a body only if the change is large.
Do not exaggerate the change.

The “do not exaggerate” part is funny, but useful. Sometimes AI-generated commit messages sound like the commit rebuilt the whole platform when it only changed one conditional.

How I Decide Between Codex App, VS Code, Cursor, and Claude Code

Right now, I do not think there is one perfect tool. I still like VS Code for hands-on coding because it is fast, familiar, and predictable. When I want to manually write code, debug something, or inspect multiple files quickly, VS Code feels natural.

I liked Cursor a lot too, and I may still use it, but recently the lag pushed me back to VS Code. I like Claude Code when I want a strong terminal-based workflow, especially around structured planning, reusable skills, and project-specific instructions.

Claude Code made me think more seriously about how to document workflows and make AI coding more repeatable. I like the Codex app when I want to supervise coding tasks, inspect files, review diffs, and manage agent work without feeling locked inside a traditional IDE.

That is the interesting shift for me. The IDE is no longer always the center of the coding workflow. Sometimes the agent workspace is.

Let’s say I have a simple app and I want to add a “recent notes” section. Old me might open the IDE, search files manually, find the home screen, inspect the data model, and start coding.

Now I might start in Codex app with:

I want to add a Recent Notes section on the home screen.

First inspect the project and answer:
1. Where is the home screen implemented?
2. Where are notes loaded from?
3. Is there already a date field or updatedAt field?
4. What is the smallest safe implementation?
Do not edit files yet.

After Codex responds, I might say:

Good. Implement only the UI section and reuse existing note data.
Show the 5 most recently updated notes.
Do not add persistence changes.
Do not change navigation.

After it edits files, I ask it to summarize the diff, tell me the edge cases, and suggest a commit message. That gives me a practical, reviewable flow instead of a random “AI changed a bunch of files, good luck” experience.

It is not magical, and it is not perfect, but it is clean.

What I Still Watch Out For

Even though I am enjoying the Codex app, I do not blindly trust it. That is probably the biggest advice I would give anyone using AI coding tools. AI can move fast, but fast does not always mean correct.

I still watch for over-engineering. If I ask for a small feature and the agent creates five new abstractions, I usually push back. I watch for silent behavior changes because a refactor that changes behavior is not just a refactor.

I watch for test gaps because if Codex changes core logic but does not update tests or at least tell me what to test, I ask follow-up questions. I also watch for Git hygiene because I do not want one giant commit containing a feature, formatting changes, unrelated cleanup, and dependency updates unless there is a very good reason.

The more I use tools like Codex and Claude Code, the more I feel my role changing slightly. I am still coding, but I am also planning more, reviewing more, writing better prompts, creating better constraints, and thinking more about architecture before implementation.

That is not a bad thing. In fact, it feels closer to how senior engineering work already happens. You do not just type code all day. You make decisions, review tradeoffs, protect the codebase from unnecessary complexity, and make sure the feature actually fits the product.

AI coding tools make it easier to generate code, but they also make it more important to know what good code should look like.

Final Thoughts

I did not expect the Codex app to change my workflow much. I thought it would be another interface around the same coding agent. But after using it, I get why the app exists.

The Codex app is not just about writing code. It is about managing coding work. It gives you a focused place to start tasks, inspect files, review changes, use Git, and guide the agent without constantly bouncing between chat, IDE, terminal, and browser.

For me, that matters. I still use VS Code. I still like Claude Code. I still think Cursor has done a lot to push AI coding forward.

But the Codex app made me realize that maybe the future coding workflow is not just “AI inside the IDE.” Maybe sometimes the IDE becomes one part of the workflow, and the agent command center becomes another.

That is the part I am excited about because when a tool helps me think, plan, review, and ship with less friction, I start enjoying the process more. Recently, that is exactly what happened with Codex.

I started enjoying it. And that is usually the first sign that a tool is going to stay in my workflow.

If you found this useful, consider clapping, following, or leaving a comment. I am currently experimenting a lot with Codex, Claude Code, VS Code, and AI coding workflows, so I will probably keep sharing what actually works for me in real projects.

I Tried the New Codex App, and It Changed How I Think About Coding With AI was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Routes, Arguments, Nested Graphs, and Real-World Flows (Without the Headaches)

Introduction

A while back, I wrote SwiftUI Navigation in iOS: A Practical Guide. That article came from a very real place: I had gone back to some older iOS code and realized how much navigation logic I used to tolerate before the newer APIs finally made things click. Around the same time, I had a similar feeling while revisiting SwiftUI State in iOS: A Practical Guide, because state and navigation usually start becoming painful at exactly the same moment: when an app stops being a toy project and starts behaving like a real one. Now I’ve had that same realization again, but this time on the Android side.

I’ve spent a lot of time building mobile apps across both iOS and Android, and one thing I’ve noticed is that navigation always looks easy in the sample app stage. You have a home screen, maybe a detail screen, maybe a settings page, and everything feels manageable. Then the app starts becoming real. You add login flows. You add onboarding. You introduce bottom tabs. You need to navigate after an API call succeeds. You need to clear the back stack after authentication. You add deep links. Suddenly, navigation stops feeling like a tiny implementation detail and starts feeling like architecture.

That’s usually when the confusion begins.

Not because Jetpack Compose navigation is bad, but because most of us first learn it through very small examples. And small examples don’t prepare you for the moment when your app has fifteen screens, three flows, and a product manager asking why the back button goes somewhere weird after sign-in.

That is exactly why I wanted to write this article.

I wanted something similar in spirit to my iOS navigation article, but for Android developers working with Jetpack Compose. Not a dry API reference. Not a toy sample that only works for two screens. I wanted a guide that feels like something you would actually refer to while building a real app.

So in this article, I’m going to walk through the mental model that helped Compose navigation finally feel predictable to me. We’ll start simple, then move into the stuff that matters in actual apps: typed-ish routes, passing arguments, programmatic navigation, clearing stacks, bottom bar navigation, nested graphs, and deep links.

If you are newer to Jetpack Compose, this should give you a solid foundation. And if you’ve already shipped a few screens and still feel like navigation is “working, but kind of messy,” this is for you too.

By the end, you’ll have:

• A clean mental model for how Compose navigation works.
• Practical patterns for moving between screens without making your code harder to reason about.
• Copy-pasteable examples for arguments, nested graphs, bottom navigation, and deep links.
• A structure that scales much better once your app stops being a demo.

Context

Before Jetpack Compose, navigation in Android often meant Fragments, XML navigation graphs, Safe Args, fragment transactions, and a lot of code spread across activities and fragment managers. It worked, but it also came with a lot of ceremony.

Then Compose arrived, and with it came a different way of thinking.

In Compose, your UI is already state-driven. Navigation fits best when you think about it the same way: your current destination is just another piece of app state.

That mental shift helped me a lot.

Because when I first touched Compose Navigation, I made the classic mistake of treating it like magic. I would copy a NavHost, throw in a few composable() blocks, call navController.navigate(...), and move on. For two or three screens, that feels fine. But once I started adding real flows, I noticed the same thing I saw years ago in mobile apps generally: navigation becomes hard when route definitions, arguments, and stack behavior are not intentional.

Here’s the mental model that made Compose navigation click for me:

Your app has a navigation graph, your NavController moves through that graph, and every screen is identified by a route.

That’s it.

A route is just a string, but if you leave it as “just strings everywhere,” things can get messy fast. So the trick is to make those routes structured enough that your code stays readable.

In practical terms:

• NavHost is where you define the map of your screens.
• NavController is what you use to move through that map.
• A route identifies where you want to go.
• Back stack behavior depends on how you call navigate() and whether you use options like popUpTo, launchSingleTop, and restoreState.

Once you stop thinking of navigation as random jumps between screens and start thinking of it as movement through a graph with rules, the API starts feeling much less mysterious.

Quick Start

The smallest Compose navigation setup that won’t haunt you later

If you only remember one thing from this article, let it be this:

Define your routes clearly, centralize them, and don’t scatter route strings across your app.

Let’s start with a very small example.

1) Basic setup with NavHost and a couple of routes

import androidx.compose.foundation.layout.Arrangement
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.material3.Button
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.navigation.NavHostController
import androidx.navigation.compose.NavHost
import androidx.navigation.compose.composable
import androidx.navigation.compose.rememberNavController

sealed class AppScreen(val route: String) {
    data object Home : AppScreen("home")
    data object Settings : AppScreen("settings")
}
@Composable
fun AppNavHost(
    navController: NavHostController = rememberNavController()
) {
    NavHost(
        navController = navController,
        startDestination = AppScreen.Home.route
    ) {
        composable(AppScreen.Home.route) {
            HomeScreen(
                onOpenSettings = {
                    navController.navigate(AppScreen.Settings.route)
                }
            )
        }
        composable(AppScreen.Settings.route) {
            SettingsScreen()
        }
    }
}
@Composable
fun HomeScreen(onOpenSettings: () -> Unit) {
    Column(
        modifier = Modifier.fillMaxSize(),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text(
            text = "Home",
            style = MaterialTheme.typography.headlineMedium
        )
        Button(onClick = onOpenSettings) {
            Text("Open Settings")
        }
    }
}
@Composable
fun SettingsScreen() {
    Column(
        modifier = Modifier.fillMaxSize(),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text(
            text = "Settings",
            style = MaterialTheme.typography.headlineMedium
        )
    }
}

This example is intentionally small, but it already shows a few habits I strongly prefer in real projects.

First, routes are centralized in a sealed class instead of being hardcoded strings in random places. Second, the HomeScreendoes not directly know about NavController; it receives a callback. That may feel unnecessary in tiny examples, but it pays off later because your UI stays easier to preview, test, and reason about.

That second point matters more than it first appears.

One of the easiest ways to make Compose screens harder to maintain is to let every screen directly grab and manipulate the NavController. It works. I’ve done it too. But over time, it turns screens into coordination layers instead of UI layers.

Passing navigation lambdas keeps things cleaner.

Why this structure is worth it

Even at this early stage, this setup gives you a few nice benefits:

• Your routes live in one place.
• Renaming screens becomes safer.
• Screens stay more reusable because they don’t depend directly on navigation internals.
• The NavHost becomes the source of truth for how screens are connected.

This is very similar to what I like about typed routing on iOS. Compose doesn’t give you the exact same model out of the box, but you can still structure your routes in a way that makes your app feel more deliberate and less stringly-typed.

Deep Dive

Passing arguments without turning your code into route-string soup

The moment navigation starts getting interesting is usually when one screen needs data from another.

For example:

• Open a product details page for product 42.
• Open a user profile for a given user ID.
• Open an edit screen with an item ID.

You can absolutely build routes manually with strings, but I strongly recommend wrapping that logic in helper functions so route construction stays consistent.

2) Define a route with arguments

sealed class AppScreen(val route: String) {
    data object Home : AppScreen("home")
    data object Settings : AppScreen("settings")
    data object UserDetails : AppScreen("user/{userId}") {
        fun createRoute(userId: Int): String = "user/$userId"
    }
}

Now let’s add the corresponding destination.

import androidx.navigation.NavType
import androidx.navigation.navArgument

NavHost(
    navController = navController,
    startDestination = AppScreen.Home.route
) {
    composable(AppScreen.Home.route) {
        HomeScreen(
            onOpenSettings = {
                navController.navigate(AppScreen.Settings.route)
            },
            onOpenUser = { userId ->
                navController.navigate(AppScreen.UserDetails.createRoute(userId))
            }
        )
    }
    composable(AppScreen.Settings.route) {
        SettingsScreen()
    }
    composable(
        route = AppScreen.UserDetails.route,
        arguments = listOf(
            navArgument("userId") {
                type = NavType.IntType
            }
        )
    ) { backStackEntry ->
        val userId = backStackEntry.arguments?.getInt("userId") ?: return@composable
        UserDetailsScreen(userId = userId)
    }
}

And update HomeScreen:

@Composable
fun HomeScreen(
    onOpenSettings: () -> Unit,
    onOpenUser: (Int) -> Unit
) {
    Column(
        modifier = Modifier.fillMaxSize(),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text(
            text = "Home",
            style = MaterialTheme.typography.headlineMedium
        )

Button(onClick = onOpenSettings) {
            Text("Open Settings")
        }
        Button(onClick = { onOpenUser(42) }) {
            Text("Open User 42")
        }
    }
}
@Composable
fun UserDetailsScreen(userId: Int) {
    Column(
        modifier = Modifier.fillMaxSize(),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text(
            text = "User Details: $userId",
            style = MaterialTheme.typography.headlineMedium
        )
    }
}

This is usually the point where Compose navigation starts making more sense to newer developers. A destination route can include placeholders, and when you navigate, you provide a concrete version of that route.

The big thing I’d emphasize here is this: never build argument routes ad hoc throughout the app.

Do not write "user/${id}" in seven different files.

That is how bugs sneak in.

Put route creation next to the route definition. Your future self will thank you.

Programmatic navigation and back stack control

One of the things that makes navigation annoying in real apps is not moving forward. Forward is easy. The hard part is controlling what happens to the back stack.

This comes up all the time:

• After login, the user should not go back to the login screen.
• After onboarding, you want to land in the main app and clear onboarding from history.
• When reselecting a bottom tab, you may not want duplicate copies of the same destination.

This is where navigate() options become very important.

3) Navigate and clear part of the back stack

navController.navigate("main") {
    popUpTo("login") {
        inclusive = true
    }
}

This says: navigate to main, and remove login from the back stack too.

That inclusive = true is the detail that makes the login screen disappear entirely from the back history.

If you leave it out, users may still be able to back their way into places you meant to leave behind.

4) A small auth flow example

sealed class AppScreen(val route: String) {
    data object Login : AppScreen("login")
    data object Home : AppScreen("home")
    data object Settings : AppScreen("settings")
}

@Composable
fun AppNavHost(
    navController: NavHostController = rememberNavController(),
    isLoggedIn: Boolean = false
) {
    val startDestination = if (isLoggedIn) AppScreen.Home.route else AppScreen.Login.route
    NavHost(
        navController = navController,
        startDestination = startDestination
    ) {
        composable(AppScreen.Login.route) {
            LoginScreen(
                onLoginSuccess = {
                    navController.navigate(AppScreen.Home.route) {
                        popUpTo(AppScreen.Login.route) {
                            inclusive = true
                        }
                    }
                }
            )
        }
        composable(AppScreen.Home.route) {
            HomeScreen(
                onOpenSettings = {
                    navController.navigate(AppScreen.Settings.route)
                }
            )
        }
        composable(AppScreen.Settings.route) {
            SettingsScreen()
        }
    }
}
@Composable
fun LoginScreen(onLoginSuccess: () -> Unit) {
    Column(
        modifier = Modifier.fillMaxSize(),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text(
            text = "Login",
            style = MaterialTheme.typography.headlineMedium
        )
        Button(onClick = onLoginSuccess) {
            Text("Sign In")
        }
    }
}

This is the kind of pattern I use a lot because it matches real product behavior. When auth succeeds, you do not want login hanging around in the back stack like a ghost from five seconds ago.

Avoiding duplicate destinations

Another navigation annoyance I hit early in Compose was duplicate destinations building up because I kept navigating to the same route repeatedly.

For example, if a user taps the same bottom nav item multiple times, you usually do not want five copies of the same screen.

That is where launchSingleTop helps.

navController.navigate(AppScreen.Home.route) {
    launchSingleTop = true
}

This tells the controller not to add another copy if the destination is already on top.

It sounds small, but it makes navigation feel much more stable in apps where users can repeatedly trigger the same route.

Bottom navigation in Compose

This is one of those topics that looks simple until you actually build it.

My first few Compose bottom bar implementations technically worked, but I always found myself tweaking them because back stack behavior was slightly off. The problem was never rendering the bar itself. The real challenge was making tab switching behave the way users expect.

Usually, users expect each tab to feel like its own section. They do not expect weird stack duplication. They also expect state restoration when they come back to a tab.

Here is a common and solid pattern.

5) Bottom navigation with state restoration

import androidx.compose.material3.Icon
import androidx.compose.material3.NavigationBar
import androidx.compose.material3.NavigationBarItem
import androidx.compose.material3.Scaffold
import androidx.compose.runtime.getValue
import androidx.navigation.NavDestination.Companion.hierarchy
import androidx.navigation.compose.currentBackStackEntryAsState

sealed class BottomNavItem(
    val route: String,
    val label: String
) {
    data object Feed : BottomNavItem("feed", "Feed")
    data object Search : BottomNavItem("search", "Search")
    data object Profile : BottomNavItem("profile", "Profile")
}
@Composable
fun MainScreen() {
    val navController = rememberNavController()
    val items = listOf(
        BottomNavItem.Feed,
        BottomNavItem.Search,
        BottomNavItem.Profile
    )
    Scaffold(
        bottomBar = {
            BottomBar(navController = navController, items = items)
        }
    ) { paddingValues ->
        NavHost(
            navController = navController,
            startDestination = BottomNavItem.Feed.route
        ) {
            composable(BottomNavItem.Feed.route) {
                FeedScreen()
            }
            composable(BottomNavItem.Search.route) {
                SearchScreen()
            }
            composable(BottomNavItem.Profile.route) {
                ProfileScreen()
            }
        }
    }
}
@Composable
fun BottomBar(
    navController: NavHostController,
    items: List<BottomNavItem>
) {
    val navBackStackEntry by navController.currentBackStackEntryAsState()
    val currentDestination = navBackStackEntry?.destination
    NavigationBar {
        items.forEach { item ->
            val selected = currentDestination?.hierarchy?.any { it.route == item.route } == true
            NavigationBarItem(
                selected = selected,
                onClick = {
                    navController.navigate(item.route) {
                        popUpTo(navController.graph.startDestinationId) {
                            saveState = true
                        }
                        launchSingleTop = true
                        restoreState = true
                    }
                },
                icon = {
                    Icon(
                        imageVector = androidx.compose.material.icons.Icons.Default.Home,
                        contentDescription = item.label
                    )
                },
                label = {
                    Text(item.label)
                }
            )
        }
    }
}

A few things are happening here that are worth understanding.

• popUpTo(navController.graph.startDestinationId) prevents the back stack from growing in weird ways across tab switches.
• saveState = true preserves prior tab state where possible.
• restoreState = true restores it when the user returns.
• launchSingleTop = true avoids duplicate copies of the same top destination.

This combination is one of those things I wish someone had explained to me earlier, because it makes a very noticeable difference in how polished tab navigation feels.

Nested graphs for flows that belong together

Once your app grows, not every destination should sit flat in one giant NavHost block.

This is where nested graphs become extremely useful.

A very common example is authentication.

You might have:

• A login screen
• A signup screen
• A forgot password screen

Those three screens belong to one flow. They are related. Grouping them under a nested graph makes your navigation structure easier to understand.

6) Nested graph example

import androidx.navigation.navigation

object Graph {
    const val ROOT = "root_graph"
    const val AUTH = "auth_graph"
    const val MAIN = "main_graph"
}
sealed class AppScreen(val route: String) {
    data object Login : AppScreen("login")
    data object Signup : AppScreen("signup")
    data object ForgotPassword : AppScreen("forgot_password")
    data object Home : AppScreen("home")
    data object Settings : AppScreen("settings")
}
@Composable
fun AppNavHost(navController: NavHostController = rememberNavController()) {
    NavHost(
        navController = navController,
        route = Graph.ROOT,
        startDestination = Graph.AUTH
    ) {
        navigation(
            route = Graph.AUTH,
            startDestination = AppScreen.Login.route
        ) {
            composable(AppScreen.Login.route) {
                LoginScreen(
                    onLoginSuccess = {
                        navController.navigate(Graph.MAIN) {
                            popUpTo(Graph.AUTH) {
                                inclusive = true
                            }
                        }
                    },
                    onSignup = {
                        navController.navigate(AppScreen.Signup.route)
                    },
                    onForgotPassword = {
                        navController.navigate(AppScreen.ForgotPassword.route)
                    }
                )
            }
            composable(AppScreen.Signup.route) {
                SignupScreen()
            }
            composable(AppScreen.ForgotPassword.route) {
                ForgotPasswordScreen()
            }
        }
        navigation(
            route = Graph.MAIN,
            startDestination = AppScreen.Home.route
        ) {
            composable(AppScreen.Home.route) {
                HomeScreen(
                    onOpenSettings = {
                        navController.navigate(AppScreen.Settings.route)
                    }
                )
            }
            composable(AppScreen.Settings.route) {
                SettingsScreen()
            }
        }
    }
}

This structure reads much more like the actual product.

There is an auth flow.
There is a main app flow.
They are separate sections of the graph.

That separation becomes really helpful once your app gets more complicated. It also makes transitions like “user signed in, leave auth entirely” much easier to express.

Deep links in Compose

Deep links are one of those features that sound fancy until you realize they are just another way of entering the graph.

A push notification might open a detail page.
A marketing link might open a specific screen.
An email verification link might route into a flow.

Compose Navigation supports this directly.

7) Deep link example

import androidx.navigation.navDeepLink

sealed class AppScreen(val route: String) {
    data object Home : AppScreen("home")
    data object ArticleDetails : AppScreen("article/{articleId}") {
        fun createRoute(articleId: String): String = "article/$articleId"
    }
}
NavHost(
    navController = navController,
    startDestination = AppScreen.Home.route
) {
    composable(AppScreen.Home.route) {
        HomeScreen(
            onOpenArticle = { articleId ->
                navController.navigate(AppScreen.ArticleDetails.createRoute(articleId))
            }
        )
    }
    composable(
        route = AppScreen.ArticleDetails.route,
        arguments = listOf(
            navArgument("articleId") { type = NavType.StringType }
        ),
        deepLinks = listOf(
            navDeepLink {
                uriPattern = "myapp://article/{articleId}"
            }
        )
    ) { backStackEntry ->
        val articleId = backStackEntry.arguments?.getString("articleId") ?: return@composable
        ArticleDetailsScreen(articleId = articleId)
    }
}

Now a URI like this can open the article details destination directly:

myapp://article/abc123

That is the nice part.

The important part is making sure your route and your deep link pattern stay aligned. If you are sloppy with naming or placeholders, deep links become much harder to maintain later.

This is another reason I like wrapping route creation in helper functions and centralizing destination definitions.

Passing more complex data

This is where I want to save people some pain.

When I first started with navigation in Android years ago, I had the same temptation many people do: “Why not just pass the full object?”

In Compose Navigation, you technically can serialize data and pass it around, but in most cases, I do not think that is the cleanest approach.

For real apps, I usually recommend this pattern instead:

• Pass a stable identifier through navigation.
• Load the actual object from a repository or ViewModel on the destination side.

So rather than passing a full User, pass userId.
Rather than passing a full Article, pass articleId.

Why?

Because routes are easier to reason about when they are small and stable. Also, once data gets large or changes over time, serializing whole objects into navigation starts feeling fragile.

If you stick to IDs for most navigation, your flow becomes more predictable.

A small route helper pattern I really like

Compose Navigation still uses string routes, so one thing I’ve found helpful is to make route definitions feel a little more structured.

Here is a simple pattern that scales well.

8) Route helper objects

sealed interface AppDestination {
    val route: String
}

data object HomeDestination : AppDestination {
    override val route = "home"
}
data object SettingsDestination : AppDestination {
    override val route = "settings"
}
data object UserDestination : AppDestination {
    override val route = "user/{userId}"
    fun createRoute(userId: Int): String = "user/$userId"
    const val ARG_USER_ID = "userId"
}

Then use those constants everywhere instead of raw strings.

composable(
    route = UserDestination.route,
    arguments = listOf(
        navArgument(UserDestination.ARG_USER_ID) {
            type = NavType.IntType
        }
    )
) { backStackEntry ->
    val userId = backStackEntry.arguments?.getInt(UserDestination.ARG_USER_ID)
        ?: return@composable

UserDetailsScreen(userId = userId)
}

This does not magically make routes compile-time perfect the way fully typed navigation can in some ecosystems, but it does reduce accidental inconsistencies a lot.

Keep NavController out of most leaf composables

This is more of an architectural habit than a hard rule, but it has helped me repeatedly.

Try to keep NavController close to the graph or screen-container level, and pass simple lambdas into child composables.

For example, prefer this:

@Composable
fun HomeRoute(navController: NavHostController) {
    HomeScreen(
        onOpenSettings = {
            navController.navigate(SettingsDestination.route)
        },
        onOpenUser = { userId ->
            navController.navigate(UserDestination.createRoute(userId))
        }
    )
}

And then keep the UI clean:

@Composable
fun HomeScreen(
    onOpenSettings: () -> Unit,
    onOpenUser: (Int) -> Unit
) {
    Column {
        Button(onClick = onOpenSettings) {
            Text("Settings")
        }
Button(onClick = { onOpenUser(99) }) {
            Text("Open User")
        }
    }
}

Instead of this in every leaf composable:

@Composable
fun HomeScreen(navController: NavHostController) {
    Button(
        onClick = {
            navController.navigate("settings")
        }
    ) {
        Text("Settings")
    }
}

The second version is tempting because it is quick, but it couples your UI directly to navigation internals. The first version stays easier to test, reuse, preview, and refactor.

Common pitfalls I hit

These are the exact kinds of potholes I’ve stepped into while working with Compose navigation.

Pitfall 1: Hardcoding route strings everywhere

Mistake: Writing raw route strings in multiple files.

Why it hurts: It becomes easy to mistype a route, change one place and forget another, or build arguments inconsistently.

Fix: Centralize routes and route builders.

Pitfall 2: Letting every composable own navigation

Mistake: Passing NavController deep into the UI tree.

Why it hurts: Your composables become harder to reuse and test, and navigation logic gets scattered.

Fix: Keep navigation near the graph or screen-container level and pass lambdas down.

Pitfall 3: Forgetting back stack rules after auth or onboarding

Mistake: Navigating to the next screen but leaving old flow screens on the stack.

Why it hurts: Users can hit back and end up in places that no longer make sense.

Fix: Use popUpTo(...){ inclusive = true } intentionally.

Pitfall 4: Duplicate destinations from repeated taps

Mistake: Navigating to the same route over and over without launchSingleTop.

Why it hurts: Your stack gets cluttered and the app feels inconsistent.

Fix: Use launchSingleTop = true where repeated navigation is likely.

Pitfall 5: Passing entire objects through routes

Mistake: Treating navigation like a dump truck for full models.

Why it hurts: It becomes fragile, noisy, and harder to evolve.

Fix: Pass IDs or small stable values, then load the full data in the destination.

Pitfall 6: One giant flat graph for everything

Mistake: Keeping auth, onboarding, tabs, and app content all at one level.

Why it hurts: The graph becomes harder to reason about as the app grows.

Fix: Use nested graphs for distinct flows.

The mental model I’d keep

If I had to compress this whole article into a few ideas, it would be these:

• A route identifies a destination.
• NavHost defines the map.
• NavController moves through that map.
• Route structure matters more than people think.
• Back stack behavior is part of navigation design, not an afterthought.
• Nested graphs and route helpers make real apps much easier to maintain.

That is the point where Compose navigation stopped feeling random to me.

It stopped being “call navigate and hope it works” and started feeling more like a system I could reason about.

Conclusion

If you are building Android apps with Jetpack Compose, this is the navigation approach I would recommend betting on.

Not because it is the fanciest possible setup, but because it stays understandable as your app grows.

For tiny apps, a simple NavHost with a few routes is enough. But once you add arguments, auth flows, bottom tabs, onboarding, or deep links, the difference between “it works” and “it scales” usually comes down to structure.

For me, the biggest shift was realizing that Compose navigation is not really about memorizing APIs. It is about being intentional with route definitions, graph boundaries, and back stack behavior.

Once that clicked, the code got easier to reason about.

And honestly, that is what I want from navigation more than anything else. I do not need it to feel clever. I need it to feel predictable, especially three months later when I revisit the project and wonder what past me was thinking.

If this article helped, I’d really appreciate a quick clap so more Android developers can find it, a follow if you want more practical mobile engineering write-ups, or a comment with the kind of navigation flow you are dealing with right now. Tabs, auth, onboarding, nested graphs, weird back-stack bugs, all of it. Those are usually the situations where the real learning happens.

Thanks for reading. This was one of those topics I wanted to write down properly because I keep seeing the same confusion show up in real projects, and honestly, I’ve hit most of these problems myself too.

Navigation in Android Jetpack Compose: A Practical Guide was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve spent most of my career building mobile apps. SwiftUI on one side, Jetpack Compose on the other, and somewhere in between, a lot of time spent fighting tiny UI details that no one outside development ever notices. Spacing. Alignment. State updates. Navigation edge cases. Things that seem small until they eat half your day.

But recently, I decided to switch gears for a bit.

I’ve been trying to build more frontend applications and intentionally taking a small break from iOS and Android work. Not because I’m bored of mobile, but because I wanted to explore a different kind of speed. The web, especially right now, feels like the most interesting place to experiment if you’re into AI-assisted development. You can go from idea to something visible incredibly fast, and that has been surprisingly refreshing.

That curiosity led me into a bunch of experiments with AI coding tools, and I wrote about one of them recently in this article:

I Let Codex Design and Test a Frontend App for Me. Here’s What Actually Happened
https://levelup.gitconnected.com/i-let-codex-design-and-test-a-frontend-app-for-me-heres-what-actually-happened-a192b514f27e

That experiment taught me something important: generating code is no longer the hardest part.

The real bottleneck is often the step before code.

It’s figuring out what the UI should even look like.

That blank-canvas moment is still where a lot of momentum dies. Even if you’re good at building apps, there’s still a lot of friction between “I have an idea” and “I have something I can actually implement.” You’re thinking about layout, hierarchy, sections, user flow, component structure, and whether the screen in your head will even make sense once it becomes real.

That’s exactly why Google Stitch caught my attention.

When I first heard about it, my reaction was honestly a mix of skepticism and curiosity. A tool that can generate UI from prompts sounds like one of those things that is either surprisingly useful or completely gimmicky. There usually isn’t much middle ground.

So I tried it.

And after spending time with it, I realized this is one of those tools that becomes much more interesting once you stop thinking of it as a “design toy” and start using it as part of a real implementation workflow.

What Google Stitch Actually Is

The simplest way to think about Google Stitch is this: it takes a text prompt and turns it into a structured UI concept. Instead of opening a design tool and manually arranging sections, cards, charts, buttons, tabs, and layouts, you describe the kind of interface you want, and Stitch generates a visual direction for you.

That alone is useful. But what makes it more interesting for developers is not just that it can create something pretty. It’s that it can help remove the “what should this screen look like?” phase that often slows down implementation.

And if you’ve been using AI tools for coding already, this matters a lot.

Because once you already have a reasonable visual structure, it becomes much easier to take that and move into actual code generation.

That’s where Stitch clicked for me.

Not as a replacement for design. Not as a magical one-click app builder. But as a practical starting point that can save you from wasting energy on the first 20% of the UI process.

Why I Wanted to Try It

At this point, I’m already using tools like Codex, Cursor, and Claude Code in different parts of my workflow. They’ve all helped me move faster in different ways, especially when it comes to planning, scaffolding, debugging, and implementation.

But even with all of that, I still noticed something weird.

I could generate backend logic quickly.
I could scaffold frontend code quickly.
I could even ask AI to build components for me.

And yet, I still kept slowing down at the exact same place.

The visual structure.

Not because writing UI code is hard for me. It’s not. I’ve written enough UI in SwiftUI and Compose to feel very comfortable there. But frontend UI still has a different kind of decision fatigue. When you start from nothing, you have to make dozens of small visual decisions before the app even starts to feel real.

How should the dashboard be split?
Should stats go at the top or middle?
Should this be a card, a chart, a tab, or a side panel?
What would make this screen feel modern instead of generic?

That’s the kind of friction I wanted to reduce.

So instead of asking, “Can Stitch design my app for me?” I approached it with a much more useful question:

Can Stitch help me get to implementation faster?

That turned out to be the right question.

My First Real Test: A Fitness Dashboard

I wanted to start with something simple enough to evaluate quickly but realistic enough to feel like a real product screen. So I gave Stitch a prompt around a fitness dashboard.

This was the prompt:

Create a modern dashboard UI for a fitness app with:
- Daily activity summary
- Heart rate chart
- Sleep tracking card
- Recent workouts section
- Bottom navigation bar
Use a clean, premium mobile app style.

What I liked immediately was that this forced me to think like a product person instead of jumping straight into code. Instead of saying “build me a screen,” I had to describe what the screen should actually do and contain.

And that alone is underrated.

A lot of bad UI starts because we jump into implementation before we’ve even clearly described the screen.

Stitch came back with a layout that, while not perfect, was genuinely useful. It gave me a dashboard structure with a top summary area, visual cards, a chart section, and enough hierarchy to understand where everything should live.

Was it production-ready? No.

Did it immediately save me from staring at an empty screen and making every design decision manually? Absolutely.

That was the first moment where I thought, okay, this is actually practical.

Why This Was More Useful Than It Looks

At first glance, a generated UI might seem like a novelty. Something fun to play with for a few minutes and then forget.

But that’s not how I ended up using it.

The value wasn’t in whether Stitch gave me the exact final screen I wanted. The value was that it gave me a strong enough visual starting point that I could immediately hand off into implementation. And that changed the next part of my workflow completely.

Because once I had a UI structure I liked, I didn’t need to “design” anymore.

I could build.

My Actual Workflow: Stitch → Codex → Cursor → Polish

This is the part that made the whole thing click for me.

Instead of treating Stitch like a standalone design tool, I used it as the first stage in a larger AI-assisted development pipeline.

The workflow looked like this:

Stitch → Generate UI idea
↓
Review layout and adjust prompt if needed
↓
Take the generated design structure/screenshots
↓
Paste into Codex or Cursor
↓
Convert into React components
↓
Refine styling, spacing, interactions, and responsiveness manually

That flow is much more powerful than it sounds.

Because the hardest part of frontend work often isn’t typing the code. It’s reducing ambiguity.

Once the ambiguity is lower, AI tools become dramatically more useful.

If you ask Codex or Cursor to “build a dashboard,” you’ll get something. But it might not be the something you had in mind.

If you instead say:

Build a React dashboard based on this layout. Use a clean card-based design with a top summary section, heart rate chart, sleep card, recent workouts list, and bottom nav.

Now you’re giving the model structure, not just intent.

That makes the output much better.

Example: Taking Stitch Into React

Once I had the dashboard idea from Stitch, I tried converting it into a simple React/Tailwind implementation.

A prompt like this worked much better than a generic “build a fitness dashboard” request:

Convert this UI into a React app using Tailwind CSS.
Requirements:
- Mobile-first responsive layout
- Reusable card components
- One chart placeholder section
- Bottom navigation with 4 tabs
- Keep the look modern and minimal

The generated structure became much more coherent because the model had something visual to anchor to.

Here’s a simplified version of what the output might look like:

export default function FitnessDashboard() {
  return (
    <div className="min-h-screen bg-gray-50 p-4">
      <h1 className="text-2xl font-bold mb-4">Today</h1><div className="grid gap-4">
        <div className="rounded-2xl bg-white p-4 shadow-sm">
          <p className="text-sm text-gray-500">Steps</p>
          <p className="text-3xl font-semibold">8,421</p>
        </div>
        <div className="rounded-2xl bg-white p-4 shadow-sm">
          <p className="text-sm text-gray-500">Heart Rate</p>
          <div className="h-32 mt-2 rounded-xl bg-gray-100 flex items-center justify-center">
            Chart Placeholder
          </div>
        </div>
        <div className="rounded-2xl bg-white p-4 shadow-sm">
          <p className="text-sm text-gray-500">Recent Workouts</p>
          <ul className="mt-2 space-y-2 text-sm">
            <li>Morning Walk - 32 min</li>
            <li>Upper Body - 45 min</li>
            <li>Stretching - 12 min</li>
          </ul>
        </div>
      </div>
    </div>
  )
}

Would I ship that exact code as-is? No.

But that’s not the point.

The point is that instead of spending the first hour trying to decide layout, sections, and visual structure, I’m now spending that hour improving something that already exists.

That’s a much better use of time.

Example: Taking the Same Idea Back Into SwiftUI

Even though I’m intentionally taking a break from mobile for a bit, I also wanted to test whether this kind of workflow would still be useful for someone like me who naturally thinks in mobile UI patterns.

So I tried taking the same Stitch-generated dashboard and converting it into SwiftUI.

That looked something like this:

import SwiftUI

struct FitnessDashboardView: View {
    var body: some View {
        NavigationStack {
            ScrollView {
                VStack(spacing: 16) {
                    SummaryCard(title: "Steps", value: "8,421")
                    HeartRateCard()
                    SleepCard(hours: "7h 42m")
                    RecentWorkoutsCard()
                }
                .padding()
            }
            .navigationTitle("Today")
        }
    }
}
struct SummaryCard: View {
    let title: String
    let value: String
    var body: some View {
        VStack(alignment: .leading, spacing: 8) {
            Text(title)
                .font(.subheadline)
                .foregroundStyle(.secondary)
            Text(value)
                .font(.largeTitle.bold())
        }
        .frame(maxWidth: .infinity, alignment: .leading)
        .padding()
        .background(.white)
        .clipShape(RoundedRectangle(cornerRadius: 20))
        .shadow(radius: 3)
    }
}

Again, not a finished product.

But very usable as a starting point. And that’s what I think a lot of developers still underestimate with AI tooling. You don’t always need perfection.

You often just need a strong enough first draft that lets your brain move into refinement mode instead of invention mode.

Where Stitch Actually Shines

After using it a bit, I don’t think Stitch is most valuable for designers trying to replace Figma.

I think it’s most valuable for developers, indie hackers, and builders who want to reduce the cost of getting from an idea to a believable interface.

That makes it especially useful for:

• MVPs
• Side projects
• Internal tools
• Hackathon builds
• App validation experiments
• Landing pages
• Admin dashboards
• Early mobile UI exploration

This is exactly the stage where speed matters most.

If you’re trying to validate an idea, you should not be spending three days manually polishing the first screen before you even know if the product is worth building.

Tools like Stitch are powerful because they help you get something real in front of your eyes quickly.

That’s often enough to either move forward with confidence or realize your original idea needs work.

Both outcomes are useful.

Where It Still Falls Short

Now for the important part: Stitch is not magic.

And if you go into it expecting it to produce polished, production-grade, highly branded interfaces out of the box, you’ll probably be disappointed.

There are still very obvious limitations.

For example:

• It won’t understand your exact product taste every time.
• It may generate layouts that feel slightly generic.
• It won’t replace design judgment.
• It still needs human cleanup.
• It doesn’t remove the need for frontend implementation skills.

And honestly, that’s fine.

Because I don’t think tools like this need to be perfect to be valuable.

They just need to remove enough friction that your workflow improves.

And Stitch definitely did that for me.

The Bigger Shift This Points To

The most interesting part of this isn’t Stitch itself.

It’s what Stitch represents.

For a long time, design and implementation have been separated by a frustrating handoff. Even when one person is doing both jobs, there’s still a mental context switch between imagining a screen and actually building it.

What tools like Stitch are starting to do is compress that gap.

And when you combine that with tools like Codex, Cursor, Claude Code, or even strong prompt-based workflows, you start to realize we’re entering a very different kind of development loop.

The new loop looks more like this:

• Describe what you want
• Get a visual starting point
• Turn it into code
• Refine it fast
• Ship sooner

That is a very different experience from the old “start from a blank file and manually create everything from scratch” workflow.

And honestly, I don’t think most developers fully appreciate yet how much this changes solo building.

If you’re a single developer trying to test ideas, move fast, and ship more, this is a massive unlock.

My Honest Take After Trying It

If you asked me whether Google Stitch is something I’d use every single day for every project, the honest answer is no.

But if you asked me whether it has earned a place in my workflow for frontend experiments, MVPs, UI exploration, and fast implementation cycles, the answer is definitely yes.

What I like most is that it helps me skip the most annoying part of UI work: the slow, fuzzy beginning where the app exists only vaguely in your head.

That stage used to require a lot more energy.

Now, with tools like this, I can get to “something real” much faster.

And once I have something real, I know what to do next.

That’s where all of this becomes useful.

Not because AI built the app for me.

But because it helped me start better.

GitHub Repo

I’ll probably clean up one of these Stitch-based experiments and publish the code soon.

GitHub Repo:

GitHub - sanjaynela/personalFitnessApp: A sample fitness app that was designed with Google's Stitch

Screenshots of Mobile App:

Conclusion

If you’re already using AI tools to write code, Google Stitch feels like a very natural next step. It doesn’t replace design thinking, and it definitely doesn’t replace frontend engineering, but it does make the path from idea to implementation much shorter.

And right now, that’s probably the most valuable thing a tool like this can do.

If you’ve been curious about AI-generated UI but assumed it was mostly hype, I’d say Stitch is worth trying, especially if you care more about building momentum than chasing perfection on day one.

That’s how I’m using it, and honestly, it fits surprisingly well into the kind of workflow I think more developers will adopt over the next year.

If you’ve tried Google Stitch, Codex, Cursor, or any similar workflow, I’d genuinely love to hear how you’re using them. Drop your thoughts in the comments, and if this article was useful, feel free to clap and follow. That really helps more people discover my work and lets me know what kinds of experiments to write about next.

I Tried Google Stitch for UI Design and It Changed How I Build Apps was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

A little while ago, I wrote about finally trying Codex 5.4 because I kept hearing that it could control the computer, and honestly, I was too curious to ignore that. That earlier article was really about the moment of curiosity itself. I had been trying Codex more seriously, I was enjoying it a lot, and I wanted to see whether the hype around 5.4 was real or just another “this changes everything” moment that sounds more dramatic in demos than it feels in actual work. If you haven’t read that one yet, here it is: I Heard Codex 5.4 Could Control the Computer, So I Had to Try It. This article is the follow-up I actually wanted to write after that one. Not another general take on the model, but a more practical question: what happens if I specifically try the two things that stood out most to me in OpenAI’s own video, namely persistent computer-use capabilities and image generation for frontend design?

That combination immediately caught my attention because it maps surprisingly well to how frontend work actually feels in real life. Frontend development is rarely just “write a component and move on.” It is usually a loop of building something, opening it in the browser, noticing that the spacing feels weird, realizing the mobile version is worse, changing the layout, refreshing again, then arguing with yourself about whether the page looks polished or just expensive-looking. On top of that, a lot of the hardest parts are not even coding problems. Sometimes the issue is that you do not know what the page should feel like yet. You want a nicer hero section, but “nicer” is not a real technical requirement. You want the design to feel premium, but premium can mean ten different things depending on the product. That is why this particular Codex workflow felt worth testing. If one part of the system can help generate visual direction and another part can help inspect and interact with the actual rendered result, then suddenly the loop starts to look a lot more like real product work and a lot less like glorified autocomplete.

So instead of writing another abstract article, I decided the best way to explain this was through a concrete project that I would actually be comfortable putting on GitHub. That way the article could stay grounded in something tangible. Rather than saying, “Here are some cool features,” I could say, “Here is the exact kind of app I would build, here is how I would structure the repo, here is where computer use helps, here is where image generation helps, and here is what I would still verify myself.” That felt more honest and also more useful.

The Project I’d Build for This Experiment

The demo project I would use is a small frontend app called PromptBoard. The idea is simple: PromptBoard is a fictional product for developers who save, organize, and test prompts for coding agents. I like this kind of fake product for demos because it feels close enough to a real developer tool that the UI decisions make sense, but it is also flexible enough to show both marketing-style design work and interactive app behavior. In other words, it gives me exactly what I need to test these two concepts properly. On one side, I get a landing page where design, hierarchy, and visual mood matter. On the other side, I get a small dashboard flow where the browser interaction loop matters, because there are things to click, filter, search, and verify.

The landing page would include a hero section, a feature grid, a testimonial strip, pricing cards, and a final call-to-action section. The dashboard side would include a prompt library, tag filters, a search box, a create-prompt form, a detail view, and responsive behavior for smaller screens. That is enough to make the project feel like a real app without turning it into a giant side quest that nobody reading the article will ever rebuild. It is also the kind of repo that looks good on GitHub because it tells a very clear story: this is a focused demo built to test a modern agent workflow for frontend development.

GitHub Repo : https://github.com/sanjaynela/promptBoard

What These Two Concepts Actually Mean

Before getting into the code, I think it helps to explain these two ideas in a way that feels normal and not like marketing language. When I say computer use in this article, I am not trying to make it sound magical. I am talking about the ability for the model to work through more of the real UI loop instead of staying trapped at the source-code layer. In practical terms, that means the workflow is no longer just “read files and generate code.” It becomes closer to “run the app, open the page, inspect what is on screen, interact with it, notice what is off, and then go back and make a targeted fix.” For frontend work, that matters a lot because many of the problems we care about are not obvious from reading JSX alone. A component can look perfectly fine in code and still render awkwardly on mobile, misalign in a real browser, or feel visually weak once the full page is visible.

The image generation part is different, but just as useful. I do not see it as “AI making random pretty pictures.” I see it as a way to shorten that annoying period where you know the page needs a better visual direction but you do not yet know exactly what that direction should be. A lot of frontend work gets stuck there. The logic is fine. The structure is fine. The page works. But it still feels flat or generic. Image generation helps at that earlier stage where you are trying to figure out the mood, composition, contrast, illustration style, or overall design language. Sometimes the output becomes a direct asset you can use in the page. Other times it is more like a reference image that helps the coding agent understand what “premium dark developer tool” is supposed to look like in practice. Either way, it gives the workflow something visual to react to instead of relying only on vague adjectives.

That is really why these two ideas belong together. One helps decide what the frontend should look like. The other helps verify whether the frontend actually ended up looking and behaving the way you intended.

The Stack I’d Use

For this kind of demo, I would keep the stack extremely familiar on purpose. I do not want readers to get distracted by infrastructure or wonder whether the magic only works because of some exotic setup. I would use Next.js, TypeScript, Tailwind CSS, a few shadcn/ui components, Lucide icons, and Playwright for browser tests. That stack is boring in the best possible way. It is easy to understand, easy to run locally, and very believable as a GitHub project someone might actually clone.

The folder structure would look something like this:

promptboard/
├── app/
│   ├── page.tsx
│   ├── dashboard/page.tsx
│   ├── globals.css
│   └── layout.tsx
├── components/
│   ├── landing/
│   │   ├── hero.tsx
│   │   ├── feature-grid.tsx
│   │   ├── testimonial-strip.tsx
│   │   └── pricing.tsx
│   ├── dashboard/
│   │   ├── sidebar.tsx
│   │   ├── prompt-card.tsx
│   │   ├── create-prompt-form.tsx
│   │   └── prompt-detail-modal.tsx
│   └── ui/
├── data/
│   └── prompts.ts
├── public/
│   ├── generated/
│   │   ├── hero-concept-1.png
│   │   ├── hero-concept-2.png
│   │   └── dashboard-mood.png
├── tests/
│   └── promptboard.spec.ts
├── AGENTS.md
├── README.md
└── package.json

The public/generated folder is an important detail because it gives the project a very visible way to show where image generation fits into the workflow. I like the idea that the repo itself documents the process. A reader can see that some images were generated as visual direction, then see those assets referenced in the UI, and then see how the rest of the code evolved around them.

Building the First Version of the Landing Page

I would start with a clean but simple homepage, not because I expect the first version to be amazing, but because I want something real enough for the workflow to improve. That part matters. If the first pass is already overdesigned, the article becomes less believable. A better story is to start with a solid baseline and then show how the combination of image generation and browser-aware iteration helps push it further.

Here is a straightforward app/page.tsx:

import { Hero } from "@/components/landing/hero";
import { FeatureGrid } from "@/components/landing/feature-grid";
import { TestimonialStrip } from "@/components/landing/testimonial-strip";
import { Pricing } from "@/components/landing/pricing";

export default function HomePage() {
  return (
    <main className="min-h-screen bg-slate-950 text-white">
      <Hero />
      <FeatureGrid />
      <TestimonialStrip />
      <Pricing />
      <section className="border-t border-white/10 px-6 py-16">
        <div className="mx-auto max-w-5xl rounded-3xl border border-white/10 bg-white/5 p-8 text-center backdrop-blur">
          <h2 className="text-3xl font-semibold tracking-tight sm:text-4xl">
            Build better prompts with a workflow you can actually trust.
          </h2>
          <p className="mx-auto mt-4 max-w-2xl text-base text-slate-300 sm:text-lg">
            Organize agent prompts, test them faster, and keep your team's best workflows reusable.
          </p>
          <button className="mt-6 rounded-full bg-white px-6 py-3 text-sm font-semibold text-slate-950 transition hover:scale-[1.02]">
            Start Free Trial
          </button>
        </div>
      </section>
    </main>
  );
}

And here is a first-pass hero component:

import Image from "next/image";
import Link from "next/link";

export function Hero() {
  return (
    <section className="relative overflow-hidden px-6 pb-20 pt-24">
      <div className="absolute inset-0 bg-[radial-gradient(circle_at_top,_rgba(99,102,241,0.35),_transparent_40%),radial-gradient(circle_at_80%_20%,_rgba(16,185,129,0.22),_transparent_25%)]" />
      <div className="relative mx-auto grid max-w-6xl items-center gap-12 lg:grid-cols-2">
        <div>
          <div className="inline-flex rounded-full border border-white/10 bg-white/5 px-3 py-1 text-sm text-slate-300 backdrop-blur">
            For developers who work with coding agents every day
          </div>
          <h1 className="mt-6 text-5xl font-semibold tracking-tight sm:text-6xl">
            Your prompt library should feel as polished as your codebase.
          </h1>
          <p className="mt-6 max-w-xl text-lg leading-8 text-slate-300">
            PromptBoard helps you save, organize, version, and test prompts for tools like Codex,
            ChatGPT, and Claude without losing the workflows that actually work.
          </p>
          <div className="mt-8 flex flex-wrap gap-4">
            <Link
              href="/dashboard"
              className="rounded-full bg-white px-6 py-3 text-sm font-semibold text-slate-950"
            >
              Open Dashboard
            </Link>
            <button className="rounded-full border border-white/15 px-6 py-3 text-sm font-semibold text-white">
              Watch Demo
            </button>
          </div>
        </div>
        <div className="relative">
          <div className="rounded-[2rem] border border-white/10 bg-white/5 p-4 shadow-2xl backdrop-blur-xl">
            <Image
              src="/generated/hero-concept-1.png"
              alt="PromptBoard hero concept"
              width={1200}
              height={900}
              className="rounded-[1.5rem] object-cover"
            />
          </div>
        </div>
      </div>
    </section>
  );
}

This is already a decent start, but more importantly, it gives me something that can actually be improved. That is the point. I do not want the article to pretend the first version is perfect. I want it to show the loop.

Where Image Generation Enters the Workflow

This is the part I find easiest to relate to because it solves a very human problem. Sometimes when I am building a frontend, I do not have a code problem yet. I have a taste problem. I know the page needs a better visual identity, but I do not want to spend an hour trying to invent one from scratch while pretending I am suddenly an art director. That is where I would use image generation first, not as decoration, but as visual guidance.

Instead of saying something vague like “make it premium,” I would ask for a few concrete visual concepts for a dark-mode SaaS product aimed at developers. I would want the image outputs to explore layout mood, lighting, card depth, dashboard atmosphere, and overall style. Something like this:

Generate 3 visual directions for a SaaS landing page hero image for a product called PromptBoard.

The product helps developers organize and test prompts for coding agents.
Style requirements:
- Modern
- Premium
- Dark mode friendly
- Subtle glassmorphism
- Feels like a real B2B developer tool
- Not cartoonish
- Clean composition
- Slight neon accents
- Suitable for a React / Next.js landing page
Return concepts that could work as:
1. Hero illustration
2. Product mood board
3. Dashboard atmosphere reference

I like this because it is practical. It does not assume the generated output is the final answer. It just gives the workflow something visual to react to. Maybe one image becomes a direct hero asset. Maybe another becomes a reference for how much glow, depth, and contrast the page should use. Either way, I now have a better design conversation than simply typing “make it look better.” For me, that is already a meaningful improvement.

Building the Dashboard So Computer Use Has Something Real to Inspect

Next, I would add a small dashboard page because that is where the computer-use side becomes more interesting. A static landing page is useful, but interactive UI gives the browser loop something to do. I want filters, search, cards, forms, and mobile layout behavior because those are the things that often look fine in code but feel off when you actually open the page.

Here is the seed data for the prompt library:

export type PromptItem = {
  id: string;
  title: string;
  category: "review" | "refactor" | "frontend" | "release";
  tags: string[];
  description: string;
};

export const prompts: PromptItem[] = [
  {
    id: "1",
    title: "Review React PR for visual regressions",
    category: "review",
    tags: ["react", "ui", "qa"],
    description:
      "Inspect component changes for layout regressions, broken states, and accessibility issues."
  },
  {
    id: "2",
    title: "Rewrite landing page hero for sharper CTA",
    category: "frontend",
    tags: ["copy", "marketing", "hero"],
    description:
      "Improve headline clarity, supporting text, and CTA hierarchy without sounding generic."
  },
  {
    id: "3",
    title: "Convert utility-heavy JSX into reusable components",
    category: "refactor",
    tags: ["tailwind", "cleanup", "components"],
    description:
      "Refactor repetitive UI blocks into maintainable components while preserving existing behavior."
  }
];

And here is a clean first version of the dashboard page:

"use client";

import { useMemo, useState } from "react";
import { prompts } from "@/data/prompts";
import { PromptCard } from "@/components/dashboard/prompt-card";
import { CreatePromptForm } from "@/components/dashboard/create-prompt-form";
export default function DashboardPage() {
  const [selectedTag, setSelectedTag] = useState<string>("all");
  const [search, setSearch] = useState("");
  const tags = useMemo(() => {
    const allTags = prompts.flatMap((item) => item.tags);
    return ["all", ...Array.from(new Set(allTags))];
  }, []);
  const filtered = useMemo(() => {
    return prompts.filter((item) => {
      const matchesTag = selectedTag === "all" || item.tags.includes(selectedTag);
      const matchesSearch =
        item.title.toLowerCase().includes(search.toLowerCase()) ||
        item.description.toLowerCase().includes(search.toLowerCase());
      return matchesTag && matchesSearch;
    });
  }, [selectedTag, search]);
  return (
    <main className="min-h-screen bg-slate-950 px-6 py-10 text-white">
      <div className="mx-auto max-w-6xl space-y-8">
        <div className="flex flex-col gap-4 sm:flex-row sm:items-center sm:justify-between">
          <div>
            <h1 className="text-3xl font-semibold tracking-tight">Prompt Library</h1>
            <p className="mt-2 text-slate-400">
              Save your best agent workflows so you stop rewriting the same ideas every week.
            </p>
          </div>
          <input
            value={search}
            onChange={(e) => setSearch(e.target.value)}
            placeholder="Search prompts"
            className="w-full rounded-2xl border border-white/10 bg-white/5 px-4 py-3 text-sm text-white outline-none placeholder:text-slate-500 sm:max-w-xs"
          />
        </div>
        <div className="flex flex-wrap gap-3">
          {tags.map((tag) => (
            <button
              key={tag}
              onClick={() => setSelectedTag(tag)}
              className={`rounded-full px-4 py-2 text-sm font-medium transition ${
                selectedTag === tag
                  ? "bg-white text-slate-950"
                  : "border border-white/10 bg-white/5 text-slate-300"
              }`}
            >
              {tag}
            </button>
          ))}
        </div>
        <div className="grid gap-6 lg:grid-cols-[1.4fr_0.8fr]">
          <section className="grid gap-4 md:grid-cols-2">
            {filtered.map((item) => (
              <PromptCard key={item.id} item={item} />
            ))}
          </section>
          <aside>
            <CreatePromptForm />
          </aside>
        </div>
      </div>
    </main>
  );
}

This page already has enough going on to make the computer-use side valuable. You can open it, click the filters, type into the search bar, resize the viewport, and quickly start noticing whether the experience feels polished or just acceptable.

The Repo Instructions Matter Too

One thing I would absolutely include in a demo like this is an AGENTS.md file. If the whole point of the repo is to test an agent workflow, then the repo should help guide that workflow. I do not want the model randomly redesigning things every time I ask for a fix. I want the repository itself to explain the visual and behavioral rules.

# AGENTS.md

## Project overview
This repository is a demo project used to test Codex workflows for:
- Persistent computer-use style browser iteration
- Image-guided frontend design improvements
The stack is Next.js + TypeScript + Tailwind.
## Working rules
- Preserve the existing visual style unless the task explicitly asks for a redesign.
- Prefer small, reviewable UI changes over broad rewrites.
- After changing frontend code, run the app and verify the affected flow.
- Check both desktop and mobile layouts when editing page structure.
- Do not add a new dependency unless it clearly improves the demo.
- Prefer accessible controls and visible focus states.
- Keep the UI premium, clean, and realistic. Avoid cartoonish styling.
## Done definition
A task is complete only when:
1. The UI change is implemented.
2. The page renders without obvious layout regressions.
3. Interactive behavior is verified.
4. The final result matches the requested visual direction.

I like this because it makes the project feel intentional. It also reflects something I keep learning with AI coding tools in general: the better your environment communicates your preferences, the less time you spend cleaning up weird “helpful” decisions later.

Where Computer Use Starts Feeling Useful

This is where the workflow becomes interesting to me. Imagine the first pass of the dashboard looks okay in code, but once the app is open in the browser, a few things feel off. Maybe the search box is cramped on smaller screens. Maybe the selected filter chip is technically visible but visually weak. Maybe the spacing between the header and controls makes the whole page feel tighter than it should. These are the kinds of problems that frontend developers notice in seconds once the browser is open, but they are surprisingly annoying to describe from memory if the model cannot see the result.

That is why I would give Codex a task more like this:

Run the PromptBoard app and inspect the /dashboard page in the browser.

Look for:
- Mobile layout issues
- Weak visual hierarchy
- Any controls that feel cramped or hard to use
- Areas where spacing, contrast, or alignment feel off
Then make targeted fixes.
Do not redesign the whole page.
Keep the dark premium aesthetic.
After changes, verify the page again in the browser.

To me, that is a much more natural frontend instruction than “rewrite the dashboard component.” It reflects what I actually care about. I do not want random code motion. I want the rendered result to feel better. That is a subtle difference, but it is a really important one.

A targeted improvement might look like this:

<div className="flex flex-col gap-4 md:flex-row md:items-center md:justify-between">
  <div className="max-w-2xl">
    <h1 className="text-3xl font-semibold tracking-tight sm:text-4xl">
      Prompt Library
    </h1>
    <p className="mt-2 text-sm leading-6 text-slate-400 sm:text-base">
      Save your best agent workflows so you stop rewriting the same ideas every week.
    </p>
  </div>

<input
    value={search}
    onChange={(e) => setSearch(e.target.value)}
    placeholder="Search prompts"
    className="w-full rounded-2xl border border-white/12 bg-white/6 px-4 py-3.5 text-sm text-white shadow-[0_0_0_1px_rgba(255,255,255,0.03)] outline-none placeholder:text-slate-500 md:max-w-xs"
  />
</div>

That is not a dramatic redesign, and that is exactly why I like it. It is believable. It is the kind of adjustment that actually improves a page without turning the entire repo into a moving target.

Why I’d Still Add Playwright

Even if I am testing a browser-aware workflow, I still want regular browser tests in the repo. I do not think those ideas compete with each other. In fact, I think they make each other better. The browser-aware workflow is great for iteration and quick visual judgment, but Playwright gives the repo a stable, repeatable way to verify important behavior.

Here is a simple test file I would include:

import { test, expect } from "@playwright/test";

test.describe("PromptBoard", () => {
  test("landing page renders hero and CTA", async ({ page }) => {
    await page.goto("http://localhost:3000");
    await expect(
      page.getByRole("heading", {
        name: /your prompt library should feel as polished as your codebase/i
      })
    ).toBeVisible();
    await expect(
      page.getByRole("button", { name: /start free trial/i })
    ).toBeVisible();
  });
  test("dashboard filter and search experience works", async ({ page }) => {
    await page.goto("http://localhost:3000/dashboard");
    await page.getByRole("button", { name: "ui" }).click();
    await page.getByPlaceholder("Search prompts").fill("React");
    await expect(
      page.getByText(/review react pr for visual regressions/i)
    ).toBeVisible();
  });
  test("mobile dashboard keeps search visible", async ({ browser }) => {
    const context = await browser.newContext({
      viewport: { width: 390, height: 844 }
    });
    const page = await context.newPage();
    await page.goto("http://localhost:3000/dashboard");
    await expect(page.getByPlaceholder("Search prompts")).toBeVisible();
  });
});

This makes the repo easier to trust. A reader can see that the workflow is not just “the AI looked at the page and seemed happy.” There is still a real test harness, which I think matters a lot if the project is going on GitHub and not just living inside a demo video.

Using Image Generation Again for the Second Pass

After the first version of the app is working, I would go back to image generation one more time, but now with more focus. Instead of asking for broad concept art, I would ask for a hero visual or dashboard atmosphere image that specifically matches the product style I have already started building. Something like this:

Generate a premium dark-mode SaaS illustration for a developer productivity product.

Requirements:
- Wide aspect ratio for website hero section
- Floating UI cards
- Prompt snippets, tags, and workflow nodes
- Deep navy and graphite background
- Emerald and violet accent lighting
- Realistic product-marketing look
- Minimal, not cartoonish
- Should feel believable for a GitHub portfolio project

I like this because it is much more specific than just asking for a cool image. It gives the output a job to do. The generated asset can either be dropped directly into the hero or used as a design reference while the rest of the layout gets refined. That is a very practical way to use image generation in frontend work, and honestly, it feels much more relevant to me than the broader “AI art” conversation.

Here is what a refined hero component might look like after that second pass:

import Image from "next/image";
import Link from "next/link";

export function Hero() {
  return (
    <section className="relative overflow-hidden border-b border-white/10 px-6 pb-24 pt-24">
      <div className="absolute inset-0 bg-[radial-gradient(circle_at_20%_20%,rgba(16,185,129,0.18),transparent_30%),radial-gradient(circle_at_80%_10%,rgba(129,140,248,0.18),transparent_28%),linear-gradient(to_bottom,rgba(255,255,255,0.02),transparent)]" />
      <div className="relative mx-auto grid max-w-6xl gap-14 lg:grid-cols-[1.05fr_0.95fr] lg:items-center">
        <div>
          <div className="inline-flex items-center rounded-full border border-white/10 bg-white/5 px-3 py-1 text-xs font-medium uppercase tracking-[0.2em] text-slate-300 backdrop-blur-xl">
            Organize. Test. Reuse.
          </div>
          <h1 className="mt-6 max-w-2xl text-5xl font-semibold tracking-tight text-white sm:text-6xl">
            Build agent workflows that survive longer than one good day.
          </h1>
          <p className="mt-6 max-w-xl text-base leading-7 text-slate-300 sm:text-lg sm:leading-8">
            PromptBoard gives developers a clean place to save proven prompts, review iterations,
            and turn scattered experiments into a repeatable system.
          </p>
          <div className="mt-8 flex flex-wrap gap-4">
            <Link
              href="/dashboard"
              className="rounded-full bg-emerald-300 px-6 py-3 text-sm font-semibold text-slate-950 shadow-[0_12px_40px_rgba(110,231,183,0.22)] transition hover:translate-y-[-1px]"
            >
              Explore Dashboard
            </Link>
            <button className="rounded-full border border-white/10 bg-white/5 px-6 py-3 text-sm font-semibold text-white backdrop-blur-xl">
              See Workflow
            </button>
          </div>
        </div>
        <div className="relative">
          <div className="absolute -inset-6 rounded-[2rem] bg-emerald-400/10 blur-3xl" />
          <div className="relative rounded-[2rem] border border-white/10 bg-white/5 p-4 shadow-2xl backdrop-blur-2xl">
            <Image
              src="/generated/hero-concept-2.png"
              alt="PromptBoard UI concept"
              width={1400}
              height={980}
              className="rounded-[1.5rem] object-cover"
              priority
            />
          </div>
        </div>
      </div>
    </section>
  );
}

To me, this is where the workflow starts to feel genuinely useful. There is a back-and-forth between visual direction and actual implementation. The generated image informs the design language, then the browser loop helps verify whether the real page actually lives up to that direction.

What I Think Is Actually Interesting About This

The thing I like most about this experiment is that it makes frontend AI workflows feel a little more honest. I do not mean “honest” in some philosophical sense. I mean honest in the sense that it acknowledges what frontend work really is. It is not just code generation. It is visual judgment, browser feedback, iteration, tiny design decisions, and the constant gap between what sounded good in a prompt and what actually looks right on the screen.

That is why this combination of computer use and image generation feels worth talking about. The image-generation part helps when the page needs direction. The computer-use part helps when the page needs verification. One helps before or during implementation, and the other helps after the code exists and has to prove itself in the browser. Put together, they create a loop that feels much closer to real product building.

At the same time, I would not pretend this removes the need for judgment. I still would not blindly trust visual taste just because an image looks polished. I still would not assume a browser interaction equals product understanding. I still want explicit prompts, repo guidance, and real tests. But I do think this workflow reduces friction in some very annoying parts of frontend development, and that alone makes it worth exploring.

How I’d Package This on GitHub

If I were publishing this project along with the article, I would keep the repo organized in a way that helps readers reproduce the same experiment. I would include a clean README, screenshots of the landing page and dashboard, the generated visual assets inside public/generated, a small docs/prompts.md file that shows the exact prompts used for both image generation and computer-use tasks, and maybe even a before-redesign branch so readers can compare the rough first pass with the improved version. That kind of repo tells a complete story. It does not just show code. It shows process.

A simple README.md could look like this:

# PromptBoard

PromptBoard is a demo project built to explore two GPT-5.4 / Codex-style frontend workflows:
1. Persistent computer-use style UI iteration
2. Image-guided frontend design
## What this repo demonstrates
- A modern landing page built in Next.js
- A small interactive dashboard flow
- Generated visual assets used in the UI design process
- Browser-based verification with Playwright
- A repo-level AGENTS.md file to guide agent behavior
## Stack
- Next.js
- TypeScript
- Tailwind CSS
- Playwright
## Local setup
~~~bash
npm install
npm run dev

Run tests

npx playwright test

Why this project exists

This repo is meant to show how modern coding agents can go beyond code generation and participate in a fuller frontend loop: visual direction, implementation, browser inspection, and iteration.

Conclusion

What I like about this Codex workflow is not that it feels futuristic. It is that it feels closer to the real messiness of frontend work. A lot of the job is not writing syntax. It is deciding what a page should look like, getting it into the browser, noticing what feels off, and then iterating until it feels right. That is why this experiment interested me in the first place. Image generation helps with visual direction when I do not want to stare at a blank hero section pretending I already know the perfect aesthetic. Computer use helps with the part where the browser becomes the truth and the UI has to prove that it actually works and looks good.

So for me, this is the more interesting follow-up to my earlier Codex 5.4 article. That first piece was about curiosity. This one is about workflow. It is about taking two ideas from OpenAI’s own video and asking a much more practical question: if I built a real demo project around them, would the result feel useful or just impressive in theory? After thinking through this PromptBoard example, I think the answer is that it could be genuinely useful, especially for frontend work where visual feedback and browser behavior matter as much as the code itself.

The repo for the full code for this project is in the following link: https://github.com/sanjaynela/promptBoard

If this article helped you think differently about AI-assisted frontend workflows, clap for it so more developers can find it, follow me for more articles like this, and leave a comment if you want me to turn this into a full GitHub walkthrough with screenshots, prompts, and the finished repo structure.

I Let Codex Design and Test a Frontend App for Me. Here’s What Actually Happened was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

A lot of AI coding conversations start to sound the same after a while. Someone says a model is better at coding, someone else says it is faster, and then a benchmark or screenshot gets passed around like that settles everything. But recently, I kept hearing something more specific about Codex 5.4. I heard it could do more than just answer questions or generate code. I heard it could actually help control the computer, move through workflows, and act a little more like an operator instead of just a chatbot with strong opinions.

That immediately made me curious. Not in a dramatic “AI is taking over” kind of way, but in a very normal developer way: wait, can this actually help me do real work with less back-and-forth?

I have recently been trying Codex, and honestly, I have been loving it so far. Before that, I had been spending a lot of time with Claude Code, and I still love Claude Code too. It genuinely changed how I think about AI-assisted development. It made me realize these tools become much more useful once you stop treating them like fancy chat windows and start using them as part of an actual workflow.

I wrote about that in two earlier articles: After a Week of Claude Code: 10 Things I Wish I Knew on Day One and Claude Code Skills: The One Feature That Finally Stopped Me From Repeating Myself. Those articles came from real use, real friction, and real trial and error. This article comes from the same place.

I was already enjoying Claude Code. Then I started trying Codex more seriously. Then I heard people say Codex 5.4 could control the computer. At that point, I was obviously going to poke at it. Because once you hear something like that, it is very hard not to get curious.

So this article is really about that curiosity. What does it actually mean when people say Codex 5.4 can control the computer? Why does that matter? And why does that feel different from the usual “AI can help you code” story we have all heard a hundred times already?

What People Mean When They Say Codex 5.4 Can “Control the Computer”

Let’s make this less dramatic first. When people say Codex 5.4 can control the computer, they do not mean it has suddenly become a tiny digital employee living inside your laptop and making life choices on your behalf. What they usually mean is something much more practical: the model can move beyond just giving you instructions and help operate a workflow.

That might mean writing commands, running scripts, inspecting what is happening, interacting with tools, or helping bridge the annoying gap between “here is what you should do next” and “okay, now please actually do part of it.” That gap is where a lot of developer energy gets wasted.

For a long time, most AI tools felt like smart advisors. You asked a question, got an answer, and then went off to do the real work yourself. Open the terminal. Run the command. Open the browser. Check the page. Copy the error. Paste it back. Ask again. Repeat. That workflow is still useful, but it is also exhausting.

The exciting part here is that Codex starts to feel less like an advisor and more like an operator. Not perfect. Not magic. But more active. And that shift is a bigger deal than it sounds.

Why This Caught My Attention

The funny thing is, the more I liked Claude Code, the more curious I became about Codex. Sometimes people act like once you like one tool, you are supposed to pick a side and become weirdly loyal, like you are joining a sports team. That has never made much sense to me.

When I find a tool that genuinely improves my workflow, my first reaction is not, “Great, now I can ignore everything else forever.” It is usually, “Interesting. Now I want to understand what the other tools are good at too.” That is exactly what happened here.

Claude Code made me appreciate structured AI workflows more deeply. It made me care about memory, context, reusable prompts, and long-running coding sessions that feel less like one-off chats and more like collaboration. So when I started trying Codex and heard people describe things like computer control and auto script workflows, I wanted to see what that actually meant in practice.

Not as a headline. Not as a product demo. In actual day-to-day work. Because that is where the truth always shows up. A feature can sound incredible on social media and still be useless when you are trying to debug a broken screen late at night while your dev server is half-working and your patience is gone. That is the real test.

The Shift From Chatting to Operating

This is the part that feels genuinely new to me. Older AI workflows usually looked like this: you ask for help, the model tells you what to do, you do it manually, you come back with the result, the model gives the next suggestion, and you repeat the loop until either the problem is solved or both of you lose the will to continue.

That loop works. We have all used it. But it also means you are the bridge between the model and the task the entire time. You are the one copying commands, opening tabs, checking whether the page loaded, rerunning the test, and pasting logs. You are basically acting as human middleware.

And honestly, a surprising amount of software work is just that: human middleware.

The more interesting promise with something like Codex 5.4 is that you give the model a goal, it inspects context, it acts, it verifies, and it continues. That is a very different feeling. It means the value is not just in generating a good answer. The value is in reducing the number of times you have to manually hand off between intention and execution.

That is what makes “computer control” interesting to me. It is not that the model suddenly became infinitely smarter. It is that the workflow starts to feel more operational.

What “Auto Script Control” Could Look Like in Real Life

This is where it gets practical. Because if this idea only sounds impressive in theory, then it is not very useful.

One obvious place is localhost app testing. You are building a feature locally, you start the dev server, and you want to know if the page loads correctly, if the login flow works, if the button actually does anything, or if the layout broke in some weird new way. Normally, that means bouncing between your editor, terminal, browser, console, and whatever scraps of emotional resilience you still have left. A more agentic workflow could start the app, open the page, click through the main flow, notice visible issues, report what failed, and possibly try the obvious next step. That is where this starts to feel less like “write me a function” and more like “help me move work forward.”

Another good example is repetitive admin workflows. Every team has some version of this: a dashboard no one loves, an internal tool that works just well enough to remain alive, and a series of clicks everyone knows by memory because they have done it 600 times before. Open dashboard, search record, check status, open details, export something, go back, repeat. This kind of work is not intellectually deep. It is just repetitive. And repetitive work is exactly where controlled automation becomes interesting, not because it is glamorous, but because it is the kind of work people quietly lose time to every single week.

QA-style smoke testing is another area where the idea gets compelling fast. You make a change and want to know whether the core experience still works. Not whether your test suite passes in theory, but whether the app still behaves normally to a human looking at it. Can the page open? Can the user navigate? Is the modal blocking the screen? Did the layout collapse on a smaller viewport? Did a button disappear into the void? Traditional scripts are still important here, of course, but visual workflows catch a different class of problems. And sometimes those are the problems users notice first.

I also think setup and troubleshooting is a big one. Installing dependencies, running a project for the first time, figuring out why the environment is broken, seeing which command failed, and realizing the problem is not actually the command you thought it was. That kind of troubleshooting is rarely one clean step. It is more like a chain of small observations. That is where an assistant that can inspect, act, and continue starts feeling more helpful than one that just keeps throwing suggestions over the wall.

Scripts vs Computer Use: Why the Difference Matters

This distinction matters a lot because “script automation” and “computer use” sound similar, but they are not exactly the same thing.

Scripts are great when the workflow is structured and predictable. If you know the exact command, exact path, exact expected outcome, and exact trigger, scripts are wonderful. They are fast, clean, and reliable. But not every problem is that tidy.

Sometimes the issue depends on what is visually happening on screen. A page technically loaded, but the modal is blocking everything. A button exists, but it is off-screen. The form rendered, but the layout is broken. The app did not crash, but it looks obviously wrong. A script may happily report success in situations where a human would look at the page and say, “Yeah, this is broken.”

That is where computer-use style workflows become valuable. They are useful when the state of the task depends partly on what can be observed, not just what can be executed. To me, the sweet spot is not choosing one over the other. It is combining both. Let scripts handle the structured parts. Let computer-use workflows handle the messy, visual, context-heavy parts. That feels much closer to how real work actually happens.

How I’d Want Codex 5.4 to Work in Practice

This part matters a lot, because power without structure gets chaotic very quickly. If I am using something like Codex 5.4 in a more agentic mode, I want to give it a clear goal and define what success looks like. I want it to inspect the environment before acting, act in small understandable steps, verify instead of guess, and leave me a clean summary of what it actually did.

That last part is huge. I do not want an AI that just confidently clicks around, runs a few things, and then announces, “Everything looks good,” like an intern who is trying not to get caught. I want something that checks. Something that tells me what it observed. Something that says: here is what I ran, here is what happened, here is what failed, here is what I changed, and here is what still needs your attention.

That is the kind of workflow that builds trust. Not false confidence. Not vibes. Trust.

What Still Makes Me Cautious

As exciting as this is, I do not think it helps anyone to pretend the technology is flawless. There are still real reasons to be cautious. UI flows are fragile. Layouts change. Selectors break. Pages behave differently across environments. Permissions matter. Sensitive workflows need guardrails. And some tasks are simply too high-risk to hand over casually.

That is why I think it is important to stay grounded. I would absolutely use this kind of workflow for repetitive testing, setup help, UI inspection, and boring operational tasks. I would not blindly let it loose on something destructive just because the demo looked smooth.

That is not fear. That is just good judgment. The real opportunity here is not “remove humans completely.” It is “remove the boring glue work that humans should not have to keep doing manually.” That is a much more useful goal.

Why This Feels Bigger Than Just Another Model Upgrade

Every time a new model comes out, the internet immediately fills up with the usual conversations. Is it smarter? Is it faster? Did benchmark X go up? Did benchmark Y go down? Who won this week’s AI leaderboard argument?

All of that has some value, I guess. But what changes my day is not a benchmark chart. What changes my day is workflow compression. Less tab switching, less copy-pasting, less re-explaining, and less manual glue work between the editor, terminal, browser, logs, and testing flow.

That is what I care about. If a tool helps remove friction from actual work, that matters more to me than another screenshot proving it scored slightly higher on some abstract test. That is why this topic stuck with me. The interesting question is not just whether Codex 5.4 is “better.” The interesting question is whether it changes the shape of the work.

And I think computer control, even in its imperfect current form, points toward exactly that.

Who Should Care About This

I think this is especially interesting for developers who spend a lot of time debugging UI-heavy workflows, QA engineers who care about real visual behavior and not just pass-or-fail scripts, indie hackers who do not have time to manually repeat the same setup and testing steps all day, founders wearing six hats at once, and anyone dealing with repetitive browser workflows that are too annoying to keep doing by hand but too messy for traditional automation alone.

If you have never felt the pain of repetitive software workflows, this might sound like a neat feature and not much more. But if you have spent enough hours bouncing between your terminal, browser, logs, and broken local environment, you immediately understand why this feels exciting. It is not because it is flashy. It is because it is useful.

Conclusion

At the end of the day, this article came from a very simple place. I heard Codex 5.4 could control the computer, and I got curious.

I have been enjoying Codex a lot recently, and that curiosity made me want to understand what this feature really means once you strip away the buzzwords and look at it through the lens of real developer work. Claude Code already made me appreciate how powerful AI coding workflows can be when the tool fits naturally into how you actually work. Codex made me curious in a slightly different way. It made me ask whether AI could move one step closer from “helpful assistant” to “practical operator.”

That is the part I find exciting. Not because I think everything should be automated. Not because I think one tool will replace every other tool. But because reducing the annoying handoff between intention and execution is a genuinely meaningful improvement. And honestly, that is where I think a lot of the real progress is happening.

If you have been experimenting with Codex, Claude Code, or any AI workflow that goes beyond just chatting, I would love to hear how you are using it.

And if this article helped, gave you ideas, or matched something you have been curious about too, feel free to clap, follow, and leave a comment. I always enjoy hearing how other developers are actually using these tools in the real world.

I Heard Codex 5.4 Could Control the Computer, So I Had to Try It was originally published in Write A Catalyst on Medium, where people are continuing the conversation by highlighting and responding to this story.