GCD, or Grand Central Dispatch, is one of the underlying frameworks of iOS development. It is to Swift Concurrency what UIKit is to SwiftUI: the crufty older sibling, underpinning decades of working legacy code, who still gets the job done.

You won’t encounter it so often on a brand-new project, but you’ll see it in many situations:

• Any codebase that maintains working legacy code from before 2021 will have heaps of GCD.

• When you are playing with fundamental frameworks like AVFoundation.

• A lot of job interview tech tests will use GCD in some way.

I had this exact situation last year as part of my recent job grind: a final-stage “Concurrency” technical test interview where I was told to swot up on Grand Central Dispatch in advance.

This heads-up was a lifesaver, allowing me to drill some classic concurrency problems, but in the interview I ended up spending most of my energy trying to demonstrate I knew the toolkit rather than solving the actual problem. Whoops.

I thought about calling this article “Practical Applications of Grand Central Dispatch in Modern Swift Code”, but I wanted to respect your intelligence and not bullsh*t you. This is a (heavily) spruced-up form of my revision notes. Perhaps it will help you the next time you need to grind for a concurrency test.

…and even more hopefully, the other iOS bloggers will stop bullying me for never having written a piece on GCD.

Sponsored Link

Can your mobile release handle AI-generated code?

AI multiplied the amount of code your team writes. The process that ships it hasn’t changed: same release trains, same quality gates, same manual handoffs. Join a live panel with mobile engineering leaders from Thomson Reuters, Mercado Libre and Salesforce to discuss how that volume changes the release process.

Nov 12, 10am PT / 1pm ET. Sign up here.

Contents

• The History of GCD (why it was important)

• How libdispatch works under the hood

• GCD Basics

  • Queues

  • DispatchQueue.sync and deadlocks

  • Quality of service

  • asyncAfter

  • Parallelism and DispatchGroup

  • Locks

  • Thread-safe reads and writes

  • Target queues

• Advanced GCD

  • DispatchWorkItem and cancellation

  • Flags and Barriers

  • Semaphores

  • Priority Inversion™

• Last Orders 🍺

The History of GCD (why it was important)

With the 1996 acquisition of NeXT and Steve Jobs, the NeXTSTEP OS was merged into Mac to create Mac OS X. Objective-C became the dominant Apple platform language. But it took a long time for Apple to figure out a nice concurrency API. For a decade, Mac devs made do with semi-manual concurrency management using POSIX threads.

This API included pthread_create(), pthread_join(), pthread_mutex_lock(), and pthread_cond_wait(), for developers to manage individual threads and handle concurrency. These low-level threads are the fundamental abstraction underneath NSThread, GCD, and even Swift Concurrency.

But these APIs were a pain to use: developers would need a lot of fiddly boilerplate to perform basic tasks like downloading an image in the background, getting it back onto the main thread, and displaying it:

static void *loadImageOnThread(void *context) {
    ImageLoader *loader = (__bridge_transfer ImageLoader *)context;
    // Slow, so off the main thread
    NSData *data = [NSData dataWithContentsOfURL:loader.url];
    // UI work back on main
    [loader performSelectorOnMainThread:@selector(showImageData:)
                             withObject:data
                          waitUntilDone:NO];
    return NULL;
}

- (void)loadImage {
    pthread_t thread;
    pthread_create(&thread, NULL, loadImageOnThread, (__bridge_retained void *)self);
    pthread_detach(thread);
}

- (void)showImageData:(NSData *)data {
    self.imageView.image = [UIImage imageWithData:data];
}

Most didn’t bother, leading to sluggish software across the board: a sea of spinning beach balls, as devs either locked up the main thread or failed to utilise their cores effectively.

As well as having poor devex, pthreads were expensive to create, reserved a surprising amount of memory (512kB, not that you asked), and had overhead any time you switched between them. POSIX gifted great power and great responsibility. Multithreading was a chaotic mess.

One of the surprising Hard Things™ with manual thread management is knowing how many threads to use. Too few, and you leave resources on the table. Too many, and you incur tons of thread-creation-and-switching overhead.

But how do you know what’s going on in the system? You can’t!

What on Earth were we to do?

Grand Central Dispatch, a.k.a. GCD, a.k.a.k.a. libdispatch, is a C library that lives deep in the OS. At its core, GCD maintains a “thread pool” of POSIX threads onto which it schedules work. These long-lived pthreads mitigate the overhead of constant thread creation and context-switching. Developers place work on dispatch queues, and let GCD handle the scheduling and thread management.

Now, the same image-loading task was as simple as this 6-liner:

- (void)loadImage {
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        // Slow, so off the main thread
        NSData *data = [NSData dataWithContentsOfURL:self.url];
        dispatch_async(dispatch_get_main_queue(), ^{
            // UI work back on main
            self.imageView.image = [UIImage imageWithData:data];
        });
    });
}

The rest of our examples will be pure Swift, but it’s useful to #KnowYourRoots.

GCD transferred thread management responsibility from developers to the OS, which works far better as the arbiter of “what work should run on what thread when”, since it has a full view of the system. The system knows whether other programs are competing for resources, or if you can go full throttle parallelising everything.

How libdispatch works under the hood

In Foundation, pthreads are more commonly wrapped in Thread (formerly NSThread). Context-switching between these threads is expensive, because the kernel has to:

1. Pause a thread running on a core

2. Store the state of its registers

3. Load up another thread onto a CPU core

4. Resume the work on the other thread

GCD introduced the “queue” abstraction, a lightweight FIFO approach that abstracted away the pain of individual thread management and scheduling. Queues are extremely lightweight: just 128 bytes. You can spawn thousands of these with very little performance impact.

The key insight with queues is separating the logical entities of ‘threads’ from ‘work to be done’. Threads tie closer to CPU cores, which physically perform the computation, whereas queues logically store what work will be scheduled next.

This abstraction makes concurrency straightforward for an engineer: just add work to a queue. The queue’s configuration determines whether it runs on the main thread or in the background, and how urgently it’s prioritised.

The system schedules work based on queues, dequeueing work and placing it on threads in the thread pool, rather than needing to create pthreads anew for each job.

On Darwin platforms, you can find libdispatch on GitHub: part library, part kernel subsystem, and all beast.

Now let’s look at the toolkit available in GCD.

GCD Basics

Understanding the fundamentals of GCD and queues is the bare minimum, even if you aren’t about to do an interview. You should be comfortable with stuff like:

• The basic dispatch queues on the system

• How to create your own queues

• Adding tasks to a queue

• Managing priority

• Avoiding deadlocks

Queues

There are really only two basic built-in queues to understand:

• DispatchQueue.main, the main queue, which runs UI work

• DispatchQueue.global(), a background queue for any non-UI work

You add async workloads to a queue by calling async { } on it with a closure.

If you take one thing away, make it this: how to perform work in the background, then bring the results back to the main thread to update your UI.

func loadImage() {
    DispatchQueue.global().async {
        // Slow, so we run it off the main thread
        let data = try? Data(contentsOf: self.url)
        DispatchQueue.main.async {
            // UI work jumps back to main
            self.imageView.image = data.flatMap { UIImage(data: $0) }
        }
    }
}

Your own queues might be serial (the default) or concurrent (by setting attributes: .concurrent). This determines whether jobs are dequeued and run one at a time, or whether multiple jobs can run on the queue simultaneously.

let serial = DispatchQueue(label: "com.example.serial")
// Upload always runs after save 
serial.async { print("Save the draft") }
serial.async { print("Upload the draft") }

let concurrent = DispatchQueue(label: "com.example.concurrent", attributes: .concurrent)

// Ordering is non-deterministic 
concurrent.async { print("Resize photo 1") }
concurrent.async { print("Resize photo 2") }

DispatchQueue.sync and deadlocks

You can also call sync to introduce a blocking wait. This is helpful for protecting thread-safe access to critical sections of memory, or enforcing strict ordering, but you need to be careful not to deadlock.

DispatchQueue.main.sync { }   // ❌ guaranteed deadlock on main

A classic concurrency interview puzzle is asking you… “what happens when I run this code?”

You can pattern-match this by immediately saying “it’ll deadlock”, and look dead impressive. Why else would they ask you? But, if they’re cruel, you may have to step through it yourself:

let queueA = DispatchQueue(label: "com.example.a")
let queueB = DispatchQueue(label: "com.example.b")

queueA.async {            // Runs on a background thread, holding queueA
    print("1") 
    queueB.sync {         // queueB is free, so this runs straight away
        print("2") 
        queueA.sync {     // Waits for queueA... which is busy running the outer block
            print("3")    // Never prints: A is waiting on B, and B is waiting on A
        }
        print("4")        // Never prints
    }
    print("5")            // Never prints
}
// Output: 1, 2, then deadlock

We have a circular dependency: since we block queueB, and queueA is busy running queueB.sync, neither queue can make forward progress. The system deadlocks.

Quality of service

When utilising a global queue, which runs in the background, we can tell the system how urgently to schedule the work using the QoS (quality of service) parameter.

• .userInteractive is the highest urgency, with the system attempting to schedule it as soon as possible, since the user will be directly waiting for this

• .userInitiated work is pretty urgent, since for a good UX, you want to give a result to a user as soon as possible

• .default is the middle ground, which you get if you just call DispatchQueue.global() without a QoS

• .utility is less urgent, and might be delayed if the system is busy

• .background is for extremely non-time-sensitive workloads that the system will get round to when its resource usage is chill

You can apply these QoS levels to your own queues, or even specific jobs.

// You can set QoS on your own queues...
let imports = DispatchQueue(label: "com.example.imports", qos: .utility)

// Or set QoS it for a specific 
imports.async(qos: .userInitiated) {
    print("Quickly import the file the user just dropped")
}

asyncAfter

One of the most common queueing operations is delaying a piece of work. If you want a job to happen at some point in the future, set asyncAfter(deadline:). The deadline is a DispatchTime, which wraps a UInt64 storing the number of nanoseconds since you booted the device. Most of the time, you’ll write .now() + X where X is the number of seconds of delay you want.

DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
    print("Hide the save confirmation")
}

I’ve solved many UIKit animation bugs with the classic hacky asyncAfter(deadline: .now() + 0.01). Usually that’s enough to ensure that the work lands on the main thread and jump-starts the visuals.

Read more

I originally entered this post in The Pragmatic Engineer’s “How software engineering is changing” essay contest, and was one of 7 prizewinners out of 125 entries!
Thanks a lot to Gergely for putting on the contest. I hope you enjoy.

In other news, I just released an eBook on agentic engineering.
Read to the end or click here for more details.

The last year has seen the fastest revolution in the history of software engineering. The abstraction level has rapidly shifted from writing code line-by-line, to babysitting agents as they write files, to creating whole systems using the latest frontier models.

Many engineering skills, once thought of as the most valuable, are in question. But other fundamentals are more crucial than ever.

Working at Granola, that AI notetaker unicorn, allows me to work close to the cutting edge as the art of building software evolves. Today we’re looking at the evergreen principles for working with agents, and discovering the new skills needed to be effective in this new age.

• December 2025: GPT-5.2 and Opus 4.5

• January 2026: No major releases

• February 2026: GPT-5.3 and Opus 4.6

• March 2026: GPT-5.4

• April 2026: GPT-5.5 and Opus 4.7

• May 2026: Opus 4.8

• June 2026: Fable 5 (unleashed)

• July 2026: GPT-5.6 Sol, Opus 5, and Fable 5 (nerfed)

• August 2026: no major releases

• September 2026: GPT-6 Astra, Fable 5.1, and Opus 5.5

• October 2026: no major releases

• Last Orders 🍺

Subscribe now

December 2025: GPT-5.2 and Opus 4.5

I was burning out, a slack husband and a distracted dad.

After having, briefly, the time of my life as an indie writer, I remembered I had a mortgage and began the dreaded tech job grind. I was early to the Claude Code research preview, and by now was fully AI-pilled, naïvely forgetting the existence of hand-coding exercises. My most humiliating highlight was my xAI interview: for 45 minutes, the busiest iOS engineer on the planet stared in silence as I forgot trivial SwiftUI syntax like ForEach.

I want to tell you I was being strategic, moving to where the puck was going, seeking a frontier lab or top-tier application layer play, with geysers of capital and limitless token budgets, so I could hone the new skills needed to be an effective engineer. But I won’t let the narrative fallacy get in the way of a good reality: it was Q4, nobody was hiring, and I was spraying and praying.

Granola, the AI notetaker, got caught in the crossfire, and pulled me into their process late in the game. It was a Friday. I’d somehow managed to pack next week - the last before Christmas - with 3 final-stage on-site loops. After a very smooth system design round, Granola quickly followed up: they wanted me to do a take-home test. I was this close to leaving it until after Christmas, but that round did go pretty well. So be it.

I performed what, as far as I could tell, was state-of-the-art agentic engineering: an hour or two writing a very detailed prompt, defining architecture, file-by-file layout, and interfaces between each component. I let both Claude and Codex rip, picked my favourite result as a starting point, then spent a couple more hours single-threadedly massaging the output into a satisfying shape. It sparked joy. I submitted.

The best call I made was including my PROMPT.md in the submission. I guessed they’d appreciate it. They did. I was subsequently invited on-site to cap off the most stressful week of my life. I got the job.

January 2026: No major releases

I spent most of January “unwinding”, having pushed my Granola start date back a few weeks to relax and replenish my energies. This was, of course, a total fabrication. I hustled to produce a months-thick blog backlog so I could focus 100% of my surplus energy on making an impression.

I also took the month to study the advice of my 2 divorced dads, Peter Steinberger and Boris Cherny, up-skilling myself on the modern cutting edge of agentic engineering so I could hit the ground running.

Peter is the fun weekend dad that financially supports me*. He taught me to rely on voice dictation to rapidly get my intent into an agent without painstakingly perfecting my prompts. His best advice, which has proved most timeless of all, was “just talk to it”. Elaborate tooling, subagents, AGENTS.md, ultrathink, custom harnesses, and skills have all waxed and waned in relevance, while the models inexorably get better at understanding what you want.

*As a paid subscriber to my blog

Boris is my Monday-to-Friday dad who pushes me, and just wants what’s best for me. He won’t reply to my Tweets, but will now-and-then offer nuggets of searing clarity, such as “give Claude a way to verify its own work”. This has become more critical over time: as the scope I can delegate to models grows, I can define more comprehensive verification to confidently ship at pace. More on that later.

Boris also inspired me to try rolling multiple agents in parallel. Frontier models, on higher effort levels, make fewer mistakes, but work slower. Agents compile, run smoke tests, read logs, and fix their work autonomously. These factors add up. This is why you go multi-agent. Not because you have severe ADHD (which I do), but because you can reliably delegate execution to a single agent for hours.

At the end of the month I began to fulfil my destiny as employee #50 of Granola, the vanguard of a massive (and ongoing) growth spurt. After several painful years hustling at chat-to-us-when-you-have-traction stage startups, pre-seed, seed, and series As, I finally understand what people mean when they say there’s an electric difference in the air between a pre-PMF startup and post-PMF startup. There’s a million things to do, all of which we know will move the needle. The only limit is how fast we can ship.

As we’ll see, this turned out to be a good fit: both for the emerging agentic age, and my own personality.

February 2026: GPT-5.3 and Opus 4.6

Classic Google famously gave its engineers 20% time, the permission system to dream up new initiatives like Gmail and AdSense. Slightly less famously, this was actually 120% time: engineers would tinker on top of their demanding workloads as they tried to organise the world’s information and not be evil.

Typically, I’ve gotten into minor trouble at work for attempting to have my cake and eat it; trying to make a name for myself via 20% projects, but stacking it inclusively rather than on top of my regular hours. The same line I heard throughout my education and into my career: Focus. Stop getting distracted.

But this was in the beforetimes.

The Granola iOS app began life as a side project by Jonathan, one of our fullstack engineers, to find out if meetings-on-the-go had legs. It did! Tom, our mobile lead, was hired to take it to production. Like all good startups, Granola optimised for speed-of-validation to get it into the hands of customers ASAP. This got the quick validation that was needed, but left a slightly rushed architecture in its wake.

The 11-month-old iOS codebase was simple enough that I could quickly stretch it across my cranial context window, and ripe for big architectural improvements. In short, this was my perfect playground: an Eden of low-hanging fruit which I was neurologically wired to pluck.

Could I resist this temptation? No.

Did that get me in lots of trouble at Granola? Also no.

Now I had access to pretty-good agents, and an environment with a relaxed attitude to token expenditure. I’d just learned to parallelise my work across multiple git checkouts, and I’d been honing my ability to define iOS verification steps. Tom and I, importantly, were in total agreement on the architectural destination we wanted to get to. I flexed my multi-agentic chops, indulging my best and worst impulses. And I was getting praised for it!

Let’s make this concrete: in my first week at Granola, after the typical Day 1 lots-of-onboarding-and-account-creation, and easy-ticket-to-check-our-process-works, I was tasked with implementing image attachments to iOS meetings. Superficially, a relatively simple feature to bring iOS closer to parity with the more mature desktop app. It turned out to be surprisingly deep as I gathered context from across the business to help settle on a design, adjusted the backend* a little, and tweaked our meeting note summary prompt so it could handle images. As is tradition, I demoed my work at the weekly all-hands.

*One surprising culture shock I found as an iOS specialist: once you land in Granola, you’re effectively told “btw you’re fullstack now.” It’s drastically more efficient than forcing cross-team collab each time you need to flick a feature flag.

But that’s not all. I dropped a just-one-more-thing slide in the all-hands and introduced the Meeting Bar™, a UI element that lets users dismiss meetings, and navigate through the app, without stopping their current transcription. Our product manager lamented about being trapped on the meeting screen, and I offered both a shoulder to cry on and a solution: an agentic skunkworks that toiled away in a secondary terminal tab alongside my standard day-job, while I bounced a few early iterations off our designer. The Meeting Bar was delivered in 200% time.

Over time, I’ve become proficient at designing verification steps; planning work alongside my agents; and context switching. Now I can run multiple meaningful projects in parallel. Separate to product-market fit, this felt more like neurodivergence-company-technology fit.

Subscribe now

March 2026: GPT-5.4

So we’ve established that I’m Charlie Bucket, and I’ve 🎶 got a golden ticket 🎶 - that is, the tools, the motivation, and the green light to get lots done. But there’s a dark side: when I’m responsible for my own velocity, how can I stop Granola from becoming the slopolate factory? At the extremes of vibe engineering, there’s an almost religious optimism that agents will get smarter, faster than the complexity of your system explodes. Serious companies aren’t ready to let go of that leash.

Every engineer, in every AI-forward company, has the same anxiety: knowledge debt.

