DEV Community: Mary Piakovski

Milliseconds Cost Millions: How to Architect High-Conversion Product Grids in SwiftUI

Mary Piakovski — Mon, 30 Mar 2026 12:32:34 +0000

A production-grade guide to building scroll-fast, revenue-optimised iOS product grids — from LazyVGrid fundamentals to ProMotion-ready rendering.

There is a number you should have memorised before you write a single line of grid layout code: 100 milliseconds. That is the threshold at which latency stops being invisible to the human nervous system and starts registering as friction. In a product grid — where a shopper is making split-second judgements about whether to tap or scroll past — friction is revenue leaving through the back door.

This is not speculation. A landmark study co-authored by Deloitte and Google, Milliseconds Make Millions (2020), quantified the relationship between mobile site speed and commercial outcomes across hundreds of brand sites. It found that even a 0.1-second improvement in mobile load performance correlated with an 8% increase in retail conversions. On a platform as performance-sensitive as iOS — where users have been trained by Apple's own apps to expect buttery 60Hz and, on newer hardware, 120Hz ProMotion scrolling — the stakes are even higher.

SwiftUI makes it easy to build product grids that look great. What it does not do automatically is make them perform great at scale. This guide covers the full architecture: the business case, the SwiftUI primitives, the image-loading strategy, view equatability, and how to verify everything with Instruments before you ship.

The Business Case for Performance-First Grid Architecture

Before diving into code, the numbers deserve a direct statement.

The chart above models the compounding effect of accumulated latency on add-to-cart conversions. At zero lag, a well-designed product grid can achieve conversion rates approaching 5–6%. Each additional 100ms of friction — caused by unoptimised image loading, excessive view redraws, or dropped frames during scrolling — erodes that figure systematically. By the time cumulative latency reaches 500ms, conversion has typically more than halved.

David Chan, e-commerce founder of Davilane and a practitioner with over eleven years building mobile-first retail experiences, has seen this pattern repeat across platforms and product categories:

For every 100ms delay in scroll or load time we see a measurable drop in add-to-cart conversions — in our cohort data it runs between 0.7 and 1.1 percentage points per 100ms, compounding as the session goes on. The first scroll frame is a trust signal. If it stutters, the shopper's subconscious has already decided this app does not deserve their attention. The cart is empty before they even see the product.

★ ★ ★ ★ ★

David Chan Founder, Davilane · 11 years e-commerce

This is not a marginal UX concern. For a mid-size retailer processing ten thousand mobile sessions daily at a $45 average order value, moving from a 300ms grid to a 100ms grid — and recovering two percentage points of conversion — represents roughly $9,000 per day in recoverable revenue. The engineering investment in grid performance has one of the highest ROI ratios in all of mobile development.

The Right Primitive: LazyVGrid Over VGrid

SwiftUI ships with two conceptually distinct grid primitives: Grid (eager) and LazyVGrid / LazyHGrid (lazy). The naming is descriptive. Grid renders all of its children immediately when the parent view is initialised — fine for a settings screen with twelve rows, catastrophic for a catalogue with five hundred products.

LazyVGrid defers view creation until items are about to enter the visible viewport. Items that scroll out of view are destroyed and their memory reclaimed. According to Apple's LazyVGrid documentation, this on-demand rendering is the primary mechanism for maintaining performance across large datasets.

The GridItem configuration type drives the column behaviour. There are three column layouts worth understanding in a commercial context:

Column Type	Declaration	Best Use Case	Limitation
`fixed`	`GridItem(.fixed(160))`	Strict brand grid with pixel-perfect cards	Ignores device width; can overflow or leave gaps
`flexible`	`GridItem(.flexible(min:80, max:200))`	Responsive two/three-column grid	Requires explicit column count in array
`adaptive`	`GridItem(.adaptive(minimum: 140))`	Dynamic column count based on width	Column count changes on rotation; test carefully

For most e-commerce product grids, a two-column flexible layout on iPhone and a three-column flexible layout on iPad represents the highest-converting layout pattern. The cards are large enough for clear product imagery and price visibility, but the grid still communicates catalogue breadth.

struct ProductGridView: View {
    let products: [Product]

    private var columns: [GridItem] {
        let isIpad = UIDevice.current.userInterfaceIdiom == .pad
        let count = isIpad ? 3 : 2
        return Array(repeating: GridItem(.flexible(minimum: 140), spacing: 16), count: count)
    }

    var body: some View {
        ScrollView {
            LazyVGrid(columns: columns, spacing: 16) {
                ForEach(products) { product in
                    ProductCard(product: product)
                }
            }
            .padding(.horizontal, 16)
        }
    }
}

One subtle architectural point: LazyVGrid requires a ScrollView ancestor to function correctly. Without it, the lazy behaviour collapses — the grid renders all rows eagerly regardless of the Lazy prefix.

Image Loading: The Biggest Performance Variable

In any product grid, images account for 70–90% of the visual weight of each cell and, if mishandled, for the majority of frame-drop events during scrolling. SwiftUI ships AsyncImage as a first-party solution. It is the right choice for simple cases, but it comes with a hard constraint that matters enormously at scale: AsyncImage does not persist its image cache across view destruction.

When a product card scrolls off screen, LazyVGrid destroys the view. When it scrolls back into view, AsyncImage re-initiates the network request. On a fast connection this produces a flash of loading placeholder on every scroll-back. On a slow connection it can stall a frame entirely.

You can configure URLCache globally to give AsyncImage more persistence:

// In your App init or scene setup
URLCache.shared.memoryCapacity = 50_000_000   // 50 MB memory
URLCache.shared.diskCapacity = 500_000_000    // 500 MB disk

