Launch time is the most impactful metric you never optimise.

Say you’re WhatsApp.

You have a kajillion daily active users, except in America for some reason.

They may be warm-launching your app 10x a day. More.

A launch speed of 0.5 seconds, times 10, times a kajillion, means even a 1% improvement probably saves a few lifetimes’ worth. I haven’t checked my maths, and I’m not going to.

Apple, helpfully, checked theirs. At WWDC19’s Optimizing App Launch session, they computed across billions of daily launches: shaving just 1ms off launch saves just about enough time each day to send a rocket to Mars.

Apple had a “Snow Leopard” year this WWDC. Less flashy features, less UI overhauls nobody asked for, more cold platform optimisations. They claimed to have added a 30% boost to app launch times in iOS 27.

I’ve chatted to you before about optimising launch time on a legacy app, and tracing launch performance in production. What I haven’t done is go all the way down. So today that’s what we’ll do:

1. We’ll get to grips with the important stuff for devs to know about launch time.

2. We’ll trace iOS 26 and 27 improvements using Instruments.

3. We’ll clarify what Apple has actually done to improve things.

Subscribe now

This article is so packed with knowledge, your email client will cut it off. Click here to read on my website.

Read on my website

Launch Theory

Flavours of Launch

There are three kinds of launch:

🐢 A cold launch is what you think of as a “launch”. The app process doesn’t exist, your binary is sitting in storage. WWDC2016 explains that cold launches mostly only happen the first launch after install or restart. This is your first impression, though, so you probably want to worry about this.

🐇 A warm launch spawns a fresh process, but iOS caches binary memory pages aggressively in the kernel file cache, and dyld still holds onto a precomputed launch plan. tl;dr: the data is closer to where it needs to be.

🐅 There is no “hot launch”. It’s just a resume, foregrounding a backgrounded or suspended app that is already alive in process memory.

Launch Phases

There are 2 phases of launch to understand, based on when the main() function is called in your app process.

Knowing about pre-main launch steps is a great way to get ahead when your job interviewer is a jerk. First the kernel maps your Mach-O executable into process memory. Dyld, the dynamic linker, loads up the dynamic frameworks needed by your app, including your own code, third-party dependencies, and system frameworks like Foundation, UIKit, and Swift.

Address Space Layout Randomisation (ASLR) is a critical protection against memory corruption exploits, randomising the memory address of many of these frameworks in process memory at launch. Therefore dyld applies “fixups” to write symbol references to real memory addresses.

The Swift runtime sets up type metadata, protocol conformances, and generics. Finally, some of your own code might run: static initialisers and Objective-C load() methods.

This is a ton of work, but we will shortly see it visible in our instruments traces.

Nobody’s giving you a job for knowing about post-main. If you’re into CLIs, or hardcore (like me), you might have your own explicit main() method.

// main.swift

import UIKit

UIApplicationMain(
    CommandLine.argc,
    CommandLine.unsafeArgv,
    nil,
    NSStringFromClass(AppDelegate.self)
)

UIApplicationMain creates the app object, sets up the run loop, the app delegate, and ultimately calls application(_:willFinishLaunchingWithOptions:). You know the rest, and if you don’t, my blog has a lot of solid iOS content.

Launch ends when your first frame renders. Optimising this side is standard engineering: profile, parallelise, and minimise the amount of work on the critical path before the user gets what they’re looking for.

Reading the Launch Trace

The App Launch instrument gives a cool visual overview of the theory above.

• Launch Executable covers the full pre-main process.

• Validating Closure at the start is the tell for a warm launch, loading the launch plan computed by dyld. In cold launches, it’s Building Closure, lives at the end, and takes much longer.

• Map Image takes the actual file paths of your dynamic frameworks and mmaps them into your app process. This is where an overabundance of dynamic frameworks can slow down your launch.

• Apply Fixups wires these symbol references to actual memory addresses.

• ObjC Image Init makes classes visible to the Objective-C runtime.

• Run Static Initializer… runs your static initialisers.

• dlopen handles library loads at runtime. You can call this yourself!

Post-main, we can also see UIKit initialisation, didFinishLaunchingWithOptions, UIScene creation, then the declaration of victory: Foreground — Active*.

*god I miss being allowed to use the em-dash

Xcode 27 adds a cool flamegraph.

On the Time Profile, hit the little blue button in the top-right, filter by your process, filter to the main thread, and you’ll see something like this:

The % gives each segment’s share of CPU time in the given time window. To make things more useful for us, we can hide system libraries and see how our own code breaks down at launch*.

*The flamegraph is also useful for non-launch performance work.

Subscribe now

I’m not throwing away my shot 🎯

I’m not Apple. I don’t have a bargain bin full of iPhone 11 Pro Maxes to profile with. I get one shot per year to run a proper before-and-after to profile OS upgrades.

Since I don’t want the results to be too good, I whipped out my trusty iPhone 13 mini (from my cable drawer, which is inexplicably strewn across my desk).

Fortunately, I realised this before the automatic beta update landed. Just.

I vibe-coded a deliberately annoying Frankenstein’s monster of dynamic frameworks, static initialisers, and protocol conformances by pulling together a bunch of demo apps from previous articles. I figured I’d get more interesting results by attempting to give indigestion to dyld.

OK. This is the bit you’ve been waiting for.

Let’s take a look at how iOS 27 changes things.

The full article ships to everyone in a month. But, hey, my marginal cost is $0. Have a fortnight of membership, for free 💰.

Get 14 day free trial

Paid members read now, plus:

⚓️ Access my full library of 50 paywalled articles
🚀 Read free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training
🧑‍🚀 Get a free copy of my new eBook, “Land your iOS Tech Job”
❤️‍🩹 Support independent, sometimes funny, tech writing

Read more

But this year is actually different, because I’ve found a way to turn the WWDC grind into a side project. If you can’t be arsed to read my waffle, just click below.

View the WWDC Roundup

If you can be arsed to read my waffle, what do we mean by a Snow Leopard year? In the OS X days, Apple would proudly declare the 100s of new features they were introducing to their shiny, increasingly cumbersome desktop OS.

At WWDC 2009, they hit developers with this slide:

Snow Leopard was all about stability, bug fixes, and tools for developers. It was a banger year, introducing heavy-hitters like Grand Central Dispatch, OpenCL, and (f*cking) Objective-C blocks!

Apple has done it again. They mostly kept away from flashy UI overhauls, opting to shore things up under the hood and place the burden of innovation onto devs via lots of AI tools. They appear to have finally got their house in order since the bungled announcement of Apple Intelligence in 2024.

Anyway, long story short, there’s a ridiculous abundance of material. If I’m honest, due to a severe case of AI brainrot, I have lost the ability to make my own decisions, so I will give you the chance to influence me. Please vote on some articles you’d like to read in my subscriber chat:

• What parts of the kernel is Apple writing in Swift?

• How did Apple improve launch times by 30%?

• When to use Core AI, Evals, fm CLI, Foundation Models, or Private Cloud Compute?!

• App Intents will be the major user interface in 2027.

• How to use Core Spotlight to prepare your app for agentic Siri.

• Get users to pay your inference bill with Private Cloud Compute

• LazyStacks, Lists, and SwiftUI internals

• Programmatic Photography (or; 48MP is not why your pics look nice)

• Fine. I will learn what Evals are. Goddammit.

• Optimising performance in iOS 27

Cast your vote here

Anyway, back to my little side project. Introducing... tl;dw (too long; didn’t watch).

People really like using the Granola mobile app at conferences. So I wanted to know what all the fuss was about.* I grabbed every WWDC 2026 session video and used Granola to create summary notes for each.

*Granola didn’t pay me to write this, but they do pay me in general

I’ve used it to scan key points, to help me decide which videos to watch in full, and to ask for more detail when needed. I hope you find it useful too!

View the WWDC Roundup

If you somehow managed to find yourself on this blog post about already subscribing to me, you can do so here:

Subscribe now

This is a dual-purpose post.

On the face of it, I’m covering the various chip architectures employed by Apple over the last 50 years, colouring in the technical considerations and the business context.

But, much like I mix my cats’ worm treatment into their food, I am sneakily grinding healthy chunks of learning into the prose: each chapter serves as a framing device for fundamental CPU concepts, growing in complexity. If Android is more your cup of tea, just jump between chapters at will like an overclocked instruction pointer.

Sponsored Link

AI paywall editor: build your paywall by just prompting

Ship better paywalls faster. Just describe the paywall you want, and RevenueCat’s AI agent handles the copy, layout, styling, localization, and optimization recommendations. Read more here.

Contents

Click any of these to skip the intros and start learning.