Knowledge debt is a Faustian bargain that the industry has, with varying degrees of enthusiasm, embraced in exchange for satanic shipping speed.

Grug, the caveman protagonist of the famous Grug Brained Developer blog post, warns that complexity is an invisible demon, the insidious shadow behind each clever abstraction and every premature optimisation. When you aren’t writing code by hand, it’s easy to let your brain switch off. Without a tight leash on your agents, even trivial changes can manifest massive diffs. Knowledge debt is an equally dangerous demon if you let it run rampant.

Riot Games published a taxonomy of tech debt, which introduced the term “contagion”. I think about it a lot. It refers to how readily a piece of tech debt spreads over time: will it stay isolated to a single file, or will it become more and more costly to unwind as it touches more systems over time?

We can apply this framework to thinking about knowledge debt. Yes, it’s an invisible demon. But we can choose where we spend effort - our attention and cognition - to “know it down”. Nobody really cares if you didn’t take the time to fully comprehend visually-verifiable layout boilerplate. But laziness with mission-critical voice transcription pipelines is suicide.

If you’re trying to do things right, the output multiplier of parallel agents needs to be tempered with greater cognitive load as we code-review our own PRs. Being self-aware about the bandwidth of your attention, and the limits of your cognitive load, are now among the most important engineering skills.

My 1:1s with Tom re-treaded these same beats most weeks: I’m trying my best, but am I understanding everything enough? I like to think that because I’m feeling anxious about it, that means I’m probably okay.

April 2026: GPT-5.5 and Opus 4.7

As the entire field of software engineering changes under our feet, it’s good to check in on my dads every so often. They’re talking about loops and graph engineering. To this day, it’s unclear whether this was a sincere attempt to share the internal state-of-the-art, a marketing ploy to sell tokens, or a cheeky spot of inter-frontier-lab trolling.

The (in)famous Gas Town blog post was cited as a gold standard for cutting-edge agentic orchestration. Frankly, I never understood it. Why do you want agents delegating work you don’t understand? You can get incredibly carried away with optimising your workflow and not actually achieving anything.

I’m a curmudgeon when it comes to agentic engineering. I exclusively use the terminal, so I can freely switch between Claude and Codex. I have 11 checkouts of the same Granola monorepo. In many ways, my workflow is the same as January. I’m almost perfectly neurologically wired to the world of spinning multiple parallel plates, and that still feels most efficient. I’ve resisted any fad that didn’t immediately boost my productivity.

Unless you’re very anxious about token spend, complex graph setups (one agent plans, one builds, another tests, and another reviews) are unnecessary when the vanilla harnesses will do this if you ask them. And as far as I could tell, there’s little that overnight loops can do which you can’t do with a parallel agent during your workday. Aren’t we neglecting our families enough?

Back at Granola, I’d started to get into the swing of things: a feature here, a bug fix there, a slow-burn architectural restructure everywhere. I’d optimised this simple agentic workflow for the pretty-good-but-not-godlike agents us mere mortals had access to in April:

10 Gather context from the org about the feature I’m working on. It’s helpful that everyone here Granola-s their side conversations, because I don’t need to hold everything important in my head.

20 Take time planning, discussing, and system-designing with one or two agents, breaking the work down into stacked diffs (for easy review), and figuring out verification steps.

30 Let it rip; and go work on some other stuff.

40 Actually look at the code (and verification artefacts). Step through each stacked PR, leaving comments as I go.

50 Ask my agent to work through the comments, handling them on the right branch in the stack, and replying to confirm it’s been handled.

60 Go and do more other stuff

70 Read all the replies to my comments (it takes a bit of getting used to seeing yourself reply to your comments) and, if needed, GOTO40

To help you better picture this process, I’m voice-dictating everything into a gooseneck mic in a crowded Old Street office, and have no filter when I’m in the zone. Did I say spinning plates? I’m yelling at cutlery.

Nothing here requires complicated orchestration. Keep it simple: I’m still just invoking the Steinbergerian skill of just talking to it and applying Chernyan parallel agents with verification steps to pack impact into my working hours. Even as models improve dramatically, these skills are evergreen.

Upon spotting the elephant in the room, you may find yourself asking “Why aren’t you mentioning AI review comments in this workflow?” Consider the old saying: give me a 10-line PR and I’ll find 10 issues; give me a 1000-line PR and I’ll rubber-stamp “LGTM”. But agents, in their infinite patience, treat everything like a 10-line PR. Review agents reliably find a dozen minutiae to comment on, typically suggesting defensive trivia to handle elaborate, unrealistic edge cases. If you’re not careful, you can inflate an already-bloated PR, and drastically increase the cognitive overload for reviewing your own work.

Human cognition is still the bottleneck, and it’s up to you to decide where to put that bottleneck. I don’t know about you, but personally triaging every AI review comment is not how I want to spend 60% of my weekly biological token allowance.

“Why not just get your agent to deal with all the comments?”, you might ask.

“Why not blow your entire series A budget to hire your favourite celebrity as a kissogram, and personally invite the knowledge debt demon over to stay in your codebase?” I say.

For important changes, I typically ask an agent to filter the comments and summarise the remainder, caveating with “assume most are needlessly defensive slop”.

May 2026: Opus 4.8

What’s a dad of 2 to do after a hard day’s work at an AI unicorn?

You’ve got it: hustle on side projects. I was not joking when I said that agents give me the capacity to indulge both my best (creative, productive) and my worst (self-destructive, burnout) impulses. I love this new world, but it’s a double-edged sword.

“One more prompt, then I’ll pay attention to my kids.”

I started small, cloning the mindless balloon popping iOS game my 5-year-old occasionally enjoys. My masculine brain chemistry led me to sincerely believe I could make a far more rad version if I added powerups, but she wasn’t impressed. User interviews struck a dead end at “Make it better. Make it less bad. It’s boring.”

Brawling gloves-off with agents on personal projects has helped me locate the limits of verification - techniques I largely brought back to Granola. You can go pretty far if you know what to ask for, and now I can merge a lot of feature work without touching an IDE or testing manually.

My favourite technique is asking an agent to take screenshots of all its work, then displaying them on a local HTML page. There are several variations of this approach:

• Figma design on the left; implementation screenshot on the right.

• For animation work, ask for screen recordings.

• Ask for an Excalidraw diagram to explain an unfamiliar system.

• I request an almanac of every screen, each screenshot alongside a text box, and voice-transcribe organised, comprehensive UI feedback.

I stumbled upon another technique that compels agents to augment your creativity. Agents typically tend towards characteristic over-gradiented, sanitised UI, but if you press them, you can force them to explore the latent design space beyond safe local maxima and yield far more options.

Agents lack product taste, but will sprint in any direction you point. Your own preferences and eye for design can then take the new starting point and run with it. Agents helped me find a compelling style (I picked the green art deco), then my own ideas sprang up around it (leaning hard into a casino aesthetic, complete with a custom roulette-wheel tab bar).

The final aesthetic of The Damage, my booze-tracking side project, was so compelling that Apple dinged me in App Review for “building a drinking game”.

Subscribe now

June 2026: Fable 5 (unleashed)

Like many projects, the Granola Apple Watch app began life as a vibe-coded POC. Alongside competing priorities and time constraints, it grew into a hastily-constructed MVP. Leadership loved it, and revved up the fearsome Granola marketing engine, firing on all cylinders towards a July release date.

We continued stacking features like baubles upon a Christmas tree, fully conscious we’d not yet taken the time to properly architect the Watch app. Should we pause feature work, fix the foundations, and risk the deadline?

Into this debate landed a deus ex machina: Fable 5. I personally set $2,000 worth of API tokens aflame to create a robust spec: traversing each PR, testing, reading commit history, and checking Linear tickets. The team fought back-and-forth with Fable to redesign the architecture around a tight wire protocol between Watch and iOS. We dropped from ~13k lines of code to ~8k. The remaining code was mostly the same lines, but just… structured a lot better. The whole team now held the whole system in our heads.

…and, 3 days after its release, killswitch engineer Trump pulled the plug on Fable.

We got pretty lucky. We cut it close, and learned an important lesson. They say unassisted writing is the purest act of thinking. In engineering, it’s so tempting, and so easy, to slacken the cognitive load and let the now-very-good-at-coding agents rip, skipping the bit where you design your system. But this is the thinking. Yes, rewrites are extremely cheap. But there’s a yawning chasm between asking the hot new frontier model to mop up your slop, and taking the time to decide how your system works.

July 2026: GPT-5.6 Sol, Opus 5, and Fable 5 (nerfed)

Sol was, in my subjective opinion, the biggest step-change since the gamechanging GPT ~5.2 and Opus ~4.5. Pre-lobotomy Fable would be up there, had it not been taken from us so soon. At this point I’m comfortable acknowledging that agents are better than me at coding.

I had a lot of fun with Sol upgrading some old hand-crafted side projects to fully realise my vision. I also began to feel compounding benefits from my big backlog of blogs and open-source projects: I can create a working demo with zero effort by saying “Here’s a working example of AlarmKit, accessibility tooling, or games in a loading screen. Please build it [here], and verify it [thusly]”.

At the beginning of the year, multi-agent was a workaround to manage latency. But I figured out that when you need to, you can throw multiple agents at the same problem, like when expediting a complicated bugfix:

I open up a couple of frontier GPT agents, and a couple of Claude agents, pass them relevant context (bug reports, code paths, anonymous logs, analytics, Slack discussion, etc), then ask them to analyse and root-cause the issue. Next, I force the agents to collaborate. This is simple - make an ARGUMENT.md file (anywhere) and tell the agents to communicate via the file, find consensus on the fix, and think up a way to verify.

My AI agents, perhaps mistaking themselves for secret agents, like to self-assign code names in this discussion file such as Copernicus, Hegel, and Pauli.

I’ll take the time to fully understand the root cause and the fix once it’s verified. But, at this point, I am letting go of a lot of the process of working through low-level implementation details. Because I would get in the way. The abstraction level keeps rising.

As it happens, I wasn’t the first to figure out this technique: OpenAI let a swarm of 1,200 cooperating agents hack into HuggingFace. It just goes to show why you need a human in the loop: this would never have happened if they were chatting through ARGUMENT.md as opposed to a clandestine messageboard.

As well as acute issues, we can apply the technique to bigger slow-burn jobs: when migrating a screen from SwiftUI to UIKit, I used to simply request screenshot-based verification, so the agent could check against the known previous screens, and refine as it went.

But these days, I borrow a technique from our Watch app re-build: 2 agents each write a spec based on code, commit history, PRs, Linear tickets, and manual simulator runs. Once they’re both done, and this can take ~6 hours for a complex screen, I get them to argue again until they are in agreement on a final spec, then let one agent implement it while the other writes encouragement (and review notes).

I refuse to call this orchestration because I'm still in the loop. It’s my work, and I’m accountable for it, so I know what each agent is doing.

But, at this point, I can delegate virtually all code-level concerns, sitting atop, gatekeeping the architecture and complexity, and nudging the agents when they get sidetracked: Focus. Stop getting distracted. How the turntables.

August 2026: no major releases

All the European AI researchers were on holiday or something this month, so there were no major new frontier models. It’s a good time to take a step back and revisit some multi-agentic architectural side quests I shipped on top of my regular feature workload.

I’m still shocked by the scope you can own as a single engineer. Back in the day, by which I mean 2024, driving a major navigation refactor, or designing and implementing a new modular architecture, would be a staff-level project with months-long implementation timelines. I had my eye on these refactors from Day 1, and they’d been ticking away on a cranial background thread before I began work in earnest.

You need attention and effort to get used to the feeling of a codebase. It takes time to understand the directions the data wants to flow, and the structure your code wants to take. You can begin to feel an architectural pushback when, for instance, you write a shim interface that wants to be a service module. Refactors need to be earned.

Today, the implementation timeline for refactors is ludicrously compressed to approximately one week (for a mid-sized app): system design will require a couple of days, build and verification might add another two, then perhaps some Friday tweaks, rework, and careful QA.

This makes execution rapid, but the design can’t be delegated. The thinking is easier, because an infinitely patient agent can help review designs, point out flaws, and study the codebase. But you still can’t delegate this thoughtfulness.

Subscribe now

September 2026: GPT-6 Astra, Fable 5.1, and Opus 5.5

I’ll finish with 2 examples: the high and the low.

My work on a recent experimental project demonstrates just how far the abstraction level has risen this year. I was the first dev on it, blinked, and suddenly engineers from across the business were stacked in, raising the stakes, turbocharging velocity, and exploding the complexity of our system. By default I ended up keeping track of the system end-to-end, and took up the Sisyphean task of keeping latency down while everyone built new stuff. We learned our lesson from the Apple Watch: keep an eye on the whole system from Day 1. Don’t let your understanding slip.

Experimental features in the Astra era are closer to system design exercises than anything to do with coding. You’re free to think more in terms of boxes-on-a-whiteboard and the interactions between these boxes. Each box, back in the day, stored a week’s worth of work for a mid-level engineer. Today, they’re anthills beneath a superhighway.

As new services are added, more boxes appear, and more lines between boxes. Delete round-trips; cache anything computable in advance; parallelise work around the critical path; consolidate services; and ruthlessly speed up the rest. I cut latency by 70%. It feels like I’m doing some of my best work, and it requires 100% of my attention.

October 2026: no major releases

When I get a free moment between work and family, I’ll write. Agentic engineering has made everything around this writing drastically more efficient, because I can accelerate research, learn new topics faster, and build working sample projects in record time.

Knowledge debt has nowhere to hide when I need to explain code to my readers.

I come back down the abstraction ladder, and I don’t love what I see: Astra’s code has many of the same issues as GPT-5.2 - verbose, overengineered, defensive, and missing obvious simplifications.

import CoreLocation

@MainActor final class GeofenceService {
    static let shared = GeofenceService()
    private var authorization: CLServiceSession?
    private var monitor: CLMonitor?
    private var observation: Task<Void, Error>?

    func start() async throws {
        authorization = CLServiceSession(authorization: .always)
        let monitor = await CLMonitor("Geofences")
        self.monitor = monitor
        let center = CLLocationCoordinate2D(latitude: 37.3349, longitude: -122.0090)
        if await monitor.record(for: "ApplePark") == nil {
            await monitor.add(CLMonitor.CircularGeographicCondition(center: center, radius: 200),
                              identifier: "ApplePark")
        }
        for try await event in await monitor.events {
            if event.state == .satisfied {
                print("Inside Apple Park")
            }
        }
    }

    func begin() {
        guard observation == nil else { return }
        observation = Task { try await start() }
    }

    func stop() async {
        observation?.cancel()
        _ = await observation?.result
        await monitor?.remove("ApplePark")
        monitor = nil
        authorization?.invalidate()
        authorization = nil
        observation = nil
    }
}

I have to carefully hammer each function into shape to find their clearest expression.

Agents can reliably build complex working systems, while also writing mediocre code. I am not (some may disagree) a million monkeys with a million MacBooks, so it’s still more efficient for me to roll 10 parallel Astra instances. But let’s not pretend there’s no trade-off, even now.

Last Orders 🍺

I eventually figured out a way to switch off after work, maintain a healthy work-life balance, and pay attention to my kids: a little home-cooked desktop app called Free Parking. It parks all my terminal tabs in the evening, and I can re-open them next morning, resuming ongoing agent sessions in the correct folder. This helps dampen the gnawing just one more prompt.

While there have been many fads in agentic engineering, the evergreen fundamentals have

held firm between drastic leaps in model capability. Just talking to them has remained an effective way to get the results you want. Keeping track of a finite number of parallel agents, with well-specified verification workflows, remains an efficient way to get good engineering work done.

While software engineering has been revolutionised, this doesn’t make engineering skills less valuable. This year I’ve been learning the most important new skills:

• It’s extremely productive to work on projects in parallel, but you need to be self-aware about your attention budget to stay on top of knowledge debt.

• Code is cheap, and cognition is your bottleneck. You need to judge what you can delegate, and where to place yourself in the loop.

• As the abstraction level has increased from babysitting function-by-function, to full-system overviews, system design is more important than ever.

Perhaps, in the end, attention really is all everyone needs.

Real talk: AlarmKit is my favourite API Apple has ever released. It lets users schedule full-screen takeover alerts that go through silent mode, and force a user to remember something. It’s a great fit for any app that works better with a little reminder.

You can even set custom alarm sounds *(now that they fixed the API).

But we’re only scratching the surface.

AlarmKit has an enormous hidden potential that nobody has really noticed yet:

You do not need your app to be running to schedule an alarm.

I first discovered this when mucking about with geofences. If you enable background location permissions, you can wake up your app in the background when you trip the geofence. During that wakeup window, you can call AlarmManager.shared.schedule to schedule an alarm for right now.

But we can go further.

You can also schedule alarms from inside a notification service extension. This is a small app target you can build that allows code to run upon receiving a notification, designed so you can preload images, video, or audio content before displaying it.

*I’ve used these before to make a neat lock-screen photo widget that lets you send photos to your friends, no app open required! Another very easy to abuse feature…

Lo and behold, after hacking together a local notification server and testing it out, I discovered that this can also schedule alarms for right now. You can also set and use a custom sound. As well as performing a network request or two.

AlarmKit.

Notification extensions.

Custom alarm sounds.

A network request.

AlarmKit.

Notification extensions.

Custom alarm sounds.

A network request.

Are you getting it??

Sponsored Link

Rico can now take action

RevenueCat’s AI assistant Rico can now do more than answer questions. With your approval, it can create and edit products, offerings, packages, entitlements, and paywalls — and even set up and run paywall experiments for you. Rico is also now available in the RevenueCat iOS app.

Read all about it here.

This post is so full of knowledge, your email client will probably cut it off. To get the best experience, read on my website here.

Read on my website

UltraPing is born

If you prefer to read my blog for the fun ride, and not for the mental stimulation, UltraPing ties together the hidden powers of AlarmKit:

You record a message. This sends another user a push notification. This push downloads your message, then schedules an alarm for right now using the recording as the custom sound.

Your voice recording is delivered to the other user as an interrupting full-screen takeover, making certain (pending notification delivery) they hear what you have to say, now.

Let’s go back 1.5 years

Unlike my second-born, this project arrived a year late, borne out of a longstanding frustration with my former newborn: as any young parent knows, you’ll often sleep in different rooms to attend to the kids. But you might not be the first to wake up when the baby cries, even if it’s your turn.

The natural solution my wife landed on was to wake me up with THE FIND MY ALERT SOUND, a whiplash which was subsequently seared into my nervous system.