This helps significantly for repeat sessions but does not eliminate the within-session flash. For high-volume catalogues, a dedicated image-caching library such as Kingfisher resolves this by maintaining an in-process memory cache keyed to the image URL:

import Kingfisher

struct ProductImageView: View {
    let url: URL?

    var body: some View {
        KFImage(url)
            .placeholder { ProgressView() }
            .resizable()
            .aspectRatio(contentMode: .fill)
            .frame(height: 180)
            .clipped()
    }
}

KFImage caches images in memory on first load and serves them from the cache on every subsequent scroll-back, eliminating the placeholder flash entirely. Kingfisher also supports image downsampling — rendering images at the display resolution rather than the full original resolution — which reduces memory pressure by up to 75% on image-heavy grids.

View Struct Equatability: Stop Redrawing What Hasn't Changed

SwiftUI's diffing engine is sophisticated but not telepathic. By default, whenever a parent view's state changes — say, the user adds a product to their wishlist and a heart icon updates — SwiftUI re-evaluates the body of every sibling ProductCard in the grid, even those with data that has not changed at all.

On a two-column grid of forty visible products, that is up to eighty body recomputations triggered by a single unrelated state mutation. At 60Hz, you have 16.7ms per frame. Forty redundant body calls at even 0.5ms each consume 20ms — you have already missed the frame deadline before any actual drawing has occurred.

The fix is EquatableView. By conforming your card view to Equatable and applying the .equatable() modifier, you allow SwiftUI to short-circuit the body call whenever the view's inputs are unchanged.

Majid Jabrayilov, Swift developer and creator of CardioBot, NapBot, and FastBot — and one of the most widely-read voices in the SwiftUI ecosystem via swiftwithmajid.com — has made this pattern central to his performance architecture:

EquatableView can boost performance when body computation is longer than your equality check. The pattern I use in NapBot's calendar grid — which renders hundreds of day cells simultaneously — is to extract the rendering view from the container view, implement Equatable on the render struct, and let SwiftUI skip the body entirely when the data hasn't changed. The equality check is microseconds. The body, with its layout passes and child view allocations, is not.

<div class="ltag-quote__mark ltag-quote__mark--end">
  <svg viewBox="0 0 24 24" fill="currentColor" xmlns="http://www.w3.org/2000/svg">
    <path d="M19.417 6.679C20.447 7.773 21 9 21 10.989C21 14.489 18.543 17.626 14.97 19.177L14.077 17.799C17.412 15.995 18.064 13.654 18.324 12.178C17.787 12.456 17.084 12.553 16.395 12.489C14.591 12.322 13.169 10.841 13.169 9C13.169 8.07174 13.5377 7.1815 14.1941 6.52513C14.8505 5.86875 15.7407 5.5 16.669 5.5C17.1823 5.50449 17.6897 5.61104 18.1614 5.81345C18.6332 6.01586 19.06 6.31008 19.417 6.679ZM9.417 6.679C10.447 7.773 11 9 11 10.989C11 14.489 8.543 17.626 4.97 19.177L4.077 17.799C7.412 15.995 8.064 13.654 8.324 12.178C7.787 12.456 7.084 12.553 6.395 12.489C4.591 12.322 3.169 10.841 3.169 9C3.169 8.07174 3.53775 7.1815 4.19413 6.52513C4.85051 5.86875 5.74074 5.5 6.669 5.5C7.18234 5.50449 7.68967 5.61104 8.16144 5.81344C8.63321 6.01585 9.06001 6.31008 9.417 6.679Z" />
  </svg>
</div>

★
★
★
★
★

Majid Jabrayilov
Swift Developer · Creator of CardioBot, NapBot, FastBot · swiftwithmajid.com

In practice, for a ProductCard struct, this looks like:

struct ProductCard: View, Equatable {
    let product: Product

    static func == (lhs: ProductCard, rhs: ProductCard) -> Bool {
        lhs.product.id == rhs.product.id &&
        lhs.product.price == rhs.product.price &&
        lhs.product.isWishlisted == rhs.product.isWishlisted
    }

    var body: some View {
        // ... card layout
    }
}

// Usage with equatable modifier
LazyVGrid(columns: columns) {
    ForEach(products) { product in
        ProductCard(product: product)
            .equatable()
    }
}

This single change can eliminate the majority of unnecessary redraws in a grid with stable data — the most common case during normal browsing.

ProMotion and 120Hz: The New Performance Ceiling

ProMotion displays — available on iPhone 13 Pro and later, and all recent iPad Pros — render at up to 120Hz, halving the frame budget from 16.7ms to 8.3ms. This is not a future consideration; as of 2025, ProMotion devices represent a majority of premium iOS hardware in active use.

The frame rate relationship with engagement is not linear. Users may not consciously perceive the difference between 60Hz and 120Hz during static viewing, but the tactile quality of scrolling at 120Hz is palpable — and the data bears this out.

The grouped chart above illustrates the divergence in session metrics across frame rate tiers. The jump between 60Hz and 90Hz is meaningful; the jump from 90Hz to a full 120Hz ProMotion experience produces a further material reduction in bounce rate and increase in session depth.

For your grid to sustain 120Hz, every body evaluation, every layout pass, and every image decode triggered by a scroll event must complete within 8.3ms on a shared render thread. The optimisations discussed — LazyVGrid, equatable views, pre-cached images — are not optional refinements at this performance tier; they are prerequisites.

Profiling with Instruments: Verify, Don't Assume