1977: 6502 Microprocessor and the Apple I & ][

• The CPU™

• Registers

• The Arithmetic-Logic Unit

1984: Motorola 68k and the Macintosh

• 8-bit vs. 16-bit

• Endianness

• Assembly Language

1994: PowerPC

• CISC vs. RISC

• Pipelining

• Clock Speed

• Emulation

2006: Intel x86 and the MacBook

• CPU Caches

• Branch Prediction

• Superscalar Architecture

• Hyper-threading

2020: Apple Silicon and disruptively good laptops

• Heterogeneous Computing

• Unified Memory Architecture

• Out-of-order Execution

• Physics: The Ultimate Constraint

Apple’s core counter-positioning has been firm from their founding all the way to becoming a $4T megacorp: tight integration of hardware and software. This gives them pricing power that OS players (Microsoft, Google) or hardware manufacturers (HP, Dell, Samsung) only dream of.

Maintaining this integration gives them a durable competitive advantage. It allows them to make products that “just work”, and also gives them full control over the ecosystem (ask Meta if that matters).

This control is what allows them to casually migrate their entire chip architecture. They’ve done it three times! There’s often skepticism regarding CPU architecture migrations. Devs get tetchy about you deprecating all their software at once.

With 2005’s move to Intel x86, some commentators even guessed it was a precursor to bringing Apple onto Windows. The horror. But, ultimately, Apple has their reasons: short-term pain for strategic gain. Each new CPU architecture helped Apple compete and differentiate.

Today’s odyssey goes through the 5 key eras of Apple CPU architecture. 1977 up to 2026. I’ll colour in the business context surrounding each migration and bring you forward through the results of each shift.

Along the way, we’ll learn the basics of CPU technology; learning increasingly complex chip design techniques along the relentless learning curve of technological advancement.

This post is full of knowledge, so much so that your email client might cut it off. Read on my website for the best experience.

Read on my website

1977

Chip Family: 6502 microprocessor
Tech it unlocked: The Apple I and Apple ][

1 smelly hippy. 1 big bushy beard. It can only be the 2 Steves.

The Apple I in 1976 launched the company. If you can dust off one of the 200 units ever produced, you’re in luck as it’s the most valuable personal computer in the world (think Ferrari money).

The Apple ][ (pronounced “Apple Two”) was their first smash hit, so good they milked it for 16 years. It truly helped revolutionise the personal computing, uh, revolution.

In the mid-70s, hobbyists orbited a few popular microprocessors like the Intel 8080 and the Motorola 6800. The instruction set architectures of these chip families were the closest thing the nascent world of hobby computing had to an ecosystem.

A few Motorola engineers defected to MOS Technology to build the 6502, which was similar enough to 6800 for Woz to be familiar with it (maybe too similar: MOS flew too close to the sun with the 6501 and got sued for IP theft).

The Intel 8080 and the Motorola 6800 both cost more than $150, which is approximately a fucktillion in 2026 dollars. Therefore the choice of 6502 was not so much strategic and more because it cost $25, and Woz’s stock options had not yet appreciated that much.

He was able to cheaply acquire a bunch of 6502s, cobble together some computers, and write a BASIC interpreter.

Woz aptly performed the 3 core activities of early computer manufacturers: choosing an off-the-shelf processor, designing hardware around it, and providing a friendly programming environment. These form the foundation of the integration between hardware and software maintained by Apple today.

The Apple I was a neat machine that counter-positioned against the do-it-yourself “kits” popular in the day: a pre-built, quality-tested, plug-and-play board introducing the “it just works” philosophy.

The Apple ][ took this baseline and created a killer consumer product with colour graphics, sound, a plastic case, expansion slots, and BASIC in its read-only memory.

Both used the 6502.

The 6502 was an 8-bit CPU running at 1.023 MHz, with a 64KB memory address space: just a hair more powerful than today’s RyanAir mobile app.

OK: numbers, acronyms, words, blah blah blah. Let’s get on the same page.

The CPU™

A CPU, or central processing unit, is a device that moves data from computer memory (RAM) into fast temporary memory (registers), runs operations on this data, and then moves the output back into memory.

A control unit takes a feed of instructions, decoding them one-at-a-time, to decide what data moves to which register, and which register’s data should be piped through which logic circuits.

Fundamentally, all software behaves by arranging inputs into the CPU and handling the outputs. Databases. Operating systems. Intelligent refrigerators.

Registers

A register is a tiny speck of storage hardware. When I say “electronic memory,” I mean a circuit which, while powered, is able to hold onto its current value: on or off, 1 or 0. The smaller you can get this circuit, the more data you can store.

This is also, more or less, how RAM works (except there’s a lot more of it).

Registers hold a tiny number of bits very close to the CPU processing circuits. They are small, and close, making them really fast, operating at the MHz (or later, GHz) levels of the fully-clocked CPU.

The ALU

The last key piece of circuitry to understand is the Arithmetic-Logic Unit (ALU), the aforementioned “logic circuits” that actually perform these operations. The ALU is fundamentally a collection of circuits that perform simple, specialised jobs, such as:

• Adding up binary numbers, e.g. 0010 + 0101 = 0111

• Perform logical operations, e.g. NOT 0000 = 1111

• Shift bits around, e.g. left-shifting 0011 by 1 place becomes 0110

The CPU executes instructions to perform operations on the data in registers, manipulating 1s and 0s which, by the magic of boolean algebra, emerge into useful outputs such as matrix multiplication, collision physics in a video game, or rasterising image data into on-screen pixels.

If this section has afflicted you with FOMO, someone built an Apple ][ emulator in JavaScript.

1984

Chip family: Motorola 68k
Tech unlocked: The Macintosh.

1981.

Reagan. MTV. Indiana Jones.

The Apple ][ is a cashflow geyser, but there are barbarians at the gates.

IBM has finally penetrated the PC mass market, precipitating an unprecedented influx of purchase orders for PCs. A young, brash, 24-year-old whizkid named Bill Gates was asked to supply their operating system.

In 10 years, let’s check in on our friends at IBM to see how this move went.

Apple needed a new platform upon which to build their future. Apple’s Lisa is shaping up to be their flagship product. After being a huge jerk to everybody for 5 years, Steve Jobs has been relegated to run the low-end Macintosh project.

Choosing a CPU

Originally planned as a lower-price-tier computer, the Macintosh under Jobs pivoted to focus on one thing: upstaging the Lisa team. Steve got some “inspiration” from his friends at Xerox PARC to bring a cutting-edge GUI to the Macintosh, and demanded advanced hardware to support it.

Subscribe now

Read more

This is the story of how I migrated the entire Granola iOS app architecture from SwiftUI to UIKit in a week. That’s the elevator pitch.

I work for an AI unicorn in London. Our iOS app was released about a year ago, and we’re barely scratching the surface of all the cool stuff we can build. But we had a problem.

Contents

• Days of Future, Past

  • UIKit who?

• Convincing Your Product Team

  • Meeting Bar

  • AI Chat

• The Old World

• Architecting the New World

  • Routes, Routers, and Screen Factories

  • The point of use

• The Timeline

• Rebuilding AI Chat

  • iOS 17 and below

• The Performance Difference

• Annoying Stuff

  • Knowledge Debt

• Last Orders

This post is full of knowledge, so much so that your email client might cut it off. Read on my website for the best experience.

Read on my website

Days of Future, Past

SwiftUI was the future, until it wasn’t.

I won’t bore you with the details, but long story short: you can do less stuff in SwiftUI:

• UI is less customisable.

• There are no delegates to perform heavy lifting and fine-tuning.

• UIPresentationController isn’t there, so good luck crafting satisfying transitions.

• Namespacing is a bloody mess.

• You’re encouraged to tightly couple your navigation code to your view code, which, to use Generation Z parlance, gives me the ick.

• It’s never going to reach full parity with UIKit.

Got it?

Oh and the performance is also worse. Dramatically so. Profile any scroll-based screen between SwiftUI and UIKit, and you’ll probably notice a few hitches and hangs in short order. If you don’t believe me, please take a look right here (we have gifs).

But this is on your shiny new iPhone 17 Pro Max. Give it a crack on low power mode, or your nan’s old XR, and tell me if you think SwiftUI is the future. Any major screen subject to complexity creep becomes harder and harder to keep smooth, taking on UI performance regressions at the drop of a hat.

Okay, I’ve bored you with the details. Sorry. I’ve pontificated a lot already, but if you’ll indulge me for one more complaint: SwiftUI is buggy as hell.

One of my first features for Granola was image attachments on notes, a button that opened a Gmail-style SwiftUI Menu component. You then selected Photos or Camera to open a PhotosPicker or (f*ck sake) a wrapped UIImagePickerController that opened the relevant camera or photo album modal.

Oh, but 50% of the time, the Menu’s dismiss animation collided with the modal presentation, and nothing is presented at all. The solution? Add Task.sleep between tap and presentation. For a native UI framework!

We just split it into two separate buttons in the end.

</rant>

UIKit who?

On the other side of the fence, the forgotten stepchild jealously observed the love, gifts, and double servings of organic ice cream given to SwiftUI via the, uh, @Observable macro. But UIKit’s new mommy (Tim Cook) finally remembered his existence, and backported Observation to work on UIKit in iOS 18+.

Now, @Observable SwiftUI view models port directly to UIKit with no changes needed.

Finally, agentic tooling has evolved in a big way. It’s not just writing your code anymore. It’s planning a multi-step migration, implementing it Pretty Well™, and, most importantly, verifying its own work.

Today I’ll show you how.

What used to be a years-long migration project can be done in under a week*

*YMMV if, for instance, your team just finished migrating Uber or Facebook to SwiftUI.

Convincing Your Product Team

As with all sweeping codebase refactors with hard-to-quantify user benefit, the hard part isn’t actually doing the work. It’s convincing stakeholders to give you air cover to do the work.

Like all opportunistic enterprising developers, I waited for my moment.

It came when two projects coincided on the horizon.

Meeting Bar

First, the “meeting bar”.

The main flow of the Granola app is recording meeting notes, using a modal drawer that contains controls for recording, notes, and attachments. Our designer proposed making this collapsible, allowing you to navigate through the rest of the app during recording.

We didn’t have the stomach to consider building this with a SwiftUI view modifier.

It would mean shoving a .safeAreaInset view into the bottom of every screen, or perhaps having it live on the top level above everything. Our chat screen would become a UIKit keyboard view, embedded in SwiftUI, re-embedded in UIKit… with a bar floating on top. No thanks.

But with UIKit? Trivial. There’s already a system component that powers this for us. The tab bar. We simply show and hide the bar, replace its view with our custom bar, and the system automatically holds it there throughout the app!

With UIKit, we also get UIPresentationController. This allows us full control over the transition animation between collapsing the drawer and presenting the meeting bar. Total control over both animation curves. This allowed us to tweak the animation curve based on the velocity of your swipe, which landed on an unbelievably satisfying experience.

AI Chat

The second project was our AI chat screen, which allows users to chat with an AI using all their meeting notes as context.

The SwiftUI screen had the classic scrolling feed issues, getting hitches and animation stutters while scrolling fast on weak devices, and had weird stutters as we streamed in text responses from the AI. SwiftUI also did not play well with the system keyboard. The screen needed some love.

And what better way to show love than to rebirth it anew, stronger and more lightweight? This screen was our proof of concept, the test ground for a potential future autonomous agent-driven rebuild.

These two projects were the perfect opportunity to perform a UIKit migration, since it served as a prerequisite task for these projects. Replacing the SwiftUI-based navigation architecture with a UIKit skeleton would make both of these features possible.

The Old World

The existing navigation was… fine. Not great, not terrible.

We target iOS 18, so used SwiftUI’s iOS 16+ NavigationStack APIs. My main qualm with this has always been tightly coupling navigation logic to your view code. We are re-inventing the “massive view controller” problem by coupling all the logic to your UI!

NavigationStack works.

But it means any UIKit you add comes wrapped in a SwiftUI host, which is iffy for performance. Anything particularly complicated like a scroll delegate or navigation transition animation, and we’re pushing back on our designer.

SwiftUI works fantastically if your designers are easy breezy and happy to have you say “no” to their most interesting ideas.

Architecting the New World

A navigation refactor is impossible to do as a big bang. You can’t really rewrite your entire app at once, and you probably won’t want to YOLO an agent to give it a try over the weekend. That’s not going to fly.

As it happens, I’m a big fan of the incremental approach.

I pitched the refactor as: keep SwiftUI views, but introduce a UIKit skeleton for navigation plumbing. We get the best of both worlds: imperative UIKit-style navigation fully decoupled from view logic, with the simplicity and iteration speed of SwiftUI for building screens (and we avoid throwing everything in the bin).

I’ve built SwiftUI navigation at five different startups since 2019. With that experience comes a pretty well-developed palate for navigation APIs.

• The classic coordinator approach where each module has flows? Nice and simple, but not flexible at all. It’s quite hard to reach screens from other parts of the app without reaching for dodgy AnyView wrappers.

• I’ve played with a cool experimental architecture centred on deep links. Every bit of navigation is powered by a deep link. It’s insanely flexible, letting any screen jump to any other screen, but the plumbing is extremely complex.

My best advice on the topic is thus:

That simplicity will save you long-term. I’ve learned the hard way. I settled on a Goldilocks approach:

Subscribe now

Read more

Reliably uploading data is sort of like brushing your teeth: it’s a dull chore, but you kind of have to do it, or you’re going to get an infected dental nerve. What was I talking about again? Right. Dental uploads. Data uploads.

Losing user data through developer negligence around upload hygiene is maybe #2 of the 3 most common Very Bad Things You Can Do™ as a client-side developer. The worst is mucking up auth and logging out all your users. That’ll kill you. Crashes are a common #3. But losing data erodes user trust. Uploading properly is really important to understand.

I hacked together a simple open-source companion project that demonstrates all the techniques here. FakeTwitter. 4 tabs, identical UI, but each employing increasingly elaborate upload reliability as we climb the ladder from simplicity, to resilience, to continuity, to durability.

The techniques can be mixed and matched based on your requirements. Usually you’ll have a mix, depending on what data needs to be reliable vs. what’s simple to ship and maintain, because each level introduces growing complexity.

I’m sharing practical advice you’ll be able to apply in your day-to-day when working with APIs. I also used the theory directly in my interview grind, specifically in system design loops.

The important takeaway I want to give you is to be thoughtful about your networking: consider what level of reliability you actually need for your feature.

Once I’m done with you, users will be clawing at your office door, begging you to upload their data.

Sponsored Link

Meet Rico by RevenueCat

Rico is your AI-powered app growth advisor. Ask questions about churn, pricing, experiments, or revenue trends and get actionable answers using your subscription data, benchmarks, and store configuration insights.

Contents

• Level 1: Fire-and-Forget

• Level 2: Retry Discipline

  • User-Surfaced Retry

  • Automated Retry

  • Idempotency Keys

• Level 3: Upload Continuity

  • Resumable Uploads

  • Background Modes

• Level 4: Durable Uploads

• Last Orders

Level 1: Fire-and-Forget

This is the simplest approach. By far. It’s also the default you’ll begin with for any upload request.

Just try POSTing your data using the bog-standard URLSession API.

You’ll ship fast, you’ll learn a lot, you’ll mostly get the data where it needs to go, but not always, and that’s fine.

Level 1 isn’t just being dumb.

Most network requests in most apps, even those shipped by big tech, begin at Level 1. You default to this when loss of data is an acceptable outcome.

You should absolutely wrap this f&*ker in a try/catch, log an error when the request fails, and surface some kind of feedback to the user. We’re Level 1 networkers, we aren’t animals.

Other than basic hygiene, there’s not too much to say.

Just remember that if the network drops, or the server has a temporary issue, your user’s data is just- poof. Gone. Kaput, like my Brewdog shares.

Level 2: Retry Discipline

This is where we start to limber up our system design chops.

You’ve likely encountered most of these, but it’s helpful to have the full toolkit laid out formally. We can introduce retry behaviour without seriously affecting our product surface, and without introducing any serious engineering challenges (yet).

User-Surfaced Retry

In Level 1, we considered surfacing errors to the user, like an alert. To advance to Level 2, just slap a retry button on this bad boy. This is actually employed by the “true” Twitter app (perhaps you could argue that X is fake Twitter) when your tweet fails to post.

Automated Retry

We don’t immediately need to run crying to the user for help.

Automated retries offer a number of strategies. The most basic is a recursive retry with an incrementing counter to attempt a max number of times.

Exponential backoff is the most famous flavour of automatic retry, where you double the wait between each attempt, the exponent in this case being t = 2ⁿ, where t is the wait before retrying and n is the number of retries. For the less mathematically-inclined reader, this is doubling every time.

If the request keeps failing, we try again after 1 second, 2 seconds, 4 seconds, then 8 seconds, and ultimately fail after 5 attempts.

Some errors are a you problem. Perhaps you listened to the Queen of Canada and stopped paying your cellphone bill. Some errors are a me problem. Oh no, the server is on fire, and can’t stop sending 500 responses.

We can introduce a circuit breaker in the latter case, blocking requests entirely. This avoids hammering our ailing server and gives it a short cooldown window to stop melting.

When your server flails, it can return errors for everyone at once. This can lead to all your users retrying simultaneously, crashing into your server once it’s back up and killing you again. This is called the thundering herd problem. We can guard against this by adding jitter to retries. This is a bit of randomised jiggle added between each backoff to space out retries.

This AWS blog post goes deep into jitter strategies (so I don’t have to).

If your backend guys are really trying to earn their staff promo, they might supply a Retry-After HTTP response header telling the client exactly when they can retry:

Idempotency Keys

“Idempotency key” sounds very complicated, primarily because idempotency is a long and scary word. I actually left my ex wife because she said I was idempotent.

Consider making a bank transaction. It succeeds on the server, but I miss the 201 success response because the connection drops at the worst possible time. Network error? Automatic retry. I do not want to be sending double alimony, but fortunately idempotency comes to our rescue.

Unlock Levels 2-4 now

Read more

Copy it on a sticky note and leave it under your monitor for your next interview.

Sponsored Link

Meet Rico by RevenueCat

Rico is your AI-powered app growth advisor. Ask questions about churn, pricing, experiments, or revenue trends and get actionable answers using your subscription data, benchmarks, and store configuration insights.

I usually love the iOS Knowledge Interview™ format: 45 mins to flex my encyclopaedic knowledge of the Swift compiler, method dispatch, memory management or Mach-O binaries.

Until recently. I was asked to “explain the rendering pipeline on iOS”.

It’s easy to let this slip. The system abstracts away the heavy lifting.

But this heavy lifting controls every single pixel on every single frame of every app you build. It’s worth taking the time to understand it properly.

The UI pipeline is a complex beast, orchestrating across several lightly-documented systems. It’s tough to find a throughline that can explain it all. Fortunately, you’re in good hands.

We’re tracking the journey of a touch event: from sensors, to your code, and back up to pixels, through every system along the way:

• Your finger taps the capacitive touch sensor.

• The kernel creates a touch event via hardware drivers.

• backboardd handles the event and forwards it to your app process.

• Your app’s run loop passes a UIEvent to the relevant view.

• Your code performs a CATransaction to update its layer tree.

• The UIWindow’s CAContext bridges to the render server via IPC.

• The render server rasterises and composites layers across each process.

• It then issues drawing commands to the GPU for compositing and animation.

• A frame buffer of pixels is generated and sent to the display hardware.

Subscribe now

Handling Physical Touch

The Hardware

In the late 90s, Uncle Sam funded some research that led to breakthroughs in multi-touch capacitive touch screens. In 2007, Daddy Steve stuck this in front of a jumble of miniaturised tech that was finally ready for prime-time: modern microprocessors, a cellular radio, and high-capacity lithium batteries. The rest is history.

Under the glass of your iPhone screen, there is a grid of transparent criss-crossing X and Y wires. A microcontroller applies an electric field across each X wire, and measures signals across each Y wire.

Because human flesh is electrically conductive (don’t ask me how I found this out), the presence of a finger changes the electrical capacitance measured at XY intersections. The microcontroller scans across each wire to create a real-time 2D touch map.

The Kernel

The kernel is the core of an operating system. It creates and manages abstractions on top of hardware:

• CPU becomes threads.

• RAM becomes heap memory.

• Flash storage becomes a file system.

The kernel’s other main responsibility is I/O: that is, talking to the hardware. This interfacing is done via drivers, specialised software that translates input commands and output signals.

The xnu kernel on iOS interfaces with the capacitive touch hardware via IOKit.

The hardware sends signals that the OS decodes into an IOHIDEvent (IOKit human-interface device event) to represent touch events such as rotations, scrolls, or swipes. This event is sent to backboardd.

backboardd

backboardd is a daemon, which you can tell from the dangling D in its name.

Daemons are background processes run by the OS. Just like their biblical namesake, they never sleep, and they’re always watching you.

In the case of backboardd, it manages system tasks like screen dimming, reads input from hardware sensors like the accelerometer, and handles physical touch events.

This section is slightly hand-wavey because it’s not documented. Apple doesn’t feel the need to, because all this complexity is abstracted away from developers.

My only data sources are old Wikis, unofficial write-ups and reverse engineering dumps. Please bear with me a moment ‘til we land in the run loop.

BackBoardServices is a subsystem inside this daemon that performs bridging between device I/O and userland processes, including your app.

It generates a GraphicsServices event (GSEvent) for the touch and sends it to the relevant app process using inter-process communication (IPC), a secure communication channel provided by the OS.

To determine the relevant app process, backboardd talks to FrontBoard (a part of SpringBoard). FrontBoard is what powers the app switcher, managing the on-screen visible “scenes” for stuff like the home screen and each individual app.

This scene, or FBScene, is associated with your app’s CAContext, or Core Animation context, underpinning all of your UI. BackBoardServices can read out the CAContext’s contextID to determine the correct app process for the touch event, and forward it on.

Subscribe now

Core Animation inside your app

The Run Loop

An iOS application process always begins the same way:

1. The user taps an icon on SpringBoard, the userland home screen app.

2. The launch daemon launchd performs syscalls to load the app into memory.

3. iOS calls the main() function in your loaded executable.

4. In turn this calls the built-in UIApplicationMain() method.

5. This inits a UIApplication, sets AppDelegate, and starts the main run loop.

6. Your app begins processing events.

7. (repeat step #6 until bored).

This run loop behaves like a permanent while loop, offering 2 basic states: waiting for stuff to happen; and doing stuff.

while let await touchInputs() {
    handleTouchEvents()
}

The main run loop of your app is awoken by timers firing, code dispatched to the main queue, and signals from backboardd like our touch event.

UIEvents

The run loop passes touch events to the UIApplication object, which converts them into UIEvents and dispatches them via sendEvent(_:) to the relevant UIWindow for the active scene. The window, in turn, dispatches the event to a UIView, determining the target via hit testing.

The same process more or less happens with SwiftUI views, but I’ll stick to UIKit for now because it’s better documented and has less ~magic~. If you want a very hand-wavey explanation, the SwiftUI attribute graph maps approximately to the CALayer tree somehow.

The UIWindow forwards the UIEvent to the target view, firing the touchesBegan(_:with:) method, or other appropriate UIResponder method.

Now that we’re no longer mucking about inside subterranean system internals, we might as well demonstrate with a nice visual example to make the most of the light of day.

Let’s create a custom skeuomorphic 3D button by subclassing UIView, complete with the aforementioned UIResponder methods:

When a user touches down, it presses in. Just like a real button should. No liquid glass nonsense here.

The full pipeline just ran before your eyes.

Back up.

To understand what happens after your tap event is registered, we should clarify that UIViews in UIKit are ultimately backed by Core Animation CALayers.

CoreAnimation, Transactions, and Commits

Core Animation is the fundamental visual core of iOS. The primary API uses layers, lightweight objects with properties like frame, border, filters, shadow, and opacity.

Regardless of whether you’re using UIKit or SwiftUI, the rendering in your app is done using Core Animation: visual content is arranged in CALayers, in a hierarchical “layer tree” owned by the UIWindow.

The main benefit of Core Animation is that it can animate all these property changes super easily (compared to the olden days). You define a timing curve, such as linear, spring, easeInOut, (or even multiple curves with keyframes), to describe how the values of properties change over time. Core Animation interpolates from start to end values, along these curves, to create the visual animation state at each frame. It leverages the GPU to do this performantly via the render server. (I’ll explain soon).

Part of our setPressed() method creates a CATransaction.

A transaction represents an on-screen visual change or animation. We might batch up our visual changes into a single transaction for efficiency, synchronicity, to share timing code, or to access a completion handler.

Writing CATransaction.begin() and CATransaction.commit() is an explicit transaction, posted to the render server on commit. Implicit transactions, changes without declaring a transaction, wait for the next run loop iteration before they commit*

*You can test this yourself: make a change to a view or layer property, then block the main thread via sleep() commands.

Most UIKit work is done implicitly: consider every time you change the text colour of a label. This is ultimately rendered via implicit CATransactions. At the end of the run loop tick triggered by our initial tap event, the run loop fires CFRunLoopActivity.kCFRunLoopBeforeWaiting, which is observed by Core Animation. If the layer tree has changed, the changes are flushed by performing a commit.

This Core Animation commit has 4 phases:

• Layout phase: Core Animation traverses the layer tree and lays out all the layers to the correct position and size. The setNeedsLayout() function can flag a layer for updating (usually on the next run loop tick).

• Display phase: During the same traversal (both are done in the layout_and_display_if_needed() function), any required drawing, graphics, or text rendering is performed.

• Prepare phase: Misc. extra work like image decoding is done.

• Commit phase: The new layer tree is sent down to the render server.

This took me a while to get my head around: The run loop is not ticking constantly, or with every frame. It’s just waiting for events, and responding to events.

It feels like it’s always running, because most of the time, your UI code will be run in response to a run loop wake-up such as a tap, timer, or main thread dispatch.

In our example code, we commit some CABasicAnimations.

These are sent to the render server, a subsystem inside backboardd.

I do hope you had a chance to work on your tan. We’re going back downstairs, into the shadowy bowels of the system.

Subscribe now

The Layer Tree and CAContext

Animations are performed by committing changes to properties on views. These commits are batched into transactions and flushed by the run loop tick implicitly, or explicitly sent via Core Animation to the render server.

Before we leave your app process, we should clarify how Core Animation logically structures your UI.

We already mentioned the layer tree: a hierarchical data structure containing the CALayers that collectively describe the visual content and animations in your UI. This is iOS’s internal representation of what is to be drawn.

We can see its structure when you look at the UI debugger:

What I didn’t tell you is that there are actually 3 layer trees used by Core Animation.

The Model layer tree stores the CALayers in their “final” state. When you set the backgroundColor property of a button from white to red, this instantly updates the model layer tree. Each CALayer of a view hierarchy is represented directly in the model layer tree (accessed via view.layer), with matching objects in the presentation and render layer trees.

The Presentation layer tree contains the currently visible property values, including the interpolated values during an animation. This means, for our button colour above, it tracks the in-flight animation state of each frame from #FFFFFF (white), via #FFAAAA and its friend #FF5555, ultimately to #FF0000 (red).

The Render layer tree is the “true” layer used to create the actual on-screen UI and perform animations. It’s private to Core Animation, living inside backboardd on the render server. The other two live inside the application process. Because rendering lives in a separate process, you will often see animations happily continue to run even when your main thread is blocked.

You might, like me, be thinking “why do we need a presentation layer tree at all if it’s not used for rendering”?

Because the presentation layer tree is accessible in your app process via view.layer.presentation(), you are able to read the current animation values, view the real-time geometry, and perform hit testing of inflight transitions.

Your app’s UIWindow owns a CAContext, which itself owns the model and presentation layer trees. When you commit your CATransaction, this layer tree data is passed down to the render server.

Subscribe now

Compositing, Animating, and Displaying

The Render Server (and lots of definitions)

The CAContext of your app’s UIWindow bridges to the render server, and updates the render layer tree, via IPC: interprocess communication. This is a very sexy name for a very boring way that separate processes running on an OS exchange data (on iOS this plumbing is Mach-based).

This IPC is keyed by the ID of the CAContext, matching it to its twin on the render server. CATransactions encode this ID alongside the committed updates to the render layer tree.

The render layer tree is hidden from us, working in the shadows inside the Core Animation render server, which, on iOS, is itself a part of backboardd. Core Animation, the framework, consists of 2 halves: the client-side API you touch on the daily, and the server-side rendering engine that lives here.

Hol’ up. Quick definition. WTF actually is “rendering”?

Rendering is when you produce an image from input data. In this context, it’s the CALayer render trees running on the render server. Core Animation running on the render server does this by rasterising and compositing the layers in the render layer tree.

For f*cks sake. More definitions? Fine.

Compositing is the process of combining visual elements from separate sources into a single image. This includes each CALayer tree in each CAContext in each visible UIWindow.

Rasterisation is taking a set of drawing instructions and producing a “raster image”, i.e. a texture/a bitmap/lots of pixels. Here, we can think of the various properties of each CALayer like frame, colour, and corner radius to be supplying these drawing instructions.

The render server is the final authority for what displays on your iDevice screen. It collects together the render layer trees of all active CAContexts across every on-screen process, computes animations in real-time, and produces the final frame sent to your display hardware.

To produce this frame, the render server issues drawing commands to the GPU via Metal to perform the heavy lifting. These commands might include configuration, selecting shader functions, selecting textures, and the actual draw calls.

The GPU

The GPU is a beast, capable of trillions of floating-point computations per second. Off the top of my head, you get something like 5k FLOPS per pixel per frame on a half-decent iDevice.

Think of the render server like the jockey, short in stature but fiery in disposition as he issues the relevant commands and base textures. The GPU is his intrepid workhorse.

The jockey doesn’t draw pixels himself. It’s beneath him (one of the few things that is, ahaha. Because he’s quite short?). He describes what the next frame should look like, and submits the description to the GPU in a command buffer.

iPhones use tile-based deferred rendering, which consists of 3 main stages (grossly oversimplified, with apology to all you graphics buffs reading):

• Vertex processing, where layer geometry is mathematically transformed into the physical screen space.

• Tiling stage, where the GPU breaks the rendering target into small (often 32px by 32px) tiles to bucket up future work.

• Pixel processing, where the GPU applies fragment shaders and blending to each tile and writes the finished tile into memory.

These stages convert the commands (and often input texture, in the case of text or images) into a full bitmap.

You can submit work directly to the GPU from your app with Metal, via CAMetalLayer or MTKView. The render server will still composite the result.

Subscribe now

Display Controller, Frame Buffer, and VSync

After the vertex and fragment shaders have done their work, composition and rasterisation is complete: the visible CAContexts across all visible windows on your device have been rendered as a single bitmap representing this frame of UI.

Now to put them on a screen.

The bitmap for the frame is placed on a frame buffer in memory and read by the display coprocessor, a dedicated chip on the Apple Silicon SoC, coordinates this final step.

This chip reads out pixels from the buffer, applies colour space management, and talks to the screen display hardware driver. It “scans out” the final pixels, line by line, to the display.

This scanout, assuming you aren’t hitching, is synch’d with the display hardware refresh cycle, vsync, which ordinarily clocks in at 16.67ms (60fps), or perhaps 8.33ms (120fps) if you’re a millionaire.

On iOS, the display coprocessor uses vsync (vertical sync) to lock the frame to the display refresh rate boundary. This is why UI performance issues lead to dropped frames: on other systems, this can manifest as tearing, where the frame buffer is swapped out mid-scan, rendering multiple frames in different parts of the screen simultaneously.

Screen Display Hardware

In the final step of our Odyssey, our tap ultimately changes some pixels on your screen.

Look, you didn’t subscribe to Jacob’s Tech Tavern to learn how LCD/OLED screens work. Read a book, for Christ’s sake.

The Full UI Pipeline

Here’s that summary again. Print it out. Get it on a Displate. Share it on your socials for clout. Instead of a shadowy, scary group of lads, now you might see them as new friends. Perhaps you want to get a beer with them. I sure need one.

Last Orders

Frankly, I don’t think I would have been able to code this UI pipeline from scratch. I probably wouldn’t even be able to vibe code it.

Core Animation was the culmination of decades of evolution across both hardware and software. iOS is also a thing. Yeah, rendering’s hard and I’m tired, so please do me a favour and imagine a really nice conclusion, there you go.

Sponsored Link

Meet Rico by RevenueCat

Rico is your AI-powered app growth advisor. Ask questions about churn, pricing, experiments, or revenue trends and get actionable answers using your subscription data, benchmarks, and store configuration insights.

If you enjoyed my post, subscribe free to join 100,000 senior Swift devs learning advanced concurrency, SwiftUI, and iOS performance for 10 minutes a week.

---

Paid members get a lot more:

🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training
🧑‍🚀 Get a free copy of my new eBook, “Land your iOS Tech Job”
❤️‍🩹 Support independent, sometimes funny, tech writing

Subscribe now

If you’re bloody sick of detailed low-level technical explanations and just want a fun, action-packed history of the history of animation APIs on Apple platforms, this is the article for you:

Sources

• Core Animation Basics

• iOS Application Rendering: A Deep Dive

• Advanced Graphics and Animations for iOS Apps

• Getting Pixels onto the Screen

• Behind the scenes of UI in iOS

• The SwiftUI render loop

• iOS Internals

• iOS: Rendering the UI

• iOS Rendering Performance

tl;dr for the busy iOS engineer:

💸 Prices go up to $15/month at the end of May.
🔒 All paid members before then keep their lower price.
🧨 Tomorrow’s article is a banger.

I turned 31 today.

You can’t just raise blog pricing every few months like a maniac. You only really get a couple of shots in the chamber. I first did it last May, but Jacob’s Tech Tavern is a much better deal than it was in 2025.

My premium content used to be “Quick Hacks”, just a little something extra for people who wanted to support me. But today my best work is behind the paywall:

📚 Premium members get a full library of 45 paywalled articles (up from 18 last May)
👉 This is 98,000 words of advanced iOS writing (up from 23,000)

Perhaps number of words is a useless vanity metric, like number of commits or lines of code. If you want to talk intangibles, you also get that warm, fuzzy feeling that comes from supporting independent (sometimes funny) writing, and also it’s my birthday.

As one final present (uno reverso), all paid subscribers now get a free copy of my new eBook, “Land your iOS Tech Job”. 🥳

Premium membership goes up to $15/month ($150/year) on May 31.
Anyone who subscribes before then will continue paying less, forever.

Subscribe now

Sneak Preview

Tomorrow, premium members will receive my greatest deep-dive yet:

Touch to Pixels: UI Pipeline Internals on iOS
A journey through hardware, backboardd, Core Animation, and the render server

Here’s a little taster of what you can expect:

Upgrade now to lock in my lower price, plus much more:

🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training
🧑‍🚀 Get a free copy of my new eBook, “Land your iOS Tech Job”
❤️‍🩹 Support independent, sometimes funny, tech writing

Subscribe now

Swift Concurrency is really bl**dy complicated, which is great for me, financially.

Swift’s whole deal is making it really hard to write broken code: type-safe nullability, automatic memory management, and compiler guarantees around data races.

This is the whole reason your codebase suddenly grew 14,000,001 compiler warnings around non-Sendable classes. The Swift team were not being jerks, they wanted you to think about data isolation.

In a rare spurt of Apple humility, the team acknowledged this unintentional complexity in the Approachable Concurrency manifesto:

Progressive disclosure is a core Apple design philosophy: make basic options easy to access, but reveal advanced use cases when needed. Think Dock → Finder → bash shell for working in your file system. The same approach applies to language design.

Easy to get started.

Straightforward to level up when needed.

Thus the Swift 6.2 Approachable Concurrency story began.

Your concurrency journey now has 3 levels:

1. Code on the main actor by default. It’s all single threaded.

2. Basic use of async functions, running on the main actor.

3. Explicit concurrency off-main actor via @concurrent.

If you come to Jacob’s Tech Tavern for the 3-line summaries, my work here is done. But these 3 bullet points conceal a lot of complexity. Admittedly, it was all pretty unclear to me until I wrote this.

Fundamentally, the new world revolves around 2 new settings in Xcode:

• Approachable Concurrency (Yes/No)

• Default Actor Isolation (MainActor/nonisolated)

The 3 levels don’t strictly have anything to do with concurrency: they’re more about how tightly you’re coupled to the main actor. From Xcode 26, new projects are opted into approachable concurrency and default MainActor isolation.

Clear as mud, right?

It’ll make sense when you read the article.

As always, I created a sample project that will allow you to play around with the threading debugger yourself.

Get the sample project

Level 1: Main Actor 4 Life

In understanding Approachable Concurrency, you have to understand the incentives and motivations of Apple Inc., the business.

The target audience for most Apple frameworks and features is the marginal developer. The one picking between SwiftUI and React Native, and most at risk of defecting to (grits teeth) Android or (shudder) the web if their needs aren’t met.

90% of budding indie devs don’t give a sh*t about performance, because a workout tracker, AI recipe planner, or fart app doesn’t need parallelism. It needs to work out of the box and find product-market fit.

By default, Swift now puts these devs in baby mode to protect them from themselves.

The safest possible starting point is a single-threaded app. And most apps don’t actually need much more than that.

Users are happy because random concurrency bugs don’t ruin their experience; and devs are happy because they get to keep 69%** of the cash spent on their app (after the 30% Apple tax and the 1% RevenueCat fee*).

*RevenueCat, please sponsor my blog. Oh wait.

**Nice.

Serial main actor execution is the first-class mode in Swift 6.2.

Really! Check out the sample project and try to run non-async code off-main in Level 1. It’s impossible. Erm, mostly.

Prove me wrong

Concurrent mutation of shared state, and data races more broadly, are rendered impossible. This serialised code is also easy to reason about: everything runs on the main actor, so you can shut up and ship.

If you want to get to grips with actors, tasks, executors, and the underlying cooperative thread pool, this post is a great place to begin.

Level 2: Async and Serial

Look, this is probably the trickiest part to get your head around. But, basically, in Level 2, your Swift code turns into JavaScript. I know. The horror.

We introduce async operations, but all our code, and critically, our data models, remain single-threaded, isolated to the main actor.

This is the really important bit:

Subscribe now

Read more

One of the reasons I reckon I’m a decent writer is that I can remember what it’s like to be very junior. Noob-y mistakes were my bread and butter. I hailed from the “no question is a stupid question” school of thought, and had zero filter when I felt blocked.

These traits combined to make me very annoying to Josh and Si, our resident seniors. My relentless requests for help were invariably met with some variant of:

• “You forgot to assign the UITableViewDataSource, didn’t you?”

• “You didn’t set translatesAutoresizingMaskIntoConstraints = false”

• “You have to call .resume() on that URLSessionDataTask”

This wistful nostalgia trip got me thinking.

What actually happens when you call .resume() on a URLSessionDataTask?

The subsequent rabbit hole is quite fascinating, and required reading if you never stopped to wonder how literally the entire internet works.

So today is a theory lesson + case study.

We’re covering the conceptual model underpinning the vast network of networks that make up the internet.

Along the way, we’re going to follow the unassuming URLSessionDataTask as it traverses each layer of abstraction: from your app’s API request, to system frameworks, into the kernel, via drivers into the radio hardware, and finally out into the physical world as electromagnetic radiation.

Sponsored Link

Lessons Learned from Security Incidents in Mobile Apps

Join Security Researcher and Pentester, Jan Seredynski, on a live stream on May 12 as he dissects recent real-world security incidents in banking, food delivery, and e-commerce. From face verification bypass to location spoofing, he'll break down the anatomy of a breach and what teams can do differently to address them.

Sign up here.

Contents

• What is the Internet?

• URLSession and the Application Layer

  • URLSession

  • Resuming the DataTask

  • HTTP, DNS, and Cookies

• Network.framework & the Transport layer

  • Transport Layer Protocols

  • Segments and Reliability

  • Network.framework

  • The Kernel TCP Stack

• IP and the Network layer

  • Network Layer Datagrams

  • Forwarding Datagrams

  • Buffering Datagrams

  • Network Layer in the iOS kernel

• The link layer (feat. Wi‑Fi) ()

  • URLSession at this layer ()

• Electrons and the Physical layer

  • iPhone hardware

• Last Orders

Subscribe now

What is the Internet?

The internet is a global system of interconnected computer networks, with 2 major types of entity:

• End systems (a.k.a. “hosts”). This might be an iPhone, a server in a data centre, or perhaps a very clever fridge.

• The network core. This is a mesh of routers, packet switches, and IXPs (internet exchange points) that play pass-the-parcel with packets of data.

This network core includes the global backbone of the internet: an interconnected web of physical infrastructure like copper wire, fibre optic cable, and undersea cables carrying data between networks.

This lowest level of infra is operated by friendly, totally non-evil companies such as Verizon, AT&T, and Google. The interconnectivity is key: the internet as we know it works because these companies all agree to route each other’s traffic.

The networks are compatible because they all speak to each other via IP, the internet protocol. This is the most fundamental thing to understand. A protocol is simply a specified format for sending and receiving messages. These formats are agreed via an “RFC” process run by a shadow cabal, the Internet Engineering Task Force.

Routers forward packets between each other as data traverses this physical system of cables, fibre, and radio links to their destination; from your iPhone in the UK, through to a VPN server in Sweden, down to an edge cache in Germany to retrieve your favourite scheiße video (and back).

To understand how we go from URLRequest to a streamed .mp4, we follow the classic five-layer Internet model:

• application

• transport

• network

• link

• physical

The layered model is all about abstractions.

The application layer worries not about the underlying orchestration of packet encapsulation and transport links. It might as well be magic. Who cares? Data go into pipe, data come out of pipe.

This “who cares” powers the entire global software ecosystem, preventing lowly web developers going insane when confronted with manmade horrors beyond comprehension (like ethernet ports).

Abstraction saves you from understanding implementation details of each layer. You just need to know the protocol, that is, the format of data in and out. Abstraction is everywhere. It’s why you’re able to ship profitable SwiftUI apps without understanding the low-level process memory management done via a red-black tree inside the XNU kernel. Whoooooo. Cares.

Let’s investigate each layer, step-by-step, looking at real code to understand as we go.

URLSession and the Application Layer

The application layer is where all the interesting stuff around the network can be done. It contains HTTP, DNS, cookies, caches, configuration, and everything else you actually touch in your day-to-day.

URLSession

URLSession is your entry-point into this world. To handle a run-of-the-mill network request, you’ll create a session, configure it, set up a task, and kick it off with resume().

p.s. I am using the handy open-source FoundationNetworking library here, which relies on curl rather than CFNetwork.

Internally, URLSession uses both Grand Central Dispatch and NSOperation to avoid data races, using GCD queues to protect its internal state, and operations to handle URLSessionDelegate callbacks.

Resuming the DataTask

Individual requests are created and executed using a URLSessionDataTask. This calls into the underlying implementation library (curl or CFNetwork) and feeds data back to the session. The task tracks its state, counts bytes, and finishes with either a URLResponse or an Error.

This data task gives devs the opportunity to configure the request before work begins. It inits in a suspended state, kicking off when resume() is called.

The async/await form conveniently handles both task creation and resume() internally. It’s truly nothing special, wrapping the O.G. dataTask(with: URLRequest) function in withCheckedThrowingContinuation.

HTTP, DNS, and Cookies

In the application layer, network requests often have a human-readable format, such as the ubiquitous HTTP request.

You can trivially instrument the application layer yourself: via Charles Proxy, Proxyman, or on the web, by right-clicking and tapping “inspect element”, then looking at the “Network” tab of the site debugger.

DNS is a distributed dictionary that maps URL hostnames to IP addresses. Caches on your URLSessionConfiguration help decide whether your request even needs to hit the network. Cookies attach metadata to stateless requests to help our server maintain a consistent user state. If you want a stateless request, you can use an ephemeral session configuration.

The curl and CFNetwork libraries handle lower-level details in the application layer such as multiplexing, which combines multiple HTTP streams onto the same TCP connection (see below), saving energy by reducing connection overhead.

Ultimately, these lower-level libraries run syscalls into the kernel such as connect, socket, send, and recv. This brings us down to the next layer.

Subscribe now

Network.framework & the Transport layer

The transport layer moves messages between end systems.

Transport Layer Protocols

I’ll jump ahead very briefly, because there’s one really important thing to understand about IP (in the layer below), that explains everything about transport layer protocols:

IP is unreliable.

When a packet is sent with IP, there is no guarantee that it arrives to its destination, on time, or at all.

Now we know that, we can appreciate the 3 important protocols of the transport layer:

• TCP, Transmission Control Protocol, is a system that creates a (pretty) reliable connection on top of IP by verifying that each message was sent. Most of the internet is built atop TCP/IP.

• UDP, user datagram protocol, is fire-and-forget. It’s simple and fast, and “good enough” for streaming live video calls and gaming.

• QUIC, quick UDP internet connections (QUDPIC just sounded silly), is a modern protocol that powers fast and reliable connections on top of UDP. Ask your backend engineers if they support HTTP/3 today!

I’m going to resist the temptation to write another 12,000 word behemoth, and focus on explaining why TCP is interesting, and relate it to iOS.

Segments and Reliability

When sending an HTTP request via TCP, the request is split into segments, which add bookkeeping logic around the original request data.

---------------------------- 32 bits ----------------------------
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |           |U|A|P|R|S|F|                                |
| Offs | Reserved  |R|C|S|S|Y|I|           Window Size          |
| et   |           |G|K|H|T|N|N|                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |        Urgent Pointer         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (if Data Offset > 5)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Application Data                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This bookkeeping includes sequence numbers, acknowledgements (ack), and checksums. When a segment is sent successfully, success is ack’d. TCP checks acks and “the lack of acks” to infer lost data segments for retransmission.

This is reconstructed into the original HTTP request on the receiving end system, and returns back an ultimate success response for our intrepid URLSessionDataTask.

Reliable doesn’t mean guaranteed. If Dick Dastardly snips your router’s ethernet cable, or blows up your local IXP with an implausibly large crate of TNT, the message won’t magically get delivered.

This is explained best in Joel Spolsky’s classic the law of leaky abstractions.

In a beautiful symphony of collaboration that makes you wish for the good ol’ days, TCP throttles the request if it detects an abnormally slow receiver. This forms the basis for congestion control and traffic management for the entire Internet. Kum baya, my friend.

Network.framework

Foundation is abstracted well away from the transport layer, but we can absolutely play around with it using the lower-level Network framework.

This gives devs access to transport-layer primitives like TCP, UDP, and QUIC, allowing you to configure properties like message format, retries, timeouts, authentication, encryption, and state machines.

This is used by apps like Telegram to implement custom application-layer protocols that offer end-to-end encryption, and transmit data over standard transport layer primitives.

The Kernel TCP Stack

Ultimately, these transport layer primitives are built at a lower-level: the OS. The kernel (XNU) implements the TCP/IP stack and handles the necessary segmentation, routing, and congestion control:

This ultimately leads us down to the Network layer, and the Elvis of networking protocols: Internet Protocol.

IP and the Network layer

The network layer is responsible for moving packets of data (a.k.a. “datagrams”) from one end system to another. The packet traverses the network core by being forwarded between routers.

What does a router do? Two main things:

• Forwarding datagrams.

• Buffering un-forwarded datagrams.

Network Layer Datagrams

First, what is a datagram?

If you’re rolling IPv6 (weirdo), it looks like this:

----------------------------- 32 bits ---------------------------
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Traffic Class |           Flow Label                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Payload Length         |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address (128 bits)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address (128 bits)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Extension Headers (optional)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Payload (e.g. TCP)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP has 2 key flavours, relating to the format of the source and destination addresses:

• IPv4, which looks like 192.168.1.10

• IPv6, which looks like 2001:db8:85a3:0:0:8a2e:370:7334

If your first reaction is total disgust at the IPv6 address, you would be correct. Workarounds like network address translation allowed millions of devices to hide behind a single IPv4 address, thus kicking the “there are only 4 billion possible IPv4 addresses” can down the road indefinitely.

Forwarding Datagrams

Routers are linked together to multiple other routers, via copper cables, fibre, or ethernet, across network links, or within an IXP (more wires tbh). Each router has its own IP address. This address acts less like a postal address, and more like a coordinate, narrowing down the logical location of the end system across the whole network.

When network topology changes, routers re-construct a forwarding table: they read the IP address of each neighbouring router, and determine which IP ranges should be forwarded to which links.

As long as the network is stable, picking the next “hop” in the network is easy: routers ship the datagram on to the closest prefix-matched IP on their forwarding table.

Across dozens of links, the packet gets closer and closer to its destination until it arrives at the destination end system (or gets dropped).

Buffering Datagrams

If you haven’t read the title, you might think that slicing a TCP segment into IP datagrams is as low-level as we get. Ultimately, though, no spoilerinos, the electrons that encode bits are transmitted serially through the network.

A router needs the full packet before forwarding anything, so latency adds up with each hop between routers. When the output is busy sending another datagram, your packet is buffered in a queue.

IP is best-effort, rather than reliable: a network connection is only as fast as the slowest, most congested link, so your p99 network latency often stems from a single dodgy link across the network core. If the buffer is full, the packet can just get dropped.

This unreliability can be political as well as technical: peering disputes between network operators have led to latency issues, and in the worst cases, “blackholes”, where a router intentionally discards traffic.

Network Layer in the iOS kernel

iOS has enforced IPv6 compatibility for years. Probably a good thing, otherwise their device sales would account for 75% of the total IPv4 address space. iOS devs really don’t touch the network layer, but we can track it down in the xnu kernel source:

The kernel selects the outgoing interface using its routing table. From here, it hands packets down to the iPhone’s link layer: the network driver (Wi-Fi) or the baseband subsystem (cellular).

Subscribe now

The link layer (feat. Wi‑Fi)

The network layer moves packets across the wider Internet, to a destination.

The link layer is far less ambitious. Its job is to move “frames” from one network element to the next adjacent link in the chain. Just one.

For your iPhone, that next link may be:

• a Wi‑Fi access point

• a cellular base station

• or perhaps you’re hot-spotting and your device itself is the link.

This is your access network, the first leg that connects your device to the wider Internet. The link layer takes the IP datagram from the network layer and wraps it in a container, or frame, that includes just enough info to get it across the current link.

This info includes:

• Who should receive this frame; for WiFi/Ethernet, this is the MAC address.

• Error detection bits to flag up data corruption and mangled frames.

• Control metadata like sequence markers, priority, flags, or frame types.

These frames differ based on how you are connected; ethernet (IEEE 802.3), cellular (LTE/5G), and WiFi (IEEE 802.11) all have their own protocols. The link layer also performs a lot of invisible labour, such as retrying these frames locally if they were lost. TCP hogs all the credit.

Wi‑Fi is a shared medium, meaning all the local devices occupy the same band of radio spectrum. Therefore, to avoid a prisoner’s dilemma of signal hogging, the protocol forces devices to wait and take turns when transmitting to the router. Therefore, WiFi throughput is often a function of the other devices on the network, as any parent of a gaming teenager knows while on a business video call.

With cellular, the base station tells you when you can transmit, and for what resources. What are you gonna do about it? Your cellular radio tends to hang around in a higher-power state after any burst of traffic, so batching up requests is kinder to battery life than constant little drips of network activity.

URLSession at this layer

I don’t even think our URLSessionDataTask knows what’s going on at this point.

The OS picked an interface, handed the packet to the relevant subsystem (cellular modem or WiFi driver), and your HTTP request has been mutilated beyond recognition, dismembered, and squeezed into a suitcase to hop to the next link.

Electrons and the Physical layer

The final layer in our digital lasagna of abstractions is called the physical layer because it’s… uh, I actually don’t know why it’s called the physical layer.

You’ll be pleased to know that we basically don’t have any wanky container names like packets or datagrams or frames here; just bits. Bits that move from point A to point B.

Every abstraction bottoms out here, because data has to actually exist: a change of voltage pushing electrons (slowly) through a copper wire, a pulse of light bounced through a fibre optic cable, or an electromagnetic wave ̶y̶e̶e̶t̶e̶d̶ cast aloft through the air.

iPhone Hardware

Your URLRequest ultimately becomes energy in the real world.

On your iPhone, the radio hardware accepts bits from higher layers, encodes them, maps them to symbols, modulates a carrier wave, amplifies the result, and sends it out through an antenna. The receiver in your WiFi router or local cell tower does the reverse, fighting noise, reflections, interference, distance, and walls.

The network request is no longer data: it’s encoded into an oscillating electric charge in radio circuitry, then an electromagnetic field produced inside an antenna, and then a spherical wave of microwave-frequency photons, propagating out from your device until eaten by a receiver.

As you can imagine, antenna design matters a lot to hardware engineers.

Recall iPhone 4.

The hardy steel rim lived a double life as a part of the antenna subsystem, meaning the way you held the phone could materially degrade the already-meagre 3G cell reception. Following this fiasco, Steve Jobs literally died from embarrassment.

Modern radios are adaptive f*ckers. They adjust their modulation and coding based on channel quality. In a clean signal environment, they can apply faster, denser schemes to push more data. In a noisy signal environment, they back off to slower, more robust schemes so the bits still squeeze through. Chuck in multiple antennas, MIMO, beamforming, and digital signal processing, and phones are subsequently pulling in gigabit ranges per second.

Last Orders

Ultimately, your app does not talk to “the server.” It cries into the endless void, through a Lovecraftian rat king of network links and routers.

Abstractions allow us to comprehend the incomprehensible without going insane.

• The application layer happily pretends to be speaking directly to a server via tin cans and string.

• The transport layer does the hard work making sure segments actually arrive.

• The network layer goes postal to get your data to its destination.

• The link layer locates the next link as frames traverse between network nodes.

• The physical layer is where abstraction stops and life starts.

On its journey, requests are chopped, wrapped, addressed, buffered, retransmitted, routed, modulated, amplified, and chucked across the planet by machines that mostly agree to cooperate with each other. And, incredibly, it works.

Next time you all URLSessionDataTask.resume(), just remember: Internet go brr.

Sponsored Link

Lessons Learned from Security Incidents in Mobile Apps

Join Security Researcher and Pentester, Jan Seredynski, on a live stream on May 12 as he dissects recent real-world security incidents in banking, food delivery, and e-commerce. From face verification bypass to location spoofing, he’ll break down the anatomy of a breach and what teams can do differently to address them.

Sign up here.

Subscribe now

Rate my setup.

If you’ve been following my escapades for a hot minute, you’ll know that after my brief stint of independence, I landed in Granola, a hot London startup building a popular AI notetaker. We just landed our Series C, officially making us a unicorn 🦄.

Now, sit down. I’m about to rock your world: we use lots of AI.

Our tiny mobile team punches well above our weight, shipping faster than I’d have dreamed possible back in November 2022 when ChatGPT launched (has it only been 3ish years?!).

With my left hand, I wield a maxxed-out Claude Code subscription. With my right, a maxxed-out Codex subscription. The overwhelming majority of the code I ship (yes, easily ~99%) is written by an agent. This is, to use 2020 lingo, the new normal.

I’ve been mucking around with agents since May last year, but rolling multiple agents in parallel most workdays has honed my workflow substantially. Seriously though, I’m getting so much done. It’s almost unbelievable.

It’s absolutely not a strict measure of productivity, but I’m landing eight PRs a day on average.

Nothing in this blog post is prescriptive: everyone has a workflow that works best for them. Some rip through Opus 4.7 credits in the terminal, some utilise the Cursor’s IDE for everything, some rock the Codex app. Many are gradually accelerating from single agent to multi (and beyond).

Our guiding philosophy? Ship bricks.

I hope you find it interesting.

Contents

• Agents running for hours

  • Context Switching

• Feature Workflow

  • Stacked Diffs

  • Planning

  • Letting it Rip

  • Breaking the Bottleneck

  • The Timeline

• Parallel Workflows

  • Product & Design

  • UI work

  • Debugging

  • YOLO-ing

• Handsfree Tooling

  • WisprFlow

  • Slack Integrations

  • UI work & MCP

  • Bash Shortcuts

• Cognitive Debt & Downsides

• Last Orders

Agents running for hours

Let’s get this one out of the way first, because I myself have been inflicted by impostor syndrome from the tech bros that tweet about this constantly.

I used to be incredulous about people who left agents running for a long time - or, worse - overnight, until I cracked it myself. And realised it’s nothing special at all:

1. The best models (Codex/Opus/Mythos(?)) in the highest thinking mode take way longer than default settings, but make far fewer mistakes.

2. You need to set up verification on your agents so they can build, navigate through your app, log stuff, run tests, and perform fixes autonomously. This, again, takes ages but returns extremely trustworthy work.

3. You can set up agent rules that follow your workflow consistently, whether that’s worktrees, verification pathways, or a git strategy (more on this later). Often each step in a plan requires an extra verification run.

This is why you go multi-agent. Not because you have severe ADHD (which I do), but because when your agents are doing their job properly, these factors combine multiplicatively.

The longest recent example I can recall was my Bitrise pipelines. Naturally, the remote tests were flaky, but my agent had access to the MCP. It could simply wait 20 minutes between each push and read the results.

As the lowly human in the loop, there was little for me to do but enter caffeinate and run it overnight. Waking up to a green build (amongst the ashes of my Bitrise credits) was a good (if bittersweet) time.

Context Switching

This is the true downside of the multi-agent world. In an ideal world, agents will be lightning fast and you could run single-threaded. But when using the strongest models and longest thinking modes, latency management is a fundamental skill in this new world (until the models get faster).

I have 6 (and counting) identical separate checkouts of our source repo, so agents can work on different tasks without stepping on each other’s toes. In order to get this to work with Xcode, we set up local derived data folders for each checkout, so xcodebuild doesn’t lock the local DB for each concurrent build.

I tried both the Claude and Codex apps, but frankly I prefer the terminal so I can more easily flit between models and tabs in the same terminal window. It admittedly also better serves my self-image as an elite hacker from the Matrix. Both good.

Feature Workflow

This is the big one, okay? Here’s what you came for. I’ve been refining my workflow for working on new features pretty drastically.

Unlock the full workflow

Last chance to take advantage of my eBook sale 🧑‍🏫

This week only, own my best work for $30 off!

📕 Advanced Swift Concurrency Training is a real-work concurrency simulation, guiding you through 12 increasingly complex challenges, allowing you to apply and master practical concurrency knowledge. You get a certificate at the end.

Advanced Concurrency Training ($25)

📓 Land Your iOS Tech Job is the novelisation of my epic job grind last year, packed to the gills with practical advice to crush technical interviews and maximise your income. Get it before the market turns and/or the price jumps back up.

Land your iOS Tech Job ($19)

Read more

Sponsored Link

How iOS apps actually make money

RevenueCat’s State of Subscription Apps report is out, analyzing 115,000+ subscription apps and more than $16B in revenue. Use it to benchmark your pricing, trials, and conversion rates against what’s actually working across the app economy.

The original cargo cult came from World War II; electric boogaloo. Pacific tribes observed cargo planes distributing supplies & food to soldiers. In short order, they began ritualistically copying military practices: marching about, building runways, and talking on fake radios. This imitation was done in the vain hope of summoning more planes, with more supplies.

It’s fun to point and laugh at the silly historical tidbit, until you realise that in tech, we often do the exact same thing.

“Cargo culting” in tech is when we observe and imitate the behaviour of top companies, without understanding the underlying reasoning. You know what I mean: OKRs. Dashboards. SCRUM. Story points.

The behaviour is at its most insidious in the engineering department. You aren’t just cosplaying as a big Silicon Valley swingin’ d*ck, you’re actively kneecapping the productivity of your org, forever.

Distributed Microservices™ is the most famous case study. Popularised by Amazon in the early 2000s (when they had billions in sales and 40m customers). At scale. Desperately imitated by companies (and sold by consultancies) with microscopic sales and nano customers. (Nah, no customers). Even Amazon is seeing the light.

Complexity debt is orders of magnitude worse than tech debt, because you are paying it every time you touch your system.

It’s insidious because engineers love introducing complexity. You need an iron fist to prevent them introducing the latest networking paradigm, shipping a proprietary UI rendering system, or re-architecting the app to RIBs (sorry, ).

I’m deeply impressionable, and no stranger to the allure of the cargo cult. When I CTO’d my own startup, I made the decision to roll a serverless stack so we’d scale 2 da moon 🚀, even though a $5 box could trivially handle our meagre DAUs.

Today we’re focusing on mobile engineering, because I have a lot of war stories to draw on. And we’ll cover the full roster of cargo-culting deadly sins:

• 👑 Pride: Knowing better than Apple about UI frameworks

• 🤑 Greed: Everything must be available offline

• 🧨 Wrath: My architecture is bigger than yours

• ⚙️ Envy: We must adopt Google’s build system

• 🍆 Lust: Let’s make our networking stack polyamorous

• 🤤 Gluttony: Om-nom-nom all the modules

• ⛓️ Sloth: Automate all the things!

Subscribe now

👑 Pride

Knowing better than Apple about UI frameworks

Apple gives you UIKit and SwiftUI. One’s performant, and one’s nice to write.

But we want to have our cake and eat it. If we re-write the app in HypeUI, we can get blazing-fast UIKit performance with easy SwiftUI-style syntax! Kind of.

This is fun for side projects, but consider migrating your entire codebase:

1. Now you have inconsistency between most screens across the codebase, slowing down every context switch.

2. Invents years of make-work to re-write screens that already work.

Velocity suicide.

This is even worse in the age of AI: perhaps you know the framework inside and out. But the training data is scarce, and your agent will start to hallucinate like it’s 2022.

This is, in my experience, the deadliest sin. I’ve seen it slow feature development to a glacial crawl. If scroll performance is a problem, give UIKit a go. If it’s still a problem, simplify your UI.

Subscribe now

🤑 Greed

Everything must be available offline

Sometimes you want everything. Offline-first architecture, total reliability, and sub-millisecond latency.

Over-zealous local persistence won’t kill you, but it’ll slow you down. Lots. The rubric for cargo culting is “copy what Meta does”, but even Meta doesn't bother doing this on your news feed!

There’s a dark, oft-whispered-about practice that’s even more harmful to your productivity than persisting everything: sync engines. Automatically ensuring the local user data is eternally kept up-to-date with the backend representation.

This might not sound that bad, until you try it.

You’re introducing distributed system problems to a f*cking client app! You better at least be rolling “last write wins”, or I’ll really kick off.

Look. Persisting some stuff is good.

You’ll usually want some caching. And some data is great to have locally for fast retrieval or offline availability. For some apps, keeping important user data like voice notes or documents offline is obviously a requirement. But for 96% of apps, 96% of data does not need to be persisted.

🧨 Wrath

My architecture is bigger than yours

We’ve all felt like this at some point.

I can’t believe they chose to run vanilla MVC for this app! All the interactions and navigation are run through a view controller extension in a different file! This is dumb. I could totally improve this by using MVVM+C.

You’re not doing your job as a developer if you don’t think the people who originally built the software you’re maintaining were total morons.

But it’s dangerous when you actually try to change things.

Consistency is a superpower for a codebase. Your devs can land on the folder for a screen, know which file does what, how the navigation works, where data is fetched, and where user interactions are handled. All the moving parts are easily searchable, making debugging, maintenance, and new feature work super straightforward.

Architectural churn destroys this hard-won institutional knowledge.

My advice? Pick an architecture and religiously stick to it. Unless you have non-overlapping feature teams who never touch each other’s systems, a-la Monzo’s famously laissez-faire “let teams pick whatever” strategy, architectural inconsistency will hurt you forever. Trust me, this creates years of tech debt.

Subscribe now

⚙️ Envy

We must adopt Google’s build system

This is the bread-and-butter cargo culting justification.

Oh no! Our build times are ticking up! Our dependency graph is getting a little heavy. Better consult my two amigós, Buck and Bazel! 🏜️🤠

This will achieve 3 things:

• It looks phenomenal on your CV.

• You can’t be fired, because no-one else understands how to change the config.

• Your build times are fixed, but nobody can really get anything else done.

Google rolls a custom build system. Uber rolls a custom build system. Meta rolls a custom build system. What could possibly be different between your 100k-line project and their 100m-line project? Other than a paltry 99.9m lines of code?

Bazel was created by Google to solve Googley problems like “git stopped working in our monorepo”. These tools are designed to build your whole system and unify deployment across backend and frontend, but there’s a second level of this sin: deploying a hyper-complex build system for a single platform alone, negating the entire point.

Look. I love Tuist. They don’t pay me. Yet 😏.

Pedro, pls sponsor my Substack 🙏

It’s the everyman’s alternative build system, and solves problems like “xcodeproj files suck arse” or “caching modules speeds up your builds a whole bunch”, not “our repo literally won’t fit on your hard drive”.

Maaaaaybe you can justify a hyperscale build system like Buck if you’re a team of ex-Facebookers building a company, and want to just use what you know. But you’re creating more work down the line: onboarding overhead for every new team member, forever, and a dramatic maintenance burden. Why take the hit?

🍆 Lust

Let’s make our networking stack polyamorous

When you study system design for the first time, you might think you can create the optimal system that’s good for everything by applying a range of networking stacks:

• REST where you need simplicity

• GraphQL where you need flexibility

• gRPC when you want to minimise latency

Let’s be real.

YOU ARE NOT GOOGLE. You aren’t Google.

Ask your devops guys now. Seriously. How much are you spending on network I/O? What’s your p95 for fetching user info?

If you have less than a million customers, it’ll be nothing. Certainly trivial when compared to real infra costs like DB, compute, and storage.

Using the “optimal” approach for each given situation creates the worst of all worlds for people who actually have to touch the networking stack, because engineers have to re-learn the tooling for each paradigm every time they touch it.

The maintenance burden is real. These approaches sprout divergent error modes, caching semantics, auth patterns, and observability methods. If you’re serving advanced requirements like pagination, delta queries, or offline mode, you incur a combinatorial explosion with each stack handling them differently.

⚠️ Info Hazard Warning: Don’t let your resident architecture astronaut read below! ⚠️

Did you know you can build your own proprietary application-layer networking stacks with Network.framework if you really want?

Frankly I struggled to avoid putting “GraphQL” for this whole sin and taking an early lunch break, because I hate it, but I’m a professional.

Stick to a stack. Keep it simple. Go fast.

Subscribe now

🤤 Gluttony

Om-nom-nom all the modules

Look, it’s really good to modularise your app, in a thoughtful way. Build times go down, you can easily split up responsibility as your org grows, and you can make the app more simple.

But there can be too much of a good thing.

Investing in automation to spit out modules (or, these days, asking an agent to do it) is nice, but without due care it’s possible for your dependency graph to descend into the depths of spaghetti.

Not sure what module a new screen fits into? Hell, just make a new one, for that single screen.

You can introduce another combinatorial explosion here where you introduce more than 1 submodule per module: after all, why not have an API module alongside each feature module? We need a test target, after all. And what about the service layer? Huh? You want an alternative service layer for our watch target? Why not!

It gets real messy real quick.

Modules are great! Use them. But keep your feature modules carefully scoped. Just be thoughtful when adding new stuff. Avoid your dependency graph turning into a Gordian Knot.

⛓️ Sloth

Automate all the things!

Automation is great. You should automate boring, repetitive, routine work as much as possible.

But, like this delicious, ice-cold Peroni I am drinking, it’s best enjoyed in moderation.

Automation is a high-leverage activity. You can spend a day automating work that saves your team an hour a week. Think release CI, routine QA testing, or performing analysis on your analytics.

So what am I getting at? Why am I being a sourpuss?

Automation can go wrong when you start to default to it, before even proving something is routine: “let’s make a devtool to enforce this rule we just thought of”, or “let’s use Swift subprocess to wrap our build commands”. Automation always feels like a high-leverage activity, but you are often introducing annoying, hard-to-kill overhead.

You also create a new maintenance vector: when you’re freezing random workflows in a hard-to-change CLI, everything grinds to a halt if suddenly you find yourself on the wrong Rust runtime version.

I think the root issue is premature optimisation: you don’t really need to set up codegen or a DSL to build simple stuff like analytics events or deep links. Now, instead of just changing the thing, you have to re-learn how to use some tool (this is a major part of why I dislike GraphQL).

I like to think that in the age of agents, this will become less of a problem. Claude Code, especially alongside an MCP, can often automate most routine tasks. But pessimistically, it can just as easily spit out a bash script that works, until it doesn't. Or, god forbid, a Git Hook.

Nobody wants to be the jerk that kills someone else’s automation project, and so you are usually stuck with these forever. Over-automation can backfire badly: devs can get both clever and sloppy with workarounds for an overly-pedantic suite.

Many times have I intentionally squashed several tickets into a single PR to get around the annoying overhead of a ponderous, inflexible test suite (that insists on running UI tests and a build).

What I’m really trying to get across is, trust your devs!

Subscribe now

The Golden Rule

When is it okay to Cargo cult?

The insidious thing about cargo culting is that you can trick yourself into justifying it.

• You’re getting frame drops? Drop SwiftUI and find a UI framework that can handle your design.

• Clean builds taking over 10 minutes? Re-architect to Buck immediately.

• Engineers stepping on each other’s toes with MVVM architecture? Whip out VIPER for the ultimate separation of concerns.

It’s incredibly easy to justify big-tech cargo-culting with a “real business need”, but often this is poorly thought through. You see the problem one step in front of you, but don’t see the death by a thousand maintenance cuts your decision will create in the medium-term.

Just consider whether you’re solving a problem, or cosplaying as one of the big boys.

The golden rule?

Try to understand the problems that each technique is designed to solve.

Big-tech solutions are for problems ~two orders of magnitude bigger than most mobile teams, even really successful ones, ever hit.

As a heuristic, try not to be the smallest company you know that’s using the approach. But also, if you can find a smaller company doing it, find out why.

If a startup full of ex-Snapchatters is starting from scratch with Buck, they probably all know how to use it, and don’t want to learn something new, and are stoically accept the onboarding overhead for new team members in the future.

Facebook invented ComponentKit for the news feed because they had thousands of mobile engineers, dozens of UI components (so cell reuse exploded memory), serious frame drops on a billon low-end devices, and spaghetti data-flow. UIKit simply wasn’t designed to handle these issues, because nobody had encountered these issues before. And I hate to tell you this, but you are (probably) not Facebook.

If you are Facebook, might I interest you in my group subscriptions; 33% off?

Get 33% off group subscriptions

Last Orders

Back in 2020, my startup’s commercial co-founder insisted that our MVP works 100% offline. This constrained our options to AWS Amplify (alone). I’m easy. It came with a free sync engine. But we had to use GraphQL. I dropped it for V2.

These cargo-culting deadly sins have a lot in common: they feel like they solve a problem now (even if that problem is, “my CV isn’t exciting enough”), but create complexity and overhead for the rest of your team, forever.

Simplicity is a gift. That boring codebase will be equally boring 10 years from now, allowing the inexpensive AGI maintaining our work in the future to easily get their head around it.

CV-driven development is the deadly enemy of simplicity. Engineers love to make things complicated, and often the loudest, most disagreeable voice can win out.

Motivations might be pure (in a capitalistic sense): complexity is usually accepted to solve a real business problem. Maybe the builds are too slow. We might be getting too many frame drops. Perhaps your team isn’t always following the process.

But consider the full picture. Yes, we may solve frame drops on this screen with a shiny new UI framework. But we also permanently slow down feature development by 50%, and invent a huge class of “rebuild” work that no user asked us for.

Today we covered the seven deadly sins of cargo culting:

• 👑 Pride: Knowing better than Apple about UI frameworks

• 🤑 Greed: Everything must be available offline

• 🧨 Wrath: My architecture is bigger than yours

• ⚙️ Envy: We must adopt Google’s build system

• 🍆 Lust: Let’s make our networking stack polyamorous

• 🤤 Gluttony: Om-nom-nom all the modules

• ⛓️ Sloth: Automate all the things!

Which are you most guilty of?

Sponsored Link

How iOS apps actually make money

RevenueCat’s State of Subscription Apps report is out, analyzing 115,000+ subscription apps and more than $16B in revenue. Use it to benchmark your pricing, trials, and conversion rates against what’s actually working across the app economy.

Subscribe now

As a final word; here’s two very good blogs on this topic that formulated my core opinions in this post:

Choose Boring Technology
The Grug-Brained Developer

My numbers were going up and to the right, and I was on top of the world.

But then, in late December 2025, I got a job.

I never told you why. Really.

My first motivation was financial: I crunched some numbers on a spreadsheet, and I’d struggle to break even before going bankrupt. I know how it goes.

But that’s just short-term downside risk.

Long-term, who the f&ck knows what the job market is going to look like?

Best to hitch my wagon to a muscly horse. Or, in my case, a unicorn 🦄

The way I see it, there’s two ways to safeguard your career future from the risk of AI disruption:

• Play defence: Becoming way more knowledgeable than average.

• Play offence: Position yourself in a company that will survive.

I’m here to help you with both of those things.

Introducing…

Land your iOS Tech Job
(Jacob’s survival guide for the modern interview grind)

This is a comprehensive 109-page guidebook helping you prep for each stage of the big tech hiring process: from technical screenings, to system design, and the mysterious “iOS coding” interview.

It’s informed by my 10 years of iOS experience, conversations with senior engineers at Meta and Snap, and my personal experience from my own grind: 30 technical interviews across big tech and hot startups in December 2025.

Because it’ll be a little awkward to expense this to your company, I’m pricing it at a special reduced price of $19.99 this month only.

Buy the book now ($19)

If you’re an existing paid subscriber? You get it for free. Thanks for the support!

Contact me if you’re a student, unemployed, or a layoff victim, and I’ll sort you out with a discount.

Cheers for reading Jacob’s Tech Tavern! 🍺

Landing a job is never easy.

There are a lot of themes you’ll encounter across many interview loops: take-home projects, system design, iOS knowledge, and LeetCode puzzles. These are pretty universal, and straightforward to prepare for.

In my interview grind over December, I worked through ~30 individual technical interviews. Along the way, I encountered several rounds simply labelled “iOS coding round” or “app building exercise” or “programming in iOS”. I’d email the internal recruiter, and get zero details. Flying blind.

Companies are being deliberately vague: They want to see you handle an unknown problem using your raw skills.

But, as a candidate, accepting the unknown is a crappy way to prepare for an interview. There is a way to train yourself to handle any curveball an iOS interview might throw at you: Drills.

Drilling a wide variety of problems helps train your engineering muscle memory and load up your cranial CPU caches, honing your ability to tackle any problem thrown your way. With practice, you can demonstrate your skills in the best light.

Today, I’ll detail the 5 broad archetypes of “iOS coding” interviews you’ll encounter. I’ll be sharing real practice problems (and solutions) that I used to land a tech job last month.

• Screen building

• Component design

• LeetCode-“lite”

• Fundamentals

• API design

This post comes packed with a fully-fledged sample project with drills to help you practice each class of interview problem.

Today is the last day of the Spring Sale for my Swift Concurrency eBook bundle. Get 55% off my paid-only concurrency masterclasses and own them forever.

Master Concurrency for $29

Categories of “iOS Coding” exercise

If you’ve been out of the job market a while, you might be unfamiliar with the format.

Some companies, the stars, give you a highly detailed PDF explaining what they’ll interview you about, and what you can expect.

The vast majority are pretty taciturn when telling you what to expect.

If you know, you know. The email invite will look something like this:

• “An interview focused on programming and debugging in iOS.”

• “An interview involving an app building exercise”

• “An interview focusing on your experience with the iOS ecosystem, including core programming, architecture, and problem-solving.”

• “An interview testing understanding of algorithms, data structures, and clean code”

• “An interview on software engineering & API-oriented programming.”

Deciphering these is more art than science.

Some are mercifully transparent: perhaps, for an app-building exercise, I should practice building an app. Others are painfully opaque: I guess it’s an interview about programming?

Across the 30 technical rounds I completed, I can map the generic “iOS-programming” style rounds to a few core categories, which dramatically focuses the scope of what you can do to prepare:

Screen building

This is the most straightforward challenge: you will be asked to build a screen from scratch with UIKit or SwiftUI. Practicing these is almost trivial: time yourself building various designs within 30 minutes or so.

Component design

You’ll be asked to build some kind of reusable UI component, demonstrating you can code, think about requirements, and recognise edge cases. Drilling is straightforward: practice building these components from scratch.

LeetCode-“lite”

Many companies say they’ll test you on algorithms and data structures, but insist that “it’s not LeetCode”. What they mean is that it’s not a specific LeetCode problem. But the only way to practice for these kinds of exercises is, you guessed it, practicing LeetCode.

Fundamentals

This is a broad category of problem where you’re asked to demonstrate something like concurrency skills, debugging skills, or testing skills. This is where AI tooling really shines in creating practice questions, with a little guiding hand.

API design

API design is a pretty uncommon format. It’s closer to a system design exercise, except you’re expected to show some code. You’ll be asked to design protocols to effectively implement a feature or system.

Modern tooling makes it easier than ever to drill problems.

Agentic CLI tools like Claude Code and Codex will trivially generate sample projects for you and enable you to work through dozens of problems to practice your fundamentals, or develop your skills with a framework such as GCD.

Alternatively, it is helpful to poke holes in your own code, highlighting flaws, sloppy code, or missed edge cases.

Drilling random challenges train you to tackle unknown problems and allows you to shine in the interview.

Now I’ll give a worked example of each category of problem, sharing the sample code so you can drill for yourself. When you’re ready, you’ll have the power to generate and grade your own drills.

Upgrade to unlock this article, plus much more:

🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

Read more

I’m no stranger to taking some heat when publishing my work. I got crucified for Apple is Killing Swift, and annoyed a lot of people with 2025: The Year SwiftUI Died.

My 3rd-most-controversial post might surprise you: Swift Enums 🤝 Design Systems. It was a friendly little number where I talked about my favourite approach for building design systems in SwiftUI, with a progressive-disclosure-inspired approach to my view component initialisers.

This reads like pretty reasonable stuff, until the terminally-online permafrost of SwiftUI zealots read it and admonished me: “This is not idiomatic! You should be using view composition!”

They’re not wrong. My approach is not idiomatic. It’s pragmatic.

But you should really decide for yourself.

So I’m going to take my opinions and put them in my pocket, and coldly present the two approaches you can apply while building a design system in a large-scale SwiftUI project. You should use the approach that works for you.

• Design Systems

• The Sample Project

• How to Composition

  • Custom ButtonStyle

  • Shared Components

  • Composition in action

• Progressive Disclosure

  • The Initialiser

  • Progressive Disclosure in action

• The Really Important Things With Design Systems

  • Keeping the design system simple

  • Extensibility

  • Documentation

  • #Preview

  • Is it marginal?

• Last Orders

This week, I’m offering my 2-eBook concurrency bundle for 55% off

📘 The Complete Swift Concurrency Toolkit explains every facet of Swift Concurrency from async/await to the latest Swift 6.2 actor isolation changes.

📕 Advanced Swift Concurrency Training takes you through 12 increasingly complex real-world problems, allowing you to lock-in practical knowledge.

By the end, you’ll have a finely-honed concurrency killer-instinct.

Get the Swift Concurrency Bundle for $29

Claim your free month to unlock this article, and much more:

🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Get 30 day free trial

Read more

I love SwiftUI; I hate SwiftUI.

I love UIKit; I hate UIKit.

When you’re as suggestible as me, it’s easy to be swayed based on the last blog post you read.

SwiftUI has forever been on a long journey to parity with UIKit, and the question of “is SwiftUI production-ready” has had a clear answer for years: Yes, but.

Yes, but you will need to drop down to UIKit for stuff like the Camera.

Yes, but some functionality like UIScrollViewDelegate scroll velocity is missing.

Yes, but performance on an infinitely-scrolling feed will never be as good.

Performance.

Specifically, scroll performance.

At one time or another, we’ve all sat under the thumb of an imperious product manager or QA tester, demanding the single frame drop on their nan’s iPhone 4s be eliminated before you can go home.

But they do have a point:

Performance is the final bastion of native iOS supremacy.

You don’t want to hear it, but if we get comfortable shipping apps with noticeably mediocre performance on scroll-heavy screens, we might as well ship with React Native.

iOS 26 crosses the rubicon: in WWDC 2025’s What’s New In SwiftUI, Apple spent half the runtime explaining the improvements they made to List updates and scroll performance more widely.

Sponsored Link

How iOS apps actually make money

RevenueCat’s State of Subscription Apps report is out, analyzing 115,000+ subscription apps and more than $16B in revenue. Use it to benchmark your pricing, trials, and conversion rates against what’s actually working across the app economy.

These improvements aren’t theoretical: Thomas Ricouard’s Ice Cubes app saw a substantial not-to-sniff-at drop in the scroll hitch rate since building against the iOS 26 SDK in version 2.0.0.

Let’s put Apple’s claims to the test in the ultimate head-to-head battle of the scrolls.

SwiftUI vs UIKit.

We’ll find out, once and for all, whether SwiftUI has hit parity on performance.

Subscribe now

• Designing the most ridiculous scroll view I can imagine

• A fair test

• SwiftUI performance (feat. List)

  • Animation performance with Instruments

  • Memory, CPU, and thermal profile with Xcode

  • The SwiftUI Performance instrument

• UIKit performance (feat. UICollectionView)

  • Animation performance with Instruments

  • Memory, CPU, and thermal profile with Xcode

• The Elephant in the Room

• What the future looks like for SwiftUI

• Last Orders

Designing the most ridiculous scroll view I can imagine

If we want to meaningfully understand the performance characteristics of SwiftUI and UIKit scroll performance, we need to really put them to the test.

If you’re just rendering a simple storefront with a carousel of images, maybe with some text on each cell, then this isn’t the article for you. Both frameworks are probably fine.

But today I’m making the most complex scrolling feed I can imagine in SwiftUI.

What requirements are needed to make a UI truly ridiculous?

• High resolution images.

• A complex view hierarchy of elements, text, and gradients.

• Permanent autoplaying animations.

• Variable-sized cells to force layout re-computation on cell reuse.

• Multi-gesture UI interaction that update a data store in real-time.

But how can we achieve this?

I have an idea. With a little help from my friend, 2001’s 22,000 Animated Gifs CD-ROM.

Uh, so this disc image is from 2001. I need to mount the .iso somehow… macOS won’t play along. You know what, this is below my pay grade. I’m gonna get Claude to dump it out and export me a folder of .gifs.

Throwback to the early 90s when dancing baby was literally the funniest meme ever.

Now we have our secret sauce, I can build out twin chaotic UIs in both SwiftUI and UIKit.

These gifs are bananas. And yes, I do pronounce it just like you.

The complexity of this UI forces the screen to aim for the high-performance 120fps refresh rate, giving just 8.33ms to render each frame. There is no hiding from this in my performance profiles.

So.

Once and for all.

Is SwiftUI finally as performant as UIKit?

Subscribe now

A fair test

I’m a scientist.

Well. Kind of. I did a physics degree.

Did I drop out of my masters into the 3-year bachelor course? Yes. But only because I’m smart enough to know that I’m not smart enough to do a masters.

I digress.

To ensure a fair test, we want to control the extraneous variables. (Or is it confounding variables? I digress. Again).

Anyway. I’m running everything on my iPhone 17, with iOS 26.1. You can complete the exact same tests yourself to corroborate (or deny!) my results, using the open-source project:

Download the project

Honestly, this is worth doing purely to see the menagerie of retro gifs.

To go further with controlling variables, I shared as much code as practicable. About half of the code was factored into a shared public module, including the @Observable view model used by both the UIKit and SwiftUI feeds.

I also used a third-party library, SwiftyGif, to handle gif animations. I wasn’t enormously happy to wrap the gif in a UIViewRepresentable to expose it to SwiftUI, but the small overhead incurred here was massively preferable to using an entirely different library. Known error bars and all that.

I applied a few basic performance tricks to ensure we’re putting our game face on with both UI frameworks:

• We’re caching images via NSCache (with a reasonable ~300MB limit to avoid eating all our memory).

• We’re paginating our data (even though it’s all local) to avoid overburdening our view model on load.

• I compressed the larger background images to avoid unnecessarily heavy decoding.

• I am using the @Observable macro for the shared view model to ensure data flow behaviour is identical.

• When moving our gif stickers around via gestures, we only write changes to the model state when the gesture ends (via updateSticker), rather than per tick.

Now let’s run the experiment.

SwiftUI performance (feat. List)

Last year I wrote a popular piece profiling the various approaches for building a scrolling feed on SwiftUI. After testing out VStack, LazyVStack, and List, I confirmed that List was the undisputed king when it comes to SwiftUI scroll performance.

We built out this List here to design our feed UI.

Now let’s begin profiling.

Animation performance with Instruments

We find Instruments from the Xcode > Open Developer Tool menu. To profile animation performance, the Animation Hitches instrument is pre-packaged with profiles for Hitches, Hangs, Display Sync, and Time Profile.

I ran the same test a few times:

• Loaded the app up.

• Scrolled slowly.

• Began scrolling more quickly.

• Scrolling very rapidly, up and down.

• After 10ish seconds of this, I moved and resized some gifs with gestures.

I have crappy perception, so didn’t rate my ability to feel minor animation issues. But during my first run, I felt two very noticeable hangs, where the UI was briefly unresponsive betwixt tap and scroll.

But this wasn’t the half of it. Once I looked at my proper instruments trace, I felt like the detective barging into a Jack The Ripper’s crime scene.

• 78 hitches (frame drops) in 24 seconds of running.

• 2 severe hangs (unresponsive UI) of ~2 seconds each.

This was consistent across multiple runs. Average hitch duration was just over 24ms, meaning ~3 dropped frames per hitch. The UI threw up 3.4 hitches per second. Given that I struggled to perceive this, I should think about going to Specsavers.

You can see clusters of red lines on the Hitches trace, representing more frame drops where I was scrolling more rapidly.

Memory, CPU, and thermal profile with Xcode

So scroll performance wasn’t great. Let’s look at some other important performance metrics, this time directly in the Xcode debugger.

Memory usage wasn’t dramatic, but was interestingly spiky. Perhaps due to the different numbers of gifs and different resolution of the images rendered on each cell.

CPU and thermal performance was a whole ‘nother story: it’s clear now why we had so many hitches. Even at rest, no scrolling, the CPU screamed at 100% capacity to render every gif, and well past 100% (distributing work across CPU cores) when I scrolled.

The “Very High” energy impact rapidly heated my device. The measured thermal trace crept up towards Serious. When I wasn’t paying attention, the app was even killed by the OS, presumably hitting a critical thermal spike.

The SwiftUI Performance instrument

Okay, so that wasn’t ideal. But, hey, look, new instrument!

Okay. This isn’t really relevant to this test, but it is nice. For Xcode 26, Apple created a brand-new tool for debugging slow View computation updates in SwiftUI.

As you can see here, highlighted view update issues neatly coincide with UI hitches.

In production, this is another wrench in your tool-belt you can use to tweak heavy SwiftUI bodies. It even includes a cause & effect graph so you can see exactly what state changes trigger re-renders.

Subscribe now

UIKit Performance (feat. UICollectionView)

Okay, so our SwiftUI List didn’t work fantastically when faced with a paginated scrolling feed, containing high-res images, gradients, animations, gesture-based interactions, and a ton of gifs.

What is the state of the art for achieving this in UIKit? The UICollectionView.

Let’s jump straight into the profiles.

Animation performance with Instruments

I did the same set of tests, the same number of times. Load, scroll, scroll faster, and play with the gifs.

I freely admit I’m not enormously perceptive, but there was something there. The SwiftUI one, even before looking at the trace, and experiencing the UI freeze, felt unexplainedly… off.

UIKit version had no such problems. This is some Unreal Engine 5 sh*t. Just… no part of my subconscious lizard brain was screaming while I scrolled.

When it comes to the actual Instruments trace, UIKit is almost showing off.

Across my tests, I measured 0.7 hitches per second (compared to 3.4 for SwiftUI).

Average hitch duration was the same. No hangs were detected, but there were a couple of brief (38ms) interaction delays, highlighted in grey.

Memory, CPU, and thermal profile with Xcode

When it came to profiling peak memory and energy usage, I expected the same kind of results I saw in SwiftUI: We’re still displaying an enormous number of elements, animating them the same, and these images are not any bigger or smaller, right?

Now don’t I look silly.

Memory usage hovered around 92MB for UIKit, compared to 248MB in SwiftUI.

After giving a serious beating to my shiny new A19 chip, the same feed in UIKit produced comparatively nearly trivial CPU and energy usage.

• At rest, UIKit dropped as low as 11% CPU utilisation, vs a consistent 100% for the SwiftUI version

• Energy usage correspondingly held at High for UIKit, vs Very High for SwiftUI.

I gave up waiting for the thermal profile to hit Fair after 3 minutes.

The Elephant in the Room 🐘

Even in iOS 26, SwiftUI is dramatically outclassed by UIKit when it comes to scroll performance of very complex UIs.

But why is this performance different?

Perhaps you’re thinking what I’m thinking.

Isn’t List implemented via UICollectionView under the hood?

Here’s our UIKit version, in the view hierarchy debugger, resplendent with our manually-crafted UICollectionView:

The SwiftUI screen contains a mysterious UpdateCoalescingCollectionView.

So it’s not a vanilla collection view. And the performance is drastically different.

SwiftUI’s performance characteristics are constrained, fundamentally, by its architecture. I’ve always been saying that the beautiful, reactive, automagical data flow out-of-the-box comes with a cost:

• State changes cause SwiftUI to re-compute the body of affected views, perform diffing, and potentially calculate layout, before committing changes to be rendered. Apple can optimise this to death, but it’s never not going to add overhead.

• Although List applies cell reuse at the UIKit layer, this does little to mitigate costs: SwiftUI has already re-computed and reconciled the view hierarchy before reused cells are reconfigured with new data.

• Even List, the paragon of high-performance SwiftUI, incurs bridging overhead. We can see this directly in the view debugger with UpdateCoalescingCollectionView.

• SwiftUI rendering is gated behind unidirectional data-flow. Moving a gif around changes its @State properties and forces a view re-computation. UIKit offers a shortcut: you can just transform the view itself, no abstraction.

Subscribe now

What the future looks like for SwiftUI

Mastodon went wild recently over a rumour shared by Steve Troughton-Smith:

🗣️ I do enjoy a good rumor, so I’ll share this nugget:

I have heard that SwiftUI has been losing political capital, and credibility, internally at Apple because it has repeatedly failed to meet software engineering goals, and needs. It’s no longer thought of as the clear default choice for new stuff.

That might explain why it was deemphasized at WWDC compared to the past few years.

Spicy stuff.

I look forward to the next edition of Apple’s internal use of SwiftUI by Alexandre Colucci. We can cross-reference whether this rumour is substantiated by seeing whether the SwiftUI usage has plateaued across the internal iOS binaries.

Last Orders

In my experience using SwiftUI heavily at 5 companies, I’ve found that it’s really brilliant if you have a very understanding product or design team, who are happy for you to push back on certain design aspects, and compromise a little on detailed rendering minutiae.

When there’s a company-wide focus on UI performance, you’re going to have a bad time. You can do irreversible damage to your app architecture by pivoting away from SwiftUI after years, and incur cognitive overhead from switching between architectures forever into the future.

The biggest advantage of SwiftUI has always been the fast, easy-to-write declarative syntax. But with the rise of Agentic Engineering, the annoying overhead of writing programmatic UIKit code is negligible.

I hate to be the one to say it, so please do my job for me and whisper this quiet affirmation as you go into work this week:

“SwiftUI is dead. Long live UIKit.”

Sponsored Link

How iOS apps actually make money

RevenueCat's State of Subscription Apps report is out, analyzing 115,000+ subscription apps and more than $16B in revenue. Use it to benchmark your pricing, trials, and conversion rates against what's actually working across the app economy.

If you liked my post, subscribe free to join 100,000 senior Swift devs learning advanced concurrency, SwiftUI, and iOS performance for 10 minutes a week.

Subscribe now

Not convinced yet? If you enjoyed this topic, consider taking a look at my related posts:

The best-paying tech companies administer a system design round as part of their final-stage interview rounds. This interview, the successor to the classic whiteboarding exercise, challenges you to architect a complex system on iOS:

• Show me how you’d architect an encrypted messaging app.

• Demonstrate how you’d structure a news feed on a social app.

• Design an SDK fit for a large analytics company.

There are virtually no resources online (aside from expensive coaching) that teach you to tackle these interviews for iOS roles.

Until now.

I went through an extremely intensive interview grind at the end of 2025, and faced down three system design challenges at three different companies. I’m coming to you today with personal, hard-won experience.

The real meat and potatoes here is a full worked example: a real system design interview, demonstrating what you can expect from a system design round today and how to tackle the problem. For dessert, I’ll highlight all the parts of prep work that were actually useful, so your own grind can be efficient and (mostly) painless.

• A framework to structure every interview

• A full worked example based on my recent interviews

• Miscellaneous practical tips to help you prepare

• Common client-side design concepts I didn’t know about

• Last Orders (and a handy cheat sheet)

A framework to structure every interview

A lot of interviewers these days will try to pretend that your interview is a casual chat. Don’t be fooled. Obviously, act natural, smile, but it will never hurt you to introduce some formality via a framework.

A framework is a simple structure you can follow to answer the problem. A reusable way of arranging your thoughts while you design the system. The framework goes like this:

• Scoping

• Functional requirements

• Non-functional requirements

• Data model

• API design

• High-level design

• Drill-down questions

With system design, “measure twice, cut once”. You must understand the problem space and what needs to be designed before you draw anything.

As iOS developers, it’s tempting to dive straight into SwiftUI vs UIKit, MVVM vs MV vs VIPER, and your favourite concurrency toolkit. That’s a dangerous game: the system design interview is far more about data flow and structure than UI or frameworks.

Now let’s look at a full worked example of an interview, demonstrating how to tackle the interview systematically. This might be the best prep out there, because it’s based on three of the real final-stage panel interviews I did last month.

My worked example takes you through the most popular system design question out there today.

By the end, you’ll have the confidence to tackle your own iOS system design round.

Upgrade to unlock this article, plus much more:

🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

Read more

Writing online is a lot like creating content on OnlyFans.

And I’m not just saying that because I’m very sexy.

I’m saying that because it has a strict power-law distribution.

There are several big names at the very top of the leaderboard that pull in millions of dollars a year. On the other side, there’s an incredibly long tail of people who make almost no money, perhaps with a tiny number of paid readers and/or simps.

Between the extremes, a quiet middle class at #88 on the technology leaderboard who are probably pulling in something like minimum wage (p.s. that’s exactly where I’m at, hence my recent job-hunt).

This power-law distribution shows up everywhere. In software engineering, it manifests in the complexity of problems that we work on day-to-day. There is a very long tail of everyday “build this screen” or “investigate this bug” that you can largely perform on autopilot.

There are regular mid-level challenges in the middle, that crop up every month or two: profile this subtle performance problem, or help architect this new feature.

Once in a blue moon; maybe just once in your career; you have to pull off something nobody’s built before. Something with so many moving parts it needs constant work to prevent it overwhelming your team.

This rare peak challenge is what I’m bringing to you today. The hardest engineering challenge I have ever faced. A one-of-a-kind feature that orchestrated an automated, client-side, comprehensive, high-volume data ingestion pipeline.

• Webscraping a third party service

• Long-running downloading jobs

• Parsing and storage for ~200MB of data

• Real-time data analysis

• High-volume data upload and polling

• And, finally, the year of whack-a-mole to keep it working

Building a reliable system on top of an unreliable system is always quite traumatic, so please excuse my occasional abrupt screams as I write this.

The original pipeline allowed you to fetch your Google data, which could reach Gigabyte scale for each user, the root of much of the complexity. For this example, however, I’m doing the same thing with my Spotify data, because open-sourcing my music search history in the sample project will be less likely to get me arrested.

I didn’t build this bad boy from scratch. This system was inherited MVP form, by an engineer who is a lot more intelligent than me. I did, however, have the pleasure of spending a year hardening the pipeline from a neat (but fragile) pipeline into a battle-hardened production system that worked robustly.

This article comes complete with the full sample project, demoing the whole pipeline in its glory (with companion server code!)

Come and see the man-made horrors beyond your comprehension.

Paid members get the full article, and a lot more:

🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

Read more

The last 6 months have been the most tumultuous period ever in the field of software engineering. More than compilers. More than the internet. Maybe even more than the transistor.

In late 2025, a Rubicon was crossed. In March last year, we all laughed at the Anthropic CEO for his prediction that “within 6 months, 90% of code will be written by AI”. Today, among software engineers, there are 2 camps emerging:

• Default to AI, with a vast majority of code not hand-typed.

• Still hand-coding by default, pasting into chat windows for help.

I’ve heard this story more than once: a very senior, serious engineer at a company will trial AI for the first time, with a big refactor. After a few days, they’ll debrief the team, explaining that it isn’t quite what it’s cracked up to be, and a distraction. The punchline is they were using f*cking Copilot.

I had a recent, quite eye-opening, Twitter exchange: someone claimed “AI is bad at programming”, then proved it by showing me a half-baked prompt in a web chat, asking about a Steam API, and getting a hallucinated response.

This was insane to me! How did this person not know to open Codex in a terminal, set high thinking mode, paste the link to the relevant documentation, and ask it to make the change in your codebase!?

To use AI tooling effectively, you need experience. Specifically, finding a workflow that is effective for you. I became proficient with Claude Code over summer, and rapidly my entire daily workflow changed around it.

But things have moved really fast.

My default approach: “big detailed prompt, oneshot, then optimise” is great for sample projects and takehome tests, but is weaker for larger, more complex projects.

I need to optimise my workflow some more.

So.

Today I’m going to revisit the state of the art, address any FOMO you might have from boycotting Tech Twitter™, and discover the novel techniques I’m missing. Specifically, what’s useful for iOS development.

Next, I’m going to set up the workflow used by Boris Cherny, the guy who invented Claude Code, a “vanilla” approach involving orchestration between 15 parallel agents.

Finally, I’ll test drive this approach by building an app I first envisioned in 2020: Maxwell.

Sponsored Link

RevenueCat Paywalls: Build & iterate subscription flows faster

RevenueCat Paywalls just added a steady stream of new features: more templates, deeper customization, better previews, and new promo tools. Check the Paywalls changelog and keep improving your subscription flows as new capabilities ship.

Contents

• The State of the Art

  • The Best Models

  • MCP, Verification, and Xcode 26.3

  • Multi-agent and Orchestration

  • AGENTS.md and Skills

  • Teleporting Sessions to the Web

  • Tab Completion

  • The Ralph Loop

  • OpenClaw (aka Clawdbot)

• Cargo-Culting the Creator of Claude Code

• Building Maxwell in an afternoon

• Last Orders

The State of the Art

I already wrote about my early agentic workflow in September 2025. It’s a good piece. If you are unfamiliar with using agentic AI to code, it is a great introduction.

But there are a ton of new developments, innovations, and tools in the GPT-5.2 and Opus 4.5 era which massively impact your day-to-day, especially in iOS.

Let’s cover some:

The Best Models

Codex (5.2) and Claude Code (Opus 4.5) are the best models by far.

At the time of writing, gpt-5.2-codex is unambiguously the best, thinks carefully, and makes fewer mistakes than other models.

Update the Friday before this published:
Opus 4.6 and Codex 5.3 just came out! The jury’s out on which is better. This will be me over the weekend:

You can also configure the reasoning level which gives the model extra time to reason through a problem and think about each step carefully. I get really good results by defaulting to High.

If you start to run out of weekly credits, you might consider dropping down to Medium. This will lead to a lot of really dumb mistakes…

My beautiful team of crack nerds locked in a basement turns into a dim primary school class that can’t be left alone for 30 seconds.

I guess I need to upgrade my plan.

MCP, Verification, and Xcode 26.3

One of the most critical missing links in an AI workflow, especially on iOS, is a way for the agent to autonomously verify its work.

You can verify via compiles, running unit tests, or manually on the simulator.

Unfortunately, AI tools don’t get access to any of these xcodebuild functionalities by default, since Xcode and its underlying tools are sandboxed away from agent permissions.

That’s where XcodeBuildMCP (by camsoft2000) comes in: it enables agents to interact with Xcode tools, including compiling your code, testing, and even interacting with features in the simulator (though recently agents have learned to at least compile).

Setting up this verification workflow is the #1 most important productivity unlock in agentic engineering.

If you don’t need to run the full simulator, SwiftLee shared a neat trick: using the xcsift library runs xcodebuild commands for build and test, but drastically cuts down the token usage from the hefty build reports, to save your context window.

And, naturally, I have to mention the biggest, hot-off-the-press-the-paper-is-still-warm announcement: Xcode 26.3 and agentic coding.

Xcode 26.3 introduces its own first-party MCP support for verification, as well as introducing a support for Claude Code and Codex agents directly inside the GUI. I can only hope their harness doesn’t suck.

You can set up the MCP for any agent using these docs.

Multi-agent and Orchestration

We’ve picked the best model, set the reasoning budget to “high”, and now we have the agent automatically verifying its work via XcodeBuildMCP. Amazing!

But now it’s taking 10 minutes to work after being asked to make a change.

How can we handle this latency? We introduce a multi-agent workflow!

This is exactly what it sounds: running multiple instances of the CLI and context-switching between tasks as they work in parallel.

Orchestration takes this further, automating multi-agent workflows via open-source tools. They spawn specialised agents under a supervisor with shared memory, task decomposition, and handoff, creating separate agents for tasks like planning, coding, testing, and review.

In my experience, multi-agent is very good and productive, with the engineer as the orchestrator. Automatic orchestration is a little too rich for my blood, but you can read this great post about Gas Town if you want the full scoop.

Unfortunately, on iOS at least, multi-agent and automatic verification can cause problems: with XcodeBuildMCP, only one build is allowed at once, and you can run into annoying DerivedData build errors with two simultaneous builds.

Setting your terminal client to send notifications is a godsend with multi-agent, because you can immediately jump to the tab with completed tasks and re-prompt.

AGENTS.md and Skills

The open-source community has been taking iOS pain points and documenting them for posterity. Paul Hudson open-sourced an AGENTS.md file designed to guide LLMs to shed bad habits and write more idiomatic SwiftUI. Unfortunately, it’s not had a ton of community input since release.

What I was surprised by, is that the agents have become GOOD at following and remembering instructions in this file in the last few months. To the extent where it’s nearly pedantic: no, you don’t need to write a plan when I ask you to checkout a new branch.

They are also great at using their skills without being asked:

Codex and Claude Code have Skills, a feature that allows you to pre-package instructions, resources, and scripts to improve performance on repeatable workflows

Thomas Ricouard (legend) has open-sourced a number of skills useful in iOS including SwiftUI performance auditing, SPM app packaging, and Swift 6.2 Concurrency adoption.

What Codex 5.2 does better than any model before: it actually reliably uses skills when appropriate, and follows the instructions you configure. You can set up your AGENTS.md file with a specific workflow:

• Always pull main and check out a new branch before work.

• Always document a plan and get my sign-off before changing code.

• Always verify your work via compile/test/run with XcodeBuildMCP.

And it will follow this to the letter!

Recently, sites like skills.sh have collected together open-sourced skills in a discoverable format, making them installable via a simple shell command, like this:

npx skills add https://github.com/avdlee/swiftui-agent-skill --skill swiftui-expert-skill

Annoyingly, Anthropic still hasn’t bothered to adopt the standard AGENTS.md and .agent/skills formats yet, but you can create a simple file-path alias inside your CLAUDE.md pointing at the main file as a source of truth.

Teleporting Sessions to the Web

Claude Code and Codex live in your CLI. But they can also live in the cloud!

Paid users can connect their GitHub repos to their web client at claude.ai/code or chatgpt.com/codex to get that lovely agentic goodness on-the-go

The win here isn’t immediately obvious.

But consider the workflow it unlocks:

• Set up your team, including non-technical, with Claude Code or Codex.

• They find a bug and report it directly in a Codex session via the iOS app.

• An agent could potentially diagnose the issue, fix it, and create a PR.

Claude Code goes one step further: the teleport command enables you to jump a running CLI session to a web session. This is useful if you wanted to keep track of your agents at the work do, on the loo, or perhaps on a date with your boo.

Tab Completion

Cursor is arguably the most successful AI application out there, allowing devs to pick between GPT-5.2 and Opus 4.5 models in a VS-Code-forked IDE.

But I kind of always felt iffy about it.

But when I tried it in early/mid 2025, it was objectively quite sh*t.

It was useless at gathering context across more than a trivially small codebase, and felt like it throttled, or perhaps lobotomised, the underlying models to squeeze them into a $20/mo subscription fee.

But I need to revisit it at some point, because people say it’s the gold standard for manually programming these days.

The Tab Completion workflow is considered both fast and accurate, often suggesting what you need. Just tap Tab to accept.

The Ralph Loop

Ralph, and yes it’s named specifically after Ralph Wiggum, is a plugin for getting your agent to continuously work until it’s actually finished.

When Claude Code finishes working on a task, the plugin stops it from completing, and re-sends the original prompt. It forces the agent to run in a loop until it converges on an optimal output.

The core idea is that a good prompt and multiple iterations on the same code tend to produce better results than one-shotting, as long as Claude Code can verify its work via tests or builds. The plugin itself automates this process, while also helping stop the loop from accidentally eating through all your credits.

I don’t have a dog in this fight, but some people reckon that using a plugin to force Claude Code to verify its work is unnecessary when Codex can get it right first time.

OpenClaw (aka Clawdbot)

A recent project by the legendary Peter Steinberger took the internet by storm early this year. But, frankly, it took me a very long time to understand what it was.

In short (I’m criminally underexplaining here), it’s Claude + Memory + Texting. It links to messaging apps like WhatsApp or Telegram, and allows you to chat to the agent while on a date with your wife. Finally.

People have bought Mac Minis specifically for this (you can just as easily get a Hetzner box but that’s no fun) and, to listen to them, found God (or at least AGI). Someone claimed their agent paid for a phone number from Twilio, connected to the ChatGPT voice API, and rang the user.

It’s probably little ill-advised to give your credit card details to a robot, but it’s hella cool.

Cargo-Culting the Creator of Claude Code

The first cargo cult originated in world war 2. Pacific tribes saw planes stocked with supplies and food landing, and began ritualistically imitating allied military practices in the hope of getting more planes to come with more supplies.

“Cargo cult” is also my favourite metaphor in tech. It describes the classic fallacy:

If we copy what big tech companies do, we will become a big tech company.

Developers love introducing complexity, and need to be constantly hit to prevent them from introducing custom build systems, proprietary UI frameworks, and re-architecting to VIPER. Solutions designed for problems “at scale”, meaning tens of millions of users, and not a team of 3 devs in a basement.

But, sometimes, it can be handy to find out what the big boys are doing so we can cosplay.

So I’m going to replicate Boris Cherny’s Claude Code workflow. Along with some of the new techniques we learned about earlier.

What is he doing?

1. Running 5 Claude Code instances in parallel on the terminal

2. Regularly teleporting to sandboxed web sessions for background processing

3. Sticking religiously to the slowest, smartest thinking model

4. Maintaining a single, big, shared, CLAUDE.md in the repo

5. Using Github Actions to update CLAUDE.md as part of PRs

6. Starting sessions in plan mode, refining, then one-shotting

7. Creating slash commands for commonly-used workflows, e.g. commits

8. Using a few subagents for specific workflows, e.g. verification or simplifying

9. Using a PostToolUse hook to run linting on generated code

10. Avoid --dangerously-skip-permisisons, but allow permissions in settings.json

11. Configure MCP to interface with tools like Slack and SQL using mcp.json

12. For long-running tasks, ensure Claude verifies its work in the background

13. Solid verification is critical: tests, iOS simulator runs, or bash scripts

Alright, let’s put this cargo-cult to the test, and build the one that got away: Maxwell.

Oh, and he actually tweeted again recently. Things do move fast.

What now?

1. Use worktrees (or just multiple git checkouts) to run agents in parallel

2. Always start with a plan, then get another agent to review the plan (personally I like to pit Claude Code against Codex!)

3. Ensure your AGENTS.md/CLAUDE.md is updated every time an agent makes a mistake

4. Create skills regularly and commit them to git, especially common daily tasks

5. Use Slack MCP to directly tell @Claude/@Codex to fix a bug and make a PR

6. Utilise these pro prompts:

   1. Ask the agent to grill you on changes so you understand

   2. After a mediocre fix, tell it to scrap the change and re-implement

   3. Write detailed specs with minimal ambiguity before handing off work

7. Customise your terminal and utilise voice dictation (WisprFlow is best!)

8. Subagents can be useful to get more compute or preserve your context window

9. Agents can connect to analytics and databases to answer questions

10. You can have the agent explain the “why” behind the changes, and even present visual diagrams explaining your codebase.

Building Maxwell in an afternoon

Maxwell was conceived as part of a team building exercise, where we pitched a novel business idea. After discarding my original idea of anti-covid-branded hand sanitiser, I pivoted.

I’d just moved into my first home, and experienced the annoying hassle of lightbulb management for the first time. Lights are everywhere, bulbs fail intermittently, and there are dozens of fittings, styles, and colour temperatures you need to understand if you want to replace them.

Maxwell was born.

Map out the lightbulbs in your home. Track what needs replacing. And automatically replenish them.

24-year-old Jacob never got this off the ground, because in a shocking evolution of his maturity, he actually tried to verify the business side before building anything.

Unfortunately, this verification didn’t get much further than an email to B&Q customer support and an InMail to their CEO. He tried.

Because he wasn’t able to get the drop-shipping side to work, he put the project on the permanent backburner.

Until now.

Er, hold on.

Okay, disregard what I said, I totally tried to build it back in 2020.

I hazily recall my quixotic quest to build a lightbulb fitting classifier ML model using CreateML. My rush to implement Stripe payments before even a hint of revenue. My zealot-like insistence on using Carthage as a dependency manager.

I also found my old logo!

The only half-valuable thing I got out of my Apple Pencil.

I’m putting my updated workflow to the test to build out this project:

• I did all this work in Codex using the gpt-5.2-codex high model.

• I set up XcodeBuildMCP with the intention of verifying all my work autonomously via tests and simulator runs.

• The repo contains some open-sourced AGENTS.md, slash commands, and skills for SwiftUI and concurrency review.

• I’m going to aim to run 5 instances of Codex in parallel, numbered, with each CLI window pinging me via system notification when they finish.

• For each instance, I’ll carefully plan each feature before trying to one-shot.

• I’m going to set up web sessions via the ChatGPT app and attempt to ship some QA fix PRs while eating dinner.

• If I have time, I might install Cursor and implement some manual fixes, with my fingers, like it’s the 1970s.

Here’s the full project!

The sample project on GitHub

Well, it’s not exactly finished, but I trust you not to PIP me.
Pretty good for an afternoon’s work, I reckon.

Last Orders

I spent summer diving headfirst into agentic engineering using Claude Code (and later, Codex), realising they were finally very, very good.

But they have not stopped in the last 6 months. I suspect I’ll have to make this a semi-regular post to ensure we stay ahead of the curve!

Frankly, while multi-agent workflows are the current razor’s edge for productivity, it’s actually a deeply suboptimal workaround to latency. If high-thinking-budget inference ran 100x faster, we would not need to perform this context-switching, and could simply roll a single agent as the fully-engaged human in the loop.

I reckon that’s where the next 6 months is going to go.

If you liked my post, subscribe free to join 100,000 senior Swift devs learning advanced concurrency, SwiftUI, and iOS performance for 10 minutes a week.

Subscribe now

Sponsored Link

RevenueCat Paywalls: Build & iterate subscription flows faster

RevenueCat Paywalls just added a steady stream of new features: more templates, deeper customization, better previews, and new promo tools. Check the Paywalls changelog and keep improving your subscription flows as new capabilities ship.

“Interview grind? Huh?”, I hear you say from your screen, in the future, “I thought you were going independent?!”

Yeah, I thought so too.

Today’s post is one part life update, seven parts survival guide.

I’ll give a recap of where I got on my independence journey.

Next, I’ll share my experience working through 50 interviews in one month, and offer you practical advice for maximising your chances at passing each stage of the big tech interview process.

• My Going Indie Scorecard

• The job market

• CV optimisation

• Recruiter screening

• First technical round

• Take-home test

• The Panel Interview™

• Offer & Onboarding

• Last Orders

My Going Indie Scorecard

Before I tell you what’s new, let’s put together a scorecard of my 100 days as an independent creator:

My initial approach to shipping content: all bangers, all the time.

My first month of independence was spent artisnally crafting each new article over a full 5 working days. Each one of these pieces of content was a killer, growing my paid subcount by over a dozen apiece. Content Score: A+.

Riding high, I deigned to actually do a budget.

And… f*ck.

You’d think a digital services business would have phenomenal margins, but costs like EU VAT, transaction fees, blog hosting fees, and income tax added up quickly.

Break even would be tough. Optimistically, maybe in 8 months, if my growth rate stayed at the maximum. Maybe I could do this before running out of money. But this is kind of a dumb risk when I have a wife, a mortgage, and 2 young kids.

War Stories landed me some great content, and was a brilliant excuse to connect to other prolific creators. You should definitely read my interviews if you haven’t had the chance! I will definitely continue to do more of these.

My Creator Spotlights collab with fatbobman also went ahead, and netted some nice cross-pollination with our mutual readership of iOS devs.

These collaborations produced some solid content, and allowed me to share some very fun war stories. My strategy, however, was about growing my free subscriber base significantly, and unfortunately I was not able to move the needle enough for this to bootstrap my independence. Collaboration Score: B-.

My experiment with paid acquisition was a big success in terms of scaling my readership, with my cost-per-acquisition down to (something like) $2 per inorganic free subscriber. These have translated into exactly zero paid subscribers (since I fixed my UTM tags last month). Paid Acquisition Score: C.

Tavern Tools™, my beautiful vision for a dev tools suite, was aborted before I began. I realised it was a giant distraction from growing my free base. My paid conversion rate was already sitting pretty at over 5%, so I didn’t need to create extra incentives here. DevTools Score: D for “dunno”, as I never showed up to the exam.

One bright spot in my scorecard was netting a sponsorship deal (perhaps more? Watch this space!) to advertise on my blog with my friends at RevenueCat. However, it turns out that in the incredibly mature world of dev tools marketing, budgets can be tight for a new entrant. Sponsorship Score: B+.

Overall Grade: B. Must try harder.

In the crushing wake of my budget, I realised what I had to do. I had to find my white whale. And what is an employer, if not just one really big paid subscriber?

My Job Application Journey

Thus began my first foray into job applications since 2015.

My previous 3 job moves were through recruiters, and I’ve never had the luxury of treating the application process as a full-time job before.

The grind I underwent in December has given me insight into the state of the market, and finally given me the space to properly get ready for the tough interview loops that big tech companies apply to candidates.

Here’s my full stats: 26 applications. 2 offers.

For my kings and queens who write native iOS for a living: the market isn’t as bad as the startup winter of 2022. It’s healthy. There are a ton of well-capitalised AI startups hiring native iOS engineers, despite the narrative that cross-platform is eating our lunch. There are a lot of established companies growing their teams too.

That said, unless you live in an American city, there are not many FAANG jobs to go around. In London, the only “big” big tech co’s hiring for iOS at the end of 2025 were Snap (I got to the panel) and Meta (who ghosted me).

I’m kind of in a privileged position. I know the average engineer (who doesn’t run a popular blog) isn’t getting a >50% hit rate on the CV screening. But I can share a lot of useful knowledge from my interview grind that can help you out with every step of the process.

Upgrade to unlock this article, plus much more:

🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

Read more

I love working on app performance.

It just sounds cool. Performance. Performance.

While the bozos on feature teams are busy building stuff that actually brings in paying customers, platform engineers can feel smugly superior, typing away from our windowless basements, reducing launch time by 0.01 seconds. For everyone!

Unfortunately, if you don’t have a full-time platform team, “performance work” is generally treated the same as “tech debt tickets”.

Despite what app release notes will have you believe, no one’s going to give us time to work on performance optimisations, because a lot of the time it’s invisible. Everyone agrees that high performance is desirable, but it’s virtually impossible to quantify the impact of marginal improvements.

So how does this ever get done? And how do we stay on top of it?

There is a way. And if you can master the technique, it’s also a pretty good way to get promoted.

Be the dev that keeps a close eye on the Xcode Organizer.

There’s nothing better for your promo packet (and, for my indie readers, your own customers) than identifying low-hanging fruit, recent regressions, or serious performance bottlenecks; crafting a proposal to solve them; and allotting engineering time to solve it.

This is not theoretical; this is pretty much my standard playbook.

I’ll keep a watchful eye on the Xcode Organizer. I’ll flag to Product or Engineering leadership whenever I spot an opportunity to improve something that users will actually notice: Launch time, scroll hitches, terminations, battery usage, storage usage. All these issues often have fairly trivial root causes, and offer an outsized user impact once you solve them.

Xcode Organizer is easily where 80% of my performance optimisation work originates. If you’re on top of it, you can usually pre-empt user complaints.

Sponsored Link

Substack, which powers my newsletter, is hiring iOS engineers!

The team is small, close-knit, and provides ample opportunities for mentorship, growth, ownership, and autonomy. You can apply for either the growth team or the enterprise team. Check out their jobs page for the full list of technical and non-technical openings.

The Xcode Organizer

We can find the Organizer in Xcode’s Window menu.

Even if you’ve never touched the performance charts, you’re likely already acquainted with the Organizer, since it’s where all your Archives live.

If you’ve been in the indie game for a while, you’ll also experience a nostalgia tour of everything you’ve ever submitted to the App Store.

Oh dear.

I just realised; none of my apps have enough users to actually display any data here.

Stand by.

☎️ Thomas, help me out please! 📡

Famous Twitter personality and iOS engineer Thomas Ricouard generously took the time to share the performance stats of his indie app, Ice Cubes for Mastodon. Please show your appreciation by downloading it, either if you’re a Fediverse fanatic or even if you’re merely toot-curious.

Thomas also posted a really good piece recently on The State of Agentic iOS Engineering in 2026, which I massively recommend both if you’re new to agentic engineering or you’re already a Claudepilled Codex-cel.

You can get very specific when you look through the organizer. You can slice most of the reports by time, by device, and by version.

There are usually tons of low-hanging performance optimisation fruit at the top level, but if you have enough users, you can often spot OS-version, device, or version corner cases by narrowing things down.

Many performance attributes in the Organizer have both metrics and reports to investigate. Metrics are aggregated numbers sliced across all your users and versions, and reports surface individual code-level issues.

I think of the Xcode Organizer like the top of the performance funnel. You get fully aggregated metrics across your whole user-base. When you spot a problem, you can often go deeper with Instruments. Once you identify the bottleneck, you can then solve it in code and verify the improvement.

Now let’s look at how to apply each report in the Organizer to optimise your app’s performance today (and make you look like a hero in the process!).

Upgrade to unlock this article, plus much more:

🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

Read more