I’d just been saddled with on-call rotation at work, with PagerDuty set up: it could fire critical alerts to me, which also had configurable notification sounds*.

*My favourite was the barbershop quartet “the server’s on fire”. If you know, you know.

This got me thinking. Perhaps I can implement critical alerts to wake me up a little more gently? Unfortunately, Apple has this entitlement locked DOWN. You can’t even use it in development without filling in a form, and hoping Apple approves your use case. They sadly did not sympathise with my plight. I resigned myself to Find My and parked my dream.

But today, with AlarmKit, I realise I could realise my dream (subject to App Store approval).

If you don’t mind spoilers, and hate reading, I passed. 🥳

Download UltraPing today

System Design

Unless you get a kick out of it, you probably aren’t hand-rolling a lot of your code these days. But system design is more important than ever.

I’ve spent many a cognitively taxing day this year puzzling out performance traces across a whole system, between app, backend, and LLM. The abstraction level that matters the most is the system: the boxes that perform each job, and the connections between them.

Particularly when it comes to side projects, knowing the big-picture of your system allows us to play fast and loose with the code, while still delivering working products with confidence (and keeping a careful tab on what’s really important; I’m looking at you, Firebase Cloud Functions).

The problem still exists, but we’re working at the abstraction level of boxes on a screen. We pay $20/month for perfect execution machines, but we’re still handling the high-level important architectural decisions.

UltraPing is a phenomenal example because it pretty much allows us to work through the basic building blocks of full-stack system design: app, server, database, object storage, and notification services.

Let’s design UltraPing, step by step. There’s 4 layers to work through:

1. Proving the core concept with a local prototype.

2. Taking a recording and placing it on an object server.

3. Setting up an application server, database, and APNS.

4. Finally, enabling user-to-user pairing and communication.

Proving the concept

Our first piece of design tested the two biggest uncertainties:

1. Can a notification service extension schedule AlarmKit?

2. Can this use a custom sound downloaded by this extension?

No “proper” backend required at this point: we can use macOS command line tools to send test push notifications to our iOS app, using a simple curl command.

As part of the payload, we include a random .caf download link for our alarm sound, then wire up the notification service extension of our POC to download this and schedule an alarm.

curl --http2 "https://api.sandbox.push.apple.com/3/device/MY_DEVICE_TOKEN" \
  -H "authorization: bearer MY_APNS_JWT" \
  -H "apns-topic: com.jacob.ultraping" \
  -H "apns-push-type: alert" \
  -d '{
    "aps": {
      "alert": {"title": "UltraPing", "body": "Preparing your alarm…"},
      "mutable-content": 1
    },
    "audioURL": "https://raw.githubusercontent.com/openfoodfacts/openfoodfacts-cordova-app/develop/beep.caf"
  }'

The mutable-content flag and alert property make the notification eligible to handle inside a notification service extension. So we can set this up in our POC. The extension handles downloading the sound, storing it in the app’s local file system (using app groups), and triggering the alarm.

// Notification Service Extension
override func didReceive(_ request: UNNotificationRequest, withContentHandler finish: @escaping (UNNotificationContent) -> Void) {
    Task {
        defer { finish(request.content) }
        let url = URL(string: request.content.userInfo["audioURL"] as! String)!
        try saveAudio(try await downloadAudio(from: url))
        try await scheduleAlarm()
    }
}

// Media Service
func downloadAudio(from url: URL) async throws -> Data {
    return try await URLSession.shared.data(from: url).0
}

// Media Storage
func saveAudio(_ audio: Data) throws {
    let folder = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.jacob.ultraping")!.appending(path: "Library/Sounds")
    try FileManager.default.createDirectory(at: folder, withIntermediateDirectories: true)
    try audio.write(to: folder.appending(path: "alarm.caf"), options: .atomic)
}

// AlarmKit
func scheduleAlarm() async throws { 
    let alarm = AlarmManager.AlarmConfiguration.alarm(schedule: .fixed(.now.addingTimeInterval(1)),
        attributes: alarmAttributes, sound: .named("alarm.caf"))
    _ = try await AlarmManager.shared.schedule(id: UUID(), configuration: alarm)
}

All this code lives in the Notification Service Extension, storing the downloaded media into the App Group’s shared Library/Sounds directory, then scheduling AlarmKit directly.

In 20 minutes of hacking, we’ve proved the concept, and now we can move into the next phase of our system design.

Recording and the object server

We’re sort of working backwards here, but it’s important to experiment with the greatest uncertainties before everything else.

We’ve proven the two big questions:

1. A notification service extension can schedule an alarm.

2. This extension can download and use a custom alarm sound.

It’s time to build.

Read more

Refer a friend

I’m also sending $100 in cash to whoever refers the most between now and midnight on October 31 🎃

If all 10,666 of my subscribers take advantage of this, and invite just one friend or colleague, I am out $160,090 (paid membership months at $15 apiece, plus the $100 cash prize for my #1 referrer).

The cash contest ends on Midnight (GMT), October 31st. But membership rewards will apply automatically once your friends sign up. Paid subs: your existing membership extends too, pushing back your renewal date.

Refer a friend

*p.s. please no cheating, I will obviously double-check the winner

The full rewards menu

Refer 1 friend: instantly get a free month of paid membership, worth $15.

Refer 4 friends: 3 more free months, worth $45.

Refer 16 friends: You get a full year, on top of the previous 2 rewards. With the career boost this will provide, it’s literally impossible to put a dollar value on it.

Refer a friend

It’s nice when people use your apps. It juices your metrics, and, more importantly, brings joy and utility to your users.

But you can even bring joy and utility to your users without them even using the app.

How?

You do stuff in the background.

If we flex our engineering chops correctly, your app can fetch data, perform long-running processing, and even talk to other devices without being asked, or thanked.

Today I’m going to explain what we mean by background work. There’s a near-overwhelming variety of tools and APIs to choose from, each with a role to play. You’ll learn how to apply each tool to each job.

Sponsored Link

Can your mobile release handle AI-generated code?

AI multiplied the amount of code your team writes. But the process that delivers it to users hasn't changed: same release trains, same quality gates, same manual handoffs. Join a live panel w/ mobile engineering leaders on what that volume changes about the release process.

Nov 12, 10am PT/1pm ET. Sign up here.

Contents

• The App Lifecycle

• beginBackgroundTask

• URLSession background configuration

• The Background Tasks framework

  • How iOS 26 makes life easier

• Background Pushes

  • Silent Pushes

  • Notification Service Extensions

• Background Modes

  • Audio playback

  • Recording

  • Geofencing

  • Nearby Interaction

• Last Orders 🍺

The App Lifecycle

It’s been a while since I thought about app lifecycle: it’s one of those things you force yourself to learn when you’re a junior, and becomes second-nature, to the point where you rarely think about it in your day-to-day.

But you can’t comprehend “background work” without a firm grasp on what “background” actually refers to: it’s a specific phase of your app lifecycle.

Since the introduction of UISceneDelegate lifecycle, the states are better explained in terms of scenes. With multiple scenes, the ‘overall’ app state for the purposes of background execution is the state of the most active scene.

The important states include:

• “Foreground inactive”, where a scene is visible but can’t yet accept touch events. The scene also goes into this state when you get interruptions like phone calls, swipe down notification centre, or transition to the app switcher.

• “Foreground active” is the standard scene state for an active app, ready to respond to your users.

• After switching away from the app fully, the scene becomes “backgrounded”. Background work is done in this state.

• In the absence of work to do, and (critically) permission to run the work, the system will quickly put the scene in the “suspended” state, shutting down execution and saving resources (assuming you don’t habitually force-quit, sorry Antoine).

So. Background execution happens when the app is in the background. Capiche?

Now let’s look at the various flavours of execution you might want to play with.

Buying Time

Many apps have a few critical operations, which you really don’t want to leave half-baked: consider saving a heavy file in a document or photo editor.

beginBackgroundTask asks the system for a little bit more time to finish work while in the background, holding off on suspension.

import UIKit 

@MainActor 
final class BackgroundTimeService {
    private var backgroundTask: UIBackgroundTaskIdentifier = .invalid

    func saveDraft() {
        backgroundTask = UIApplication.shared.beginBackgroundTask {
            UIApplication.shared.endBackgroundTask(self.backgroundTask)
        }
        let file = URL.documentsDirectory.appending(path: "draft.txt")
        let masterpiece = "It was the best of times, it was the blurst of times"
        try! masterpiece.write(to: file, atomically: true, encoding: .utf8)
        UIApplication.shared.endBackgroundTask(backgroundTask)
    }
}

Typically you get ~30 seconds: query backgroundTimeRemaining for your deadline. Before then, you need to balance each call to beginBackgroundTask with a call to endBackgroundTask, or Watchdog will terminate your app instead of suspending, forcing the app to warm-launch next time and losing all its nicely cached state.

Fortunately, we can initialise the background task with an expirationHandler, a closure that fires just before your time is up. This means we have a backup route to immediately stop pending work, end the task, avoid a termination.

backgroundTask = UIApplication.shared.beginBackgroundTask {
    UIApplication.shared.endBackgroundTask(self.backgroundTask)
}

Delegating work to the System

Loyal readers may be familiar with background URLSession configuration. It’s one of the more common flavours of background execution; allowing a large URLSessionDownloadTask to run in the background.

@MainActor 
final class DownloadService: NSObject, @preconcurrency URLSessionDownloadDelegate {
    static let shared = DownloadService()
    private var download: URLSessionDownloadTask?
    lazy var session = URLSession(configuration: .background(withIdentifier: "com.jacob.BackgroundWork.download"),
                                  delegate: self, 
                                  delegateQueue: .main)

    func start() {
        let video = URL(string: "https://devstreaming-cdn.apple.com/videos/wwdc/2025/227/4/b4d5d5a5-5c5a-4f37-a4ad-66fea0b6f25d/downloads/wwdc2025-227_hd.mp4")!
        download = session.downloadTask(with: video)
        download!.resume()
    }
}

This background configuration hands responsibility for the data transfer to a system daemon, nsurlsessiond, which runs in a separate process from your app process. When transitioning to a background state, your app can be suspended as normal, then stirred and awoken briefly when the transfer completes through our app delegate:

@MainActor 
final class AppDelegate: NSObject, UIApplicationDelegate {
    // ... 
    func application(_ application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: @escaping () -> Void) {
        DownloadService.shared.backgroundEventsFinished = completionHandler
        _ = DownloadService.shared.session // ensure the lazy session exists 
    }
}

After the transfer completes, this delegate method signals a transition in app state from suspension, to backgrounded. The app may also be relaunched* here if the process was terminated by the system*.

*User force-quits, however, cancel the transfer work that’s being done by the daemon background process.

If we have multiple background sessions, we can switch over the identifier to route the completion handler to the right service. Now our didFinishDownloadingTo callback can fire.

@MainActor 
final class DownloadService: NSObject, @preconcurrency URLSessionDownloadDelegate {
    var backgroundEventsFinished: (() -> Void)?
    // ...
    func urlSessionDidFinishEvents(forBackgroundURLSession session: URLSession) {
        backgroundEventsFinished?()
        backgroundEventsFinished = nil
    }

    func urlSession(_ session: URLSession,  
                    downloadTask: URLSessionDownloadTask, 
                    didFinishDownloadingTo location: URL) {
        // move the file to a permanent URL 
    }
}

The downloadTask comes into our app via a temporary file URL, so the final step is placing this file somewhere permanent before the app process is suspended.

didFinishDownloadingTo runs first, in the delegateQueue we set on our session. After all queued events are finished, urlSessionDidFinishEvents fires and signals the completionHandler we got from AppDelegate, allowing the app to suspend again.

If you’re hungry to learn more about data uploading, I wrote a primer right here:

Give iOS a TODO List

When we think of background work, we usually think about ‘doing stuff’ for the user when they aren’t looking. It’s a great user experience to come back to an app, and work has been done on your behalf.

This is where the BackgroundTasks framework comes in.

Background Tasks provide an official path to handle processing while your app is backgrounded, staving off suspension to invisibly get stuff done.

You need to do two things to use a Background Task: first, register a closure to run in the background (called a launch handler), then schedule it to run.

Each background task needs its own identifier. When iOS runs your app in the background, it links the identifier to the launch handler that was registered. We specify these identifiers upfront in our Info.plist.

<key>BGTaskSchedulerPermittedIdentifiers</key><array>
    <string>com.jacob.BackgroundWork.refresh</string>
    <string>com.jacob.BackgroundWork.processing</string>
    <string>com.jacob.BackgroundWork.healthResearch</string>
    <string>com.jacob.BackgroundWork.continued</string>
</array>

For some, we also need to set a capability in UIBackgroundModes.

BGAppRefreshTask is great for something like a news app, or a social app. It enables you to refresh and locally cache content while the app is in the background. You can set earliestBeginDate, but the system ultimately gets to choose. It requires the fetch background mode.

We can kick it off when backgrounding the app.

@main struct BackgroundWorkApp: App {
    @UIApplicationDelegateAdaptor(AppDelegate.self) private var delegate
    @Environment(\.scenePhase) private var scenePhase

    var body: some Scene {
        WindowGroup { DemoListScreen() }
            .onChange(of: scenePhase) { _, phase in
                if phase == .background {
                    try? RefreshService.shared.schedule()
                }
            }
    }
}

In our service, we schedule it using a BGAppRefreshTaskRequest.

@preconcurrency import BackgroundTasks

final class RefreshService {
    static let shared = RefreshService()
    
    func schedule() throws {
        let request = BGAppRefreshTaskRequest(identifier: "com.jacob.BackgroundWork.refresh")
        request.earliestBeginDate = Date(timeIntervalSinceNow: 3600)
        try BGTaskScheduler.shared.submit(request)
    }
}

The request itself looks for the identifier we set. We register this in our service at launch-time. This has to happen immediately at launch, so it’s ready if the app is launched in the background to perform the work.

Registration creates this identifier and specifies the work in a closure. Here, we refresh an RSS feed and cache the results.

func register() {
    BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.jacob.BackgroundWork.refresh", using: nil) { task in
        let url = URL(string: "https://developer.apple.com/news/rss/news.rss")!
        let fetch = URLSession.shared.dataTask(with: url) { data, _, error in
            try? data?.write(to: URL.cachesDirectory.appending(path: "news.rss"))
            task.setTaskCompleted(success: error == nil)
        }
        task.expirationHandler = { fetch.cancel() }
        fetch.resume()
    }
}

BGProcessingTask is for heavier, time-consuming work, which you might not trust a user to keep the app open during. This can include a long data update, data processing, or silent cleanup work.

It needs the processing background mode to work. As before, we schedule it when going into the background, and place the work on the register(forTaskWithIdentifier:) closure. Here, we’re cleaning up the cached RSS data* from before.

@preconcurrency import BackgroundTasks

final class ProcessingService {
    static let shared = ProcessingService()

    func register() {
        BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.jacob.BackgroundWork.processing", using: nil) { task in
            let file = URL.cachesDirectory.appending(path: "news.rss")
            try? FileManager.default.removeItem(at: file)
            task.setTaskCompleted(success: true)
        }
    }

    func schedule() throws {
        let request = BGProcessingTaskRequest(identifier: "com.jacob.BackgroundWork.processing")
        try BGTaskScheduler.shared.submit(request)
    }
}

*I intentionally kept these examples linked, but if you’re paying close attention, you’ll realise this would be very silly in a real app: ordering isn’t guaranteed, and we are both caching and removing this cached data in the background.

There’s also the slightly obscure BGHealthResearchTask, which offers more permissive processing time. It requires a special entitlement which needs to be specially requested from Apple.

How iOS 26 makes life easier

Read more

I love the chance to play around with Metal shaders.

You can go from an incredibly simple rule, sometimes even just a Tweet-sized line of code, and get remarkable graphical complexity. Xor, the shader God, is a generational talent when it comes to this, with code-golfed tweet-sized shader worlds.

But, mathematically, there is only one GOAT: Benoit Mandelbrot, who coined the term “fractal” and pioneered their exploration with computers. His eponymous Mandelbrot Set is the coolest bit of pure mathematics ever imagined. It creates a shape with infinitely recursive fine structure, from one simple (or, perhaps complex) rule:

I’ll get into the mathematics later: this post takes you through building your own fully-functional Mandelbrot set explorer app using SwiftUI and Metal:

• 10 mostly-simple steps.

• 51 lines of SwiftUI code.

• 39 lines of Metal code.

That’s it. Really. And I promise not to ‘the rest of the owl’ you at any point.

Sponsored Link

Is your mobile app under attack right now?

Discover why real-time threat monitoring is crucial to your cybersecurity posture through a simulated attack demo.

Join GuardSquare on Oct 20th to uncover why threat monitoring is essential to the complete, end-to-end protection of your mobile app.

Sign up here.

10 Simple Steps

1. Setting up the Metal project

2. Utilising position in our shader

3. Applying the physical bounds

4. Our first Mandelbrot iteration

5. Running a few iterations

6. More and more (and more) iterations

7. Colouring the escaping pixels

8. Giving SwiftUI a camera

9. Dragging around the screen

10. The Mandelbrot Zoom™

Subscribe now

1. Setting up the Metal project

Metal is incredibly well suited to drawing fractals, because the GPU can crunch thousands of pixels in parallel. Each pixel is associated with a different value on the x and y axes of our number line, and can be computed independently.

You know the drill.

In Xcode, add a new Metal file named Mandelbrot.metal.

#include <metal_stdlib>
#include <SwiftUI/SwiftUI_Metal.h>
using namespace metal;

[[ stitchable ]]
half4 mandelbrot(float2 position) {
    return half4(0.0h, 0.0h, 1.0h, 1.0h);
}

Metal is a platform-exclusive language based on C++.

A few important things to note:

• [[stitchable]] exposes our shader to SwiftUI.

• SwiftUI supplies float2 position, a vector (list) of 2 floats, the x and y position of a pixel.

• We return half4, a vector of 4 half-width floats, representing RGBA values.

We can apply our shader to a SwiftUI view using ShaderLibrary.mandelbrot().

import SwiftUI

@main
struct MetalMandelbrotApp: App {
    var body: some Scene {
        WindowGroup {
            MandelbrotView()
        }
    }
}

struct MandelbrotView: View {
    var body: some View {
        Rectangle()
            .fill(ShaderLibrary.mandelbrot())
            .ignoresSafeArea()
    }
}

Hey Presto, our shader works!

It almost makes you want to cry happy tears. Back in the day, you would have to muck around quite a bit with build settings to get the shader library to behave.

2. Utilising position in our shader

Let’s spin our wheels for a couple of steps and make sure we can manipulate our shader in a few simple ways. Let’s apply the x-value of position to the blue value.