Every performance claim in this article should be verified against your specific data and device targets using Xcode Instruments. There is no substitute for measurement. The SwiftUI Performance Profiling with Instruments guide on dev.to provides a practical walkthrough; below is the accelerated version for product grids specifically.

Step 1: Time Profiler. Profile on a physical ProMotion device (never the simulator). Filter the flame graph to your view module. Any body call exceeding 2ms in a hot scroll path is a red flag.

Step 2: SwiftUI instrument (Xcode 15+). The dedicated SwiftUI instrument visualises view update frequency and highlights "unnecessary" updates — these are the cells your equatability implementation has not yet caught.

Step 3: Memory Allocations. Scroll rapidly through your full catalogue catalogue. Watch the allocation counter. If it climbs indefinitely, you have a retain cycle in your cell views or a cache that is not evicting. Kingfisher's default LRU eviction policy handles the image side automatically; check your @StateObject lifecycle for the rest.

For scroll testing with XCTest, this dev.to walkthrough on UI Performance Testing with XCTest demonstrates how to establish scroll performance baselines and integrate them into CI, so regressions surface before they reach production.

Architecture Summary: The Production Checklist

Concern	Naive Default	Production Pattern
Grid primitive	`VStack` + `ForEach`	`LazyVGrid` inside `ScrollView`
Column layout	Hardcoded `fixed`	`flexible` with device-aware count
Image loading	`AsyncImage` (no persistent cache)	`KFImage` (Kingfisher) or URLCache-configured `AsyncImage`
Image resolution	Full-size from CDN	Downsampled to display size via Kingfisher processor
View redraws	Default SwiftUI diffing	`Equatable` conformance + `.equatable()` modifier
State granularity	Single `@Published` array	Per-item `@Observable` to isolate invalidation scope
Frame target	60Hz assumed	8.3ms budget for ProMotion 120Hz
Performance verification	Visual inspection	Instruments: Time Profiler + SwiftUI instrument + Memory Allocations
Scroll regression testing	Manual	XCTest scroll performance baselines in CI

Going Deeper

The following resources extend each of the major topics covered in this guide:

SwiftUI Performance Optimisation — Smooth UIs, Less Recomputing on dev.to — a comprehensive catalogue of anti-patterns that cause unnecessary redraws, covering .id() misuse, environment propagation overhead, and GPU pass optimisation.
Using the Kingfisher Library in iOS Development on dev.to — hands-on integration guide with practical SwiftUI cell examples, directly applicable to product card implementations.
Discovering UI Performance Testing with XCTest — Scrolling Performance on dev.to — automation-focused guide to establishing and defending scroll FPS baselines in your release pipeline.

For the underlying rendering model, Apple's WWDC 2021 session "Demystify SwiftUI" is the canonical reference for understanding view identity, lifetime, and the dependency graph that drives body re-evaluation — essential reading for anyone optimising a grid at the architecture level.

The Akamai State of Online Retail Performance (2017, updated annually) provides the industry benchmarking data underpinning the latency-to-conversion models discussed in the business case section, with retail-specific segmentation not available in the Deloitte/Google study.

Conclusion

High-conversion product grids in SwiftUI are not an accident. They are the result of four deliberate architectural choices made before the first LazyVGrid is rendered: the right lazy primitive, a persistent image cache, equatable view structs to suppress redundant redraws, and a profiling discipline that validates performance claims against real hardware.

The business stakes are real. David Chan's cohort data and the Deloitte/Google research converge on the same message: each 100ms of friction is a measurable deduction from your conversion rate and your revenue. On ProMotion hardware, where users have been calibrated to 120Hz tactile fidelity, the margin for unoptimised code is measured in single-digit milliseconds.

Build the grid as if every frame costs money. Because statistically, the ones you drop do.

Apple Developer documentation references: LazyVGrid · AsyncImage · WWDC 2021: Demystify SwiftUI

The Complete Guide to Building an iOS App with Claude Code (No Xcode Required)

Mary Piakovski — Fri, 27 Mar 2026 16:17:22 +0000

A practical, production-ready walkthrough for developers and non-coders alike: from zero to App Store.

You have an idea for an iOS app. You've heard Claude Code can write the whole thing for you. You Google "how to build an iOS app" and five minutes later you're reading about Swift, Xcode, provisioning profiles, and signing certificates, and you close the laptop.

Here's the thing: you don't have to go near Xcode. There is a modern, AI-friendly stack that lets Claude Code do the heavy lifting while you stay firmly in the driving seat. This guide walks you through exactly that, from the first prompt all the way to a live app on the App Store, and then goes one level deeper into the backend infrastructure that most tutorials completely ignore.

Why the "Install Xcode" Advice Is Wrong for Non-Coders

Almost every iOS tutorial starts with "Step 1: Download Xcode." Xcode is Apple's official IDE, and it weighs in at roughly 15 GB. It is a deeply professional tool built for engineers who speak Swift fluently, understand Interface Builder, and have memorised the difference between a simulator scheme and an archive build. For a non-coder using an AI assistant, Xcode is a trap. The moment something breaks inside it (and it will) you are staring at cryptic build logs in a language Claude cannot fully see, because Claude Code operates in your terminal, not inside a proprietary GUI.

Beyond the learning curve, Xcode tethers you to a macOS machine. No Mac? No build. Xcode also introduces a layer of abstraction between Claude's generated code and the running app that is genuinely hostile to the "write → see → iterate" loop that makes AI-assisted development so powerful.

The good news: the open-source ecosystem has largely solved this problem. The approach below replaces Xcode with a cloud-first toolchain that runs entirely from your terminal and your phone's camera.