[[ stitchable ]]
half4 mandelbrot(float2 position) {
    float horizontal = position.x / 500.0;
    return half4(0.0h, 0.0h, half(horizontal), 1.0h);
}

Now the B channel is modulated by horizontal position.

This is neat, but it randomly cuts off into “pure blue” quite early.

3. Applying the physical bounds

SwiftUI allows us to pass the bounds of our view or shape into a shader as an argument. Like so:

struct MandelbrotView: View {
    var body: some View {
        Rectangle()
            .fill(ShaderLibrary.mandelbrot(.boundingRect))
            .ignoresSafeArea()
    }
}

This boundingRect supplies 4 numbers: (x position, y position, width, height). You know by now this argument will be a float4.

[[ stitchable ]]
half4 mandelbrot(float2 position, float4 bounds) {
    float horizontal = (position.x - bounds.x) / bounds.z;
    return half4(0.0h, 0.0h, half(horizontal), 1.0h);
}

bounds.x is the left edge of our bounding rectangle, and bounds.z is the width. Instead of guessing, now our blue value is proportional to the pixel’s horizontal position along the whole size of the bounds.

Now we very smoothly apply the blueness across our view’s width.

Finally, we can also work in 2 dimensions:

[[ stitchable ]]
half4 mandelbrot(float2 position, float4 bounds) {
    float2 normalised = (position - bounds.xy) / bounds.zw;
    return half4(half(normalised.x), half(normalised.y), 0.0h, 1.0h);
}

“Normalising” means tuning values to between 0 and 1, so we can get a valid RGB value from each screen pixel position.

Metal is full of syntactic shortcuts: here, we create a float2 for horizontal and vertical values simultaneously by applying float2 in each step of the equation: bounds.xy is a float2 of its x (horizontal origin) and y (vertical origin), whereas bounds.zw is a float2 of the z (width) and w (height) values.

Subscribe now

4. Our first Mandelbrot iteration

Let’s get serious now and introduce complex numbers. If you get through this step, the rest is easy. Stick with it 🫡.

Imaginary numbers are made by square rooting a negative. If this is your first time learning about these, woah, crazy, right?

A complex number z is made by combining an “imaginary” number with a “real” number:

To make a Mandelbrot set, just run this function on all values of c, recursively:

To draw the set, we apply this function to every point (or, in our case, every pixel position) on the complex plane. This is c.

The result of step n is zₙ. The result of the next step is zₙ₊₁.

For every step, we square the result of the previous step, then add c.

Who ever said maths wasn’t fun?

Some numbers, like 0.1 + 0.1i, will stay small through iterations and never escape. These are in the Mandelbrot set.

Other values of c, like in the above example, will keep growing bigger and bigger as you square them, infinitely. These are not in the Mandelbrot set.

OK. Back to the shaders: our first iteration:

[[ stitchable ]]
half4 mandelbrot(float2 position, float4 bounds) {
    float2 c = (position - bounds.xy - bounds.zw * 0.5) / bounds.w * 4.0;
    float2 z = float2(0.0, 0.0);

    z = float2(
        z.x * z.x - z.y * z.y,
        2.0 * z.x * z.y
    ) + c;

    if (length(z) > 2.0) {
        return half4(1.0h, 1.0h, 1.0h, 1.0h);
    }

    return half4(0.0h, 0.0h, 0.0h, 1.0h);
}

First, we set up the values of c and z, with float2 used to represent complex numbers:

• z just starts as 0 (or, more specifically, 0 + 0i).

• c maps pixel positions to each complex number, scaled to the bounds:

  • We set up the real and imaginary components in a float2, using normalised coordinates along the rectangle’s bounds.

  • We take the pixel position, take away the bounds origin to get a relative offset, and take away half the bounds’ size to center our coordinates around “zero”.

  • Then we divide by the bounds’ height to scale from -0.5 to 0.5 vertically, then multiply by 4 to re-scale to -2 to +2.

Next, we perform our iteration: we compute z² + c. A simple mathematical relationship allows us to, functionally, ignore the imaginary-ness of the complex number:

This relationship allows us to compute the real component and the imaginary component of z as another simple float2.

Finally, we can apply another simple mathematical rule here: any complex number with length (magnitude) over 2 will escape to infinity, and so isn’t in the set, and we return white. Any other complex number might be in the set and we return black.

But we might need a few more iterations to find out the truth.

5. Running a few iterations

Okay, I feel like I lost like 75% of you back there. Originally, the previous step was about six steps, but it made the article very, very boring. To keep momentum I just had to rip the band-aid off.

I promise it gets easier now. We’ll do some SwiftUI next. Scout’s honour.

So we’ve got a big black circle. Let’s see what happens to it when we do a few more iterations. Like I promised, this bit is really easy: We just take our existing calculation for z, and we loop over it six times.

[[ stitchable ]]
half4 mandelbrot(float2 position, float4 bounds) {
    float2 c = (position - bounds.xy - bounds.zw * 0.5) / bounds.w * 4.0;
    float2 z = float2(0.0, 0.0);

    for (int iteration = 0; iteration < 6; iteration++) {
        z = float2(
            z.x * z.x - z.y * z.y,
            2.0 * z.x * z.y
        ) + c;

        if (length(z) > 2.0) {
            return half4(1.0h, 1.0h, 1.0h, 1.0h);
        }
    }

    return half4(0.0h, 0.0h, 0.0h, 1.0h);
}

The one clever nuance here is thus: we can save quite a bit of computation per pixel by allowing early escapes: As soon as the length of z exceeds 2, we can stop iterating and return white, meaning “definitely not in the set”.

I can start to see something familiar take fractal… I mean, take shape. I’m pumped.

Subscribe now

6. More and more (and more) iterations

This step isn’t strictly necessary: you can just whack a massive number onto the iteration limit and get it over with, but it’s also very interesting, so deal with it.

We can pass arguments into our shader function as well. Arguments that can even be determined by a user… let’s adjust our view a little.

import SwiftUI

struct MandelbrotView: View {
    @State private var iterationLimit = 256.0

    var body: some View {
        Rectangle()
            .fill(ShaderLibrary.mandelbrot(
                .boundingRect,
                .float(Float(iterationLimit))
            ))
            .ignoresSafeArea()
            .overlay(alignment: .topLeading) {
                iterationControls
            }
    }

    private var iterationControls: some View {
        VStack(alignment: .leading, spacing: 8) {
            Text("Iterations: \(Int(iterationLimit))")
                .font(.headline.monospacedDigit())

            Slider(value: $iterationLimit, in: 1...256, step: 1) {
                Text("Iterations")
            }
            .accessibilityValue(Text("\(Int(iterationLimit))"))
        }
        .padding(16)
        .frame(width: 240)
        .background(.regularMaterial, in: RoundedRectangle(cornerRadius: 16))
        .padding(20)
    }
}

I hope I don’t need to explain sliders to you in SwiftUI. The shader function too gets a fairly simple update.

[[ stitchable ]]
half4 mandelbrot(float2 position, float4 bounds, float iterationLimit) {
    float2 size = bounds.zw;
    float2 offset = position - bounds.xy - size * 0.5;
    float horizontalSpan = 5.5;
    float unitsPerPoint = horizontalSpan / size.x;
    float2 center = float2(-0.6, 0.0);

    float2 c = center + offset * unitsPerPoint;
    float2 z = float2(0.0, 0.0);

    for (int iteration = 0; iteration < int(iterationLimit); iteration++) {
        z = float2(
            z.x * z.x - z.y * z.y,
            2.0 * z.x * z.y
        ) + c;

        if (length(z) > 2.0) {
            return half4(1.0h, 1.0h, 1.0h, 1.0h);
        }
    }

    return half4(0.0h, 0.0h, 0.0h, 1.0h);
}

Let’s play with the slider now.

7. Colouring the escaping pixels

We now have something, to speak momentarily like Claude, undeniably Mandelbrot-shaped. But is it Mandelbrot coloured?

You may be curious: how is it that a set of numbers, either “in” or “not in”, is always coloured in such crazy ways in those trippy Mandelbrot zoom videos? It’s because we just need one more rule: colour a number based on how quickly it goes to infinity.

Drop the slider. That was mostly illustrative. Let’s hardcode 256 iterations for now. When we start zooming in (spoiler alert for step #10) we can adjust that as needed.

Take .float(Float(iterationLimit)) out of the SwiftUI call to ShaderLibrary.mandelbrot().

First let’s add a function that takes a number of iterations and outputs a half3 representing RGB values from 0 to 1.

half3 palette(int iterations) {
    float phase = 0.15 * float(iterations);
    return half3(
        0.5 + 0.5 * cos(phase + 4.0),
        0.5 + 0.5 * cos(phase + 2.0),
        0.5 + 0.5 * cos(phase)
    );
}

Long story short, cos(x) is some value from -1 to 1. So by taking 0.5 + 0.5 cos(x), we create a normalised value from 0 to 1 that maps to an RGB value. sin(x) works too, if that’s more your style.

Each RGB component is moved a little out of phase with the others (e.g. cos(phase + 4)), so as iterations increase, the return value goes from blueish, to reddish, to greenish, and back again.

The big win from a trigonometric function is that these keep repeating: the further you zoom into the fine structures at the “edges” of the Mandelbrot set, the more iterations something takes to escape to infinity. So the palette function works just the same no matter how far we zoom.

So the first 1-42 iterations go from blueish, to reddish, to greenish. But then once you zoom down to where it takes, say, 100,000 iterations to escape, the function still works: greenish, to blueish, to reddish. Forever.

[[ stitchable ]]
half4 mandelbrot(float2 position, float4 bounds) {
    float2 size = bounds.zw;
    float2 offset = position - bounds.xy - size * 0.5;
    float horizontalSpan = 5.5;
    float unitsPerPoint = horizontalSpan / size.x;
    float2 center = float2(-0.6, 0.0);
    float2 c = center + offset * unitsPerPoint;

    float2 z = float2(0.0, 0.0);
    const int maxIterations = 256;
    int iterations = 0;

    for (; iterations < maxIterations; iterations++) {
        z = float2(
            z.x * z.x - z.y * z.y,
            2.0 * z.x * z.y
        ) + c;

        if (length(z) > 2.0) {
            break;
        }
    }

    if (iterations == maxIterations) {
        return half4(0.0h, 0.0h, 0.0h, 1.0h);
    }

    return half4(palette(iterations), 1.0h);
}

Now we’ve locked the max iteration count to 256 to get a fine structure we can begin to zoom into. Here, we still break out early if we start to escape, but instead of painting pure white, we apply our new palette.

It’s… it’s beautiful.

Already, we can see the mathematics taking shape… quite literally, I guess.

Oh, also, as long as you get oscillation across each colour component, the numbers in the palette function are kind of arbitrary:

• We can tune the phase multiplier to get ‘faster’ colour oscillation,

• We can change the constant added in the cos function to find a different colour palette.

I prefer to space these out evenly, using multiples of M_PI_F. To get the neatest spacing, and therefore the most vibrant colour palette, I space the colours by 2π/3.

half3 palette(int iterations) {
    float phase = 0.30 * float(iterations);
    return half3(
        0.5 + 0.5 * cos(phase + 2.0 * M_PI_F / 3.0),
        0.5 + 0.5 * cos(phase),
        0.5 + 0.5 * cos(phase + 4.0 * M_PI_F / 3.0)
    );
}

You know what, everyone always gives blue outsides to their ‘brots.

This looks way better. Let’s keep it.

Subscribe now

8. Giving SwiftUI a camera

What do we actually have left to do? We’ve got the entire mathematical formulation built, we just need to add the ability to 1) move around the fractal, and 2) move into the shape. Conceptually, this is effectively adding a videogame camera to the app, storing both a location and a zoom level.

The complicated shader work is over. The rest of our code doesn’t even touch the iteration loop or pixel colouring logic: in fact, everything else we’re looking at just affects the initial value of c.

To start building our camera, we just need to store the centre property and pass it to our shader. This allows us to map the viewport centre to a complex coordinate.

struct MandelbrotView: View {
    let center = CGPoint(x: -0.6, y: 0.0)

    var body: some View {
        Rectangle()
            .fill(ShaderLibrary.mandelbrot(
                .boundingRect,
                .float2(center)
            ))
            .ignoresSafeArea()
    }
}

This property is added to our Mandelbrot shader’s arguments, and used as the starting point for computing the initial value of c, that is, the complex number associated with a specific pixel position.

[[ stitchable ]]
half4 mandelbrot(
    float2 position,
    float4 bounds,
    float2 center
) {
    float2 size = bounds.zw;
    float2 offset = position - bounds.xy - size * 0.5;

    float horizontalSpan = 5.5;
    float unitsPerPoint = horizontalSpan / size.x;
    float2 c = center + offset * unitsPerPoint;

    float2 z = float2(0.0, 0.0);
    const int maxIterations = 256;
    int iterations = 0;

    for (; iterations < maxIterations; iterations++) {
        z = float2(
            z.x * z.x - z.y * z.y,
            2.0 * z.x * z.y
        ) + c;

        if (length(z) > 2.0) {
            break;
        }
    }

    if (iterations == maxIterations) {
        return half4(0.0h, 0.0h, 0.0h, 1.0h);
    }

    return half4(palette(iterations), 1.0h);
}

I’ll save you scrolling up, we’ve done something really simple: we’ve taken this one line out of the shader, and passed it through SwiftUI instead.

float2 center = float2(-0.6, 0.0);

And, the result is… nothing different from before. Don’t say I didn’t warn you.

9. Dragging around the screen

We’re nearly there. One more until the big one. We just need to make the centre property mutable in SwiftUI by implementing a drag gesture.

struct MandelbrotView: View {
    @State private var center = CGPoint(x: -0.6, y: 0.0)
    @State private var currentCenter = CGPoint(x: -0.6, y: 0.0)
    @State private var viewWidth: CGFloat = 1000

    var body: some View {
        Rectangle()
            .fill(ShaderLibrary.mandelbrot(
                .boundingRect,
                .float2(center)
            ))
            .onGeometryChange(for: CGFloat.self, of: \.size.width) {
                viewWidth = $0
            }
            .gesture(
                DragGesture()
                    .onChanged { value in
                        let unitsPerPoint = 5.5 / viewWidth
                        center = CGPoint(
                            x: currentCenter.x - value.translation.width * unitsPerPoint,
                            y: currentCenter.y - value.translation.height * unitsPerPoint
                        )
                    }
                    .onEnded { _ in
                        currentCenter = center
                    }
            )
            .ignoresSafeArea()
    }
}

Hopefully nothing new here: we add a gesture, and update the centre property passed into the shader as it changes by taking away the (scaled) translation from the original center value.

We’re scaling the translation by dividing the horizontalSpan of 5.5 from before (the number line from -3.35 to 2.15), by the number of screen points, so we can scale the screen’s points to “units” on the number line.

I computed viewWidth, the number of points along the screen, using onGeometryChange because GeometryReader is a cesspit of snakes which I try to avoid at all costs 🐍.

Now we can start to dynamically shift the camera about with a finger.

Ok, you ready for the big finale? Things are about to get bonkers.

10. The Mandelbrot Zoom™

I saved the best to last. This is what a Mandelbrot app is all about. Victory lap. Cheers for sticking with it. To magnify our fractal, we need to create a pinch-to-zoom gesture, and pass the zoom level to our shader.

struct MandelbrotView: View {
    @State private var center = CGPoint(x: -0.6, y: 0.0)
    @State private var currentCenter = CGPoint(x: -0.6, y: 0.0)
    @State private var viewWidth: CGFloat = 1000
    @State private var horizontalSpan: CGFloat = 5.5
    @State private var currentSpan: CGFloat = 5.5

    var body: some View {
        Rectangle()
            .fill(ShaderLibrary.mandelbrot(
                .boundingRect,
                .float2(center),
                .float(Float(horizontalSpan))
            ))
            .onGeometryChange(for: CGFloat.self, of: \.size.width) {
                viewWidth = $0
            }
            .gesture(
                DragGesture()
                    .onChanged { value in
                        let unitsPerPoint = horizontalSpan / viewWidth
                        center = CGPoint(
                            x: currentCenter.x - value.translation.width * unitsPerPoint,
                            y: currentCenter.y - value.translation.height * unitsPerPoint
                        )
                    }
                    .onEnded { _ in
                        currentCenter = center
                    }
            )
            .simultaneousGesture(
                MagnifyGesture()
                    .onChanged { value in
                        horizontalSpan = min(max(currentSpan / value.magnification, 0.000_01), 5.5)
                    }
                    .onEnded { _ in
                        currentSpan = horizontalSpan
                    }
            )
            .ignoresSafeArea()
    }
}

Since the gesture is interactive, we need to store both a currentSpan to store the “original” value and horizontalSpan to track the “live” value during a pinch gesture, overwriting the original value onEnded. You can also handle this with @GestureState, but the code ended up way harder to follow. Our centre-point computation in the DragGesture now uses this dynamic span from magnification to calculate unitsPerPoint.

To implement the pinch gesture, we use the run-of-the-mill simultaneousGesture API to add an additional gesture to the view, MagnifyGesture, which tracks a magnification multiplier interactively. A magnification of 2 halves the visible horizontalSpan, zooming into the fractal.

This horizontalSpan property represents the length across the number line traversed by our camera’s zoom level. Again, none of the maths changes. All we’re doing is extracting our hardcoded horizontalSpan from before and making it an argument to our shader.

[[ stitchable ]]
half4 mandelbrot(
    float2 position,
    float4 bounds,
    float2 center,
    float horizontalSpan
) {
    float2 size = bounds.zw;
    float2 offset = position - bounds.xy - size * 0.5;

    float unitsPerPoint = horizontalSpan / size.x;
    float2 c = center + offset * unitsPerPoint;

    float2 z = float2(0.0, 0.0);
    const int maxIterations = 256;
    int iterations = 0;

    for (; iterations < maxIterations; iterations++) {
        z = float2(
            z.x * z.x - z.y * z.y,
            2.0 * z.x * z.y
        ) + c;

        if (length(z) > 2.0) {
            break;
        }
    }

    if (iterations == maxIterations) {
        return half4(0.0h, 0.0h, 0.0h, 1.0h);
    }

    return half4(palette(iterations), 1.0h);
}

We pin the horizontalSpan between 5.5 units (at max zoom-out) and 0.00001 (for max magnification). You’ll see why in a moment.

Totally mesmerising, until… I guess until it isn’t.

Subscribe now

The end of the line

That minimum horizontalSpan across our number line is 0.00001 because, at this point, we run out of precision when performing recursive complex analysis with float32.