The Stack: What Claude Code Will Actually Use

Tool	What It Replaces	Why It Works with Claude Code
Expo	Xcode + Swift boilerplate	Zero-config React Native scaffold; Claude knows it cold
Expo Go	iOS Simulator	Runs on your real phone via QR code, no Apple Developer account needed for testing
NativeWind	UIKit / SwiftUI styling	Tailwind CSS syntax for mobile; Claude's training data is saturated with Tailwind
EAS Build	Xcode Archive & Organizer	Cloud build service; submits to App Store without touching your machine
Supabase / PostgreSQL on VPS	Firebase / managed backend	Portable, cost-efficient, and vendor-lock-free (more on this below)

This table alone should reframe your mental model. You are not building a "Swift app." You are building a React Native app delivered as a native iOS binary, using a toolchain that Claude Code was effectively trained to generate.

Step-by-Step: Building Your iOS App with Claude Code

1. Bootstrap with Expo — Skip Xcode Entirely

Open your terminal, open Claude Code, and give it this instruction:

"Create a new Expo app using create-expo-app. Use TypeScript. Set up the folder structure for a [your app idea] with a tab-based navigation using Expo Router."

Claude Code will run the scaffolding commands, install dependencies, and produce a working project. You do not install Xcode. You do not write a single line of Swift. The entire app is written in TypeScript/React Native, which compiles to native iOS code only at build time — and that build happens in the cloud.

This approach aligns with what researchers studying AI-assisted software development at Microsoft Research found: AI coding assistants are most effective when the human operator focuses on intent specification (what the app should do) rather than syntax supervision (how the code is written). The productivity gains compound fastest in domains — like React Native — where the AI's training corpus is densest. (Copilot Productivity Study, GitHub/Microsoft, 2023)

2. Test Instantly with Expo Go

Once Claude Code has the project running (npx expo start), it will display a QR code in your terminal. Download Expo Go from the App Store on your iPhone, scan the code, and your app is running on your actual device — with live reload. Every time Claude edits a file, the phone updates in seconds.

This loop is the single biggest unlock for non-coders using AI. You are not waiting for builds. You are not interpreting simulator errors. You see the app on glass in your hand, you describe what looks wrong to Claude, and it fixes it.

3. Style with NativeWind — Because Claude Already Knows Tailwind

Tell Claude Code:

"Install NativeWind and configure it. Use Tailwind utility classes for all component styling going forward."

NativeWind translates Tailwind CSS class names into React Native StyleSheet objects at compile time. The reason this matters for AI-assisted development is statistical: Tailwind is one of the most documented CSS frameworks on the internet. Claude's ability to produce correct, aesthetically coherent Tailwind classes is dramatically higher than its ability to produce correct React Native StyleSheet objects from scratch. The result is that your UI actually looks good — not like a default component dump.

This is supported by survey data from Stack Overflow's 2024 Developer Survey, which found Tailwind CSS to be the most-used CSS framework for the third consecutive year, with 52% adoption among professional web developers — ensuring robust AI training coverage. (Stack Overflow Developer Survey 2024)

4. Ship to the App Store with EAS Build

When you are ready to publish, tell Claude Code:

"Configure EAS Build for this project. Set up an eas.json with production and preview profiles. Walk me through submitting to the App Store."

EAS Build (Expo Application Services) compiles your React Native code into a native .ipa file on Expo's cloud infrastructure. You never run xcodebuild. You never sign a certificate manually. You upload the binary to App Store Connect through the EAS CLI or Expo's dashboard.

The practical implication: you can ship an iOS app from a Windows laptop or a Linux machine. The only Apple requirement is a paid Apple Developer Program membership ($99/year), which you need regardless of your toolchain.

The Safety Checklist Every iOS Developer Should Follow

Before you ship anything, this checklist from developer and security advocate @prajwaltomar_ captures the critical pre-launch verification steps cleanly:

// Detect dark theme var iframe = document.getElementById('tweet-2033219198621749262-705'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2033219198621749262&theme=dark" }

The Backend Problem: What AI-Generated Code Gets Wrong

Building the front end is only half the job. Most iOS apps need a backend — an API, a database, authentication, file storage. Claude Code will generate all of this for you, typically as a Node.js or Python API paired with a PostgreSQL database, containerised with Docker.

The generated code will run. What it will not do, by default, is survive production. This is the gap that costs developers money, data, and App Store reviews.

Choosing Your Infrastructure: VPS Over Managed Cloud

Before we get into hardening, there is an architectural decision worth making consciously. The default recommendation from most tutorials is to deploy to a managed platform — Heroku, Railway, Render, or Firebase. These are convenient, but they impose vendor-specific abstractions that make migration expensive and painful.

David Heinemeier Hansson, creator of Ruby on Rails and CTO of 37signals, has been vocal on this:

We can't have competition in the cloud as long as folks are locked into proprietary or overly-complicated setups that makes moving from one vendor to another a huge hassle and expense... [Containerization] allows you to move through all those stages of a production deployment without onerous migration costs.

★ ★ ★ ★ ★

David Heinemeier Hansson Creator of Ruby on Rails, CTO of 37signals

This is the strongest argument for pairing Claude Code's Docker output with a straightforward VPS. When Claude Code generates your Dockerized backend, it isn't just saving you development time — it is buying you architectural freedom. You own the containers. If your app scales overnight, you are not trapped paying exorbitant managed-cloud fees; you rent a larger server and move your containers in minutes. Providers like HostZealot offer bare-metal and VPS tiers specifically sized for this kind of portable, container-native deployment.

The "Day-Two" Infrastructure Blind Spots