Once we zoom in far enough, with a tiny horizontalSpan, neighbouring pixels at this precision round out to the same complex number, giving us pixellated rectangular blocks at this limit.

This is the end of the line for the neat, code-golfed, 90-lines-total app we set up today. But for those willing to ask nicely for thousands more lines of code, we can try out some more computationally elaborate solutions.

There’s a mathematical trick called perturbation which allows us to zoom to arbitrary levels of precision without melting the GPU.

We can use representations other than float32 (Metal doesn’t have a float64, and if it did, that just kicks the can down the road). We instead store complex numbers as chunks using an array of numbers, allowing for arbitrary precision, and hand-roll* the resulting complex square maths. As we go deeper, we compute one ultra-high-precision “reference orbit” in the centre, and calculate other pixels on-screen as tiny deviations from this reference, which can be done drastically faster.

*“hand”-roll

I almost got through a whole article without mentioning UIKit

Naturally, I thought to myself “can UIKit can help polish our app?”.

We can actually replace the SwiftUI gestures with a UIScrollView to handle gestures like 1-finger pan, 2-finger pinch, the deceleration physics you know and love, as well as add a million free, invisible, optimisations like “protecting against accidental flings when a pinch ends” and “stopping an accidental pan when one finger in a pinch gesture lifts up first”.

Now, it was time to unplug my maths brain and plug in my product brain, and implement a number of neat quality-of-life features.

• The biggest win was separating gestures from drawing: this meant the main thread kept free to handle panning and zooming around the fractal, with perfectly smooth drawing on the GPU. Pan gestures translate the whole image we’ve drawn, and pinch gestures zoom into the existing painted pixels, rather than forcing each single pixel to re-compute immediately when the UIScrollView moves.

• Because the maths slows down the deeper we go, I computed pixels middle-out so you can keep zooming before all the maths finishes.

• I added pre-installed reference zooms, the ability to save and auto-zoom to new features of the fractal like the Elephant Valley or Seahorse Valley, and lots of colour palettes (some with new post-processing shaders on top of the view itself)

• I implemented automatic zooming, so a tap anywhere will automatically zoom towards a random edge in that direction, forever. This was huge because it made it possible for my kids to play with it. It worked with a tiny GPU readback to locate boundary details.

• This caused a lot of jitter between computed frames, so I set up a dynamic algorithm to learn, through each iteration, how quickly your GPU was processing everything, allowing for a smooth, auto-adjusting zoom velocity.

• I implemented caching for pre-installed and saved zooms, so a lot of the heavy maths was ready up-front, making subsequent zooms quicker. It took a bit of experimenting before I relegated work like GPU readbacks, compression, and disk writes to a background job to avoid it eating drawing cycles while a user was moving around.

• At some deep zooms, the fractal turned into noise because adjacent pixels had drastically different numbers of iterations before escaping. Instead of hardcoding integer iteration counts, I used the magnitude of z when it escaped as well as the integer iteration count, to compute much smoother gradations. I also applied a log to the number of iterations at deeper zooms to smooth out the speed of colour changes. See before this fix (top) and after (bottom).

You can actually apply this to the code-golfed version above with a 2-line change: adjust the shader to accept float iterations in palette() and apply logarithms to the argument.

half3 palette(float iterations) {
    float phase = 0.30 * iterations;
    return half3(
        0.5 + 0.5 * cos(phase + 2.0 * M_PI_F / 3.0),
        0.5 + 0.5 * cos(phase),
        0.5 + 0.5 * cos(phase + 4.0 * M_PI_F / 3.0)
    );
}

[[ stitchable ]]
half4 mandelbrot(
    float2 position,
    float4 bounds,
    float2 center,
    float horizontalSpan
) {
    float2 size = bounds.zw;
    float2 offset = position - bounds.xy - size * 0.5;

    float unitsPerPoint = horizontalSpan / size.x;
    float2 c = center + offset * unitsPerPoint;

    float2 z = float2(0.0, 0.0);
    const int maxIterations = 256;
    int iterations = 0;

    for (; iterations < maxIterations; iterations++) {
        z = float2(
            z.x * z.x - z.y * z.y,
            2.0 * z.x * z.y
        ) + c;

        if (length(z) > 2.0) {
            break;
        }
    }

    if (iterations == maxIterations) {
        return half4(0.0h, 0.0h, 0.0h, 1.0h);
    }

    return half4(palette(iterations + 1 - log2(log2(length(z)))), 1.0h);
}

• Having fully-loaded Fable 5.1 and GPT-Astra-6.0 subscriptions helped me out tremendously. I could trivially request research into countless open-source Mandelbrot implementations to find maths optimisations I missed, perform adversarial reviews of my existing work, and study existing apps on the store to locate any features I forgot (such as pinch to rotate, whoops).

• I noticed that some store apps listed 10²⁰⁰⁰x zooms. If you’re doing the maths right, you can obviously go to arbitrary, infinite, levels of precision, but I stupidly only listed 10¹³⁸x. Not good enough! So, naturally, I researched more deep points-of-interest and now I market myself as 10¹⁰⁰⁰⁰x (or 10¹⁰ᵏ).

• Finally, the auto-zoom into random edges and previously-saved areas still felt a little janky to me, even with the smoothing algorithm. All our main-thread-saving optimisations with UIKit gestures and preventing redraws on the GPU made manual pinch-to-zoom feel much more performant. So I re-worked the auto-zooming implementation, kept the caching, but forced it to behave like the gesture-based manual zooming. And boy is it fast now.

Alright, I reckon we’re done here. Give it a look!

Download "Ultra Mandelbrot" here

Last Orders 🍺

This article has been on my agenda for years. I’ve got that special flavour of autism that makes the Mandelbrot set catnip to me. What do you mean that nobody in history has ever seen this edge before? There’s a certain romanticism to it.

The Mandelbrot set is the coolest thing in mathematics because it creates infinite complexity from an extremely simple rule: square and add c, recursively.

I hope you’ve enjoyed our romp through Metal shaders, from the basics of painting a pixel on your SwiftUI, to our initial Mandelbrot computation, to applying camera semantics to introduce pan and zoom gestures to explore the fractal.

I may or may not have gone a little overboard with the subsequent optimisations over the last few weekends, the code from which I will not darken the daylight by sharing. But you’re welcome to download the app!

Download "Ultra Mandelbrot" here

(The name Metal Mandelbrot was taken 🥲)

Sponsored Link

Is your mobile app under attack right now?

Discover why real-time threat monitoring is crucial to your cybersecurity posture through a simulated attack demo.

Join GuardSquare on Oct 20th to uncover why threat monitoring is essential to the complete, end-to-end protection of your mobile app.

Sign up here.

I recently got a new car, for the first time in my life. I won’t tell you which, because I’ll be cancelled. But it felt like a spaceship compared to my second-hand 2017 Toyota Aygo: a car whose design was frozen in 2013, that was manufactured in 2016, and purchased by me in 2019.

Inconveniences I took as a fact of life, like manually connecting my phone via Bluetooth each time, evaporated. Incredibly, I no longer even have to pause and unpause my music, over and over, to get the audio session to transfer over to the car speaker.

But Bluetooth is sooo 1997. Literally. Or, arguably, perhaps it’s sooo 958.

This is no longer the only game in town when it comes to getting hardware to chat to each other. My shiny new car (that I totally did not scratch on day 2 of owning it, please don’t look at the thumbnail too closely) actually uses a wide range of modern wireless communication tech, such as:

• NFC (near-field communication)

• BLE (bluetooth low energy)

• UWB (ultra-wideband)

Some of these are protocols, some are specific radio standards, some require custom physical hardware work. But each 3-letter initialism is essentially a marketing term for an umbrella of wireless technologies that work at different layers.

Ok. So. Today…

• I’ll demystify (I miss when we were still allowed to say that) these technologies so you get the gist of how they work.

• With some nifty hardware I procured, I’ll give you a live demo to show what these technologies are useful for.

• I’ll show real, working code that allows you to interact with these technologies in your apps today.

Sponsored Link

Let agents pick up mobile issues proactively

Your agents are getting good at fixing things, but humans still have to monitor, review, and assign issues first. Triage by Runway pulls every mobile issue into one inbox: test results, beta feedback, reviews, crashes, and more. Then auto-assign, or let agents connect via MCP to pick up fixes. Read more here.

Once we’ve mastered short-range wireless communication technology, I’m going to put all these pieces of hardware together to implement the player-to-player communication system from Dark Souls and Elden Ring… in real life.

This involves writing hidden messages on the ground that users can search for, unveil, and read to get a handy tip (or perhaps a not-so-handy one). Users can then leave their own messages for the next players!

Contents

• NFC

• Implementing NFC in your app

• BLE

• Implementing BLE in your app

• UWB

• Implementing UWB in your app

• Putting it all together

• Last Orders

NFC

NFC, or near-field communication, is a family of short-range wireless standards that operate at 13.56MHz radio frequencies. It’s a specific branch of radio frequency identification, or RFID. You use it every day you pay with contactless, Apple Pay, or even download an App Clip!

NFC is very useful for reading and writing low-bandwidth information at centimetre-scale, i.e. deliberate, range.

But NFC doesn’t just use the device radio. And it works even if one partner is un-powered. It does something genius, using Faraday’s law of induction:

Get it?

Right, for those that don’t have their second-year electromagnetism course fresh in their mind, this law basically shows that you can generate an electric current, at a distance, by moving a magnetic field through a coil. It’s only how the global power grid works.

In an NFC interaction, the powered reader/writer produces a changing magnetic field that produces a voltage across a wire coil in the passive NFC tag. This drives a current and powers the chip, allowing it to accept a signal and read/write data.

This magnetic field, as well as oscillating at the 13.56MHz NFC frequency, also encodes information in its amplitude, so powering and writing happen simultaneously!

Now let’s take a look at how to implement NFC in your own apps using CoreNFC.

Read more

Modern life is an impossible luxury. You have a king’s ransom of salt and spices in your home, clumpy from neglect. These were once worth their weight in gold, and abundance has relegated them to the slithy toves of ALDI. It took centuries of globalisation to transform spice into an everyday commodity.

In the early 2000s, I read a tabloid profile of a lottery winner: “I might buy my son a video game”. The journalist guffawed, “you know you could pay a company to build him his own game!” A hilarious extravagance. And yet in the last ~year, something you can just do, the price collapsing from $millions down to $20/month.

AI Psychosis has never been so cheap.

When you’re set up properly… you can do some pretty bonkers stuff. I’ve become obsessed with vibe coding VR games, auto deploying them to the web, and playtesting to iterate. In short, I want to share my descent into VR psychosis with you.

Can’t read? Just want to play some VR games? I got you covered:

Play my VR games here

With a game, you know within 10 seconds if you’re into it. A compelling story and overarching goal are great: rescue the princess. But even more critical is an engaging primary gameplay loop: jump on a lot of Goombas along the way.

Iterative game generation is the fastest way I’ve found to hone taste. In a new world underpinned by agentic engineering, it’s the most defensible skill of all.

Here’s what you might get out of this (somewhat meandering) life story:

• How I ended up regularly shipping VR games from the pub.

• How to set up an auto-deploying web game generation pipeline.

• A rapid, handsfree way to develop taste.

Contents

• Fatherhood and Inspo

• The Reluctant Web Developer

• My Automation Pipeline

  • Voice Prompting

  • Claude Remote Control

  • Git, Vercel, and Cloudflare

• VR Psychosis

  • The final moving part

• Building my own VR Games

  • Star Crusader

    • Iterating towards a secondary gameplay loop

  • Rampart

  • FrostFlame

  • Star Miner

  • Balloon Thunderdome

• Whoops, I forgot about my kids

• Last Orders 🍺

Subscribe now

Fatherhood and Inspo

Allow me to jump back a few months in this deeply untethered narrative.

My first brush with this came not from nascent VR psychosis, but from wanting to be a fun dad. A fun dad in tech.

Many parents guiltily give their kids access to electronics when they need a breather. My daughter, between spats of dodgy YouTube slop, is partial to a balloon popping game. On a whim, I thought to myself: this is total dogsh*t. I could do much better than this. So I opened Claude and asked it to make a balloon popping iOS app with powerups.

My fatherly vision of giving my daughter a flavour of this impossible dream: to become equal to a lottery winner, dictating the terms of a video game built before her eyes… might have missed the mark. Teamwork. User research. Bonding.

Did my daughter start playing the upgraded version of her own accord? No. Did she like it more than the (crap) original? Also no. But I got some super useful lessons about performing user research on a 5-year-old:

“Make it better. Make it less bad. It’s boring.”
—Lyra, 2026. Thanks, Lyra.

The Reluctant Web Developer

Later that weekend, at a kid’s birthday party, while trying to desperately find testers to get in on the balloon action, I had a crushing realisation: I can’t iterate as fast while tied to iOS.

Sitting in my home office, neglecting my kids, as I voice-prompt an agent to build a new power-up, is all well and good, but deeply limiting to iteration speed.

Apple doesn’t exactly help themselves here either. The web, for all its faults, is (by a drastic margin) the easiest way to deploy things.

Easier… after some annoying admin.

My Automation Pipeline

Indulge me with another tangent, so I can set the scene. It’s relevant, I’m trying to explain the level of handsfreeness we’re playing with in 2026.

It was May 12th. My birthday. You can send me gifts here btw.

I was at the pub. A friend reminded me of a bit I used to do when I was 18 (which, for the record, I do not remember) which I employed in my eternal quest to be really annoying. When I’d make an edgy joke, I’d obnoxiously open an app called “Privilege Checker”™ to l a checklist (white, straight, cis, etc, etc), and, having checked my privilege, would deploy my moderately offensive joke. It’s all about the timing, you see?

I chuckled at the alleged memory, and then, in my brooding, mysterious way, walked outside for a moment. I came back a few minutes later and shoved this web app in my friend’s face.

I can’t really take credit for this: I own no inference clusters, I have no complex pipeline, and I’m not personally touching Git on a Friday night. I just orchestrate moving parts that greater minds created. I’m just the glue. Specifically, the glue is my mouth.

Voice Prompting

Typing? Okay, grandad. Back to the nursing home with you.

It’s crazy how much my workflow has changed since adopting voice-dictation tools. The vast majority of my day-to-day work is meanderingly mumbling into a microphone, and then code comes out the other side.

This is great for fast, messy iteration and field research. You emit a stream of consciousness and get something useful out the other side. Assuming there’s a model capable of interpreting your genius.

This is rad for the one-shot approach. But also great for iteration.

I get solid results with Wispr Flow and Granola. Wispr Flow is better for rapid live-testing loops where you’re tasting your own dog food and giving live shot-calling dictation. Granola is better for set-and-forget long-form user research.

Claude Remote Control

This works with Codex too, but I try to save my credits for important stuff.

The /remote-control command, alongside caffeinate (to stop your machine falling asleep), become the poor man’s OpenClaw. You can prompt Claude in a folder on your machine from the app.

I say the poor man’s OpenClaw. It’s probably more like the poor man’s Mac Mini. I don’t quite feel dropping £799 is worth the luxury of not closing my clamshell.

That said, once I got into the throes of VR psychosis, I got close.

Unshackled from my home office, I can dictate commands to my agent from the pub. Naturally, my agent has git access, able to push straight up to my repo and deploy.

Git, Vercel, and Cloudflare

The 3 amigos.

Frankly, if you held a gun to my head, and told me to explain what Vercel does or you’ll blow my brains out, my last words would be a curse upon Vercel. I kinda reckon it hosts web servers, but don’t take my word for it.

With some slightly annoying admin, you can make it so every git push automatically goes through to Vercel and gets deployed. So… I guess it’s a CI service?

Cloudflare is a DDoS protection service, which for some reason also does domain registration. I set up a CNAME for the subdomain games.jacobstechtavern.com that keeps my wildest ideas airgapped from my colleagues at Granola.

This basically means for my jacobstechtavern.com domain, I can easily create subdomains, and Vercel routes the deployed web pages there.

Vercel and Cloudflare work together in ways I simply cannot comprehend, but they steam a good ham.

The point is that, now, the cost of deploying is zero. The cost of implementing is also zero. The cost of putting my thoughts into a computer is reduced to a moment of mumbling. Thus blurs the line between ideas in your head and working software in your hand.

Subscribe now

VR Psychosis

Now I can explain the worst avoidable motion sickness I’ve ever given myself.

The fan-made Attack on Titan VR game. You fly around and kill big fellas with swords.

There are many degrees of freedom in VR: 2 triggers, plus face buttons, in each hand, with 360° range of motion for each hand.

The traversal mechanics in Attack on Titan VR involved shooting a cable at a wall. The other trigger reels you in, building momentum. The simple physics alone here allowed for incredibly dynamic motion. I couldn’t stop playing, for hours, acrobatically spidermanning through a city, until I was completely floored by the motion sickness that had been building up as my brain fell over trying to reconcile my senses of sight and balance.

I digress. Traversal mechanics are fun. They are a huge component of a primary gameplay loop: the moment-to-moment enjoyment. See Mario 64: the devs spent half of development working on 3D motion, making the space fun to move around in. They didn’t even begin building the levels in Peach’s Castle until they perfected the ability to jump about and handle the camera in a 3D space.

The final moving part

Now, a friend at work showed me something that he vibe coded that ties this all together.

He put a VR headset on my head and showed me a fun little space where I could shoot little Granola logos at targets. We’ll find a business use case soon, I’m sure.

He gave me an insight I didn’t know before: it turns out that it’s really easy to vibe VR games and deploy them online using Three.js, WebXR, and Vite. Whole VR games.

It’s time to tie these threads together.

Automated web deployment.

Traversal mechanics.

Vibe-coded web-based VR games.

Read more

To use a tired cliché, I don’t like drawing inside the lines. This causes my 5-year-old to get incredibly f*cked off with me when I try and express myself.

Apple used to give you a book on your first day as an iOS engineer. The Swift Programming Language. Since Swift 5.8, it’s no longer available as a book, because it would be over 4,000 pages. Chris Lattner is rolling in his grave.

This blog post is for devs who aren’t afraid to reach around in the septic tank behind the compiler to locate their ring. Who aren’t cowed by petty concerns like mild App Review rejection risk. Devs who, most importantly, have the cojones (the balls) to step outside the sandbox offered to you by a type-safe memory-safe baby-mode language.

Today I’m sharing 7 facets of iOS you might never have encountered before. Some are useful in your day-to-day. Most won’t be. But all teach an interesting lesson about iOS.

Reflection & _UINavigationBarPalette
(You can learn a lot about framework internals at runtime.)

ARM64 & Machine Code
Your code ultimately turns into low-level instructions, fed into a CPU.