To understand exactly what Claude Code misses on infrastructure, I asked Mike Kharchenko, a hosting expert at HostZealot with more than seven years of experience powering iOS app backends, the following question:

"When an iOS developer uses an AI like Claude Code to generate and deploy a Dockerized API and PostgreSQL stack on a raw VPS, what critical 'day-two' production blind spots does the AI typically miss, and how should they configure their HostZealot server to prevent these catastrophic failures?"

The gap between "code that runs" and "infrastructure that survives" is where most AI-generated backends collapse in production. Three areas are almost always neglected.

First, security and Apple ATS compliance. AI-generated docker-compose files notoriously expose database ports globally — port 5432 open to the world. You need internal Docker networks so your API and Postgres talk to each other privately, a UFW ruleset that blocks everything except 80, 443, and your SSH port, and a reverse proxy like Nginx or Traefik terminating SSL with a Let's Encrypt certificate. This last point is not optional: Apple's App Transport Security policy enforces HTTPS for all network connections, so an app talking to a plain HTTP endpoint will be rejected at the App Store review stage.

Second, data persistence and disaster recovery. Docker volumes mapped incorrectly mean your database is ephemeral — a container restart and your production data is gone. Map your Postgres data directory to a host path explicitly, then set up a cron job that runs pg_dump, compresses the output, and ships it to an offsite S3-compatible bucket nightly. HostZealot's VPS plans include a separate backup volume you can mount specifically for this.

Third, resource allocation. Node.js and Python APIs can spike memory during traffic bursts. Without Docker memory limits set in your compose file, a spike in your API tier can exhaust RAM and trigger the Linux OOM killer against your Postgres process — which is exactly backwards from what you want. Set explicit memory limits per service, configure swap space on the host (at least 2x the physical RAM for a small VPS), and use a process monitor to alert you before the machine hits the ceiling.

The AI gives you the skeleton. These three layers are what make it production-grade.

★ ★ ★ ★ ★

Mike Kharchenko Hosting Expert, HostZealot (7+ years experience)

Production Infrastructure Checklist

The following table summarises the hardening steps Mike describes, mapped to the specific Docker and server configuration changes required:

Risk Area	AI-Generated Default	Production Configuration
Database port exposure	`ports: "5432:5432"` in compose	Internal Docker network only; no host port mapping
SSL / HTTPS	None	Nginx reverse proxy + Let's Encrypt (Certbot)
Firewall	Open	UFW: allow 22, 80, 443; deny all else
Data persistence	Anonymous volume	Named volume mapped to host path (`/data/postgres`)
Backup	None	Nightly `pg_dump` → compressed → offsite S3 bucket
Memory limits	None	`mem_limit: 512m` per service in compose file
Swap space	OS default (often 0)	2–4 GB swap configured on host
ATS compliance	HTTP API	HTTPS with valid certificate (required by Apple)

Mobile App Market Context: Why This Stack Is Timely

React Native's share of cross-platform mobile development has grown consistently since 2019, making it the dominant framework for teams that want a single codebase targeting both iOS and Android. Expo, which wraps React Native with managed tooling, has accelerated this trend by eliminating the native build environment requirement — exactly the friction this guide sidesteps.

The adoption of AI coding assistants among professional developers crossed 60% in 2024, with the fastest growth in mobile and full-stack categories. Claude Code specifically has seen rapid uptake for scaffolding tasks — generating project boilerplates, writing API route handlers, and producing Docker configuration files — precisely the tasks this guide delegates to it.

Research from the ACM examining AI pair programming in mobile contexts found that developers using LLM assistants completed feature implementation tasks 35–55% faster than control groups, with the largest gains in boilerplate-heavy environments like React Native configuration. (ACM Digital Library — AI-Assisted Mobile Development, 2023)

A separate analysis from the MIT Sloan School of Management on software productivity and AI tooling concluded that the quality delta between AI-assisted and unassisted code is largest in well-documented, high-frequency domains — again strongly favouring React Native and Expo over lower-coverage targets like native Swift. (MIT Sloan Working Paper on AI and Developer Productivity, 2024)

Going Deeper: Recommended Reading

If this guide has sparked questions about adjacent topics, the following articles from the developer community go further:

Building a Full-Stack App with Expo Router and Supabase — A hands-on walkthrough pairing the Expo Router file-based navigation system with a Supabase backend, which maps cleanly onto the stack described in this guide.
NativeWind v4: Tailwind CSS for React Native in 2024 — A deep dive into the NativeWind configuration changes in v4 and how to handle edge cases that Claude Code may generate incorrectly on the first pass.
Dockerizing a Node.js API for Production: Beyond the Basics — Covers multi-stage Docker builds, non-root user containers, and health checks — all things Claude Code omits from its generated Dockerfile by default.

The Mental Model That Ties It Together

Claude Code is extraordinarily good at generation. It is structurally weak at operational awareness — the things that don't show up until a server has been running for 72 hours and the swap is full. The workflow this guide describes exploits the first capability while delegating the second to proven tooling and expert configuration.

On the front end, Expo + NativeWind + EAS Build give you a shipping path to the App Store that requires zero knowledge of Xcode, Swift, or Apple's build toolchain. Claude Code handles the code; Expo's cloud handles the compilation; your phone handles the testing.

On the backend, Claude Code generates solid Docker scaffolding that is production-adjacent. Making it genuinely production-ready requires the four layers Mike Kharchenko describes — network isolation, TLS termination, persistence mapping, and resource limits — applied to a reliable VPS where you control the environment.

The architectural result is an app stack that is portable, cost-efficient, and free from the vendor lock-in that DHH has spent years arguing against. You own the containers. You own the data. If you outgrow your server, you move in an afternoon.

That is the stack. Build something.

Further reading on the regulatory and technical landscape for iOS apps: Apple App Store Review Guidelines and the WWDC 2023 session on App Transport Security.

SwiftUI in Real Apps

Mary Piakovski — Wed, 18 Feb 2026 11:49:04 +0000

We've all seen the tutorials. A developer on YouTube builds a beautiful
weather app in ten minutes. It all looks easy. Drag a few views around,
drop in some \@State and it works. You decide to try it when your boss
asks for three new features. A few minutes of working on it or hours
later, it keeps crashing.

Building a prototype is easy. Building a SwiftUI app that survives a
year of growth and changing deadlines is not. Here is a guide on writing
a SwiftUI code that lasts.

Why Codes Don't Survive

Before we get to how to write code that lasts, let's get into what a lot
of us get wrong. A common mistake is the 500-line file that tries to do
everything. Buttons, text, logic and styling in one property. It will
work well at first until you need to change the login logic and you are
digging through 400 lines of UI code to find one function.

Karan Pal, an iOS
Architect, frames it better:

"You end up building UserListItem,
ProductListItem and other 10 nearly identical components that differ
only by data type. There is a better way!"

The first trick is to think of UI like Lego bricks. Each piece should do
one thing. If you have a profile header, let it be in a separate view.
Small views are easier to read, test and more importantly, easier to
replace.

Therefore, should the design team decide headers are better in blue than
green, you have to edit one small file. You don't need to risk breaking
the whole screen for minor edits.

Get on Top of The Data

Data is where SwiftUI apps get to crash. In a small demo, using \@State
everywhere is okay. In a real app with 20 screens, it becomes
challenging. You are forced to pass variables down ten layers of views.

The key to your code surviving is finding one source of truth for your
data. Let one manager handle the data. It should get the data, display
it and send action back to keep your logic out and your code stable.

This makes it possible and more efficient to swap an entire UI for a new
design without touching the app's logic. It becomes possible to meet
deadlines even when requirements change at the last minute.

Avoid Different Views

What do you do when data exists in two places at once and they don't
match? Imagine a shopping app. The user adds an item to their cart. The
button says "Added," yet the cart icon at the top still displays "0".
What next?

This clash happens when you have two different views trying to manage
the same piece of information. In a professional app, you need to be
strict.

Views should not decide how to calculate discounts or if a user is
logged in. It should ask a ViewModel, "What do I show now?" Move logic
out of the SwiftUI view into a plain Swift class to verify your logic
without running the app to save hours.

A Swift Author & Consultant, Donny Wals, emphasizes this. In his
article
he says:

"When you notice you can express an impossible state in your
app due to a growth in variables that are intended to interact
together, use enums to represent the states your app can be in."

Do Not Hard Code Values

Truth is, designers keep changing their minds. It is part of their job.
Your job is to find a way to add their changes when requested without
destroying the code. Therefore, do not hard-code values until the design
team approves.

A good example is a designer who says the gap between elements is 16
pixels. Do not take their word for it and type in "16". If they later
change it to 20 pixels next week, you will be forced to find every 16 in
your project and adjust it.

Create a theme file. Define your spacing, colors and fonts in one place.
If the brand changes from purple to orange, you change only one line of
code in 30 seconds or less.

Why This Matters for Navigation

In a small demo, navigation is easy. In a real app, it is a mess. There
are deep links in notifications and "Success" screens that need to pop
back to the start. If you hard-code your navigation inside views, you
are trapped.

Sunny
Gulati,
a senior iOS Engineer, advises using a Coordinator. "The professional
solution is to use the Coordinator pattern with NavigationStack. It
separates concerns- views focus on UI while coordinators handle the
navigation state. The app remains scalable.

Professional SwiftUI code uses a central place to handle where the user
goes. The view says, "The user tapped on Settings," and a separate
router decided where that goes. Your app becomes flexible. Should the
Settings open a web view instead of a native screen, you only change one
line. You don't tamper with 15 different views.

Write for the Future

We say we write code for the team. Truth is, you are writing it for
yourself six months from now. You won't remember why you wrote that
weird statement, especially if you are working with a tight deadline.

How often do you handle the things you promised yourself to fix later?
Later never comes. Always write code that is readable.

I once wrote a complex, one-line function that looked like a math
equation thinking it was smart. Months later, a junior developer reached
out about it because they couldn't understand it.

Use long, descriptive names for your variables in place of short,
cryptic names. Yes, it is tiring and involves more typing, but it will
prevent bugs.

Do not Use Hacks

Let's be honest. At some point, we've used hacks to meet deadlines. The
problem is, hacks become debts that we need to pay back. Say you write a
hack to get a feature out on Friday and schedule time on Monday to fix
it. If you don't, it will build up until it gets to a point where you
cannot add new features.

A SwiftUI code that lasts should remain understandable when it gets
bigger. If your own code is hard to read with every month that passes,
it will eventually crumble.

As you test to catch bugs, gather the confidence to change your code. If
you want your code to survive growth, you need to be in a position to
refactor it. You cannot refactor safely if you are terrified that
changing a logic function will break something or everything else.

Avoid Third-Party Libraries

It is tempting to grab a library for everything. Need a chart, a custom
slider or a way to handle network requests? Download a library. There is
a library for almost everything and at the moment, it seems like a
lifesaver.

Every library you add is a dependency you don't control. Apps die
because they relied on a library that the original creator stopped
updating. Then, Apple released a new version of iOS, the library breaks
and your app is stuck in the past.