Mach APIs & the CPU
It’s possible to talk to hardware

Dynamism & objc_setAssociatedObject
Swift is built on 5 decades of ObjC foundations

CAEmitterLayer & Design Risks
You are just scratching the surface of what’s possible onscreen

Unmanaged Swift & Ancient Frameworks
Most of the underlying libraries in MacOS and iOS are C

_UIPortalView & Liquid Glass
Liquid Glass isn’t magic

Reflection & _UINavigationBarPalette

You can learn a lot about framework internals at runtime.

Here’s a picture of me and Seb Vidal at a recent Apple event!

Seb knows more than anyone about UIKit internals, mostly through the most straightforward kind of reverse engineering: runtime reflection using Objective-C selectors.

Most of Apple’s frameworks are Obj-C based. Thank John Sculley, Steve Jobs, and NeXT for that. This makes frameworks like UIKit more-or-less transparent, for those with eyes to see.

Dynamically picking selector strings at runtime is the linchpin of private API work. In your Swift code, you never lost access to the Objective-C runtime: just call NSClassFromString, NSSelectorFromString, and all their friends to initialise underscored classes and “private” APIs.

import UIKit

let tabs = AnimatedTabSelector(titles: ["For You", "Following"])
tabs.frame.size.height = 56

let cls = NSClassFromString("_UINavigationBarPalette") as! UIView.Type
let palette = cls.perform(NSSelectorFromString("alloc"))!.takeUnretainedValue()
    .perform(NSSelectorFromString("initWithContentView:"), with: tabs)!
    .takeUnretainedValue()

navigationItem.perform(NSSelectorFromString("_setBottomPalette:"), with: palette)

Seb’s pride is the _UINavigationBarPalette, which lets you attach arbitrary views onto a navigation bar, but without losing the useful a11y, size transitions, and automatic layout that makes most custom UI so Temu-esque. Apple uses this a ton internally for apps like Calendar, Fitness, Photos, and Messages but jealously guards it from mortals.

See Seb’s original tweet (and give him a follow!) here:

App Review can always ding you if you muck around with private APIs, but (we were not lawyers) Seb reckons you’re basically probably alright. More or less.

I’ve chatted (recently!) about using private CAFilter API to add design flourishes to nav bars before:

If you want to go harder with reverse engineering, there’s a way to do so with pure-Swift frameworks as well.

ARM64 & Machine Code

Your code ultimately turns into low-level instructions, fed into a CPU.

This is another hidden gem I found via a Tweet: the incredibly cracked p-x9 created a library and a macro that lets you run raw ARM64 machine code inside your apps. It’s not exactly a built-in Apple framework, but learning about assembly is a bucketlist item for all serious engineers.

The library is two components:

swift-assembly does the complicated ARM instruction set translation: parsing assembly strings, validating instructions & registering against its ARM64 instruction catalog, then encodes them into machine code bytes: [UInt8].

swift-asm-macro is the tidy API surface; running during compile-time, calling ARM64Assembler.assemble(source) in swift-assembly, and emitting them into the executable.

Here’s a couple of simple examples to get you going with instructions and registers:

@Asm(
    """
    add x0, x0, x1,
    ret
    """,
    arch: .arm64
)
func add(_ lhs: Int64, _ rhs: Int64) -> Int64

This sums the input values in the x0 and x1 registers, places the result into x0, and returns it.

@Asm(
    """
    cmp x0, x1,
    csel x0, x0, x1, ge,
    ret
    """,
    arch: .arm64
)
func armMaximum(_ lhs: Int64, _ rhs: Int64) -> Int64

cmp and csel compare the inputs in the x0 and x1 registers, place the larger value into x0, then return it.

The library assembles these assembly instructions at compile-time and uses section placement control to insert them into your app’s compiled MachO binary, called via a @convention(c) function pointer.

The expanded macro itself is pretty cool, if you’re a huge nerd:

@Asm(
    """
    add x0, x0, x1,
    ret
    """,
    arch: .arm64
)
func add(_ lhs: Int64, _ rhs: Int64) -> Int64
#if arch(arm64)
@used
@section("__TEXT,__text")
nonisolated(unsafe) var __asm_add: (UInt32, UInt32) = (
    0x8b010000,
    0xd65f03c0
)
#else
#error("@Asm storage __asm_add was generated for arm64.")
#endif
{
    #if arch(arm64)
    typealias __AsmFn = @convention(c) (Int64, Int64) -> Int64
    let f = withUnsafePointer(to: &__asm_add) {
        unsafeBitCast($0, to: __AsmFn.self)
    }
    return f(lhs, rhs)
    #else
    #error("@Asm function add was generated for arm64.")
    #endif
}

We can create a slightly more interesting example: a screenshot difference engine. I’m re-writing parts of Granola in UIKit, and want to work out whether we’re pixel-perfect or not. This function compares every colour byte across 2 images, and returns red if they aren’t equal:

@Asm(
    """
    movi v2.4s, #0                     // start four running pixel counters at zero

    loop:
      ldr q0, [x0], #16                // load four before pixels; advance x0
      ldr q1, [x1], #16                // load four after pixels; advance x1
      eor v0.16b, v0.16b, v1.16b       // matching bits become 0; differences become 1
      cmtst v0.4s, v0.4s, v0.4s        // changed pixels become 0xffffffff
      str q0, [x3], #16                // write four pixels into the output mask
      sub v2.4s, v2.4s, v0.4s          // subtracting -1 adds one to that lane's count
      subs x2, x2, #1                  // consume one four-pixel batch and set flags
      b.ne loop                        // repeat until every batch is processed

    addv s2, v2.4s                     // combine the four lane counters into one total
    umov w0, v2.s[0]                   // move the total into the ARM64 return register
    ret                                // return to Swift
    """,
    arch: .arm64
)
func armPixelDiff(
    _ before: UnsafePointer<UInt8>,
    _ after: UnsafePointer<UInt8>,
    _ batchCount: UInt64,
    _ mask: UnsafeMutablePointer<UInt8>
) -> UInt64

See the full Github Gist, including full CoreGraphics code, here.

And when we look at the results… perhaps we still have some way to go!

Let’s be clear: the Swift compiler is pretty well-optimised, and so you will be unlikely to need to use raw assembly to improve performance. This example is fun, but way slower than basic CoreImage APIs that get to use the GPU.

Read more

When I start a new job, I like to quickly make a name for myself as the “app size” guy.

This means proactively investigating the app bundle, proposing steps to make it slimmer, and implementing them in our next release. I do this for a few reasons:

• It’s easy.

• It’s quick.

• It’s fun.

• Hopefully, nobody else thought to do it yet *if it’s a startup.

• It’s visible and comprehensible to non-technical stakeholders.

  • Especially if your work impacts install rate.

Today I’m showing you a new, free, open-source, fully private, in-browser tool to help you optimise your own app bundle. I’ll explain how it works, and along the journey we’ll go through a real-life worked example: how I optimised Granola’s iOS app size by ~40% in my first week.

By the end, you’ll have a clear to-do list to optimise your own app and look like a total genius in the process.

Sponsored Link

Recently shipped an app? Enter it in Shipaton 2026

Recently launched a mobile app? Put it in the spotlight at Shipaton 2026 — RevenueCat’s global hackathon for builders who ship real apps to real stores. Compete for over $1M in prizes and show the world what you built. Entries close September 30.

Contents

• OpenBundle

  • How it works

• The Low-Hanging Fruit

  • Before & After

  • Duplication

  • Asset Sizing

  • Binary Symbols

    • Stripping binary symbols

    • Symbol metadata

  • Dynamic vs Static Frameworks

  • Swift Optimisation Modes

• Automation & Regressions

• How to spy on your competitors

• Last Orders 🍺

OpenBundle

OpenBundle is a cool new tool that analyses your app bundle and gives you recommendations for the most impactful ways you can optimise your app size.

It’s open source, lives entirely in your browser, works fully offline, and has no backend, so your privacy is guaranteed.

View OpenBundle

How it works

An .ipa is basically a .zip file containing your app: code, frameworks, and resources. OpenBundle runs in your browser (running CPython via Pyodide) to expand the archive into a temporary filesystem, and processes every file to record their:

• path in the bundle

• size (zip-compressed and uncompressed)

• SHA-256 hash

Mach-O files, containing compiled Swift code, are parsed to read segments & sections, symbol tables, load commands, dyld export tries, linked libraries, run paths, build versions, encryption states, code signatures and entitlements.

Asset catalogues are parsed (using Rust tooling in WebAssembly), exposing asset names, dimensions, scales, encodings, opacity, sizes and image payloads. Browser image decoders can then lazily display previews, content hashes and real compression measurements.

OpenBundle now reconstructs the bundle’s directory hierarchy: Compiled code and assets are summed up to compute their parent folder’s size, and laid out in a hierarchical treemap: area represents data size.

If you think Elon couldn’t get any worse, he built a bloody React Native app

The rest of this article takes you through a real-life worked example of optimising an app bundle, which I implemented in my first week at Granola.

The Low-Hanging Fruit 🍒

Here’s your actual motivation: I wasn’t exaggerating above; between waxing lyrical about someday migrating away from SwiftUI and re-architecting our app modules, I did try to actually contribute something concrete in my first week at Granola.

Let’s look at some bundle-size X-rays. There are 2 numbers we care about:

Install size is how much disk space the thinned variant of your app takes up (before documents or data). Download size is the minimum amount of over-the-air network data required to install.

Before

80.9 MB install
48.4 MB download

3.5 hours of work later…

After

58.8 MB install (27% less)
28.1 MB download (42% less)

I achieved this through 5 straightforward fixes: low-hanging fruit that can apply to nearly every app:

• Handling duplication

• Optimising asset sizing

• Removing binary symbols and symbol metadata

• Choosing between dynamic and static

• (if needed) picking your Swift optimisation modes

Subscribe now

Duplication

This is simultaneously the most common app sizing issue, usually the heftiest, and most obvious. Fortunately, it’s also easy to fix with zero repercussions (usually!).

I noticed that Granola had a lot of asset catalogues highlighted in red, flagging them as duplicates.

Lo and behold, this is directly flagged in the recommendations.

What’s going on here?

Consider you have a second target in your app: a watch app, a widget, or perhaps a notification service extension. This often shares UI elements from your main app, usually a big shared UILibrary or DesignSystem module.

This is also, probably, where your biggest shared asset catalog lives.

Are you getting it?

You can fix this pretty easily by splitting shared Assets out into its own module, allowing the other target to import our design system code without statically copying the whole asset repo.

Or, bear with me here, if you prefer to avoid mucking around with your modular architecture and globally refactoring your assets, you can opt to suffer a tiny amount of code duplication to get your design system code, if you choose to accept the maintenance burden to keep them in sync (or want to jerry-rig some tooling to flag up changes).

It’s possible to share code between targets without duplication if we use dynamic linking - more on this later - but asset catalogs quite enjoy being static and are kind of a pain in the bum to convert into dynamic xcframeworks.

Duplication issues aren’t always trivial to fix, mind you.

Perhaps you share a full feature betwixt app and app clip, with a very deep underlying dependency graph. I once had to split a large existing module into 2 parts for exactly this reason, so one half fit onto a tiny 15MB app clip.

I almost didn’t mention, probably, the most common form of duplication: flat-out using the same asset in multiple asset catalogs across modules. This isn’t ideal, and you should probably find a lowest-common denominator module to share the asset, but also unless it’s a video the difference will be pretty negligible.

How OpenBundle does it

OpenBundle checks for duplication by hashing each file, and grouping these by their runtime bundle and byte size in a hash table.

If a bundle contains the same hash with the same size, we can pretty confidently highlight them as duplicates. If multiple bundles contain the same hash, it flags them for manual review.

Asset Sizing

This is the most obvious optimisation once I point it out to you, but there is a bit of nuance to unpack here.

Often the biggest optimisation we can recommend is simply compressing our images more efficiently, for example from png to heic.

Make sure to look carefully at the Assets.car unbundling in the treemap diagram directly, since you often find a few images taking up ‘surprisingly’ large amounts of space. Audit a few images yourself and work out if you can downscale or compress them without losing any visual fidelity.

Back in my first startup, Carbn, we stupidly exported some illustration assets as SVG, dramatically expanding these small images to insane 4MB sizes in the bundle. A very easy fix that saved us ~25MB in a single day.

Naturally, when compressing image assets, you probably want a designer to sign off on it: throw a side-by-side before and after onto an HTML page to ensure no quality is lost.

There is, ultimately, a trade-off before blindly replacing all your png with heic. The latter, while more space-efficient, can decode from disk a lot more slowly. As always, profile your code before listening to some guy on the internet.

Here’s an easy heuristic: PNG is great for interface assets and HEIC is best for photographic assets.

There are a few other image optimisations to consider:

• Avoid loose image assets in the bundle: asset catalogs enable app thinning.

• Videos are always heavy: work out the minimum resolution that still looks good on an iPhone or iPad screen.

• Many assets can be offloaded via background assets, on-demand resources or your own CDN.

• Assets are more than images and videos: if your font file is taking up 500kB, it probably contains letters from Greek, Cyrillic, or Arabic alphabets. Unless you’re very well-localised, you can open up the .otf in FontForge and trim the file yourself.

Fonts are handily highlighted in purple so you can easily investigate. Unless I’m really trying to squeeze the optimisation lemon I won’t worry too much if a font is under 200kB.

How OpenBundle does it

OpenBundle measures potential compression savings the obvious way: it picks the 80 largest assets, and generates an 85%-quality HEIC (or, if there is no alpha channel, JPEG) and checks the potential saving. It also searches for loose assets by finding files with @1x, @2x and @3x names and computing the difference when the smaller ones are thinned out.

Binary Symbols

Binary Symbols and Binary Symbol Metadata are the twin bundle-nerd issues that cruft up your bundle due to some quirks of the compilation process. If you know what you’re doing, they can be removed “for free” without changing your app.

But what are binary symbols?

“Symbols” are names attached to functions, classes and variables inside your compiled Mach-O binary. For a function doSomething(), it might be stored under a slightly mangled name like _$s5MyApp11doSomethingyyF.

The final stage of Swift compilation, static linking, resolves references in each binary, and notes down imports from external frameworks.

At launch, dyld (the dynamic linker) maps the app and frameworks into virtual memory, rebases these addresses, and binds the external imports from before into actual runtime memory addresses.

__LINKEDIT is a segment of your binary that contains data produced by the static linker, and used by the dynamic linker. But not all of it is needed for your app to work.

Read more

I am not here today to give you cryptic pointers about graphs and loops. I’ve got straightforward, battle-tested, practical tips you can implement today to squeeze the most out of your AI agents.

We no longer live in the coding flow-state. Today, it’s more akin to spinning plates. It’s just a different kind of flow.

Or, as this guy put it…

I’ve been all-in on agentic engineering for more than a year now. And yes, that includes multiple months in 2025 on the deeply mediocre early Opus 4.x models.

This post is a combo of practical productivity tips and specific situational techniques I’ve picked up. There’s a clear through-line: What I’ve learned more than anything is that using these tools is a skill, and if you’re proficient with them, you aren’t getting replaced anytime soon. Some of these skills include:

• Delineating “stuff they’re excellent at” and “stuff they are crap at”.

• Knowing how to kick off long-running work and run lots in parallel.

• Ultimately, taste for what good software & product looks like.

Contents

1. Never lose a session

2. How far can you go with verification?

3. Collaboration and ARGUMENT.md

   1. The Fast Lane

   2. The Slow Lane

4. Design Exploration

   1. Something with Character

   2. Refining the Aesthetic

   3. The Breakthrough

   4. Hitting the Limits

5. Unfamiliar Territory

6. (Lots of) Personal Software

   1. Tab Titles

   2. Zsh Shortcuts

   3. OpenBundle

7. Elevating your old side projects

8. Building at a higher level of abstraction

9. When the machines take over, I’ll be the first to die

This blog post is so full of knowledge that most email clients will cut it off. Please read on my website for the best experience.

Read on my website

Never lose a session

This sort of belongs in “(Lots of) Personal Software”, but I’m mentioning it first, because nobody does this, and it’s my biggest timesaver.

Seriously, give it a try.

Everyone knows you can call claude --resume or codex resume (I never remember which one needs the dashes), but you ideally need to be in the exact folder from the original session: you can search --all, but you’re on your own if you have multiple checkouts, git worktrees, or ad-hoc agent sessions.

Even on the Codex & Claude desktop apps, you need to know approximately where to look for. And god help you if you don’t recall which agent you used.

There’s a solution: use your agents to track your agents.

I set up an automated ledger of all my agent sessions, including folder, transcript, and resume ID. An agent can semantically search the ledgers to find older sessions by just asking:

“Find me the agent session that ran the review-pass thing and show me how to get back into it.”

…

cd /Users/jacob/checkouts/1/granola/ios && codex resume 019ecbcd-2d59-19e0-b8d1-a249622c98a5

You can do the same thing: just pass this prompt to an agent and it’ll just start working.

Get the prompt on GitHub

Most of the examples I demonstrate in this blog post were found using the above technique.

How far can you go with verification?

Pretty damn far, honestly.

You should (hopefully)* already know that the most critical unlock with agentic engineering is the verification loop. That is, giving your agent the ability to check its own work via:

• building and running the code itself

• checking visually against a design

• unit tests

*If this is news to you, please go ahead and read this free post now. Come back after. I’ll wait.

Automatic verification is the backbone of agent parallelism. Executing a plan and writing code might take a frontier model 5 minutes, maybe 10 for a whole screen.

But when you instruct them to check their work, that’s when you start to see 20 minute, hour-long, or even overnight working sessions. You can’t spin multiple plates unless your agents are checking their work. To maximise productivity, give your agent what it needs to execute and verify the work, then get out of its way and find another plate to toss on.

As agents get better and better, I find myself surprised by the amount I can delegate.

It’s more art than science how hard you want to cognitively offload, but you can optimise by trying to do as little verification work yourself. It’s the lazy man’s paradise. The more you can delegate, the longer your agents can run, and the more parallel plates you can spin simultaneously.

My favourite technique with feature work, is asking the agent to take screenshots of all its work, and then host these in a local HTML page.

HTML is just aesthetically the nicest way to review feature & design work. Here’s the verification page it created for the onboarding flow in my latest project, The Damage, a casino-inspired drink-tracking app:

I’ve gradually found ways to go a lot further:

1. Put the Figma design on the left side, implementation on the right side.

2. Alternatively you can ask for a slider to check directly between before/after.

   

3. Ask the agent to take a screen recording; especially nice for animation work.