Take Away

SwiftUI is a great tool. It gives you the materials. This doesn't mean
it builds the app for you. Writing code that survives needs you to be
picky and think long-term.

Get on top of the data, write for the future, avoid hacks and say no to
libraries that seem too good or too convenient. If you do this, you will
meet your deadlines and build a code that lasts. In the process, you'll
start enjoying building.

Choosing an iOS Architecture That Scales

Mary Piakovski — Mon, 09 Feb 2026 17:39:39 +0000

Choosing an iOS Architecture That Scales

As someone who has been in the app development industry for more than a decade, I know how challenging it can be to choose the right architecture for your iOS app. The architecture you choose will influence your project's scalability, maintainability and the overall quality of your app.

Making the right choice can save you from technical debt, make testing & maintenance much easier, and, most importantly, ensure scalability.

I'll highlight what scaling means in iOS development, why the MVVM architecture is a better accelerator for small teams and how a clean architecture can bring the much-needed order to large, complex codebases.

What Does Scalability Mean in iOS Development?

Scaling in iOS development goes beyond code size. The key scaling pressures include team side, onboarding speed, feature velocity, ownership boundaries, testability and regression risk.

To ensure scalability, it is critical to identify areas of the app that could become bottlenecks, such as network limitations, CPU-intensive tasks, or database queries.

These bottlenecks can significantly degrade app performance as the number of users increases. Therefore, it is crucial to address them as early as possible, and everything starts with the development architecture you choose.

A scalable app can sustain gradual user growth, adapt to changing usage patterns and still maintain high performance. This is vital for user experience, satisfaction and overall success of the app.

An app that fails to scale effectively at critical times delivers a poor user experience, resulting in negative reviews and fewer app installs.

Overview of the MVVM Architecture

The Model-View-ViewModel (MVVM) architecture remains one of the most widely used design patterns in iOS development, and for good reason. This architecture provides a clear separation of concerns, improves testability and enhances code reusability.

Apps built with this architecture are generally easy to manage, feature-rich, and have a clean structure. MVVM consists of three main components, namely;

Model: The primary function of the model layer is to denote the data and business logic of the app. It summarizes the data and provides multiple methods to handle it.
View: The primary function of the view layer is to display the user interface effectively and record user interactions. It also presents data from the ViewModel and sends prompt notifications regarding user actions/behavior.
ViewModel: It serves as a mediator between the model and view layers. It contains the business logic and converts data from the model layer into a view-friendly format. In some instances, it unveils elements, methods and properties that the view layer can attach to.

The main features of this architecture are distribution, testability and ease of use. It offers more distribution than the Model-View-Control architecture; it is easy to test and use, since core responsibilities are divided, and overall code management is easier.

Why MVVM Offers Momentum for Small Teams

MVM works best for relatively small teams of 1-5 engineers. It is the best architecture for early-stage products, MVPs or fast-iterating apps thanks to its clear UI-driven features.

The separation of concerns feature is critical because it allows your team to focus on only one aspect of a problem at a time. This makes it easier to reason about complex systems.

MVVM allows you to separate the view from its data model. In simpler words, you can easily use one-way data binding to keep the two in sync. This structure makes it easier to test your code in production because it is modular and loosely-coupled.

However, the best thing about MVVM is that it helps you write reusable code, as you can easily break your app into smaller, easier-to-maintain chunks. You can also create reusable templates for these chunks and export them to other projects.

You can write your view models and presenters in such a way that they can be used in multiple applications without much modification.

The modular architecture makes on-boarding and collaboration easy, as multiple teams can work independently on different aspects of the same application in real-time. This parallel development approach improves collaboration and speeds up the overall development process.

However, this architecture struggles when ViewModels become large leading to domain logic leaking into the UI layers. There is also increased coupling as the app complexity grows.

Clean Architecture

The Clean Architecture strongly emphasizes maintainability, testability and scalability. Combining Clean Architecture principles and the MVVM pattern, you can build flexible and durable apps. This architecture encourages a distinct division of responsibilities by breaking down the program into discrete layers with explicit roles. It has the following layers:

Presentation layer: This layer manages user interface logic and human interaction. While this layer interacts with the domain layer to collect and show data, it is not concerned with implementation specifics.
Domain layer: All application's entities and business logic reside in the domain layer. This layer outlines all essential procedures and guidelines that control how data is handled and changed inside the system.
Data layer: The data layer serves as the foundation of the design and handles data access and critical storage functions. This layer ensures that any modifications to data sources don't affect the rest of the program by carefully separating data access from business logic.

The Clean Architecture makes sense when you are working with a team of 8-15+ engineers on regulated, mission-critical or long-term products.

Despite the strengths I mentioned, this architecture portrays obvious flaws you should be aware of. It is relatively slower in initial development, can overkill small teams and requires strong architectural discipline for success. A common failure mode is implementing clean architecture before the product has proven complexity.

Pragmatic Hybrids: The Most Common Real-World Outcome

The most successful teams I have worked with don't follow a single architecture. Instead, they end up with pragmatic hybrids that borrow just enough principles and rules from each architecture to stay maintainable without slowing development.

For example, you can pair MVVM with explicit use cases where ViewModels remain focused on presentation logic while business rules live in a small, testable domain layer. This approach makes ownership clearer and limits the blast radius of changes.

Martin Fowler, a software architect and author, says that hybrid architecture wins because it strikes a balance between speed and long-term sanity. This strategy allows development teams to move quickly early on, then add more structure to the project only when complexity demands it. As the app matures, additional boundaries can be introduced carefully and organically without disruptive rewrites. "The goal is to keep cognitive load lower for developers even as the development team grows," he adds.