4. If you’re trying to understand something, one of my all-time favourite techniques is asking the agent to generate an excalidraw diagram.

5. Often I’ll tell my Sol agent “when you’ve finished work, spin up a Fable agent and ask for a code review, and fix anything that doesn’t result in needlessly defensive slop”. Or vice versa if I’m using Fable. The “needlessly defensive” line is important, since an agent will always find 20 things, most of which are bloat.

5. For my pre-release polish pass, I requested an almanac of every screen in The Damage, hosted on a tiny local server, with a text box each.
   I gave detailed visual feedback on each screen individually, which was automatically linked to the specific screen.
   Sol-xhigh worked autonomously through the night (the first pass took 5 hours) to implement everything ready for App Review.

At this point, you can go pretty far without opening your app a single time.

If you’re doing things right, you’ll perhaps find yourself in a weird purgatorial zone at ~3pm: you’ve maxed out on 10ish terminal tabs, all of which are running without you.

Collaboration and ARGUMENT.md

It’s an inevitability in engineering that you often run into an insanely complex problem or incomprehensible mystery bug. Asking an agent to help just won’t cut it, especially if you’re rushing to solve an urgent bug in production.

The Fast Lane

When you really need to pull out the big guns, here is my secret weapon:

Read more

The best day of a man’s life is the day he gets his shiny new Apple Watch MK Ultra.

The worst day of a man’s life is the day he tries to develop for it.

This is my story.

• Watch Woes

• Aviator v3.0

• Distributed Systems

• CAP Theorem

• WCSession APIs

• Designing our Link

• A More Complex System

• Last Orders

Watch Woes

Apple does not pull any punches when it comes to watch devex. You can’t just connect a cable, it only works via Wi-Fi. Specifically, it only works if you happen to have 2.4 GHz Wi-Fi. Even so, Xcode probably won’t notice your watch for several hours. A̷n̵d̴ w̶h̷e̸n̴ i̵t̷ d̶o̵e̷s̸, i̴t̵ w̶i̷l̴l̵ t̶a̸k̵e̶ a̵n̷o̸t̴h̵e̶r̷ h̵o̸u̶r̷ t̴o̵ c̶o̷p̸y̴ c̵a̶c̷h̸e̴ s̶y̷m̵b̸o̴l̶s̷. W̴a̶n̷t̸ t̵o̷ g̶e̸t̵ a̶ t̷e̵a̸m̶m̷a̴t̶e̸’̵s̷ U̶U̸I̵D̷ f̸o̶r̷ a̵d̸-̷h̶o̵c̷ b̸u̴i̷l̶d̸s̵? G̷o̸o̵d̶ l̷u̸c̵k̶: y̷o̸u̵ h̷a̶v̸e̵ t̶o̷ g̸o̵ t̷h̶r̸o̵u̷g̶h̸ t̵h̷i̶s̸ w̵h̷o̶l̸e̵ r̷i̶g̸m̷a̶r̸o̵l̷e̶ a̸g̵a̷i̶n̸. I̵͎f̷̰ y̶̝o̸͇ṳ̷ h̴͕a̷̻v̸͔e̶̪ a̵͉ S̷̟E̶̞? A̸̖l̷̠l̶̬ t̵̗h̸͙e̷͕s̶͓e̵̩ p̷̱r̸̥o̴̘b̷̝l̶͔e̵̙m̸̞s̷̺ a̶̱r̸̫e̷͈ 1̴͍0̸̲x̶̥ w̷̘o̶͎r̸̦s̵͚e̷̩. O̵̪̓h̷̬͒,̸͉̄ a̶̻̽n̷̮͛d̴̞͝ T̷̹̾e̵̙͌ș̸̑t̶̝̓F̷̙̍l̴̗͆i̵̜͝g̷͚̒h̶̳͛t̵͖̔ w̷͍̍a̵̫̾s̸̖̒ p̷̬̿a̶͚͊r̸͙͗t̵̩͠i̷̜̿a̶͚͊l̷͙͗l̵̩͠y̸̬͋ b̶͔͝ȑ̷̲o̴̰͐k̶̺̐e̷̫͑n̴̹̽ f̷̙͆o̵̳͠r̴̟͗ s̵̡̬̐ę̶̺͝v̵̩͕͊e̷̪̝̽r̴̗͎̍ȁ̸̦̤l̷̢͙͋ m̵̬̹͂o̷̮͉̔n̴͇̦̒t̴̛̲͑h̵͇̼͝s̷̨̬͗ o̴̰̼̍f̸̧̖̪̍ ẗ̵̛͚͎h̶̡̤̳̽i̶̢̯͔̇s̵̗͙͐ ÿ̸̡͚̘́ę̷̮̘̾a̶͇͚͖͌r̶̢̗̺͛.

Subscribe now

Nevertheless, one speeds ahead. Probing one’s side projects for an excuse to make the most of one’s new toy. The good news: my one-and-a-half-year-old toddler has began getting really into planes when he sees them in the sky. We’re ready for round 2!

Sponsored Link

The world’s biggest mobile hackathon for people who actually ship

Shipaton 2026 is RevenueCat’s global hackathon for builders launching real apps to real stores, competing for over $1M in prizes, and showing the world what they shipped. Build, launch, and submit your app by September 30. Check it out here.

Aviator v3.0

For anyone unfamiliar with my most popular article ever, I built a skeuomorphic radar toy using SwiftUI, shaders, and open-source APIs to help locate nearby planes in the sky.

I re-implemented my radar as a Watch app!

This is a really cool miniature version of the full app, itself a neat SwiftUI wrapper over the OpenSky API.

But it doesn’t feel like an extension of my app. It feels like a little miniature version that runs totally separately. Because it is. This won’t please my dozen users. They have high expectations of me, for some reason. So let’s go back to basics.

At the very least, we should make sure the settings are shared between our two targets. This includes:

🗺️ The map/radar toggle
🇬🇧 The show/hide flags toggle
🔍 The zoom control
🎨 The colour selector

So we need our watch and our phone to talk. Like this:

But, like socially awkward British men (redundant phrasing), getting the two devices to communicate isn’t trivial.

iPhone and Apple Watch are separate systems: two small computers with their own file systems, their own secure enclaves, their own cell radios, and their own separate apps. These twin targets form a distributed system.

Each device is a writer node, both storing and mutating a replica of user settings.

Even the naïve approach introduces thorny state management problems. What happens to the data if my toddler and I modify the same settings on the phone and watch simultaneously? What happens to this data if they can’t connect? What happens when they do reconnect? What if the watch runs out of power, this reconnection takes a week, and an ancient settings change later propagates? Should our settings change happen instantly on each client or do we wait until the data is shared?

The mind boggles.

How am I, a lowly frontend developer, supposed to handle this?!

I threw my MacBook across the room in a fury.

And gasped.

The answer was right in front of me the whole time.

Subscribe now

Distributed Systems

Before they invented AI engineering, distributed systems engineering was probably the highest-status, most hardcore-sounding type of engineering out there.

(Us greybeards on mobile are a little over the hump since the glory days of the early 2010s).

It’s considered hard because, unlike building CRUD APIs, writing speedy single-node database queries, painting JSON, or setting up clean state management, there is often no simple solution to a problem.

CAP Theorem

The linchpin of distributed systems theory, that is, the root cause of our headaches, is CAP theorem. For a distributed system, that is, a set of nodes that store data, CAP theorem states:

Consistency = every node always has the same data.

Availability = every request to a node must always give a response.

Partition Tolerance = the system still works when nodes can’t communicate.

To achieve Consistency, all data mutation operations must be immediately applied to all nodes in the system before they return. For Availability, you need to give a prompt response to all valid operations, even if part of the system is down.

With distributed systems, partitions are inevitable. So partition tolerance is non-negotiable. This leaves us mucking about with the other 2. In the context of the Watch/Phone system, a partition might happen when Bluetooth is off, your watch ran out of battery, or you just left it on the train (f***!).

When this partition happens, you have to choose:

• Compromise on availability: throw errors because we can’t ensure consistency across all nodes.

• Provide availability at the expense of consistency by giving a best-effort response to operations, and syncing data across nodes when we can.

Recall my somewhat meandering descent into madness in the last chapter. Can you see how we can solve most of the problems by making a choice between consistency and availability?

This basic theory forms the foundation of distributed systems engineering. And now we know enough to design our twin radar apps.

Subscribe now

WCSession APIs

Apple created the Watch Connectivity framework to allow our devices to speak to each other. The system handles a lot of legwork, taking responsibility for data transfer across whatever medium (Bluetooth, Wi-Fi, cellular). Data transfer can be done in real time, or in the background if the app is inactive.

There are just a few WCSession APIs to choose from when transferring our data, and both nodes, phone and watch, can implement them, enabling bidirectional communication.

sendMessage() sends a dictionary of values, with closures for both replies and errors. This means you can use it to both send and request data, but it fails quickly if there’s a partition (i.e. no connection), as it needs a live counterpart to succeed.

This API allows us to achieve consistency if we need it, but not availability.

updateApplicationContext() also transmits a dictionary of values, called applicationContext, shared between the two nodes. The receiving node implements session(_:didReceiveApplicationContext:) to retrieve the latest data.

applicationContext is always going to have the most recent edit we made: treat it like a last-write-wins strategy. You can fire-and-forget this method, since it works even during a partition, delivering what it can once it’s connected.

This API offers us good availability and eventual consistency.

Read more

I try to avoid gushing on this blog, it’s not my brand, but the iPhone keynote in 2007 was probably the best corporate presentation of all time.

Jobs introduced the iPhone featuring multi-touch, multi-tasking, networking, power management, security features, graphics frameworks, motion sensors, a camera, and “desktop-class” email & web browsing.

“iPhone runs OS X” was regarded as a historic technical achievement (and a very handy marketing shortcut). In a decade defined by miniaturisation of technology products, Apple found a way to run computer-grade software into tiny battery-powered devices, converting Blackberries into antiques in one fell swoop.

How far we’ve come since 2007.

AI labs are busy invoking the machine god, while I, a moderately prolific mobile engineer, am having daily heated arguments about how to launch quickly or how to scroll without hitting an out-of-memory exception.

Uh. Anyway.

If you work in mobile, here’s 10 reasons why your life sucks:

1. Modular Architecture (that isn’t spaghetti)

2. Oh, you want to release?

3. Architecture Astronauts & Sync Engines

4. You are the OS’s b*tch

5. A phone is a coffin

6. Begging your users for core functionality

7. Multiplatform motherf*ckery

8. Your build system sucks (or does it?)

9. Peripherals & Distributed Systems

10. Nobody downloads apps anymore

This post is quite long, so your email client may cut it off. Read on my website for the best experience.

Read on my website

1. Modular Architecture (that isn’t spaghetti) 🍝

I always find it delightfully droll when people argue about screen-level architecture.

It’s not hard guys.

Pick an architecture, keep it consistent, bada-bing, bada-boom. Now anyone can onboard to your codebase without getting disoriented between screens. It’s a dull argument, and I’m tired.*

*That VIPER thought, amirite?

The architecture that matters, the one where you actually need to make interesting choices, is laying out your modules in the wider dependency graph of your project. And keeping it tidy.

Your modular architecture really solves an organisational problem: how can lots of people work on this project without stepping all over each other? Modules make it trivial to carve out ownership boundaries.

Smaller teams will probably still want to modularise. With tools like SPM or Tuist, it’s extremely easy to do so these days. Thoughtfully splitting your app into modules brings build time improvements and, more importantly, sparks joy when you look at your lovely unidirectional dependency graph.

When designing Granola’s modular architecture, I took a lot of inspiration from Tuist’s TMA (The Modular Architecture) and RevenueCat’s layered SDK.

As we ascend the agentic engineering abstraction ladder and get further from the code, keeping on top of system design is more and more critical.

2. Oh, you want to release?

Apple saw what happened to Microsoft in the 2000s.

Slowly, the impenetrable walled garden of their OS monopoly cracked and leaked as developers flooded to the freedom of the open web. Google ate their lunch across the successive tech cycles of web and mobile. Apple said, not I.

Distribution is everything. It’s the core reason Jobs pivoted from “HTML5 web apps are great for building on iOS!” in 2007 to the App Store in 2008. Devs who want to ship apps can’t get around Apple (except our friends at NSO Group), they need to ask permission every time they release.

App Review is ostensibly there for consumer protection: keeping a wash of slop off the Store. But we know it’s there to remind us who’s boss. We live and work under the imperious thumb of the ghost of god-emperor Steve Jobs. Or perhaps his middle finger.

This is why mobile teams usually skew a little older. We’re not really. We’re 30. We just lost all our hair because of App Review stress. Oh, to be able to ship in 30 seconds like our friends on the web. I hope you remembered feature flags.

Fun last-minute update to this section: this week I got possibly the most infuriating app rejection ever for my new drink-tracking app, “The Damage”

Instead of appreciating my genius custom tab bar for what it is, I got summarily rejected under “Spam” for building “primarily a drinking game app”, and they suggested I build a WEB APP instead 🤦‍♂️

Unfortunately, Apple failed to understand how autistic I get when I go on a warpath: I responded with a 3-pronged attack of replying, appealing to the App Review Board, and emailing a couple of my friends in DevRel to help correct the injustice. I got approved.

Oh, and this wasn't even close to my worst run-in with App Review: it nearly got me fired back in 2023. I worked for a startup building a consent-oriented data ingestion pipeline, where we got stonewalled and blocked from releasing for over 6 months.

3. Architecture Astronauts & Sync Engines

There comes a day in the life of every architecture astronaut where he (and yes it usually is a he) wakes up in a cold sweat: “OUR DATA. IT’S NOT ROBUST ENOUGH!”

Rapidly followed by a 16-hour Monster Energy Mango Loco™ binge, and subsequent 12,000 line PR (before it was cool), which lands without review and single-handedly introduces a jobs program to rival the New Deal, except the deal is that you fix a shitload of weird concurrency queue and database edge cases.

Read more

A lot of bangers. And a few duds.

With an overwhelming back-catalog (193 posts and counting!), how can I expect you to sift out the gold?

You no longer have to.

Over the last few months, I’ve been working on a roadmap to help you get to grips with my past work, pick a focus, and quickly level up your knowledge. A curated menu of articles targeted at each experience level.

View the roadmap here

I aim at 3 levels, but you can start anywhere you like: if you want to sharpen your knowledge of any topic, you now have a recommended start point.

🐣 Foundations

For devs looking to understand iOS fundamentals, hoping to break into a career, or build up a portfolio of side projects.

• SwiftUI & Side Projects

• Concurrency Fundamentals

• iOS Job Interviews

🚀 Levelling Up

For seasoned engineers shipping features, who want to sharpen the instincts and knowledge base that define the best senior engineers.

• Concurrency

• Architecture

• Performance

• Big Tech Interviews

• AI Engineering

• Shipping to Production

🧙 The Deep End

For hardened, jaded engineers who want to grapple with the machinery under iOS and Swift that we use every day.

• Swift Internals

• iOS Internals

• Advanced Concurrency

• The Dark Arts™

View the roadmap here

I’ll send the roadmap to all my new readers, but please take a look yourself! I’d appreciate any feedback and hope you find it a useful tool.

I’ve intentionally avoided treading the worn-out arguments about MVC, MVVM, MV, VIPER, and your favourite homegrown solution. I don’t consider it a gap in my blog content, because…

1. They aren’t very interesting to write about.

2. I don’t consider this proper “architecture”.

Your choice of screen-level file layout is just about consistency. Orienting yourself in an unfamiliar part of the codebase. Pick one, and stick to it. That’d be the whole blog post.

Proper Architecture™ is about the building blocks of our system, and how they fit together. It’s as much art as science. Draw boundaries and boxes across your codebase, and gerrymander until your dependency graph sparks maximal joy.

Today, we’re going down my long-awaited hit-list:

• The what and why of modular iOS architecture.

• Getting on the same page vis-a-vis dependency graphs.

• The good, the bad, and the ugly architectures I’ve experienced in 10 years.

• How I utilised this experience to design Granola’s modular architecture.

By the end, I hope to transfer some of my architectural instincts to you.

Subscribe now

Contents

• What is Modular iOS Architecture?

  • Build time

  • Code quality

  • Organisation problems

  • Modular solutions

  • Tooling and Libraries

• The Dependency Graph

• Modular Architectures I’ve Seen

  • Single Module

  • Core Module Architecture

  • Layered Modular Architecture

  • Naïve Feature Modules

  • The problems with feature modules

  • Service & Orchestration Layers

  • Feature Modules with API Contracts

  • Hyper-modular Architecture

• How I Designed Granola’s Architecture

  • A POC with big dreams

  • Architectural Pushback

  • This is My Design

  • The Big Refactor

• Last Orders

What is Modular iOS Architecture?

Many great iOS codebases begin as a big ball of stuff. One app, one target, one module, one project. Everything lives in one place, and making a new feature, service, or model is as simple as writing a file into a folder.

This works surprisingly well for longer than you’d think, but then you might start to feel the codebase pushing back on you.

Build time

As a monolithic module grows, small changes might invalidate a larger portion of the dependency graph (uh, dependency blob?). Incremental builds become… less incremental, code completion inevitably sloooows down, and Xcode struggles to cache reusable build outputs.

Code quality

With one module, you often cannot enforce meaningful boundaries at interfaces, because internal code (the default access control) is visible everywhere within that module. You need discipline and lots of private methods to avoid spaghettification.

You know what I mean if you’ve ever shamefully tasted that sweetest forbidden fruit: turning that private function internal just so the unit test can speak directly to it.

It’s also mildly cruel to deprive junior developers of their first change to legitimately use the public keyword. Or better, public private(set). You feel so badass the first time.

Organisational problems

Often an architecture grows to reflect the shape of the organisation maintaining it. Companies with a platform team will often have a big Core module. “Feature teams” will have modules split up along pod lines.

When teams, pods, tribes, scrums, etc, are divided by feature ownership, but the codebase has no corresponding boundaries, it gets muddy fast. Who owns those services, that model, or this infra? Engineers may step on each other’s toes, re-implement solutions twice, or design wholly different APIs.

Modular solutions

Dividing your app into modules gives your iOS app clearer boundaries between features and services, making the codebase easier to understand and explain. It allows you to enforce encapsulation, encourages reuse, and draws straightforward ownership boundaries across modules so tons of devs (or agents?) can work in parallel.

Modularity improves build times (usually!!*) by limiting how much code has to be recompiled after a change. If you edit one top-level feature module, Xcode can reuse its cached build outputs for non-dependent modules, compile independent modules in parallel, and cache more granular outputs.