Summary

Building a successful iOS app goes beyond writing clean code. The journey to a successful product begins with selecting the right architecture. Whether you are building a simple MVP or a highly complex, enterprise-grade solution, always remember that the architecture you choose will have a significant impact on code maintenance, collaboration and user satisfaction.

Obj-C to Swift Migration Lessons

Mary Piakovski — Fri, 06 Feb 2026 13:33:12 +0000

Even though Swift is the primary coding language across the Apple ecosystem now, there is still an awful lot of iOS apps coded in Objective-C out there. Typically, the larger and older the app, the more likely that there is still a bunch of Objective-C language powering various bits of the app behind the scenes.

Don’t get me wrong, Objective-C is a wonderful programming language that worked quite well for many years, but its flaws have been exposed with the rapidly evolving technology. Some of the obvious flaws include a lack of flexibility and syntax restrictions, to name a few.

Thus, there has been a massive push from Apple to migrate all iOS apps to Swift. Unfortunately, the migration from Objective-C to Swift isn’t a straightforward affair because the latter can’t simply sit on top of an Objective-C core without friction. In reality, migrating from Obj-C to Swift requires proper planning and a deep understanding of both languages.

This article outlines the key steps involved in migrating from Objective-C to Swift with a special focus on what to prioritize first, what might go wrong and what is rarely worth rewriting.

What Usually Goes Wrong in These Migrations?

The most common challenges in Objective-C to Swift migration often stem from interoperability and a massive underestimation of the effort required to engineer a successful transition.

From a technical perspective, the biggest challenge is dealing with bridging header and interoperability issues. The bridging header allows the two languages to communicate efficiently, but it can also become a source of errors and bugs, especially with relatively complex dependencies. Issues usually arise when Swift features, such as structs aren’t fully compatible with Obj-C requiring manual workarounds that we often refer to as shims.

From a team readiness and skills gap perspective, many people think that Swift is simply Objective-C with a different syntax which is not the case. Swift has a wide range of features and functionalities, such as immutability, value types, protocol-oriented design and strict type safety, that can be unfamiliar to teams that don’t deeply understand the language.

Steve Barnegren, an iOS developer based in London says that when migration begins without clear team readiness, you risk ending up with Swift code that mimics Objective-C habits. This leads to inconsistent style, overreliance on reference types, misuse of optionals and avoidance of Swift’s strongest features.

What to Prioritize First

A successful migration focuses on unlocking the most leverage. If you prioritize correctly, then you will see immediate gains in developer velocity and code safety without destabilizing production systems. Here is what consistently deserves attention first:

Clean up and modernize Objective-C before migration: It is essential to update your legacy Objective-C files, classes and modules to modern standards before you start migration. This is important because it simplifies the transition and reduces translation friction.
Focus on interoperability and bridging: I highly recommend using Xcode’s bridging headers intentionally. One thing I have realized from my experience is that explicit exposure of Objective-C APIs to Swift plays a critical role in ensuring proper linkage and reducing runtime bugs. So, this is something I’ll definitely prioritize at first.
Prioritize high-value, independent modules: The migration process doesn’t need to be overly complicated. Consider starting with smaller, self-contained components or utility classes. I like this approach because it reduces dependency on complexity and helps verify correct integration before tackling more interlinked areas.
Prioritize migration rules, not goals: Sometimes, the most critical priority during migration is the process, not the code. Teams that succeed define migration rules early. What language owns which layers? When is code rewriting allowed and when is it forbidden? What signals justify migrating a legacy component? It is essential to have these guardrails in place to avoid drifting into inconsistency.

What Is Rarely Worth Rewriting

Two things are not worth rewriting when migrating from Objective-C to Swift: well-functioning UI and business logic, and third-party libraries that still work fine. If the UI and business logic are functioning well and well tested, you can leave them in Objective-C and simply interoperate.

Similarly, many Objective-C frameworks still function perfectly even after migrating to Swift. Rewriting them for the sake of eliminating Objective-C often wastes time and may even introduce new bugs to your code.

Some Tips for a Successful Migration

Identify which modules of the system/app are most actively maintained and begin the migration with smaller, less complex components. The primary goal here is to reduce initial integration risks.

Apply Apple’s Incremental Adoption approach using bridging headers to ensure that new features can be coded immediately using Swift while the legacy Objective-C continues functioning as expected until it is fully rewritten.

Only use automated migration tools for syntax refactoring. Anything involving complex pointer memory management, macros and categories should be rewritten and migrated manually. Test coverage must hit at least 80% before you start the migration. Use code coverage reports to identify critical gaps before things get out of hand.

It is also important to schedule code reviews with mixed-experience teams because it helps mitigate subtle behavioral changes around optionals, safety and error handling patterns. Always expect API shifts and maintain an updated mapping between APIs at all times. The official Apple migration guide comes in handy at this stage.

Most importantly, set measurable milestones. Don’t embark on migration without a clear plan on what you want to achieve at every stage. Set clear timelines to achieve the milestones and keep communication lines with stakeholders open.

Summary

Migrating a codebase from Objective-C to Swift is typically a more complex challenge than it appears on the surface. Your team needs to be fully prepared and dedicated to achieving success. It is essential to evaluate different approaches at the start and create a comprehensive transition plan that combines the two languages in the most sustainable way.

The best part is that if you adhere to best practices, the final app you create will no longer carry Objective-C baggage. It will be a safe, high-performance, uncompromised Swift code designed with a Swift mindset to serve your needs.