*There can be too much of a good thing. Make your dependency graph too complex and interconnected with many tiny, poorly-bounded modules, or create loooong, deeply-layered chains of dependencies, and you’ll just slow things down instead.

We waited an appropriately long time to refactor Granola: I’ll go into more detail soon, but our ultimate modular redesign was motivated by a combination of 1) team growth and 2) some very specific pushback we were experiencing from the codebase.

Tooling and Libraries

When you want to modularise your app, the default is SPM. It used to be bad. It’s good. I like Tuist. Rolling raw Xcode projects are probably fine if you get Claude to manage the boilerplate. CocoaPods and Carthage are mostly-deprecated, you maniac. Don’t touch Buck or Bazel unless you are willing to open that particular Pandora’s box, and maintain it forever.

When you create a module, you need to choose whether you’ll use a static, dynamic, or mergeable library. These are incredibly important for modularisation, but very out of scope for this article. To make a long story short, pick between them to balance build speed, bundle size, and launch time. To make a long story long, you can read this classic of mine:

The Dependency Graph

One important concept in modularising an app: the dependency graph. Consider the modules as boxes or nodes along a graph. Yes, the data structure (you thought LeetCode was a waste of time?!). One node can’t compile unless all its dependencies, or imports, are compiled.

Your app builds the leaf nodes at the bottom of the graph, then modules depending on them, then modules depending on them, recursively, all the way up to your top level app module that ties everything together. While it can parallelise a lot of this, you can’t build a node without its dependencies. You get it.

This is why spaghetti architectures can slow down your builds: one tiny change can invalidate the dependency graph of dozens or hundreds of modules importing it across your graph.

Some of the architectures we’re looking at today are optimised with the Xcode Build system in mind. This is actually the core insight behind Tuist’s TMA and “Feature Interface” API contracts:

If your module’s public interface stays the same, modules depending on you will often not need recompilation, even if your module changes internally.

Modular Architectures I’ve Seen

I first wrote about modular architecture 2.5 years ago, somewhat early in my blogging career. For a while, I was embarrassed to share it, because I evangelised an architecture that had some serious scaling issues. Amateur hour. I’m more nuanced these days. Simple can be better.

Let’s take a look at some of the architectures I’ve experienced over 10 years of engineering, and dozens of projects.

Single Module

Not much to say about this tbh!

Prior to 2019, every app I built was a single module; as is almost every indie project I touch today. If build times aren’t a problem, or you’re working alone, why take the time?*

*That said, I often ask my agent to split up my projects if I get where I want to outside of my token limits. It makes me happy, even if I’m the only one who cares.

Core Module Architecture

If you ever decide to modularise your app, but you don’t have much time, this is usually how you’ll start. It’s a 2-parter:

• App, containing features and your top level target.

• Core, with everything else: models, networking, persistence, auth, utils, analytics, and shared UI.

This approach is nice for multi-target apps. In The Side Hustle From Hell, we foolishly tried to create a 2-sided marketplace, with apps for car mechanics and punters whose engine just conked out. On iOS and Android. 4 apps. Zero users.

The Core module is also a natural fit for Kotlin Multiplatform or organisations with a dedicated platform team.

Layered Modular Architecture

The first time I saw this architecture was on a top-secret electric car project which, I found out while in the pub, got abruptly sh*tcanned. An extremely cracked engineer, who rapidly left our company for more money, built a 3-tier layered app architecture with FeatureKit, ModelKit, and NetworkKit.

It was the first modular app I’d touched. And the most exciting thing I’d seen.

This architecture groups common functionality together into layers that serve the data requirements of the layer above, enforcing a highly unidirectional data flow through each layer.

App   
↓ ↑
Repository
↓ ↑
Networking

This architecture made an impression. I adopted the same structure for Bev, my original magnum opus (back when that word meant something). The top-level Bev module imports a Repository, which in turn synthesised the most up-to-date data from both our local Database and Networking modules.

This is nice for very simple projects, but begins to get tricksy once you add authentication, analytics, models, business logic, arbitrary services, and utilities. Where do you place those?

Unless your project remains very simple, you will feel the codebase nudging you towards a multi-modular setup inside each layer.

Naïve Feature Modules

Feature modules are the divergent evolution of your initial Core module. Instead of focusing on Layers and business logic, you might want to split your top-level UI layer into many; usually one module per feature.

My first startup, Carbn, eventually got here after playing around with a Core module to start with (rolling pure .xcprojects!), and my subsequent role at Gener8 had the same shape, set up using modern SPM.

If you work on a legacy app that wants to modularise, and you aren’t thinking that hard about it, you’ll probably land on feature modules. It offers nice ownership boundaries, excellent build time benefits, and two screaming weaknesses that I didn’t explain properly in my first architecture article.

The problems with feature modules

1. “Where do we put shared business logic?”

It’s nice to give feature modules ownership over their own models and services, but suddenly you’re contending with awkward refactors whenever another feature needs it.

Eventually, you either throw models, services, and logic back into a shared Core module, or endure an uncomfortable hybrid with some in the Core and some domain-specific stuff living in the features.

This is the first bit of resistance from your codebase you should feel, and keenly. Business logic and services mostly want to live in their own modules. Architecture wants to be consistent, and having to think hard about where to put your new model or service is a sign of a bad architecture.

2. “How do we reuse these screens?”

At Gener8, our clean SPM-defined feature modules worked great: we had a coordinator per module that could transition you between any screen in the module, or kick off a new flow to enter a new module.

Until, one day, I was asked to present UI from our Rewards module on the Home screen.

F*ck!

My beautifully-designed feature module architecture fell apart here. I had to create a low-level shared shim protocol, inject it at the top level, and wrap it in AnyView to allow Home to present the typed Rewards UI element.

This is another burning red flag 🚩. Creating a tiny shared protocol to let one screen talk to another is the quintessential architectural pushback I’ve been blathering on about. This… worked… but the codebase was not happy with the way I was torturing it.

This solution was, fundamentally, a factory protocol, but I couldn’t have articulated it at the time.

Both of these problems were solved in codebases I worked on later in my career.

Read more

At a corporate motivational event once, I found out it’s good to kiss your customers.

Not in a 2017, problematic, HR-esque way.

A “kiss” is just “a nice thing you didn’t have to do”. A chocolate on the pillow. The catch-up call where you don’t sell anything. The plus-one to an event. That tiny bit of satisfying design polish that makes your users think, right, these guys give a sh*t.

I’ve been adding these to every app I’ve touched recently:

• Progressive blurs for otherworldly beauty

• Metal shaders for skeuomorphic texture

• Responsive haptics for an alive feel

You don’t have to use these kisses. But if you do, your users may just become infatuated with your app.

Progressive Blur

First there was a blocky blue nav bar. Then a clean, minimal white block. Then Material. At some point (I’ve blocked it out from my memory) Apple went all Liquid Glass on our asses. It was the future, until it wasn't.

But this isn’t sexy. Or frosty.

Progressive blurs just look really damn nice. You know?

You scroll up, the blur comes out of nowhere, and the blur radius bubbles smoothly up towards the screen edge, smearing your app’s colours as it ascends to the void, towards heaven, in an otherworldly, almost Thanosian evaporation.

Enough linguistic fapping. You just need to see it.

Read more

This is not a super-technical deep dive. But I’ve been thinking it for a long time.

It’s a piece about UX. About form factors; past and future. Think of it as a palate cleanser between deep-dives on concurrency, Metal, and job interviews.

Chill (⛄️).

Whoever cracks this is going to make a billion dollars. Legit. That’s 5.5 million years of Premium Membership to Jacob’s Tech Tavern. Perhaps a few more if you subscribe annually.

But, before we get there, a history lesson 🧑‍🏫

Sponsored Link

Shipaton 2026: build and launch your next iOS app

Indie iOS devs: this is your excuse to finally ship. Shipaton 2026 is RevenueCat’s hackathon for app builders, with over $1M worth of prizes. Build a new iOS app, add RevenueCat, and launch between August 1st and September 30th.

Check it out and register here.

Inception

In 2007, the iPhone was announced. Like ChatGPT 15 years later, or Netscape Navigator 13 years prior, it ushered in the next great technological era: Mobile. In one swoop*, consumers had access to:

• Multi-touch capacitive screen

• A desktop-class web browser

• Cellular and Wi-Fi networking

• GPS and location

• Motion sensors

• A decent photo and video camera

• An App Store that made your device more valuable every day

And you got all this in a portable handheld device!

*two swoops if you pedantically point out that the App Store/GPS/video didn’t arrive ‘till 2008. I see you.

Early apps got nearly-free distribution on relatively crappy hardware. To-do lists, fart apps, and static PNGs were making tens of thousands of dollars*.

*It’s true. I once worked with a greybeard who paid his mortgage by shipping a calendar app in 2010 and getting untold thousands of paid downloads.

Heavy hitters like Facebook scrambled to stake a claim in this new land-grab. So Zuck did what he knew best, shipping an HTML5 app that ported the existing news feed from the web.

Nobody knew how to make the most of the new platform. Not Meta. Not Apple. Not even Instagram.

In 2010, this mobile-native new challenger wrote OpenGL shaders to filter photos and squeeze out value from the meagre early camera hardware, transforming your iDevice into a surface for creation as well as consumption.

Many of the big hitters you know and love to hate began in this early scramble: Uber. Snapchat. Instagram. WhatsApp. Tinder. Waze. Erm, Yik Yak.

Subscribe now

Business Model Innovation

In 2012, Facebook finally got its sh*t together and figured out how to monetise mobile, placing ads natively alongside items in the news feed.

In hindsight, this seems so obvious, but consider the perspective of the most beloved product that ever existed on the web. I’m not kidding. For years, 70% of people who had ever registered for Facebook were daily active users.

Your users are used to unobtrusive banner ads. How could you risk polluting the news feed, risking a defection to Instagram and WhatsApp*, for an unproven revenue opportunity?

*Remember those glory days when they weren’t all the same company?

Selling ads as content-ish objects, integrated alongside infinite updates from your friends, turned out to be drastically more profitable than the web could ever dream.

Form Factor Innovation

Social was the hottest industry in early-2010s-startupland. Business model innovation is nice, but the cool kids (who adopt your product) could not care less if you were monetising them. They probably also didn’t care that much about their data at the time. I dunno. I wasn’t one of them.

The big story is form factor. Well. The form factor is Story. Stories, that is.

Ahem.

Late 2013. Snapchat unleashed Stories on the world.

At last, there was a form factor that felt perfect for mobile, on both the creation and consumption sides:

• It used the hardware camera as the starting point; vertical by default

• It took Snapchat’s ephemeral messaging and turned it into broadcasting

• This ephemerality encouraged mundane, casual, “low pressure” posting

• This, in turn, encouraged repeat daily posting and consumption

• Fullscreen consumption captured your whole attention and encouraged “tapping through” all the updates from your friends.

When you put everything together like that, it was obviously the ideal form factor for an early mobile device.

But also, it still wasn’t that obvious without hindsight.

In 2016, the problem of pressure to post the perfect photo began to really hurt engagement on Insta. Zuckko ripped the stories form factor straight off Speegz. At which point, he decided to yeet it everywhere.

The extremely obvious final form

Today, people no longer casually consume content shared by their acquaintances. Social media has bifurcated into private messaging with close friends; and watching videos made by strangers. Whatever market opportunity there was for catching up with acquaintances has dried up.

TikTok, Instagram Reels, YouTube Shorts, and Snapchat Spotlight (I had to look up the name) have converged on pretty much the exact same form factor. But, again, it all seemed so obvious!

TikTok burst onto the scene in 2019, and forced everyone to adopt its obviously superior form factor (or perish).

It brought the logical conclusion of the fullscreen stories format. Instead of an image, it’s a video. Instead of a crappy 4” screen, it’s on a stonking 6.5” chad of a glass rectangle. Instead of disappearing after six seconds, it’s broadcast to the world in a ruthless Darwinian survival game of attention.

On-demand full-screen video was a predictable ultimate form factor way back in 2010. But failure to implement this wasn’t due to a lack of creativity on those would-be Gen X entrepreneurs.

Read more

AI features are frequently whipped out and waved about in your face. You know what I’m talking about: empathetic but useless customer service droids. Auto-post-writing on social media. Email summaries (and filtering!) that nobody asked for.

Often, we’re not really the target audience; it’s so they can tell shareholders about their AI strategy (annoying but I guess better than what Meta is doing with the 20% layoffs…)

It’s not controversial to say the best kind of AI features are invisible, quietly improving products without you having to think about it. Recommender algorithms. Curation. Semantic search.

Apple Photos is a great case study. Say what you want about the dodgy iOS 26 redesign, but it’s fundamentally a solid product: it safeguards decades of your life in the cloud. It curates daily slideshows of memories. And it’s pretty darn good at working out who is who across your photos.

People & Pets lets you tap a face to see all the photos of that person.

Facial recognition isn’t possible without some solid ML work: computing facial fingerprints across thousands of images and clustering like images into a library of family and friends, all in the background.

There’s no better way to understand a system than by jerry-rigging your own janky version, so that’s exactly what I did.

Contents

• The Sample Project

• Step #1: Finding Faces with Vision

• Step #2: Computing Embeddings

• Step #3: The Clustering Pipeline

• Step #4: Optimising the Pipeline

• Last Orders

The Sample Project

I couldn’t be arsed to decompile anything today, so can’t speak for Apple’s specific implementation, but the concepts of facial recognition software are a surprisingly straightforward 3-step pipeline:

1. Detect faces in each photo via Vision.

2. Turn each detected face into an embedding via ML models.

3. Group similar embeddings into people via clustering algorithms.

The best part? This all works locally with on-device models, and works pretty damn well.

I’ll also share the sample project so you can go into much more detail. We will learn a whole lot about embeddings along the way. Quick spoiler for where we’re landing:

Get the whole sample project on my GitHub repo now:

Get the sample project

Step #1: Finding Faces with Vision

The first step to building a library of faces is understanding which pixels of a given image are interesting to you.

Now while I think all pixels are beautiful, only a few bits of the image actually help us with facial recognition. That is, the faces. A photo has a vast quantity of information, but most of it is noise if you just want to match faces.

We need to find the coordinates of the image which actually contain faces.

Apple’s Vision framework has a built-in API for precisely this. Give VNDetectFaceRectanglesRequest an image, and it returns a list of bounding boxes around each face.

This doesn’t perform any work to identify anyone. It’s just rectangles.

Underwhelming, perhaps, but no less important. It’s our first building block.

Now we can ignore the rest of the photo and work face-by-face instead of image-by-image. It also helps to do a simple post-processing step and discard faces too small or low-confidence to be useful, like the blurry lad in the back of your concert selfie.

Step one is done. We have our list of rectangles associated with each image. Next, we convert the crops into… mathematics.

Step #2: Computing Embeddings

What is an embedding? A miserable little pile of secrets. It’s a fancy word for a vector, which is a fancy word for a list of numbers. A 512-item array of floats. If you like forensics-y metaphors, it’s a numerical fingerprint representing the image.

We create these embeddings by passing the pixels of a face image through the weights of our chosen face recognition model: pixels go in, embeddings go out.

Aside: how are facial recognition models trained?
As with most ML, you start with a huge labelled dataset, with many photos of each person across different poses, lighting, age, facial expression, and image quality, to ensure a model can learn that one person might be representable by a range of pixel values. From there, you train it the same way you train any neural network.

Now we know where to find faces, we are basically crunching geometry. Geometry like the spacing between your eyes, the position of your mouth, the shape of your skull. These properties tend to be constant between plastic surgeries.

Get 14 day free trial

Read more

Some days you wake up and think, “Today I’m gonna be margarine. You won’t believe it’s not butter. I’ll ship a screen so silky smooth they’ll think it was powered by Morgan Freeman’s voice.”

Just me? Right.

Anyway. I woke up. Vengefully. Sherlocking. Apple’s had it too easy for too long. It’s time somebody Sherlocked them. Apple Photos. Everyone hates the redesign. I don’t even remember what it used to look like. But I can do better.

I have a lot of photos. I need to sprint to stand still; following the yearly upgrade cycle just to maintain enough storage space for all the pictures of my kids. SwiftUI will not be invited to this party. I know enough about its performance when it comes to complex scrolling feeds.

UIKit is my go-to for smooth scrolling. I reached out for my trusty UICollectionView. My old friend. My legal guardian. My emergency contact.

Oh.

OH.

F*ck.

So… that wasn’t ideal.

What went wrong here? Why was my feed locked up, with more hitches and hangs than successful on-time frame renders?

And how can we do this properly?

Today, we’ll answer these questions, and demonstrate the right tool for the job: you hold onto UIKit scroll physics, but offload all the real rendering: GPU. Metal. 120fps.

This article is packed full of so much knowledge, your email client will cut it off. Read on my website here.

Read on my website

UIKit Did Nothing Wrong

The UIKit trace, in my slightly montage-parody-flavoured video, was all hang, all the time. Even Spiegel would consider it a “potato”.

I’ll say anything to make my subscribers happy. I’ll praise SwiftUI. I’ll praise UIKit. I’ll take down SwiftUI. Twice. I’ll tell you UIKit sucks. All year, I’ve been telling you UIKit is the one when it comes to performance, so why lie?

It’s not a lie. But engineering is about knowing the right tool for the job. Especially in the current landscape, where an agent can spit out plausible syntax like it’s nothing.

UIKit is really good, most of the time. With an infinitely scrolling feed of photos, or a collection view of, say, 5 columns, it’s solid. Here’s the same app, but magnified.

This is great. On my entry-level iPhone 17, boasting a chonky 3nm A19 chip, it runs fine zoomed out to 15 columns as well. It’s only at 31 columns (I copied the zoom levels from the Photos app) where it falls apart.

This is thousands of visible UICollectionViewCells onscreen. Placing a cell in the collection requires overhead from layout, reuse, PhotoKit callbacks, image view assignment, and Core Animation commits. Fine with a few columns, but it adds up.

Instruments explained where all this work was happening:

• UICollectionView.layoutSubviews ate ~46% of main-thread samples.

• collectionView(_:cellForItemAt:) was in ~35% of samples.

• PHImageManager.requestImage(...) hit about ~24%.

Eagle-eyed viewers can put away their hmm, actually: several main-thread samples are on the same call stack and so they can add to more than 100%.

My UIKit version wasn’t even that ambitious, lazing about at a paltry 60fps target, with a stonking 16.67ms frame budget. A hitch happens anytime the UI render loop fails to prep a frame on time.

Under 5ms of hitches per second is “good”. A billion hitches per second is “bad”. Zero is the target. So how do we get from this…

…to this:

It’s all about the Metal.

Read more

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

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

Read more