Jacob’s Tech Tavern

Survive the AI tech hiring winter ⛄️

Jacob Bartlett — Mon, 06 Apr 2026 15:03:00 GMT

Late last year I went independent. My wife gave me 100 days to get to sustainability.

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

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

I never told you why. Really.

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

But that’s just short-term downside risk.

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

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

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

Play defence: Becoming way more knowledgeable than average.
Play offence: Position yourself in a company that will survive.

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

Introducing…

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

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

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

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

Buy the book now ($19)

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

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

Cheers for reading Jacob’s Tech Tavern! 🍺

Oh sh*t, I have an "iOS coding" interview and don't know what to practice

Jacob Bartlett — Tue, 31 Mar 2026 15:00:44 GMT

Landing a job is never easy.

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

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

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

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

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

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

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

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

Categories of “iOS Coding” exercise

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

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

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

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

“An interview focused on programming and debugging in iOS.”
“An interview involving an app building exercise”
“An interview focusing on your experience with the iOS ecosystem, including core programming, architecture, and problem-solving.”
“An interview testing understanding of algorithms, data structures, and clean code”
“An interview on software engineering & API-oriented programming.”

Deciphering these is more art than science.

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

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

Screen building

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

Component design

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

LeetCode-“lite”

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

Fundamentals

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

API design

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

Modern tooling makes it easier than ever to drill problems.

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

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

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

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

Upgrade to unlock this article, plus much more:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

The SwiftUI Design System War: Composition vs Progressive Disclosure

Jacob Bartlett — Tue, 17 Mar 2026 16:02:40 GMT

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

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

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

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

But you should really decide for yourself.

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

This week, I’m offering my 2-eBook concurrency bundle for 55% off
📘 The Complete Swift Concurrency Toolkit explains every facet of Swift Concurrency from async/await to the latest Swift 6.2 actor isolation changes.
📕 Advanced Swift Concurrency Training takes you through 12 increasingly complex real-world problems, allowing you to lock-in practical knowledge.
By the end, you’ll have a finely-honed concurrency killer-instinct.

Get the Swift Concurrency Bundle for $29

Claim your free month to unlock this article, and much more:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Get 30 day free trial

Is SwiftUI finally as fast as UIKit in iOS 26?

Jacob Bartlett — Mon, 09 Mar 2026 16:01:18 GMT

If anybody was on the fence about having kids, my four-year-old daughter saw this and started dancing along with the baby GIF.

I love SwiftUI; I hate SwiftUI.

I love UIKit; I hate UIKit.

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

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

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

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

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

Performance.

Specifically, scroll performance.

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

But they do have a point:

Performance is the final bastion of native iOS supremacy.

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

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

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

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

Or, perhaps, all the most tight-fisted Mastodon users stubbornly holding onto their iPhone 4s suddenly upgraded en masse

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

SwiftUI vs UIKit.

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

Designing the most ridiculous scroll view I can imagine

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

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

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

What requirements are needed to make a UI truly ridiculous?

High resolution images.
A complex view hierarchy of elements, text, and gradients.
Permanent autoplaying animations.
Variable-sized cells to force layout re-computation on cell reuse.
Multi-gesture UI interaction that update a data store in real-time.

But how can we achieve this?

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

Hell. Freakin’. Yeah.

Uh, so this disc image is from 2001. I need to mount the .iso somehow… macOS won’t play along. You know what, this is below my pay grade. I’m gonna get Claude to dump it out and export me a folder of .gifs.
Throwback to the early 90s when dancing baby was literally the funniest meme ever.

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

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

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

So.

Once and for all.

Is SwiftUI finally as performant as UIKit?

Upgrade to read this article right now, or wait until next month.
Paid members get several benefits:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

iOS System Design interviews in 2026

Jacob Bartlett — Tue, 03 Mar 2026 16:01:49 GMT

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

Show me how you’d architect an encrypted messaging app.
Demonstrate how you’d structure a news feed on a social app.
Design an SDK fit for a large analytics company.

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

Until now.

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

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

The enterprising free subscriber can avoid the paywall by skimming the sticky notes on my monitor.

A framework to structure every interview

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

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

Scoping
Functional requirements
Non-functional requirements
Data model
API design
High-level design
Drill-down questions

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

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

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

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

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

Upgrade to unlock this article, plus much more:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

The Most Complicated System I Ever Worked On

Jacob Bartlett — Tue, 17 Feb 2026 16:01:15 GMT

Writing online is a lot like creating content on OnlyFans.

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

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

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

Wow, TIL Substack was even more top-heavy than OnlyFans (source)

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

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

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

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

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

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

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

It’s a certified banger, I swear

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

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

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

Paid members get the full article, and a lot more:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

Agentic AI Engineering Workflows for iOS in 2026

Jacob Bartlett — Mon, 09 Feb 2026 16:02:05 GMT

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

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

Default to AI, with a vast majority of code not hand-typed.
Still hand-coding by default, pasting into chat windows for help.

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

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

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

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

But things have moved really fast.

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

I need to optimise my workflow some more.

So.

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

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

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

RevenueCat Paywalls: Build & iterate subscription flows faster

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

The State of the Art

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

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

Let’s cover some:

The Best Models

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

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

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

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

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

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

I guess I need to upgrade my plan.

MCP, Verification, and Xcode 26.3

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

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

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

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

XcodeBuildMCP

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

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

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

From Apple Newsroom

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

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

Multi-agent and Orchestration

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

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

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

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

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

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

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

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

AGENTS.md and Skills

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

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

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

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

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

From swift-concurrency-expert by Thomas Richard

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

Always pull main and check out a new branch before work.
Always document a plan and get my sign-off before changing code.
Always verify your work via compile/test/run with XcodeBuildMCP.

And it will follow this to the letter!

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

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

skills.sh

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

Teleporting Sessions to the Web

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

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

The win here isn’t immediately obvious.

But consider the workflow it unlocks:

Set up your team, including non-technical, with Claude Code or Codex.
They find a bug and report it directly in a Codex session via the iOS app.
An agent could potentially diagnose the issue, fix it, and create a PR.

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

Tab Completion

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

But I kind of always felt iffy about it.

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

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

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

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

The Ralph Loop

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

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

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

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

OpenClaw (aka Clawdbot)

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

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

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

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

OpenClaw

Cargo-Culting the Creator of Claude Code

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

Image source had no credit

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

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

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

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

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

What is he doing?

Running 5 Claude Code instances in parallel on the terminal
Regularly teleporting to sandboxed web sessions for background processing
Sticking religiously to the slowest, smartest thinking model
Maintaining a single, big, shared, CLAUDE.md in the repo
Using Github Actions to update CLAUDE.md as part of PRs
Starting sessions in plan mode, refining, then one-shotting
Creating slash commands for commonly-used workflows, e.g. commits
Using a few subagents for specific workflows, e.g. verification or simplifying
Using a PostToolUse hook to run linting on generated code
Avoid --dangerously-skip-permisisons, but allow permissions in settings.json
Configure MCP to interface with tools like Slack and SQL using mcp.json
For long-running tasks, ensure Claude verifies its work in the background
Solid verification is critical: tests, iOS simulator runs, or bash scripts

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

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

What now?

Use worktrees (or just multiple git checkouts) to run agents in parallel
Always start with a plan, then get another agent to review the plan (personally I like to pit Claude Code against Codex!)
Ensure your AGENTS.md/CLAUDE.md is updated every time an agent makes a mistake
Create skills regularly and commit them to git, especially common daily tasks
Use Slack MCP to directly tell @Claude/@Codex to fix a bug and make a PR
Utilise these pro prompts:
1. Ask the agent to grill you on changes so you understand
2. After a mediocre fix, tell it to scrap the change and re-implement
3. Write detailed specs with minimal ambiguity before handing off work
Customise your terminal and utilise voice dictation (WisprFlow is best!)
Subagents can be useful to get more compute or preserve your context window
Agents can connect to analytics and databases to answer questions
You can have the agent explain the “why” behind the changes, and even present visual diagrams explaining your codebase.

Building Maxwell in an afternoon

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

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

Diagram from Hirostart

Maxwell was born.

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

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

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

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

Until now.

Er, hold on.

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

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

I also found my old logo!

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

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

I did all this work in Codex using the gpt-5.2-codex high model.
I set up XcodeBuildMCP with the intention of verifying all my work autonomously via tests and simulator runs.
The repo contains some open-sourced AGENTS.md, slash commands, and skills for SwiftUI and concurrency review.
I’m going to aim to run 5 instances of Codex in parallel, numbered, with each CLI window pinging me via system notification when they finish.
For each instance, I’ll carefully plan each feature before trying to one-shot.
I’m going to set up web sessions via the ChatGPT app and attempt to ship some QA fix PRs while eating dinner.
If I have time, I might install Cursor and implement some manual fixes, with my fingers, like it’s the 1970s.

Here’s the full project!

The sample project on GitHub

Well, it’s not exactly finished, but I trust you not to PIP me.
Pretty good for an afternoon’s work, I reckon.

Last Orders

I spent summer diving headfirst into agentic engineering using Claude Code (and later, Codex), realising they were finally very, very good.

But they have not stopped in the last 6 months. I suspect I’ll have to make this a semi-regular post to ensure we stay ahead of the curve!

Frankly, while multi-agent workflows are the current razor’s edge for productivity, it’s actually a deeply suboptimal workaround to latency. If high-thinking-budget inference ran 100x faster, we would not need to perform this context-switching, and could simply roll a single agent as the fully-engaged human in the loop.

I reckon that’s where the next 6 months is going to go.

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

Subscribe now

RevenueCat Paywalls: Build & iterate subscription flows faster

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

My (deeply stressful) big tech interview grind

Jacob Bartlett — Tue, 03 Feb 2026 16:02:51 GMT

“Interview grind? Huh?”, I hear you say from your screen, in the future, “I thought you were going independent?!”

Yeah, I thought so too.

Today’s post is one part life update, seven parts survival guide.

I’ll give a recap of where I got on my independence journey.

Next, I’ll share my experience working through 50 interviews in one month, and offer you practical advice for maximising your chances at passing each stage of the big tech interview process.

My Going Indie Scorecard

Before I tell you what’s new, let’s put together a scorecard of my 100 days as an independent creator:

My initial approach to shipping content: all bangers, all the time.

My first month of independence was spent artisnally crafting each new article over a full 5 working days. Each one of these pieces of content was a killer, growing my paid subcount by over a dozen apiece. Content Score: A+.

Riding high, I deigned to actually do a budget.

And… f*ck.

You’d think a digital services business would have phenomenal margins, but costs like EU VAT, transaction fees, blog hosting fees, and income tax added up quickly.

Break even would be tough. Optimistically, maybe in 8 months, if my growth rate stayed at the maximum. Maybe I could do this before running out of money. But this is kind of a dumb risk when I have a wife, a mortgage, and 2 young kids.

War Stories landed me some great content, and was a brilliant excuse to connect to other prolific creators. You should definitely read my interviews if you haven’t had the chance! I will definitely continue to do more of these.

My Creator Spotlights collab with fatbobman also went ahead, and netted some nice cross-pollination with our mutual readership of iOS devs.

These collaborations produced some solid content, and allowed me to share some very fun war stories. My strategy, however, was about growing my free subscriber base significantly, and unfortunately I was not able to move the needle enough for this to bootstrap my independence. Collaboration Score: B-.

My experiment with paid acquisition was a big success in terms of scaling my readership, with my cost-per-acquisition down to (something like) $2 per inorganic free subscriber. These have translated into exactly zero paid subscribers (since I fixed my UTM tags last month). Paid Acquisition Score: C.

Tavern Tools™, my beautiful vision for a dev tools suite, was aborted before I began. I realised it was a giant distraction from growing my free base. My paid conversion rate was already sitting pretty at over 5%, so I didn’t need to create extra incentives here. DevTools Score: D for “dunno”, as I never showed up to the exam.

One bright spot in my scorecard was netting a sponsorship deal (perhaps more? Watch this space!) to advertise on my blog with my friends at RevenueCat. However, it turns out that in the incredibly mature world of dev tools marketing, budgets can be tight for a new entrant. Sponsorship Score: B+.

Overall Grade: B. Must try harder.

In the crushing wake of my budget, I realised what I had to do. I had to find my white whale. And what is an employer, if not just one really big paid subscriber?

My Job Application Journey

Thus began my first foray into job applications since 2015.

My previous 3 job moves were through recruiters, and I’ve never had the luxury of treating the application process as a full-time job before.

The grind I underwent in December has given me insight into the state of the market, and finally given me the space to properly get ready for the tough interview loops that big tech companies apply to candidates.

Here’s my full stats: 26 applications. 2 offers.

My job application stats in 2025

For my kings and queens who write native iOS for a living: the market isn’t as bad as the startup winter of 2022. It’s healthy. There are a ton of well-capitalised AI startups hiring native iOS engineers, despite the narrative that cross-platform is eating our lunch. There are a lot of established companies growing their teams too.

That said, unless you live in an American city, there are not many FAANG jobs to go around. In London, the only “big” big tech co’s hiring for iOS at the end of 2025 were Snap (I got to the panel) and Meta (who ghosted me).

I’m kind of in a privileged position. I know the average engineer (who doesn’t run a popular blog) isn’t getting a >50% hit rate on the CV screening. But I can share a lot of useful knowledge from my interview grind that can help you out with every step of the process.

Upgrade to unlock this article, plus much more:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

Xcode Organizer: Your Performance Cheat Sheet

Jacob Bartlett — Tue, 20 Jan 2026 16:01:22 GMT

I love working on app performance.

It just sounds cool. Performance. Performance.

While the bozos on feature teams are busy building stuff that actually brings in paying customers, platform engineers can feel smugly superior, typing away from our windowless basements, reducing launch time by 0.01 seconds. For everyone!

Unfortunately, if you don’t have a full-time platform team, “performance work” is generally treated the same as “tech debt tickets”.

Despite what app release notes will have you believe, no one’s going to give us time to work on performance optimisations, because a lot of the time it’s invisible. Everyone agrees that high performance is desirable, but it’s virtually impossible to quantify the impact of marginal improvements.

So how does this ever get done? And how do we stay on top of it?

There is a way. And if you can master the technique, it’s also a pretty good way to get promoted.

Be the dev that keeps a close eye on the Xcode Organizer.

There’s nothing better for your promo packet (and, for my indie readers, your own customers) than identifying low-hanging fruit, recent regressions, or serious performance bottlenecks; crafting a proposal to solve them; and allotting engineering time to solve it.

This is not theoretical; this is pretty much my standard playbook.

I’ll keep a watchful eye on the Xcode Organizer. I’ll flag to Product or Engineering leadership whenever I spot an opportunity to improve something that users will actually notice: Launch time, scroll hitches, terminations, battery usage, storage usage. All these issues often have fairly trivial root causes, and offer an outsized user impact once you solve them.

Xcode Organizer is easily where 80% of my performance optimisation work originates. If you’re on top of it, you can usually pre-empt user complaints.

Sponsored Link
Substack, which powers my newsletter, is hiring iOS engineers!
The team is small, close-knit, and provides ample opportunities for mentorship, growth, ownership, and autonomy. You can apply for either the growth team or the enterprise team. Check out their jobs page for the full list of technical and non-technical openings.

The Xcode Organizer

We can find the Organizer in Xcode’s Window menu.

Even if you’ve never touched the performance charts, you’re likely already acquainted with the Organizer, since it’s where all your Archives live.

If you’ve been in the indie game for a while, you’ll also experience a nostalgia tour of everything you’ve ever submitted to the App Store.

Oh dear.

I just realised; none of my apps have enough users to actually display any data here.

Stand by.

☎️ Thomas, help me out please! 📡

Famous Twitter personality and iOS engineer Thomas Ricouard generously took the time to share the performance stats of his indie app, Ice Cubes for Mastodon. Please show your appreciation by downloading it, either if you’re a Fediverse fanatic or even if you’re merely toot-curious.

Thomas also posted a really good piece recently on The State of Agentic iOS Engineering in 2026, which I massively recommend both if you’re new to agentic engineering or you’re already a Claudepilled Codex-cel.

You can get very specific when you look through the organizer. You can slice most of the reports by time, by device, and by version.

There are usually tons of low-hanging performance optimisation fruit at the top level, but if you have enough users, you can often spot OS-version, device, or version corner cases by narrowing things down.

Many performance attributes in the Organizer have both metrics and reports to investigate. Metrics are aggregated numbers sliced across all your users and versions, and reports surface individual code-level issues.

I think of the Xcode Organizer like the top of the performance funnel. You get fully aggregated metrics across your whole user-base. When you spot a problem, you can often go deeper with Instruments. Once you identify the bottleneck, you can then solve it in code and verify the improvement.

Now let’s look at how to apply each report in the Organizer to optimise your app’s performance today (and make you look like a hero in the process!).

Upgrade to unlock this article, plus much more:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training

Subscribe now

How to design an SDK to handle $10bn in transactions

Mon, 12 Jan 2026 16:01:24 GMT

RevenueCat has a neat business model: Take an enormously painful hassle (managing in-app subscriptions), abstract it into something bearable, and charge devs a cool 1% for the service. Classic painkiller.

This abstraction is where the value lies.

$10bn worth of value (so far!).

When tens of thousands of devs are relying on you to make money, the stakes can’t get much higher. Consequently, the RevenueCat iOS SDK is one of the most battle-hardened open-source projects out there.

Therefore, we can learn a lot about SDK design principles by analysing it:

Backwards compatibility as a top-level constraint
Façade-first design for public APIs
Sensible defaults and progressive disclosure of complexity
Careful layering of dependencies
Relentless logging, diagnostics, and profiling
Orchestration between services for complex flows
Offline-first correctness
“Invisible” performance characteristics
Friendly abstraction over janky third-party APIs
Keeping mindful of dev-ex (developer experience) every step of the way

We’re taking a deep-dive into the payments flow: how the SDK abstracts away the complexity of making purchases and setting up in-app subscriptions.

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

(That’s right, I finally manifested my bit from 2023)

High-Level System Design

Consider the RevenueCat SDK at a basic level: how would you design such a thing? Don’t think about payments, subscriptions, entitlements, receipt validation, and paywalling yet.

It’s easier to start with a big box that abstracts away everything a user has to worry about.

Now consider: who are the big players involved?

There’s the client app, of course, who pays you money to use the SDK. Then, with a great big box, we can represent the SDK. The other major players are StoreKit, Apple’s own servers, and of course the RevenueCat backend itself, mostly all chatting to each other.

Mini system design drill I took during my big interview grind this December

The SDK needs to abstract all the complexity away of creating a customer, displaying products on a paywall, talking to StoreKit during a purchase, updating and handling user entitlements, and posting transaction info to a server so everything links up cross-platform.

Inside the SDK, the architecture is loosely set up in layers, with very heavy usage of constructor injection to manage dependencies across all the classes. These dependencies are all initialised on SDK init, with lower level services injected into high level managers and orchestrators where needed.

For payments, the conceptual layers look a little like:

Façade layer containing Purchases, the public API surface
Orchestration layer where PurchasesOrchestrator coordinates everything
Managers layer containing business logic and services like OfferingsManager, CustomerInfoManager, and ProductsManager.
Infrastructure layer containing basic services like Backend, HTTPClient, and OperationDispatcher.

Let’s dive down into these layers in detail to see how the SDK handles payments.

There are a couple of useful keywords to clarify before we go too far into the guts of RevenueCat, because they come up a bunch:

Entitlements refers to the level of access and features the user has unlocked. For instance, whether they are on your free tier, your paid tier, or your founding members tier.
Products are the different individual things a user might buy; for example a free trial, a monthly membership, or a discounted annual or lifetime membership. They list separately on the App Store, Google Play, and Stripe (for web!).
Packages refers to equivalent products across platforms (basically this makes paywalling admin easier).

How to make a Purchase

There are actually two ways to make purchases via the SDK:

The default mode is using the built-in paywalls, which automatically display your offerings. Set up on the dashboard, and the SDK handles everything automatically.
You can also manually tell the SDK to execute a purchase like this. I’m going to follow this one, because we can follow through the full public API:

Think of a Package the same as a Product displayed a paywall, but cross-platform

The Façade Layer

Façade is a top-3 design pattern for me because I love the little accoutrements on the letter C there (apparently called a cedilla).

Purchases, the main object devs use to init and use the SDK, is this façade, a minimal developer-friendly API that distills the tasks of complex StoreKit integration, receipt validation, and entitlement management into a few simple function calls.

Purchases

Woah, Nelly, that’s a lot of dependencies. And I redacted a lot. But we can spot also a few interesting SDK design techniques already:

If the SDK is not configured, it will fatalError() on access. This is a deliberate design choice: this makes it virtually impossible for the developer to mess up basic initialisation and misuse the SDK.
Note the @objc(RCPurchase) at the class declaration. This exposes the class to Objective-C, and provides a prefixed alternative name (because ObjC uses a global namespace). Objective-C compatibility is a must when you are working with thousands of iOS projects that might never migrate to Swift.
Purchases also serves as the root of the dependency graph, owning references to all the services, managers, and orchestrators used throughout the SDK. It applies manual constructor injection, which is preferable to introducing a third-party DI framework as a sub-dependency into every app shipped by your customers.

Configuration and Progressive Disclosure

Initialising the SDK reveals another interesting tidbit around progressive disclosure in API design, which is vital for your dev-ex.

Most devs will start by configuring their payments SDK with the API key only.

@objc(configureWithAPIKey:)
@discardableResult static func configure(withAPIKey apiKey: String) -> Purchases {
    Self.configure(withAPIKey: apiKey, appUserID: nil)
}

As you grow towards more advanced use cases, you might end up using this alternative function that allows for configuration:

@objc(configureWithConfigurationBuilder:)
@discardableResult static func configure(with builder: Configuration.Builder) -> Purchases {
    return Self.configure(with: builder.build())
}

This Configuration object offers more granular control over SDK behaviour:

This means we can keep APIs simple while enabling customised behaviour for power users.

Consider a developer introducing this advanced configuration for the SDK to enforce response verification, hardcode StoreKit 2, and configure timeouts:

let config = Configuration.Builder(withAPIKey: apiKey)
    .with(observerMode: true)
    .with(storeKitVersion: .storeKit2)
    .with(responseVerificationMode: .enforced)
    .with(networkTimeout: 90)
    .with(storeKit1Timeout: 45)
    .with(preferredLocale: "fr_FR")
    .build()
Purchases.configure(with: config)

Without being able to apply this configuration at init, we would have to make the API surface far more complex, for example the basic purchase() API would require far more parameters:

try await Purchases.shared.purchase(
    product: product,
    observerMode: true,
    storeKitVersion: .storeKit2,
    responseVerificationMode: .enforced,
    networkTimeout: 90,
    storeKit1Timeout: 45,
    preferredLocale: "fr_FR"
)

Because this all lives in the configuration at init, the API can remain simple:

try await Purchases.shared.purchase(product: product)

Configuration creep is also a problem, so you need to be thoughtful about how much should be configurable locally, vs how much can be set up on a dashboard somewhere. You need to carefully balance ease-of-use, flexibility, and actual customer needs.

Managing the Dependency Graph

The dependency graph is all wired up in the Purchases convenience initialiser: All the services, managers, and orchestrators get created here.

Purchases

Because I’m not being paid by the letter, I redacted about 80% of the code.

The layered architecture I referred to isn’t enforced logically, but is kept safe by the compiler: it’s impossible accidentally create a cycle when using vanilla constructor injection, because your code just won’t compile.

So I suppose it’s less like a dependency graph, and more like a list of dependencies that are instantiated, one after the other, in the order they appear in this initialiser.

This is not trivial, however: you still need to carefully design each dependency to avoid cycles, ensuring each service has only what it needs.

The Purchase function and backwards compatibility

It’s easy to get recursively sidetracked when analysing an interesting SDK like this. Where were we? We were searching out the purchase() function.

I found the protocol we were looking for. This is the true façade: the protocol with every developer-accessible function:

PurchaseType

When creating an SDK used by tens of thousands of developers, backwards compatibility is perhaps the most important consideration of all. You aren’t Apple. You don’t really get to deprecate stuff, because devs probably don’t have a Stockholm-syndrome relationship with you.

It’s wonderful to offer shiny new async/await APIs, but you don’t get to force devs to migrate. You need to keep those “legacy” completion block forms working too.

This doesn’t mean you have to double your code: the async versions just wrap the original completion block versions using withUnsafeThrowingContinuation.

You also can’t just gate all your functionality behind the latest OS versions: as an SDK, your deployment target is constrained by the customers of your customers. A single gambling app supporting iOS 11 for their three surviving geriatric whales means you can’t just rip the floor out from under them.

RevenueCat targets iOS 13 for their main SPM repo, but still supports iOS 11 on Cocoapods.

For our purchase(package: completion:) function, the implementation is here, firing into the PurchasesOrchestrator class.

Purchases

PurchasesOrchestrator is the next layer in our conceptual stack of pancakes. Or lasagna. I actually need to get lunch.

The Orchestration Layer

This is by far the most complicated functionality in the SDK, which is why it’s fun to write about. PurchasesOrchestrator coordinates all the services and dependencies required to make a purchase, including transacting with StoreKit, posting completed transactions data to the RevenueCat backend, and updating customer entitlements locally.

PurchasesOrchestrator

This 2000-line behemoth is the main engine driving $10bn of transactions.

Making the Purchase via StoreKit

Let’s follow along to the purchase() function.

There’s a few more interesting SDK design lessons to learn here:

Log everything on the critical path to catch errors and hit that 99.99% SLA.
We should also profile times and performance for our metrics.
Handle both legacy SK1 and SK2 transactions, while abstracting this choice away from the developer.
Wrap #available conditionals around APIs younger than the minimum deployment target to ensure backwards compatibility.
Enable users to test the flow without spending money using simulatedStoreProduct.

Let’s follow the StoreKit 2 version.

After a brief time-skip as the SDK passes through more layers of logging, profiling, caching, and error handling, we land on the function that actually calls into Apple’s StoreKit API:

Notice that SDKs don’t get the luxury of ignoring new platforms like VisionOS: you need to ensure all your APIs work with all platforms by the time it’s out of Beta!

This presents the modal payment window for an in-app purchase or subscription.

The purchase is complete! But the orchestration journey is not over.

Handling the transaction and delegating to services

Apple has now processed the transaction.

But what happens when the user upgrades to a new device? What about if they move over to Android, or your web app? How do we know they aren’t fraudulently accessing your content via a jailbroken device?

These problems of entitlements and receipt validation are two of the major reasons that payments is a headache.

To kick off the second half, after calling purchase(sk2Product…), the orchestrator manages the result of the StoreKit purchase action

This does several critical things:

Verifies this transaction using the StoreKit transaction listener, another friendly wrapper around StoreKit APIs.
If the transaction returns, it hands off the data to other SDK services.
Tracks and logs a lot more stuff.
Finally, returns the contents of the completion block (or throws an error).

It’s used as a helper function here, but the StoreKit listener also runs in the background to catch transactions that happen outside this explicit purchase() call, such as family sharing, renewals, or restoring purchases.

Handoff to the services layer

As our time with the orchestrator comes to a close, handlePurchasedTransaction cleans up paywalls, tokens, and contexts, wraps up a PurchasedTransactionData object, and hands off to more services:

Let’s take a look at two of these critical services now.

The Service Layer

There’s two important services used here to finalise a purchase: TransactionPoster and CustomerInfoManager.

TransactionPoster and backend validation

TransactionPoster itself, as a relatively high-level specialised service, further builds on top of several lower-level dependencies.

TransactionPoster

After PurchasesOrchestrator finishes a transaction, it asks TransactionPoster to send StoreKit receipts to the RevenueCat backend, which then validates the receipt, verifies the customer’s subscription, and returns confirmation to the SDK.

Pretty much every one of these functions calls into of the dependencies above:

product(with: productIdentifier) calls into productsManager to the available products.
postReceipt() tells the backend to actually send the receipt to RevenueCat servers.
handleReceiptPost() calls into operationDispatcher to jump to the main actor and performing the callback thread-safely.

CustomerInfoManager and offline correctness

CustomerInfoManager is where the entitlements of the user live. This is one of the most important services, because it dictates whether a user can access paywalled content in your app, or not. It’s really important to get this right.

CustomerInfoManager

Once the PurchasesOrchestrator has posted the receipt, it updates the cache on CustomerInfoManager to ensure entitlements are readily available, both for speed of retrieval and to ensure it still works offline.

In the end, this more or less lands in UserDefaults. Nothing is ever magic.

It’s really, really, really important that an SDK works in all sorts of conditions, such as poor network, low power mode, and offline.

One of the CustomerInfoManager dependencies, OfflineEntitlementsManager, acts as the fallback; computing customer info from locally-persisted SK2 purchase history and cached information on products and entitlements.

This is an instance where you can influence API design to improve developer experience: giving devs control over how they want to fetch customer info data, with a choice between speed and correctness.

The Infrastructure Layer

With a layered architecture SDK like this, it’s very easy to spend 50,000 words recursively going into every nook and cranny, but I think this is a really good time to take a break here.

Ok, fine, I’ll talk about Backend really quickly because it appears everywhere.

When you want to call something on the backend, you call something like: backend.offerings.getOfferings() or backend.identity.logIn(). This is because Backend serves as a neatly name-spaced API gateway. A composition surface for all of the network requests you might need.

Backend

This low-level infra isn’t immune to containing various dependencies: a collection of all the different APIs and endpoints the SDK can talk to, as well as a BackendConfiguration object containing services like HTTPClient, which wraps URLSession and handles ETag caching, response verification, request signing, retrying, and serialisation with operation queues.

Naturally, the level of logging and profiling required on the network layer is more important than ever.

Last Orders

The RevenueCat iOS SDK creates a reliable and easy-to-use way to handle a deeply complex field like payments, and has helped process $10bn in revenue (and counting!) for developers across the world. Following through the payment orchestration logic in this battle-tested project teaches us a great deal about SDK design.

Backwards compatibility is a first-class consideration.
You need a really strong handle on error handling, logging, and profiling.
The APIs need to be dead simple, with progressive disclosure of advanced use cases via confirmation.
Your dependency graph needs to be layered thoughtfully, with more complex services relying on low-level core infrastructure.
Your code has to work on a wide range of platforms and OS version.
You need to work in imperfect device conditions, including offline.

I didn’t cover this anywhere in the low-level code, but one more critical design consideration when building an SDK is that it should be invisible: there when you need it, but otherwise negligible in terms of its impact on performance characteristics like app launch time, CPU load, disk and network I/O, and app size.

Finally, because an SDK is often a piece of critical infrastructure, you also need to treat tests with the same care as production code.

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

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

Subscribe now

10 techniques to pass 90% of algorithmic interviews

Jacob Bartlett — Tue, 06 Jan 2026 16:01:38 GMT

In my 10ish years of experience (always round up), I’ve so far managed to deftly flit between startups with under-developed hiring processes. I’m a master of slipping through the cracks and convincing entrepreneurs that I’m hot sh*t at iOS.

What I’m trying to say is, I’ve managed to avoid actually learning how to answer algorithmic technical interview questions, a.k.a. LeetCode.

Many people consider LeetCode to be the “highest ROI activity in tech”. This is because it unlocks the door to big American tech companies that typically pay way better than everyone else.

Why does this filter have zero bearing on day-to-day work in a tech job?

I am devloper on Twitter

And why do these companies all support have the same hiring process?

LeetCode enforces a minimum competency bar.
LeetCode interviews help avoid “false positives”. Big tech is optimising to avoid bad hires, at the expense of rejecting some good candidates. LeetCode provides a very standardised way to discover if a candidate can perform a moderately complex coding task under time pressure.
LeetCode selects for people willing to endure an arbitrary grind.
(You aren’t meant to say this bit out loud).
In economics, LeetCode is called “costly signalling”. People who grind LeetCode to land a job are probably conscientious, have a high tolerance for bureaucracy, and will happily sacrifice their free time for career advancement.

As big tech hiring scaled up, and everyone wanted to cargo-cult Google, the mythical “algorithmic challenge” devolved into a cookie-cutter exercise, where candidates pretend to be a secret genius improvising a novel solution as they go*.

*Top tip: don’t actually refer to this as “kayfabe” during your LeetCode interview”

LeetCode was a moderately embarrassing weakness I’d failed to address, until now.

It wasn’t for lack of trying!

I halfheartedly started LeetCoding a few years ago, but after sinking in a few commutes into Two Sum and Valid Parenthesis, decided it’d be more interesting to focus on my blog.

In retrospect, perhaps that was a good decision.

I’m meandering. “Can you get to the damn point?”, I hear you ask from the future.

Big tech devs (mostly) aren’t geniuses. They’re pattern-recognition machines.

LeetCode is purely an exercise in pattern recognition.

The same ~10 patterns, over and over. In various configurations.

That’s why I can legitimately tell you that there’s 10 techniques that will carry you through the vast majority of LeetCode interviews.

You can take my word for this as well, because I’ve got a 100% pass rate on the 4-5 legit LeetCode interview loops I’ve actually done, and I will not be updating this if things go badly with Snap tomorrow.

Okay so what’s on the menu today?

I’m going to demonstrate the 10 techniques that virtually every LeetCode question maps onto.
For each technique, I’ll show you a bona-fide LeetCode question that applies it, alongside my actual diary notes I wrote while trying them for the first time, so you don’t feel so alone when you do it.
Finally, I’ll give you my rough field-guide for staying sane in The Grind™. To be honest, I would recommend reading this first, because then you feel less bad during the rest of the article.

This post is super long, so your email client may cut it off. Read on my website here:

Read on my website

The 10 Techniques

Hashmaps

Hashmaps (a.k.a. Dictionaries) are the basic cheat code for any algorithmic question, because they offer O(1) lookups (a.k.a. constant time complexity)*.

Virtually every time I’ve done a real-life LeetCode interview, I’ll write a solution that’s messy, inefficient, but works. After verifying my code, I’ll be asked “how efficient is that?” and check the time complexity, and be gently prompted to make it more efficient**.

This is usually code for “use a hash map”.

*Sets also have constant time lookups, but you’ll use those less often.
**If you’re a better candidate than me, you can do this without being asked.

Hashmap problems take many forms. You might build a dictionary to count the frequencies of each character in a paragraph. You might use a hashmap to cache values, and efficiently check if a value has already been computed or not. You might do something clever with keys, by computing a value that you’ll need later, à-la the O.G. Two Sum problem.

The core pattern is making one pass through the input data to construct the hashmap, then another to query whatever you need. Sometimes, you can do both at the same time and exit early.

That was a lot of words. If you’re a LeetCode novice, I hope I haven’t scared you off. Here’s a nice LC Easy to cleanse the palette.

My LeetCode Diary: #383 Ransom Note

Surprisingly, I’m actually pretty good at traversing a collection and populating a dictionary. This might be the first LeetCode problem I found, dare I say, fun.

This is the classic hashmap approach, iterating through to count the characters, and traversing again to decrement and check you have enough characters for the target.

You aren’t limited to integers and characters in your hashmap either.

You can store Linked List or Tree nodes in a dictionary. This is often the solution to any “make a data structure with O(1) reads and writes” problem (see LRU Cache).

You can also place Graph edges into a dictionary for a topological sort (see Course Schedule), or just track “visited” nodes for a depth-first search (see Clone Graph).

Two pointers

This is probably my favourite technique, because I feel dead smart every time I use it.

Upgrade to unlock this article, plus much more:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my course and advanced training

Subscribe now

🎄 I just gifted you 14 days' membership

Jacob Bartlett — Fri, 19 Dec 2025 17:00:03 GMT

Seasons greetings,

I’ve been pretty flat out this month grinding interview loops, so haven’t had much time to write. Plus, the kids are off school & nursery over the Christmas break, and I am told Christmas is a good time for family and stuff.

Hence, I’m taking a well-deserved 2-week break over Christmas.

To soften the blow, I gifted all my paid subscriber…

Copy-on-write teaches you EVERYTHING about Swift Internals 🐮

Jacob Bartlett — Mon, 15 Dec 2025 16:01:29 GMT

There is a global function in Swift that, when you fully understand it, will teach you everything you need to know about Swift internals.

You’ll never guess what it is, because I guarantee you’ve used it less than 3 times in the real world, if you’ve even heard of it.

isKnownUniquelyReferenced().

If you know, you know: this function powers the copy-on-write optimisation (a.k.a. CoW, a.k.a.k.a. 🐮).

It pretty much only ever comes up if a) you’re a library author, or b) you’re interviewing someone and want to rate their power level when it comes to Swift internals*

*I never let interviews get to this point, because I burn 45 minutes responding to their first question about weak references.

I wanted to understand how this function worked, and little did I know that it would take me on an odyssey through every single layer and sublayer of the Swift source code. Seriously. Every layer.

As it happens, it’s pretty much the perfect candidate for doing this. type(of:) comes close, but doesn’t quite stick the landing in as satisfying a way.

Will learning all this make your hairline recede another inch? Yes.

Are you going to come on a fun journey to learn Swift Internals™? Also yes.

Let’s work through the various sublayers of the p̶l̶a̶n̶e̶t̶ Swift Source Code and discover once and for all how isKnownUniquelyReferenced works.

I kind of wanted to do a Donkey Kong Bananza bit with each section representing a different sublayer but I truly did not think enough people would get the reference.

Journey to the centre of the 🐮

(yes we’re really going through all these)

What is 🐮?

For anyone who hasn’t brushed up on their interview prep recently:

🐮 optimises the performance of a Swift struct to get the best of both worlds:

easy-to-reason-about value semantics.
low memory overhead from reference semantics.

“Uhh, I just said I wasn’t doing interviews, can you not drop terms like “reference semantics” as if I remember what they are?” I hear you say from the future.

Right. Sorry.

Value and reference semantics

Value semantics = copies are independent entities

Reference semantics = copies point to the same underlying memory on the heap

structs that utilise 🐮 store their data in a memory buffer on the heap.

When the struct is copied, all the properties are copied, including the 64-bit pointer to the backing data, referencing the memory address 0x00000000d34db33f.

This is a shallow copy. Each copy of the reference still points to the same underling memory. This underlying memory is shared. This is reference semantics.

When the value of the data on a copy of a 🐮 struct changes, value semantics kick in.

The struct allocates a new buffer of memory on the heap, copies the updated data there, then points at the new buffer. A deep copy. It leaves the original memory block, and other instances of the struct pointing to it, unchanged.

🐮 In the Swift Standard Library

Many fundamental types in the Swift Standard Library utilise the 🐮 (copy-on-write) optimisation:

Array
Set
Dictionary
String
Data (actually an impostor from Foundation, but it’s one of the gang).

When using these data structures in your code, or even types that contain them, you reap the benefits of the underlying 🐮 optimisation for free.

But it’s possible to implement 🐮 in your own types, too!

Implementing 🐮

Very senior iOS engineers will tell you how you can implement your own types that utilise 🐮. Check out this sample robbed straight from Apple’s Swift Optimisation Tips:

In short, you place your struct, T, in Box.

Box wraps T in a reference, Ref, placing the structure on the heap.

You can read the value inside Box trivially.

When you write the value, we check if the memory inside Ref is uniquely referenced, that is, if there is only one pointer to this instance. If it is unique, the value mutates in-place. Otherwise, the heap memory buffer under Ref is copied into a new address before mutation. The Ref pointer inside Box changes to point to this new address.

This illustrative example shows how isKnownUniquelyReferenced can be used to implement 🐮, but it’s kind of sh*tty for real life code: you’re polluting your type with slower reference access semantics to make copying a bit more efficient.
It’s only a good idea when copying is expected and there is enough memory that it makes sense to place it on the heap.

A mysterious function, isKnownUniquelyReferenced, is the secret sauce that makes this optimisation possible.

As it turns out, it’s fucking mysterious, because I originally spent about 3 weeks traversing megabytes of C++ (in 2023, before AI tooling could even touch this kind of task) to understand what the hell it was doing.

The Swift Standard Library

First things first.

Let’s download the Swift source code, search for isKnownUniquelyReferenced, and take a gander at the implementation.

Or, you can just CMD+Click that bad boy in Xcode.

It’s holed up in ManagedBuffer.swift, underneath the definition of ManagedBufferPointer. I don’t love putting global functions in the same file as semi-related data structures, but who am I to question the wisdom of our Cupertinoverlords?

Here’s the implementation of isKnownUniquelyReferenced I’ve been searching for in all its glory:

All in a day’s work.

I’ll head to the pub now for a well-deserved beverage.

Builtins

I’ve got my beer!

Uh, I suppose I don’t have much else on.

Perhaps we can dive a little bit deeper and find out what _isUnique is doing.

Much deeper. Including Builtins, The Swift Compiler, The Abstract Syntax Tree, Swift Intermediate Language, LLVM Intermediate Representation, The Swift Runtime, SwiftShims, and The isKnownUniquelyReferenced Meme.

We find _isUnique defined pretty close by in Builtin.swift:

Loving the doc comments from Apple; let’s as an industry strive for more quantum physics references in our source code!

We need to find out what this Builtin.isUnique(&object) guy is trying to do.

This is where things get interesting.

We find this Builtin function defined somewhere totally different: Builtins.def.

BUILTIN_SIL_OPERATION(IsUnique, "isUnique", Special)

Why is this located in include/AST? What is a SIL operation? Huh???

Before we can progress any further, we need to understand a bit of theory about the Swift Compiler and its dad, LLVM.

(Interlude) The Swift Compiler

The Swift Compiler processes Swift source code files into efficient machine code. It’s a pipeline with several Swift-specific optimisation stages.

Swift compilation process: Image from Jesse Squires on Realm Academy

Let’s get our heads around each step in some detail:

.swift files are parsed and turned into a data structure known as an Abstract Syntax Tree (AST), making it easy for algorithms to traverse.
Semantic analysis is performed on the AST, performing tasks such as type-checking, evaluating protocol conformance, and checking variable scopes.
Swift Intermediate Language (SIL) is generated from the AST. This is a halfway point between raw Swift code and the low-level LLVM machine code.
This SIL is optimised through various passes. ARC is optimised, generics are specialised, code is inlined, and devirtualization replaces dynamic dispatch.
Optimised SIL is transformed into LLVM IR (Intermediate Representation). This is a high-level, language-independent kind of assembly language.
LLVM is a compiler toolchain: a frontend that processes any language into IR, and a backend that translates IR into machine instructions for any CPU. LLVM runs multiple optimisation passes on IR, enhancing performance for the target CPU.
The LLVM backend transforms the LLVM IR into actual machine code and produces object .o files. These contain these assembly instructions, metadata, strings, and debug information.
In the final compilation step, the Linker combines various object files with libraries into a single executable, which the OS can load to run a Swift application.

I go into way more detail here:

Our isKnownUniquelyReferenced Compass

With that substantial segue completed, let’s return to our isKnownUniquelyReferenced deep-dive.

Now that we understand how the Swift Compiler works, we have a compass with which to orient ourselves while we dredge the depths of the Swift source code.

Instead of inspecting the 859 individual instances of isUnique we find when we CMF+F the Swift codebase, we can:

Find out how the isUnique Builtin function is applied to the Abstract Syntax Tree.
Work out how isUnique looks when it is transformed into SIL (Swift Intermediate Language).
Determine how isUnique behaves when converted to LLVM Intermediate Representation.
Understand how these low-level instructions check whether an object is uniquely referenced.

(I didn’t know this at the time, but this only took me halfway).

The Abstract Syntax Tree

Last time we left off, we found the Builtin declaration for the isUnique method in the AST/ folder, Builtins.def:

/// isUnique only returns true for non-null, native swift object
/// references with a strong reference count of one.
BUILTIN_SIL_OPERATION(IsUnique, "isUnique", Special)

.def files contain exported C++ macro definitions. Think of them like header files.

The include/ folder defines a public interface to the Swift Compiler, which is made available to stdlib/, the Swift Standard Library.

Builtins on the AST

First, we need to work out how the Builtin isUnique function gets applied to the Abstract Syntax Tree.

We find the Builtin being synthesised here in Builtins.cpp:

Several methods show up here: IsUnique, IsUnique_native (with extra safety checks), and BeginCOWMutation, which the Swift Standard Library uses to internally implement 🐮 for Array, ArraySlice and ContiguousArray.

These variants all produce the same getIsUniqueOperation, hung like so many baubles onto the AST (abstract syntax tree). This itself calls getBuiltinFunction to return a pointer to a ValueDecl, which represents a function signature.

You’ll notice the function signature returns Int1, a single-bit Integer. This is actually the underlying “Builtin” backing store used to implement the Swift Bool!

Synthesising a Builtin Function

getBuiltinFunction is actually implemented in this same file:

With most code samples in this article, I’ve stripped out most of the code to make the key moving parts clearer, but feel free to look at the full source yourself. There’s still a whole bunch of code, so I apologise for my crappy redaction.

There are 3 critical steps to follow here:

A reference to the Builtin module is retrieved from the ctx, the AST context, a repository of shared information the compiler uses to generate functions.
The generic inout parameter for isUnique and the result type, Int1, are defined here, to synthesise the signature of the FuncDecl.
id, the Builtin function identifier, is used to synthesise the function declaration we want from the Builtin module, i.e. IsUnique.

In summary, a FuncDecl, a function declaration, is synthesised. This implements the isUnique method on the Builtin module, and gets hung on the Abstract Syntax Tree.

All this processing allows Builtins to behave just like regular Swift functions.

`T`he Builtin Module

Swift’s Builtin module itself contains a set of low-level functions and operations that map to LLVM IR instructions, bypassing Swift’s ordinary type safety mechanisms.

As we have seen, Builtins are used extensively in the Standard Library for performance, but Apple doesn’t trust us mere mortals to utilise them ourselves.

To be honest, I’m 2 Hepcats deep at the pub, and I wouldn’t trust me either.

Gipsy Hill brewery, pls sponsor my Substack, I’ll send you my media kit, you can pay me in beer.

AST Recap

Let’s recap on our progress so far:

isKnownUniquelyReferenced calls an internal isUnique method, which uses a Builtin method, a special low-level function implemented inside the compiler.

When Swift code compiles, Builtin.isUnique plops straight onto the AST. Indistinguishable from a run-of-the-mill Swift function. Later compilation stages treat it as such, but ultimately it maps to a dedicated instruction.

What happens to this Builtin function next? How does the resulting low-level instruction check the reference count?

To truly find out, we need to go deeper.

Let’s check our compass.

Next stop?

SIL.

Swift Intermediate Language

After constructing an Abstract Syntax Tree and synthesising Builtin function declarations, the Swift Compiler converts your code into Swift Intermediate Language. SIL is the precursor to LLVM IR, which itself undergoes multiple very cool Swift-specific optimisation passes.

In our journey to find out how the isUnique Builtin is working, the obvious first port of call is the SIL Generation library, and specifically, SILGenBuiltin.cpp. It’s not easy to find the right function calls. Naming is a bit jank between compiler steps.

This function looks… about right:

Only 10 lines this time. I’m learning. As before, I’ve left out numerous lines of C++ assertions (mostly nullability checks) to make the code easier to follow.

This emitBuiltinIsUnique method, naturally, emits the SIL instructions for the Builtin function isUnique.

Following createIsUnique further, we find it defined in include/ inside SILBuilder.h, which acts as the public interface for SIL:

C++ header files often inline their methods. createIsUnique method, in arcane C++ syntax, instantiates an instance of the type IsUniqueInst. Inst, in this context, meaning instruction, not instance.

Uh, perhaps I structured the above paragraph pretty badly.

We locate the class declaration for IsUniqueInst at SILInstruction.h:

IsUniqueInst ultimately defines the Swift Intermediate Language instruction, which checks whether an object on the heap is uniquely referenced. This SIL instruction is now ready for optimisation passes and eventual conversion into LLVM IR.

Desperate to learn more about Swift Intermediate Language? Check out my O.G. Elite Hack, my first every foray into paid content, where I go way deeper on what it does for Swift.

Let’s make this simple: we haven’t worked out how the uniqueness checks are happening yet.

The key to searching through the compiler is all about maintaining your bearings as you traverse each layer, down towards low-level instructions and runtime ABI calls. Usually, the runtime that has what we’re looking for. We’ll get to that, bear with me.

LLVM Intermediate Representation

Chris Lattner, creator of LLVM and Swift, apocryphally called Swift “syntactic sugar for LLVM.”

After parsing the Abstract Syntax Tree and Swift Intermediate Language generation, we arrive at the lowest level of the Swift frontend to LLVM: Synthesising instructions in LLVM Intermediate Representation.

LLVM IR is a language-independent, high-level assembly language around which LLVM itself is designed. The LLVM toolchain optimises this IR for any CPU instruction set architecture you want to run your code on.

After searching through lib/IRGen/, the library for generating LLVM IR, we spot a familiar-looking declaration in IRGenSIL.cpp: this time, taking in an SIL instruction as an argument and emitting LLVM IR for the isUnique Builtin function:

This method loads in a “reference-counted pointer”, that is, a pointer to the object we’re checking the uniqueness of, in loadRefcountedPtr. Then it emits the isUnique function call as an LLVM IR instruction.

Following this emitIsUniqueCall function call along; we are led to GenHeap.cpp in the IRGen/ library.

The documentation at the top of the file reads:
“This file implements routines for arbitrary Swift-native heap objects, such as layout and reference-counting.”
Is that light I see at the end of the tunnel?

Let’s read through the implementation of emitIsUniqueCall:

I’ve omitted a ton of code here, mostly around switch cases for nullables and ObjC.

The getIsUniquelyReferenced_nonNull_nativeFunctionPointer() function call generates LLVM IR, which, when compiled and linked, calls into the Swift Runtime™ upon execution.

It looks like our understanding of Builtins was a little incomplete.

This is really important, probably the most important bit so far:

Builtins usually represent low-level, memory-unsafe, hyper-efficient types like Builtin.Int1, Builtin.Int64, and Builtin.FPIEEE64 (a.k.a. “Double”). Stdlib structs like Bool and Int use these as internal backing storage.

But Builtins can also function as direct Swift runtime calls. The functions compile directly down into instructions that call into the runtime library.

This is all possible due to the incestuously interlinked nature of Chris Lattner’s Targaryen harem: The Swift Standard Library, the Swift Compiler, and the Swift Runtime.

The Swift Runtime

The Swift Runtime provides core functionality you need to execute a Swift program: Dynamic dispatch, error handling, types, and memory management operations like reference counting.

I think you can see where this is going, at last.

If you like runtimes, but aren’t sure you’re ready to love runtimes, here’s an excellent primer:

Checking the docs

Let’s investigate where the LLVM IR instruction for IGM.getIsUniquelyReferenced_nonNull_nativeFunctionPointer actually ends up.

This is more art than science: naming is fabulously inconsistent between Swift layers.

Like all good engineers, we can save ourselves hours of flailing about with a few minutes of reading documentation.

The Swift Runtime ABI documentation defines the interface that compiled machine instructions may call into. Specifically, the memory offset for each function inside the compiled runtime binary.

I’ll do an article on ABI stability once I’m convinced lots of people will pay for it, because I am not touching that sh*t for free.

The definition we’re looking for is _swift_isUniquelyReferenced_nonNull_native:

Runtime.md

Fortunately, we don’t need to search out 000000000002aea0 in some obscure binary.

Unfortunately, we do have quite a bit more C++ to sift through.

Swift Object

I investigated the Swift Runtime source code in /stdlib/public/runtime.

Looking at SwiftObject.mm (an Objective C++ file!), we locate the function that was defined in the ABI:

After some assertions to avoid undefined behaviour from null pointers (no type-safe nullability here!), we are looking at the HeapObject argument, inspecting its refCount property, and asking if it’s uniquely referenced.

HeapObject

Every reference type in Swift stored in a block of memory on the heap. HeapObject represents the “header” metadata attached to each of these blocks of memory, stored contiguously in front of the memory itself, like so:

+-----------------------+
| HeapObject            |  <- header struct
| - metadata (isa) ptr  |     <- type information
| - inlineRefCounts     |     <- reference count bits
+-----------------------+
| Instance Data         |  <- The actual data for your object 
| - field1              |
| - field2              |
| - ...                 |
+-----------------------+

HeapObject is a simple C struct storing type metadata and reference counts. RefCounts is, itself, a struct that holds the strong, weak, and unowned reference counts of the object in memory.

Uh, I also did a ridiculously in-depth deep-dive into reference counting here. Like, I literally look at the bit layout of the refCounts C struct. It’s good, clean fun.

Like SEAL Team 6, let’s target where isUniquelyReferenced() is implemented, on the refCount for a HeapObject. With extreme prejudice.

SwiftShims

SwiftShims is a lightweight compatibility layer between the Standard Library, the Runtime, the Compiler, and the OS. This collection of C and C++ header files helps to bridge high-level code with underlying system libraries.

Critically, RefCount.h implements the method we’re tracking down:

This refCount struct has an isUniquelyReferenced() property. For this uniqueness check, we safely load the memory into the bits property and ask if it’s uniquely referenced.

If the object has any weak references (or the strong or unowned ref counts overflow), the refCounts live on a “side table”. That’s why the isUniquelyReferenced() check either loads directly from refCounts or checks the side table.

Next, we can see the underlying implementation of isUniquelyReferenced():

getUseSlowRC checks whether there’s a side table storing overflowed pointer counts; and getIsDeiniting is fairly self-explanatory: deinitialisation only happens when a strong reference count is already zero.

The most important part here is getStrongExtraRefCount() == 0. Scrolling up to the documentation inline, we find:

The strong RC is stored as an extra count: when the physical field is 0 the logical value is 1.

If an object has exactly one strong reference (logical), the bits representing the strong reference count are 00000000 (physical). The getStrongExtraRefCount function finds us the strong reference count that we’re looking for, StrongExtraRefCount:

Here, we call into a C++ macro that returns the StrongExtraRefCount field stored in RefCount:

These macros operate directly on the bits stored by RefCount to return the integer value of StrongExtraRefCount. These bitwise operations can be dense, so let’s take this step-by-step:

The logical number StrongExtraRefCount is stored in the bits in RefCount‘s memory layout, bit-packed with other metadata (unowned count and flags) to save space.
Let’s say the memory layout for the RefCount looks like 00101010 (in reality, it’s 64 bits wide, I’ll actually show you in a minute).
The bit-mask has 1s for the locations of the bits that represent the StrongExtraRefCount, e.g., 00001100.
We can run a bitwise & operation to isolate just those bits, 0-ing out the rest of the data: leaving us with 00001000.
The offset ##Shift contains the number of “significant” digits which the StrongExtraRefCount lives at, which in this example is two bits from the end (in this one-byte example, we don’t need to fret about endian-ness).
The right bit-shift operator >> shifts our bit-masked data to the right, returning 00000010.
This, in full binary glory, is the strong extra reference count we’re looking for: 10, or “2” if you’re a decimal normie.

Therefore, our object has three strong references, meaning it’s not uniquely referenced!

I’ll encourage you to read “Bits and Side Tables” once again because I show you the actual physical bits inside RefCount:

The isKnownUniquelyReferenced Meme

We’ve finally determined how isKnownUniquelyReferenced is working behind the scenes to power our 🐮 optimisations.

It’s all a bit obvious, really.

Each time a new pointer is created to reference an object stored on heap memory strongly, it increments the strong reference count of that object.

isKnownUniquelyReferenced simply slips through its backchannel into the runtime to ask whether the object’s strong reference count is equal to 1.

7-tier expanding brain meme, created with Memegenerator

(Accessible version of the meme)

isKnownUniquelyReferenced just checks the strong reference count = 1
isUnique in the Swift Standard Library calls a Builtin function
The Abstract Syntax Tree synthesises Builtin functions so they can be called like regular Swift functions
Swift Intermediary Language emits the IsUniqueInst instruction, which performs the uniqueness check
The LLVM IR instruction generates the emitIsUnique instruction, which calls into the Swift Runtime ABI
The Swift Runtime inspects the bits on a HeapObject which stores the strong reference count
isKnownUniquelyReferenced just checks the strong reference count = 1

Last Orders

When I first casually looked into isKnownUniquelyReferenced back in 2023, I had no idea what I was getting into. I assumed I’d poke around the Swift Standard Library, find some funny private API that tracked a sneaky reference count property somewhere, and call it a day.

Curiosity is a heavy burden.

Like Dante, I kept pressing forward.

Into the haunted woods of the Standard Library source code. Through the purgatorial hallways of Builtin definitions. Deeper and deeper, through the infernal circles of the Swift Compiler: the Abstract Syntax Tree, Swift Intermediary Language, and LLVM IR. Until finally, paradise was found in the Swift Runtime and SwiftShims.

Today, Swift Internals is a core pillar of Jacob’s Tech Tavern.

I hope you had fun, learned a lot, and, most importantly, I hope you get the chance to flex your unbeatable 🐮 knowledge the next time you get an iOS job interview.

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

Subscribe now

This is a full re-write my most underrated post of all time. Nobody read it, because I only had 291 subscribers at the time. Really.
I hope I can bring the joy to a new generation of subscribers.
And if you liked this post, you will love this:

Ancient Secrets of the Objective-C Runtime

Jacob Bartlett — Tue, 09 Dec 2025 16:02:35 GMT

Don’t go anywhere! Seriously.

This is not some theoretical archaeological deep-delve.

I’m going to give you something you can use in your Swift apps today.

I’m NOT talking about #selector, @objc-marked methods, or dynamic functions.

This post is about Objective-C runtime internals. How ObjC is built, the powerful features it offers, and how to apply these features to simplify your modern Swift codebase.

I’ve been doing iOS for just under 10 years. I went into consulting in 2016, just after the Grand Renaming™ of Swift 2.0 to Swift 3.0.

It was kind of an annoying time to begin tbh.

I spent month #1 of my first ever job working through the Big Nerd Ranch Swift textbook, but Deloitte didn’t want to shell out $21 for the Swift 3 edition, so I spent half my time Googling each line of syntax to find the renamed version.

I dipped my toe into a few hairy legacy ObjC codebases back in the day, but I’ve managed to spend about 98% of my career rolling Swift. Yay me.

Most iOS devs today are similar. Many of you have likely never touched Objective-C.

So why am I darkening your doorstep with a d̵͈͚̈́́̑e̴͙͐̍ä̶̠̺̣́͆́d̸̳͠ ̵̰͉̾̓l̵͚̬͆͂́ā̵̧̛̼̈́ǹ̸̡͎̟̔g̶̣̜̋̊̃u̷̙̇̂͗ą̸͉͕͘͝͝g̶̢̞̈̀e̷̫͔̿?

3 reasons:

We can learn a lot from ObjC’s design and runtime internals.
There are useful practical applications that work in UIKit apps today.
It’s really bloody interesting.

Sound good? Come along for the ride.

Upgrade to unlock this article, plus much more:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my course and advanced training

Subscribe now

Method Dispatch in Swift: The Complete Guide

Jacob Bartlett — Mon, 01 Dec 2025 16:02:54 GMT

If you’re like me, you’ve worked with a grizzled staff engineer that generously doles out helpful nitpicks to improve the performance of your code.

Perhaps, like me, you’ve also been that grizzled engineer.

You know the sort.

Nitpicks like “this method should be declared fileprivate”, or “keep your generics in the same file where they’re used”, and the all-time classic “mark this function as final” to help out the compiler and speed up your code.

In modern Swift, you might as well spend your time writing branch prediction hints for the compiler. That is, the compiler and runtime do a ton of optimisation under the hood that makes these tips redundant.

These optimisations are mostly around Method Dispatch.

That is, how Swift executes function calls. This knowledge is crucial for understanding the low-level performance characteristics of your code.

Today we’re going to learn:

How (and why) Swift implements all 4 types of dispatch
What the Swift compiler does to your methods in secret
How the Swift runtime calls into your functions at runtime
How to make your code run faster
How to build an intuition about method dispatch

Subscribe free to join 100,000 senior Swift devs learning advanced concurrency, SwiftUI, and iOS performance for 10 minutes a week.

Subscribe now

Method Dispatch

In broad Computer Science terms, “method dispatch” is the process for telling the CPU where to find executable code in memory for a function call.

Method dispatch can be static or dynamic, but these break down into 4 sub-types. As you move down, method dispatch becomes more flexible, but slower: The types create a bidirectional hierarchy of speed & flexibility.

This hierarchy is defined by indirection. That is, the number of times the CPU has to jump between pointers to find the machine code for a function.

Inlining (fastest, not flexible)
This optimisation unrolls a method’s contents directly onto the code path.
Static dispatch (fast, not flexible)
The function’s memory address is known, so the CPU jumps straight to it.
Table dispatch (slow, flexible)
The CPU jumps twice: once to a table of pointers (to potential implementations), then once to the correct implementation.
Message dispatch (slowest, very flexible)
There might be multiple jumps as the runtime traverses class and superclass metadata to locate method implementations. This dynamic approach implements caching that can speed it up past table dispatch once it’s ‘warmed up’.

Most languages pick just one or two approaches:

C only uses static dispatch since it is designed around predictable low-level performance.
Java only implements table dispatch because of its focus on portability, meaning the JVM must always be able to load classes dynamically.
Objective-C uses message dispatch because it is deliberately built for runtime dynamism, with language features like swizzling and method forwarding.

Swift implements all 4.

This is due to the scope of the language.

Swift is (designed to be) as performant as C when using value types like structs and enums, which use static dispatch.
Swift also supports classes, protocols and generics, which rely on the more flexible table dispatch to locate relevant implementations.
Message dispatch, honestly, is a legacy Objective-C holdover. Swift had to be fully compatible with Obj-C and UIKit in order to achieve adoption from the aforementioned grizzled staff engineers.

This is a double-edged sword: Swift gives engineers fine-grained control over the performance characteristics of their code; but this scope also introduces many of the gotchas and misunderstandings that trip up less experienced Swifties*

(I’m pretty sure this is what they call us).

Inlining

This is the fastest approach, and is actually not dispatch at all. Inlining is a compiler optimisation which replaces the call to a function with the actual code from inside that function.

We don’t usually control this*. The Swift compiler makes the call about inlining function calls during its SIL optimisation stages.

*but you can influence it by selecting size vs speed compiler optimisations.

Let’s say you had the following code:

If the compiler decides to inline this, the compiled Swift might be equivalent to this:

Here, the call to the addOne function is just replaced with the operation num + 1, where num is replaced with our argument, 2.

Pre-computing

The compiler can go further.

Since these numbers are hardcoded, the compiler actually has all the information it needs to calculate this result at compile-time. It can, literally, pre-compute the result we need here, giving us a simple number.

Inlining skips dispatch entirely, but pre-computing avoids runtime execution altogether. No work needs to happen in our (hopefully) millions of users’ devices at runtime.

Swift Intermediate Language

Before compiling your code down to machine language, the Swift compiler converts it into Swift Intermediate Language (SIL), where it runs through many optimisation passes.

You can generate SIL yourself from Swift code like this:

swiftc -emit-sil -O main.swift > sil.txt

-O tells the compiler to run optimisations for speed, which include inlining. -Osize in contrast optimises for smaller binary size, making the compiler less likely to inline. Copying a function into multiple places inline can grow binary size.

Learn more about SIL in my mini-deep-dive:

The resulting arcane hieroglyphs allow us to see the optimisations in person:

caption...

I omitted most of the code for brevity (4 lines of Swift turns into 78 lines of SIL!), but we can see inlining in action:

Memory is allocated for the twoPlusOne property.
The pointer address of our twoPlusOne property is assigned.
An integer literal for 3 is precomputed and inlined.
This value converted into an Int struct from the Standard Library.
This Int is stored at %3, the memory address of twoPlusOne.
You’ll usually see these lines at the end of a main() function. This is simply exiting the program with code 0 (i.e. without an error).

SwiftRocks has a great article if you want more of a deep-dive on inlining and the undocumented @inline attribute.

Why is inlining so fast?

While SIL does not map 1:1 onto ARM assembly instructions (you need to run swift -c for that!), it is pretty intuitive that less SIL will execute faster than more SIL.

To truly peer behind the veil, we need to touch the metal: what is happening on the CPU when you call a function?

There is Overhead each time you invoke a function. The CPU caches the data on its registers, jumps the instruction pointer to a new memory address, and restores state after function execution.

An executing binary lives primarily in a chunky TEXT file stored in memory. Segments of executing code are copied to the CPU Caches, which are accessed 100x faster than RAM. A slow cache miss happens if a function has to be loaded from memory.

CPUs utilise Pipelining to handle multiple instructions simultaneously. When it needs to wait for a new function to be loaded in from RAM, the instruction pipeline may be disrupted, stalled, or even invalidated entirely.

The CPU applies Branch Prediction to estimate which code paths are likely to run next, allowing it to fill the pipeline with the most likely paths (and even look ahead with predictive execution). Jumps to function calls can easily disrupt a CPU’s ability to predict outcomes.

Learn more about binaries and TEXT here:
I’ve also written a lot about registers, CPU caches, and pipelining here:

Due to all these factors, inlining and pre-computation are powerful tools in the Swift Compiler’s arsenal for optimising your code for pure speed.

Static Dispatch

No, not this kind of static. Effect generated using Metal in SwiftUI: How to write Shaders

This is also known as direct dispatch or, occasionally, compile-time dispatch. These names all describe what’s going on:

static implies that the location of the function in memory is fixed…
…and knowable at compile-time.
Therefore, only one jump is required to find and execute the function, directly to the memory address of the function in the binary.

static functions in Swift, as well as functions on enums and structs, use static dispatch. The compiled machine code of these functions is stored at a known address in memory when a Swift program launches.

This deterministic nature of static dispatch enables the compiler to easily run optimisations such as inlining and pre-computation.

Let’s see this in action with a very basic struct, with another addOne function:

Let’s generate the Swift Intermediate Language for this code and see what’s going on under the hood of the compiler.

Again, I’ll massively cut down the 97 lines of generated SIL for this 7-line main.swift file to avoid information overload.

Let’s see what became of our main function:

Memory is allocated for the threePlusOne property.
The function call for the Adder struct’s init function is called.
You thought struct initialisers were implicit? They are, until the compiler generates it!
apply is the SIL instruction for calling a function, taking %4 (the type) as an argument for %5 (the function).
Next, the integer literal for our function argument , that is, the number 3, is instantiated. First a Builtin Literal is called, then an Int is initialised.
Finally, our addOne function is called; creating a function pointer function_ref, and passing the arguments created before: the Int and the Adder.

The calling convention of SIL looks a lot like Python: self, the instance, is explicitly passed to the call site of its methods.

This is because the methods on a type are shared between all instances in memory. Therefore, a reference to the instance is required to access or mutate any properties.

The definition for our addOne function is found here as well:

An integer_literal is declared using 1, and the integer value of the input argument is extracted.
This is where the magic happens: the actual functionality of the Int.+ function is inlined here using the Builtin implementation.
There is some nifty error-handling that detects arithmetic overflow (i.e. values over 2⁶³-1); and the result Int is instantiated and returned.

I won’t go into more detail here, but the Int.init(_builtinIntegerLiteral:) initialiser and the Int.+ infix(_:_:) functions are also both defined in SIL.

Not sure what is meant by Builtin? Read this post if you want to become absolutely sick of seeing them.

When compiling this SIL with optimisations, the addOne function itself is inlined straight to the call site; and the Int.init() and Int.+ functions disappear entirely.

The Swift compiler collapses entire chains of statically-dispatched function calls inline to extinguish many expensive function calls at once. Such is the power of direct dispatch.

Dynamic Dispatch

This is also known as table dispatch, or sometimes runtime dispatch (some of these words are straightforward) . Basically, the function we dispatch to is dynamically chosen. This means chosen at runtime.

Table dispatch isn’t as obvious semantically, but divulges an implementation detail: a table of pointers. This table is critical for implementing polymorphism. The power for a single type to have multiple formes.

Before you shout at me, yes, Swift actually implements two flavours of table dispatch: virtual tables for class hierarchies, and witness tables for protocols.

Virtual Table Dispatch

Photo of my 3 cats: Rosie, Cody, and Luna. It’ll make sense in approximately 6 seconds.

Consider a very basic class hierarchy involving the Felidae family (to use the most precise taxonomical term, look it up).

Here, the subclassing relationship implies that a Lion is “a kind of cat”. If this code was part of an open-source Animals package (and marked open, so subclassable in other modules), we could import it and subclass Cat ourselves, with a custom implementation of cry().

Therefore, if you use a Cat subclass in your codebase, it might roar, since Lion is a possible subclass of Cat. Swift also needs to handle other possible implementations of cry() for any other subclass of feline*.

Since our .swift files are compiled independently**, the Swift compiler can’t be sure which implementation is going to be used where. This information is only available at runtime . Until the object is actually created, we don’t know whether we’re dealing with a bog-standard kitty or the king of the jungle***.

*Let me be clear, I mean “class” Swift-onomically. Taxonomically, cats and lions are a Family, and they’re both from the class “Mammal”. A superclass if you will. Sh*t.
**.swift files compile independently when whole-module optimisation is not active. I’ll go into more detail in Making Your Code Go Faster in a moment.
***Shouldn’t it be “king of the savannah”?

The virtual table isn’t magic at all.

It’s a list, built at compile-time for each subclass, mapping each function to its implementation in memory.

If Lion overrides cry(), then the table points at the instructions defined on Lion.cry().

If it doesn’t override eat(), then the virtual table for Lion will point at the instructions defined in the Cat superclass.

This is the indirection I was talking about before.

Table dispatch is slower than direct dispatch because at runtime, to dynamically dispatch to a function, the runtime first needs to:

Jump the instruction pointer to the virtual table stored in the subclass type metadata in the binary.
Pick out the correct function pointer from this table.
Jump the instruction pointer, again, to the function’s memory address elsewhere in the binary.

Cool. What about the other tables?

Protocol Witness Tables

“Witness me” - Mad Max: Fury Road (2015)

Protocols allow developers to add polymorphism to types through composition, even to value types like structs or enums. Protocol methods are dispatched via Protocol Witness Tables.

The mechanism for these is the same as virtual tables: Protocol-conforming types contain metadata (stored in an existential container*), which includes a pointer to their witness table, which is itself a table of function pointers.

*Existential containers are an underlying implementation detail of protocols. To understand these in more detail, check out the in-depth essential WWDC talk, Understanding Swift Performance (2016).

When executing a function on a protocol type, Swift inspects the existential container, looks up the witness table, then dispatches to the memory address of the function to execute.

It’s not necessarily all indirection and jumps though.

The witness table dispatch happens if the type you’re dispatching to is an abstract protocol type. If you specify the concrete type of something conforming to the protocol, then the specific implementation of the code is known at compile-time, and can be dispatched statically.

(I’ll go into this in more detail in Building Up An Intuition soon)

Then why use abstract types?

Anything mockable, for instance. We often use abstract protocol declarations when performing dependency injection: we specify the protocol ; the interface our dependency conforms to ; without a concrete type, injecting an implementation at runtime.

Other times, we might have a Collection containing various protocol-conforming objects we want to iterate over. In these cases, method dispatch is via the witness table.

The term “witness table” is borrowed from constructive logic, where proofs serve as witnesses for propositions. In my opinion, though, this kinda-sorta feels like a post-hoc justification . They already used the term “virtual tables” for dynamic dispatch with subclasses. I reckon our boy Lattner just needed a different phrase to distinguish the concept.

Table Dispatch in Swift Intermediate Language

As mentioned, there are two main ways to invoke dynamic dispatch in Swift.

First, let’s look at the vanilla virtual-table dispatch you might find in a language like Java or C++.

We can see the virtual tables (a.k.a. vtables, if you’re a cool kid) created in the SIL. DoubleIncrementer implements both methods, but only overrides one with a pointer to its own implementation:

Let’s see how it looks when we use a protocol:

This time, we see a witness table (sil_witness_table) in the SIL we generate:

In both of these very simple examples, the compiler actually ends up statically dispatching the main() function straight to the method implementation of increment(), bypassing the dispatch tables. Agh!

If you compile with optimisations, Swift drops the functions entirely and produces precomputed results at the call site. Dammit!

The compiler won’t give you what you want; it’ll give you what it thinks you need…

Stupid, sexy, compiler!

Message Dispatch

It’s moderately more high-tech than this . Image from Pinterest

Message dispatch is the most dynamic tool in Swift’s repertoire of dispatch approaches. It’s so dynamic, the implementation of a method can be changed at runtime through swizzling. It’s so dynamic, it doesn’t actually even use Swift . It lives in the Objective-C runtime library. Huh?

Message-dispatched function invocations are dispatched using the ObjC runtime’s objc_msgSend function. Instances of Objective-C classes have an isa pointer which points to the “class object” , the implementation of the type in memory.

What’s an isa pointer? Boy do I have an article for you!

objc_msgSend follows isa to the class, then inspects its table of method selectors. If the method is found, it’s executed. If not, then the runtime follows the super pointer to the superclass table. If the method is still is not found, the runtime iterates through the object hierarchy, until the method is found or it hits NSObject, the ObjC root object.

This table of method selectors is implemented as a message passing dictionary, which is mutable at runtime. This is how ObjC implements its famous method swizzling.

The ObjC runtime caches memory addresses of methods as they’re used. Calling a cached method is about as fast as a regular table-dispatched function call, making message dispatch quite quick once the program has run for a while and “warmed up” the cache.

Look.

If you want my honest opinion, nobody implementing a language today would have even considered message dispatch . It’s a legacy holdover from the fact that virtually all of Apple’s frameworks have been implemented in Objective-C since time immemorial, including Core Data, UIKit, and Swift’s KVO.

It’s pretty neat though.

Message Dispatch in SIL

To invoke message dispatch in Swift, you need two things:

The @objc attribute, which tells the compiler to make a class, property, or method available to the Objective-C runtime.
The dynamic keyword, which tells the compiler to invoke the property or method via message dispatch.

Let’s write our final main.swift:

And now let’s take a look at the SIL output:

Here, the objc_method on Incrementer is invoked in our main() function.
Note the #Incrementer.increment!foreign to denote that the method is using something outside of native Swift.
When you have an @objc method implemented with Swift, both a Swift flavour and an Objective-C flavour of the method are emitted in SIL.
This redacted SIL code is identical to the statically-dispatched logic we looked at earlier (since we will call into it!).
Here, in the @objc Incrementer.increment(_:), [thunk] lets the Objective-C runtime statically dispatch to the Swift implementation of the method.
Using a separate ObjC function like this allows Swift-native code to call straight into the Swift version straight away (and eschew slower message dispatch).
Methods marked dynamic do not appear in the v_table, since regular table dispatch is not used to resolve the method call.

Message Dispatch. Huh. Yeah. What is it good for?

Message dispatch is certainly not the hammer you want to smash into every programming nail, but it shines in the right use case. Take Realm for example ( yes, I know it’s called Atlas Device SDKs now, but that’s also the lamest rebrand I’ve heard in my life)*.

*Atlas Device SDKs, please sponsor my Substack.

Using Realm on iOS, you need to mark the properties on your database objects @objc dynamic. This is to expose them to the Objective-C runtime. This enables message dispatch on the model properties, and hence powers key-value observation!

Under the hood, this KVO uses method swizzling to replace the getter and setter of a property with customised read/write methods. This in turn allows database objects to dynamically update whenever the underlying data is modified.

Making Your Code Go Faster

This is all really nice theory. The whole article. Wow. Well done, Jacob.

But outside of impressing your wife with your stonking depth of comp-sci knowledge, theory isn’t useful unless you can apply it.

Let’s discuss how your knowledge of method dispatch can help your own code run faster and more efficiently.

Reducing Dynamic Dispatch

The compiler works hard to optimise your Swift code before anything runs.

From the Swift repo’s own explainer on SIL:

If the static type of the class instance is known, or the method is known to be final, then the instruction is a candidate for devirtualization optimization. A devirtualization pass can consult the module’s VTables to find the SIL function that implements the method and promote the instruction to a static function_ref.

Outside the specific context of trying to demonstrate bloody dispatch methods for a blog post*, this is optimisation is generally considered pretty useful. There are several things we can do as developers to help the compiler out, and speed up our Swift code.

*I had to muck around with swiftc -emit-sil for a while to stop the compiler optimising away all my dynamic method calls in the SIL sample code.

Since I am now one with the Swift compiler; I was unable to resist inlining this information here instead of just linking you to the docs.

final and private keywords allow the compiler to optimise a class or method to use static dispatch, because it can infer there is no dynamic polymorphism on those methods. But this tip is largely redundant now that Whole Module Optimisation is on by default. The compiler processes a module’s files all together (rather than each .swift file individually, meaning internal classes and methods can be inferred as final.

Cross-module optimisation takes things a step further and enables optimisations like devirtualisation (dynamic to static) and inlining (static to inline) across module boundaries, even for public functions.

This is set at a conservative level by default, because these optimisations improve speed but can impact code size.

You can explicitly opt into more aggressive optimisations, using compiler flags in your module’s Package.swift:

// Package.swift
targets: [
    .target(
        name: "MyAwesomeModule",
        swiftSettings: [
            .unsafeFlags(["-cross-module-optimization"], .when(configuration: .release))
        ]
    )
]

You can opt out using -disable-cmo.

Performance Characteristics

The actual performance impact of the dynamic dispatch is, usually, fairly small : the additional layer of function call indirection is only a few extra CPU instructions, or clock cycles.

There are, however, two big ways in which dynamic dispatch has an impact on runtime performance:

The compiler loses the ability to perform optimisations like inlining or precomputing.
Indirection can increase the likelihood of a cache miss. Since the location of a function isn’t known at runtime, instead of the CPU reading its instructions from the L1 cache (1ns), your program may need to fetch the function code from RAM (100ns).

RAM is actually slow as balls.

Why can’t we just work out all the concrete types at compile-time?

I’m glad you asked.

The whole point of polymorphism is that concrete types aren’t fully known at compile-time, so runtime behaviour can vary. This allows us to write flexible code, where implementations aren’t instantly known the minute you type out your protocol.

But when we are bounded within a region of known access control, we can know the implementations at compile-time.

Consider the guidance the Swift team gives us about reducing dynamic dispatch . final, private, and whole-module (or cross-module) optimisation.

This gives the compiler more information.

Therefore the compiler can work out whether a type is knowable at compile-time, and therefore whether it can be converted to static dispatch and all its consequent optimisations.

Building up an intuition

Due to its support of all the dispatch methods, Swift has many unintuitive gotchas about how certain types of method are dispatched.

When you understand the underlying mechanisms of static and dynamic dispatch , and the information available to the compiler, we can actually work out how these quirks come about.

The canonical example

Protocols are commonly invoked to demonstrate this “odd quirk” (but not really) to your interns. With protocols, you can impact dispatch behaviour via the type declaration .

See this example with a protocol, an implementation, and default methods on the protocol extension:

When you call into these functions, the type declaration you use when instantiating your class affects whether you get static or dynamic dispatch.

Feel free to copy this code into a Swift playground and see for yourself!

Make sure to follow this, because it’s the most important for cementing your understanding:

When we declare an object as an Animal type, the compiler knows to expect dynamic dispatch, since the type of the animal could be mutated or set elsewhere.
cry(), which is a protocol requirement, gets dispatched via a witness table to the cat’s implementation.
Protocol requirement methods will dispatch via a sil_witness_table because the implementation isn’t necessarily definitive at compile-time*.
Calling sayHello() on the animal is statically dispatched to the protocol extension’s implementation, because non-requirement methods don’t use a witness table, and the type is known to be an Animal.
We can instantiate a Cat object, which conforms to the Animal protocol but has a definitive concrete type.
This gives the compiler a ton of information which will allow it to optimise things : if the class was final, or whole-module optimisation was turned on, then the methods on Cat will be statically dispatched.
Otherwise, they will be dynamically dispatched via the Animal witness table.
When calling the cry() method on cat, the Swift Runtime doesn’t consult the protocol witness table at all, since the concrete type is known.
Therefore, it meows (either statically or dynamically, depending on how your project is set up).
Calling sayHello() is similarly executed by the runtime on the concrete cat type, either directly or through table dispatch.

*In this instance, the compiler can know the concrete type of Animal, however Swift does not necessarily optimise this away: optimisation from dynamic to static is great, but not when it actually changes the implementation of a method.

How to intuit dispatch

At this point in the deep-dive, most contributors to Swift method dispatch discourse like to present a table with the types of entity (protocol, class, final class, extension, etc) and the type of dispatch it uses (conveniently ignoring the existence of whole-module optimisation).

In my opinion, though, it’s fundamentally unhelpful to attempt to memorise the various “gotchas”.. It’s exhausting, and more importantly, the compiler optimises away most of what you’re trying to memorise.

The trick? Just consider whether the memory location of the function is knowable at compile-time. If it’s possible, the compiler will do it.

struct methods?
Obviously static.
Methods on a class?
These can be made static, but only if the compiler can know the type at runtime.
open class methods?
This probably has to use table dispatch to find classes in other modules.
protocol requirement methods?
This always needs to use a witness table, even if the type is knowable, so that execution is consistent.
protocol extension methods that aren’t protocol requirements?
These just live with the protocol in memory, so can be directly dispatched.

Again, I’m trying *not* to give an exhaustive list, because now you have the power to work out most of these instances using dispatch theory.

Last Orders

Look, I really wanted to show you a cool sample project that showed all these dispatch performances in detail: setting up some structs, classes, and dynamic functions, then running some simple addition functions 1 million times each.

But the compiler kept inlining and precomputing everything!

After some time spent fighting these optimisations, attempting to get to grips with @inline(never), and fighting my instincts to clean up the code, I admitted defeat.

Remember my plight the next time you run into a gotcha, some unexpected behaviour, with Swift, and just remember the compiler is trying its darnedest.

If you enjoyed this deep dive, and you’re hungry for more, consider another deep dive into the compiler:

Just remember, folks: tip your compiler this Christmas.

Subscribe now

This is a full re-write of one of my early, critically under-appreciated posts, back from when I had sub-1,000 subscribers. I’m hoping to upgrade some of my old classics from the vault to spread the joy to my new generation of fans.

Inside Meta’s “iOS System Design” Interview

Jacob Bartlett — Tue, 25 Nov 2025 16:01:46 GMT

If you want to maximise your salary as an iOS developer, the second best thing you can do is work for Facebook.

The best thing you can do, naturally, is read Jacob’s Tech Tavern.

Salaries at big American tech companies are hard to believe if you don’t actually know anyone that works for them. Total comp packages for a Meta E5 (senior dev) in London range from £199k to over £400k.

This fact alone makes their interview process a worthwhile field of study.

Roles are competitive, but achievable, with intentional practice. I’ve seen multiple friends and colleagues bang their head against the interviews, year after year, until they finally landed.

Big tech interview loops contain 2 major technical components:

Algorithmic interviews (a.k.a. “LeetCode™”)
The System Design Interview™

You probably don’t need me to explain LeetCode, so I won’t. It’s a grind.

What’s more interesting is the system design component. For most Software Engineering roles, this typically means explaining how you would build the backend infrastructure for a service like Pastebin, Instagram, or Uber.

For iOS roles at Meta, however, they administer an “iOS-specific system design interview”. This is really very opaque and scary if you don’t have insider information, so I wrote this piece.

I personally went through Meta’s interview loop in 2024, and accidentally passed their first round (but ended up dropping out of the process as I’d just landed a cool startup job).

Even better, I got an E5 Meta interviewer drunk. I got the inside-track for how this interview works, and how you are rated by Meta.

He shall remain nameless to protect the innocent

What’s really interesting is that Meta levels candidates entirely on the behavioural and system design interviews. That means the intern and the staff engineer get the same hiring bar on the LeetCode component.

Nailing the iOS System Design interview, therefore, makes all the difference.

iOS-Specific System Design

This interview sounds very amorphous until you understand what it actually is.

My man on the inside summarised it in a single sentence that made me realise it was not so complicated after all:

When To Kill A Project

Jacob Bartlett — Thu, 20 Nov 2025 16:01:51 GMT

Welcome to War Stories, where I partner with famous builders in the iOS space to share real-life stories from the frontlines. It’s part narrative, part interview, all swashbuckling fun.
Today I’m working with Dave Verwer, the author of iOS Dev Weekly and co-founder of the Swift Package Index, plus many other projects you might have heard of.
To catch all my War Stories, be sure to subscribe:

Subscribe now

Without further ado, here’s When To Kill A Project:

“You have to really carefully cut the bits that aren’t working, and feed the bits that are working.”
— Dave Verwer

You might know him from iOS Dev Weekly, but Dave’s early career reminds me of another famous LinkedIn profile.

When I asked for tips about how to become a CTO within 10 years, Dave explained it wasn’t quite how it looked. Instead, it was a combination of growing up with the company as it scaled, working way too hard early on, and being the person to take the business online.

Since 2006, Dave has mostly run his own software businesses. When running your own company, you can just do things, so day-to-day work (as well as work-life balance), varies massively based on current projects and commitments.

Dave very modestly refers to himself as “not that good at coding” (which was deeply validating to my impostor syndrome), and explained his strengths lie in being a generalist, who enjoys getting stuck into all the aspects of running a small business: design, coding, research, writing, even doing the accounts.

One more very critical skill is knowing when to kill a project.

We discussed several of these projects, both successes and failures, and hammered out what we can learn from each of them.

iOS Dev Survey

Focus on what’s working, kill whatever isn’t.
— Dave Verwer

Dave wanted to do this for ages. Fortunately, since you can just do things, he did.

In 2020, he orchestrated the largest ever public Apple platform developer survey.

Dave’s decade spent cultivating a newsletter audience made him one of the only people in the world who could pull this off, and he managed it in a big way: 2,290 developers spent ~30 minutes each filling out a comprehensive survey with the promise that all the data people contributed will be made public in aggregate form.

Dave grinded for months to prepare the questionnaire, set up the website, land some sponsors, market the survey, process the data, and write commentary. It was virtually certain to be a hit.

And.

Crickets.

The site is still live. I had a really good time going through the data and commentary

Despite the enthusiasm from respondents, excitement from sponsors, fascinating analysis, and huge time investment, hardly anyone actually read the survey results.

As soon as it was clear it wasn’t going to be successful, Dave proactively refunded the sponsors (many of whom he still partners with). Reputation is everything when your business is trust.

While the 2019 survey was a flop, a few community members asked whether they could keep it going, and tried again next year. Dave agreed to hand it over, support where needed, and help with publicity, but that added up to a lot of work. When the second survey (still completed by 1,229 devs!) still failed to garner interest, Dave killed it, as it still ate up a lot of his time.

The key lesson here is that you can never predict when something will or won’t work. But you win in the long-term by knowing when to quit, and doing right by everyone.

Tackle Fishing

Market research is essential.
— Dave Verwer

Dave’s company was on a roll after a big success with the Balloons app, and was looking for their next hit.

One of his co-founders was friends with a minor local celebrity in the fishing world. While at the pub, they had the idea to put his fishing knowledge into an app: Tackle Fishing. The team went all-in on production value, even getting a full-time illustrator on staff to make beautiful artwork with parallax-effect animation.

Recovered 2x-size designs from Tackle Fishing. Unfortunately, the full artwork and animated parallax effect are lost to time.

The business model was simple: you pay to download the app 🥹 (ah, better times).

But in their excitement to ship, the team forgot an important step: Market research.

If they spoke to users and focus-grouped some fisherfolk, they’d have noticed a big problem with the concept:

You go fishing to relax, become one with nature, and clear your mind. The last thing an angler wants to do is look at their phone.

The pretty clear lesson here is to talk to your users. Oh, and don’t make apps for your mates based on a conversation at a pub. But we can go deeper than that: when doing market research, never ask someone if they’d pay for something*.

Paying hypothetical money is free, so people will happily fluff up your imaginary future revenues. People pay to have their needs met. Ask about everything around the money, and identify the needs.

*I made this exact mistake with my first startup, where our market research indicated that people would totally pay $10-100 a month to offset their carbon footprint. They did not.

AppReviewTimes

Even successful projects have an expiration date.
— Dave Verwer

If, like me, you began releasing apps around 2016, it might not be obvious why AppReviewTimes was a hit.

In the early App Store, review times were bad. Really bad. Like a-whole-month-of-waiting bad. A-month,-then-you-get-rejected,-then-you-have-to-resubmit-and-wait-several-more-weeks-for-another-review bad. It was bad, basically.

Identifying this common pain, Dave hacked together a simple Rails program to scrape the Twitter (RIP) API (also RIP) for #iosreviewtime and #macreviewtime hashtags, crowdsourcing data in real-time and parsing out averages. This job ran hourly and updated a static web page (the best kind of website).

Dave heard from a few people who would know that the numbers matched the reality of the queue size pretty well. The sample size of ~100 Tweets/day gave enough data to make the site accurate, and provided a solid alternative to refreshing the App Review status page every hour*.

*If someone can do the same thing for the Substack Tech leaderboard please tell me

appreviewtimes.com at November 1, 2014

Nothing went wrong here. The project was a smash hit, with tens of thousands of iOS and macOS devs checking it to feel better about their career choices every day.

The project started to become obsolete when Phil Schiller took over the App Store. In his first 6 months, average review times nosedived to a few days. Job done. Time to shut it down.

People encouraged Dave to keep the site up, lest Apple get lax with times again and they backslide. But with faster review times, fewer people checked the site, and less people Tweeted review times. Without a sufficient sample size, data grew less accurate, meaning there was no longer any reason or ability to keep the site active.

There was no business model with the site. Dave briefly played with ads, but those only work if time-on-site averages more than a couple of seconds. The most money the site ever made was eventually selling the domain: a gaming company bought it as an SEO play, to create high-quality backlinks for themselves. Dave struggled a bit with the decision of whether to sell it for that purpose, but it had been a couple of years since the site had stopped functioning and traffic had almost completely ceased.

With some projects, you want to shut them down. AppReviewTimes is a perfect example. See also, libraries where Apple upgrades its API to include the functionality. Apple is taking over maintenance! That’s a huge win.

Dave deftly sidestepped credit for improving review times, pointing squarely at Phil Schiller for the improvements. The most I got out of him was that maybe AppReviewTimes helped put it on Phil’s radar.

Swift Package Index

This project is still going strong, so doesn’t quite fit the “how to kill a project” theme, but I kept it anyway because I found it interesting.

Swift Package Index was a prime example of skating to where the puck was headed. While at WWDC, by the giant escalators at Moscone: he had a thought that it seemed likely Apple would extend SPM support to iOS the year after.

This opened an opportunity.

Moscone West convention center, from tripadvisor

Dave built a prototype with a few key principles in mind: Separate the index from the delivery mechanism (unlike Cocoapods). No crawling; ensure intentionality by requesting devs make a PR into a large list of packages. Read the JSON, download manifests, process the packages, and throw them into a database.

Sven emailed Dave with a suggestion for the site: integrate his Arena project so that devs could instantly test packages in a playground. They chatted on a call and agreed that to be a success with the community, the site also needed to be open-source and written in Swift rather than Rails.

Work on the Swift Package Index began a few days later.

They launched just before the next year’s WWDC announcement of SPM support for iOS, positioning themselves to become the default choice for package discovery.

I’m eternally fascinated by iOS devs building into cloud-hosted devtools, so spent extra time picking Dave’s brain about the infra. I asked about the 25% number from the Swift for Android announcement. Basically, it was fairly straightforward to add WASM and Android to their compatibility matrix, which builds each package against each version of the Swift toolchain, on each platform, each time a package update is pushed.

So 25% was the proportion of Swift packages that successfully compiled when run using the Swift for Android toolchain.

Compatibility matrix for Alamofire

The infra is neat: a combination of a big MacStadium cluster of eight M3 Ultra Macs running Apple platform builds 24/7, and an Azure cluster for Linux, WASM, and Android. Very generous contributions from Apple, MacStadium, Microsoft, and the community pay to host all this. Running a popular open source project means people will often happily help cover your costs.

Thanks again to Dave Verwer for taking the time to share his War Stories with me!
If you aren’t already on them, subscribe to iOS Dev Weekly and start using the Swift Package Index today!
If you have a story you’d like to share, get in touch!
If you aren’t a subscriber to Jacob’s Tech Tavern, get every War Story (and much more) by subscribing here:

Subscribe now

2025: The Year SwiftUI Died

Jacob Bartlett — Mon, 17 Nov 2025 16:03:10 GMT

2019: Early adoption

SwiftUI released in 2019, to tremendous excitement across the community. Unfortunately, it really sucked for that first year.

I was building a satanic side hustle at the time, and figured I’d go all-in. I blindly cobbled together a global @EnvironmentObject to run the prototype. Push navigation was mostly broken, so I was forced to make every screen transition a modal. I fell in love with the flawed framework.

By the time I did a real startup the next year, I was confident enough to make a proper bet on SwiftUI. This second version, on iOS 14, was much more stable. SwiftUI let me ship faster than I dreamed possible with UIKit. By my third startup, I targeted iOS 15+ and churned out screens like a maniac.

Like all great writers, my story has a 6-year time skip.

2025: The summer everything changed

Two twin technological happenstances collided this summer, transforming the way I work day-to-day:

Firstly, UIKit got some love from Apple. All of a sudden, the iOS 17 @Observable macro was ported to UIKit, alongside updateProperties(), a new view delegate method. It was even back-deployed to work on iOS 18.

Perhaps the eternal MVVM debate between Combine, RxSwift, closures, and binding libraries can finally be put to rest. Or, maybe it will just make the argument worse.

Funny little 2019 comic from QuickBird

Secondly, agentic AI tools took off in a big way. Improvement in context windows, foundation models, and the tool calling innovation triggered an inflection point where CLI tools started working really well. Pasting code into ChatGPT now feels a bit ‘90s.

Why do people use iOS?

There’s a reason Apple is easy-breezy* when it comes to open-sourcing Swift, xnu, libdispatch, and Foundation. There are myriad security, community goodwill, and cross-platform benefits from keeping these low-level frameworks in the open.

*I’m sure there are several Apple engineers (that aged 20 years during open-sourcing negotiations with legal) who may disagree with the term “easy-breezy”.

When it comes to SwiftUI, UIKit, Core Animation, and most system libraries, however, Apple is ruthlessly guarded.

The difference is clear: Apple is in the hardware business. Integrated system UX is a core competitive advantage, and so Apple does not want you to enjoy their UI frameworks on other people’s platforms.

Mac OS X (10.0) architecture. Aqua, the characteristic system design language, sits above everything

The secret sauce of iOS has, from day 1, been its characteristic look and feel, what Apple calls the human interface: Interaction. Responsiveness. Animation.

When you drill down into the limits of these 3 pillars, you will find the gap between UIKit and SwiftUI is starkest.

Is SwiftUI ready for production?

For years, developers have asked is SwiftUI production-ready?

For years, the answer has been yes, but.

SwiftUI gets better every year, but is eternally on the long road to parity with UIKit. Even today, basic stuff like camera previews need to come wrapped in a UIHostingController.

SwiftUI also suffers worse performance out-of-the-box due to overhead from diffing view states and dynamic layout computation. This is being worked on, but is fundamentally an architectural choice that may never quite be as fast as UIKit. Every magic system has a cost.

Everybody forgave SwiftUI’s shortcomings because of the undeniable boost to development speed and the tidy ease-of-use the API offers.

But what happens when you’re no longer writing every line of code manually?

Is SwiftUI dead?

This year, UIKit quietly became production-ready again, with Apple granting access to modern @Observable macros and introducing updateProperties().

Simultaneously, agentic AI tooling has trivialised the overhead of writing imperative layout boilerplate. Two key disadvantages of UIKit, slow development and verbose APIs, have been negated. The models are also trained on mountains of UIKit code and docs. Good luck one-shooting fresh SwiftUI APIs like TextEditor.

In 2025, the question is unavoidable:

Should you start migrating back to UIKit?

We need to understand whether SwiftUI can ever fully match UIKit in API capability and performance. Let’s look at the code that reveals the definitive answer.

I won’t tell you how to live your life, but if you want the optimal UX for your users, maximum animation performance, and total control over interactions, UIKit will remain the undisputed king.

Delegates don’t actually suck

I almost cried last year when I touched UIScrollViewDelegate for the first time since 2019.

I was building a cute interaction that animated a line of emojis along a circular path, with their motion along the circle linked to your scroll offset. I could trivially access scrollView.contentOffset.y from the scrollViewDidScroll(_:) delegate method.

Do you know how hard this is with SwiftUI preference keys!?

To be completely fair to SwiftUI, onScrollGeometryChange (iOS 18) can do this now. At the time, I was supporting iOS 17 and couldn’t touch it.

But there are hundreds of UIKit delegate methods that remain unsupported, like scrollViewWillEndDragging(_:withVelocity:targetContentOffset:).

Even if SwiftUI achieves parity with the full UIScrollViewDelegate, we are subjected to a combinatorial explosion of memorisation for new views, view modifiers, and their respective positions on the view hierarchy.

Don’t even get me started on namespacing.

You’re more or less allowed to apply every view modifier to every view in SwiftUI.

It almost feels like… maybe delegates were actually quite a good pattern for implementing the iceberg of nuance underneath the world’s most complex UI system.

That’s actually a pretty great metaphor…

The UIKit Iceberg

This is the case for pretty much every SwiftUI API that exists. Porting everything from a nearly-20-year-old framework isn’t happening anytime soon.

My controversial opinion about architecture

UIKit lends itself inevitably to “complex” architectures, such as MVC, MVVM, and VIPER. Often, you’ll split your view controller into files for every delegate applied, and every link in the chain of data-flow.

SwiftUI lends itself to simpler architectures, such as the very hot MV approach.

But here’s my edgy opinion:

The more complex your screen-level architecture is, the harder it is to write code. But the easier it is to read. If you keep strict standardisation, you’ll always know where the gesture interactions will live, and what route your data takes as it propagates from tap, to model, to animation.

The simpler your architecture is, the easier it is to write code. With a good design library, you can smash out a SwiftUI screen in an hour. The more you can reduce services into property wrappers, the faster you can ship.

But God help the next engineer who touches it.

The default standardisation from MV is, essentially, “put the stuff wherever”. It just doesn’t lend itself to consistency. Gesture handling will sit on the view that feels the most convenient at the time. If you’re lucky, interaction code sit vertically near to your state, otherwise you’ll just have to search the file(s) to hunt down what touches the data and when.

VIPER is a pain in the arse to write, but frankly, I always knew where to find what I needed.

AI + The Classic UIKit Stack™ = ❤️

This summer, I’ve been making a lot of prototypes, and I’ve been loving the workflow.

I’m rediscovering what makes UIKit so great.

It’s lightweight. It’s performant. I am not hand-coding any constraint boilerplate.

Any interaction I can dream up was built a decade ago. I don’t have to recall or research whether it has been ported yet. It just works.

And a lot of the time, for a complex screen, the code is just easier to read. Which you kind of want when you aren’t typing everything, because effort shifts towards code review of the output.

I wanted to whip up a really simple prototype for you to demonstrate all the ways UIKit is now easier to work with, but accidentally ended up going way overboard and building a full application. It was super fun, I actually can’t stop myself.

It’s an app that lets you create and edit collages from your photos, apply Metal shaders to them for cool effects, and save them to a gallery.

Every property, transformation, shader ordering, and image file path is stored on SwiftData, meaning that you can save and edit each photo any time you come back to them.

Naturally, I open-sourced it just for this post (prompts n’ all), to demonstrate how nice this workflow is.

View my code

I’m going to take you through my process of smashing the app out over a few hours, and give you a gentle reminder of all the beautiful things that UIKit makes really easy for you, as well as demo-ing the new UIKit @Observable pattern.

Prompts and one-shotting

Obviously, when you’re working on a live, complex, production app, I’d recommend being way closer to the code, and making smaller changes. But this began almost as a throwaway example app for this article, and I got carried away.

If you actually care about quality, then one-shotting with AI is a myth. But you can get pretty damn close with a clear prompt and a good eye for code review.

The secret is actually not a secret at all. You just need to explicitly detail every requirement. If you’re doing it properly, this might take a good hour. You don’t want to skimp on any details or interactions.

My initial prompt

Before you do anything, you need to create the basic project template in Xcode, because the clanker will get the Info.plist and build settings very wrong.

Actually reading your code

After your initial prompt, it’s really important to do a serious code review to catch anything you aren’t happy with.

Then you can let Codex rip autonomously for another 30 minutes.

This is pretty heavy early-project vibe-coding-between-Mario-Kart-races territory. In a serious project, you want to make small, incremental changes.

33m and 36 seconds after getting my review, I had dinner ready and the code had improved itself

Any issues you catch can also go into an AGENTS.md file to help avoid the same mistake happening twice. I landed a lot of solutions to Swift 6.2 concurrency warning solutions in there.

I’m going to be very fair. It wasn’t all fun and games. I did run into teething issues with Core Image Metal kernels that I had to mostly solve manually. There were also a bunch of low-level styling issues like borders and symbol sizes that I wasn’t able to articulate clearly enough, and had to actually type out, like a 1337 Hacker in an 80s movie. But this is more a by-product of my perfectionism.

The big AI life-hack

Something I conveniently have access to: an enormous back-catalog of side projects and demo apps. This is the most significant timesaver when applying AI engineering, because you can simply point it at a folder and say “I want this feature, like it was done here, copy it”. Software engineering isn’t usually about remaking the wheel. It’s about plumbing together known solutions to create new utility.

Being able to reference existing work is, IMO, the main skill when using agentic AI to assist with engineering. It scales all the way up to big projects when you have a highly standardised codebase*.

*This is actually a thing, called Context Engineering.

I was able to utilise a bunch of reference code from previous projects I’ve worked on for the database, the shaders, and the Vision framework.

Falling back in love with UIKit

Hyper-responsive Gestures

UIKit @Observable hooks allow the CollageViewController to listen for mutations in the view model’s canvasItems (containing each image, transformations, and shader modifications), and update subviews via updateProperties().

CollageViewController.swift

CollageViewController follows the standard MVVM single-source-of-truth, but unlike SwiftUI, we can short-circuit to get better performance.

We’re adding various gestures to each image in our collage, imperatively.

CollageViewController.swift

When we apply one of these pan, zoom, or rotation gestures to an image node, we should see the UIView transform in real-time.

The gesture updates the @Observable view model to detail transformation parameters applied to each image node.

CollageViewModel.swift

SwiftUI renders UI as a function of state, so each pinch, drag, or rotation on a @GestureState can trigger view invalidation, body diffing, layout computation, and a render pass. The UI waits for the state update pipeline to propagate back up to the pixels before it responds to the user. Frame by frame.

In UIKit, we could get the same beautiful, unidirectional flow by applying gestures to the relevant image transformation parameters on the @Observable view model. When this changes, updateProperties() will traverse each subviews and apply the transformations. CoreAnimation would only re-render each layer when its own properties change.

If we wanted to be extra efficient, we could even give each image node its own @Observable model, saving traversal across the subviews.

We can go even further and take a performance shortcut: directly apply gesture-based transformations to the UIViews in real-time, and withheld updates to the view model to the end of the gesture. This means we only hit updateProperties() on the view controller at the start and end of each gesture.

You can check for yourself!

The ability to short-circuit like this is a big reason that UIKit is virtually always faster.

CollageViewController.swift

Ultra-controlled transitions

One final stop on our rediscovery tour is the hero animation, played when opening and closing a collage. It’s powered by UIViewControllerTransitioningDelegate. There’s a ton of imperative layout boilerplate here, which is extremely easy for an LLM to write. You simply provide the taste and tune the animation parameters.

HeroTransitioningDelegate.swift

SwiftUI has started to introduce hero transitions via NavigationTransition. This is welcome, but extremely basic and inflexible. It’s missing percentage-driven transitions, interactive transitions, and lacks the precision of custom animators for transitions.

Again, we scrape the surface of the UIKit iceberg.

Last Orders

I got beers with a friend recently, and we shared the same feeling. The Classic UIKit Stack™ just feels great to rediscover.

UIKit. Combine. Delegates. DispatchQueue (though, frankly, you’ll have to pry Swift Concurrency out of my cold, dead hands). All the classics. The gang, back together again.

SwiftUI was shipped from a place of fear, in response to the twin reapers of Flutter and React Native sucking developers out of Apple’s walled garden. Everyone jumped on the bandwagon, because suddenly we could knock out a complex screen in hours, not days.

Today, less code is hand-typed. Tomorrow, it will be less still.

Reading code is, again, the primary bottleneck to productivity.

AI-assisted engineering tools bestow speed without compromising maintainability, performance, and the all-important characteristic UX of iOS we know and love.

SwiftUI is dead. Long live UIKit.

I’m able to build anything, again.

Swift Concurrency Training Kata

Jacob Bartlett — Tue, 11 Nov 2025 16:00:50 GMT

I’ve been teaching concurrency for a long time. But you can only get so far by reading a blog, or watching a video course. Knowing the toolkit is only half the battle.

For years, I’ve been saying that the best way to learn Swift Concurrency is to immerse yourself in real-world challenges. Swift concurrency experts have worked on hard problems for years and earned an intuition.

The pros have a quiet voice that tells us to use a taskGroup instead of an async let. Like seeing the Matrix, we just know which actor a function will execute on. With a glance, we might diagnose the unresponsive AsyncStream that stumped our teammate.

Welcome to my most ambitious project ever:

I compressed my 4 years of Swift Concurrency experience into one day.

12 challenges that simulate real day-to-day work.

All solved by applying the Swift Concurrency toolkit.

I built you a fully-fledged app: a murder mystery. Take the place of a detective and gather suspects, track down the crime scene, and secure a confession. The murder mystery is divided into 3 sections: Suspects, Field Ops, and Forensic Lab.

The UI, interactions, and models are all pre-built.

Your mission is to finish features, squash bugs, and wire up asynchronous plumbing with your Swift Concurrency know-how.

Clear your calendar. I’m about to guide you through 12 brutal training Kata.

By the end, you’ll bootstrap years worth of real-world experience with Swift Concurrency and build up a black-belt intuition.

The Great Connection Pool Meltdown

Jacob Bartlett — Thu, 06 Nov 2025 16:02:23 GMT

Welcome to my first edition of War Stories, where I partner with famous builders in the iOS space to share real-life stories from the frontlines as they scale their projects.
Today I’m working with Pedro Piñera Buendia, the creator of Tuist, which is designed to fix the problems shared by iOS teams as they scale Xcode projects. I have not been paid to endorse Tuist, but I do really like it.
I’m still working out the format here, so please be patient whenever I accidentally switch between first and third person. It’s part narrative, part interview, all swashbuckling fun.
To catch all my War Stories, be sure to subscribe:
Subscribe now

Without further ado, here’s The Great Connection Pool Meltdown.

Hard Things

Like many readers of Jacob’s Tech Tavern, the Tuist guys are iOS developers turned founders. Web infra at scale abruptly switches from an interview buzzword to cold reality. This is one of those Hard Things™ that we are often shielded from when painting JSON on the client-side.

One of Tuist’s core features is caching. It builds xcframeworks from each module and caches them remotely, which dramatically cuts cold build time for Xcode projects, both locally and on CI (Tuist newly integrates with Xcode 26 Compilation Caching to make it even faster).

To power a cache, you need a server. The Tuist caching server is coded in Elixir, which compiles down to Erlang bytecode and runs on the Erlang runtime. It’s famous for being great at building highly parallel, real-time services.

Tuist’s code is actually open-source if you’re interested.

The HTTP cache server processes traffic from organisations with hundreds of devs, with bursts of traffic every time a project is freshly generated. This can rack up ~100k requests per hour. Given an average xcframework module can be 5-10 MB, adds up to (approximately) a metric f*ckton of traffic.

Basic architecture of Tuist’s caching system, generated by eraser.io

This was all well and good, but strange errors began 6 months ago.

The iOS Dev’s Blind Spot

We are coddled by the Apple ecosystem. URLSession does a lot under the hood like HTTP/2 multiplexing, interfacing with system daemons that manage the radio, and maintaining an internal TCP connection pool.

This stuff will make a pretty good article actually, I’ll add it to my list.

Building on the server means you must keep TCP connections warm using a connection pool, or your users will suffer cold starts, leading to slow response times.

A caching server is a high-throughput environment, but when you’re linked to CI builds, the access pattern is actually very spiky. Every organisation onboarded to Tuist adds thousands of sporadic requests to the server as devs sprint to generate projects and merge PRs.

This leads to unpredictable surges in traffic on the server. These could queue up thousands of operations waiting to be executed, from DB queries to Postgres (fetching cache metadata), to external GET requests to Amazon S3 storage (where the xcframeworks are stored).

Each millisecond of latency counts on a cache server. You can optimise your Elixir code as much as you like, but there’s no getting around “fixed costs” like disk I/O on the database or the network latency when fetching from external storage.

Snippet of server code to get presigned URLs from S3 to download xcframeworks

If you can serve these requests in time, great.

If not, bad things can happen.

The sh*t hits the fan

The early warning signs were subtle at first.

Daily connection drop warnings were flagged from the server, because they sat in the queue too long. Users weren’t complaining, since the client would just retry failed connections, but it was annoying to begin every workday like this:

The team began to talk to their cloud provider (a popular wrapper who will remain nameless) about potential network issues in their caching server instance, but they would mostly push back and blame Pedro’s config.

The cloud provider doth protest too much, methinks.

One day, things got real bad. Contagion. The network issue spread out across the database provider and their S3 storage, proving it had nothing to do with app configuration.

All of a sudden, the server crashed.

It was a particularly high-traffic spike that toppled the service. The Tuist guys spun up the server again. It went down again.

The cloud provider’s network issue was failing to process many of the S3 requests that fetched cached xcframeworks. The failing requests sat around in the queue, waiting to retry. This hogged connection pool slots, wasted CPU cycles, and rapidly filled up application memory until the server crashed again.

The CLI client kept retrying with exponential backoff, so the server immediately got hit with thousands of requests each time it recovered.

At best, users didn’t notice much, because the Tuist client fell back to locally-cached modules. At worst, this incident manifested as time-outs on cache fetches, with the client URLSessionConfiguration set up to kill sessions after 5 minutes. This blocked CI builds and newly-onboarding developers who needed to fetch from the cache.

For what it’s worth, I’ve used Tuist at work and their team responds (and usually unblocks us) very fast on Slack anytime there’s a problem.

Firefighting mode.

Well, mostly.

Pedro was in a taxi to the hospital for surgery* as this all went down, but the 3-strong engineering team coordinated the response over Slack.

*Sick days are one of the casualties of becoming a founder 🥲

The team bought themselves time by upgrading their server instance to a chunkier one with more memory.

With a minute to breathe, they found a straightforward change to the queue configuration that let it fail fast instead of re-queueing infinitely and clogging up memory. Basically: “if network issues happen again, cascade them down to the client instead of re-queueing on the server”.

Here’s what the Postgres DB config looked like in production with this fix; check out the pool_size and queue_target parameters.

[
  ssl: [
    server_name_indication: ~c"db.tuist.dev",
    verify: :verify_none
  ],
  pool_size: 40,
  queue_target: 200,
  queue_interval: 2000,
  database: "cache_db",
  username: "pedro",
  password: "123456", # *
  hostname: "db.tuist.dev",
  port: 5432,
  socket_options: [keepalive: true],
  parameters: [
    tcp_keepalives_idle: "60",
    tcp_keepalives_interval: "30",
    tcp_keepalives_count: "3"
  ]
]

*I am about 80% sure this isn’t the real password.

But WTF was going on?!

The Route of all Evil

The first warning signs started bleeding through in early 2025, but the sh*t truly hit the fan in October. Fortunately, there was a months-long breadcrumb trail of logs and errors spanning the entire cache server that led to the ultimate conclusion:

Lo and behold, it was absolutely the cloud provider’s fault.

Tuist spun up a new machine on Render.com, routed some traffic over, and the problem was gone. The new server was faster and seemed more reliable. Switching was a no-brainer.

Pedro has not been paid to endorse Render.com, but he does really like it.

The memory and queue configuration bought the team some time. Updates were shipped to the client CLI in the meantime that made the service issues less disruptive, for example, skipping some binary cache fetches when requests were slow.

This ultimately gave them breathing space to plan out a migration, moving their entire caching infra to the new-
-Wait, I’m told they got it shifted in just under a day. Nice.

The team used Cloudflare to gradually route caching traffic to the new service to gain confidence, and once things were up and running with no issues, the original service was shut down.

Memory and CPU were stable, responses were faster, and there were no more connection drops from timeouts.

Today, the caching server efficiently handles tens of thousands of requests per hour without breaking a sweat, using relatively minimal resources. All thanks to reliable underlying infra.

The original cloud provider, after months of ignoring complaints, finally declared an incident.

Too little, too late.

Lessons Learned

As iOS-developers-turned-founders, creating web infra at scale didn’t come naturally. Learning to do Hard Things the Hard Way leaves you with scars that make you a better engineer.

There’s a lot we can take away from this story.

Measure, measure, measure

Without data, you can’t set up alerts. Without alerts, you don’t know whether your system is working. Without those annoying daily connection drop warnings, the Tuist team would have been blind when the server finally fell over.

It’s tough to improve this when you’re building a devtool, because devs are particularly strict with their data, and reluctant to share. But it’s kind of the only way to improve a setup.

It’s especially important to keep an eye on the state of the network and the latency of requests, and doubly-so if an endpoint has high throughput. Every customer onboarded to Tuist introduced new spiky bursts of thousands of requests.

I also learned this the hard way, often finding out via a recruiter, or Twitter, that my Sign-in-with-Apple was busted during my first foray into startups.

Trust your gut

The team’s initial assumption was a problem with the cloud provider. With the patterns they found in the logs, it really appeared to be the only culprit.

The cloud provider successfully gaslit the Tuist team into thinking that maybe something was wrong with their network configuration.

It took a serious incident to discard their diagnosis and revisit the initial assumption.

Elixir & Erlang are a beast

When debugging CPU and memory, the Tuist team could open a shell terminal on the prod server. The Erlang runtime has a “fair scheduler” that allows critical traffic like SSH in to inspect what’s happening, even if the CPU is at capacity.

In a prod incident, this is functionally open-heart surgery. Other runtimes might block any kind of telemetry leaving the server and make debugging 10x harder, reinforcing the choice of Elixir.

Having recently melted my own VPS while building a Vapor app, this sounds like a dream. When my CPU hit capacity, I was locked out and forced to shut it off.

Design for failure

This is Erlang’s mantra.

The CLI wasn’t designed to recover from cache failures. Therefore, the incident was felt by some customers during the incident.

The Tuist team intends to embrace this mantra across all their tooling and server apps from now on: Things will break, so the system needs to be resilient to it. Design systems that can recover from failures.

The winners and losers from the October AWS outage only make this lesson more concrete.

Thanks again to Pedro Piñera Buendia for taking the time to share his War Story with me! You can try out Tuist yourself at https://tuist.dev

I’m hoping to make this a regular column on Jacob’s Tech Tavern. If you have a story you’d like to share, get in touch!

Subscribe now

Jacob’s Tech Tavern

Survive the AI tech hiring winter ⛄️

Introducing…

Oh sh*t, I have an "iOS coding" interview and don't know what to practice

Categories of “iOS Coding” exercise

Screen building

Component design

LeetCode-“lite”

Fundamentals

API design

The SwiftUI Design System War: Composition vs Progressive Disclosure

Is SwiftUI finally as fast as UIKit in iOS 26?

Sponsored Link

How iOS apps actually make money

Designing the most ridiculous scroll view I can imagine

iOS System Design interviews in 2026

A framework to structure every interview

The Most Complicated System I Ever Worked On

Agentic AI Engineering Workflows for iOS in 2026

Sponsored Link

RevenueCat Paywalls: Build & iterate subscription flows faster

Contents

The State of the Art

The Best Models

MCP, Verification, and Xcode 26.3

Multi-agent and Orchestration

AGENTS.md and Skills

Teleporting Sessions to the Web

Tab Completion

The Ralph Loop

OpenClaw (aka Clawdbot)

Cargo-Culting the Creator of Claude Code

Building Maxwell in an afternoon

Last Orders

Sponsored Link

RevenueCat Paywalls: Build & iterate subscription flows faster

My (deeply stressful) big tech interview grind

My Going Indie Scorecard

My Job Application Journey

Xcode Organizer: Your Performance Cheat Sheet

Sponsored Link

The Xcode Organizer

How to design an SDK to handle $10bn in transactions

Sponsored Link

RevenueCat Paywalls: Build & iterate subscription flows faster

Contents

High-Level System Design

How to make a Purchase

The Façade Layer

Configuration and Progressive Disclosure

Managing the Dependency Graph

The Purchase function and backwards compatibility

The Orchestration Layer

Making the Purchase via StoreKit

Handling the transaction and delegating to services

Handoff to the services layer

The Service Layer

TransactionPoster and backend validation

CustomerInfoManager and offline correctness

The Infrastructure Layer

Last Orders

Sponsored Link

RevenueCat Paywalls: Build & iterate subscription flows faster

10 techniques to pass 90% of algorithmic interviews

Contents

The 10 Techniques

Hashmaps

My LeetCode Diary: #383 Ransom Note

Two pointers

🎄 I just gifted you 14 days' membership

Copy-on-write teaches you EVERYTHING about Swift Internals 🐮

Journey to the centre of the 🐮

(yes we’re really going through all these)

What is 🐮?

Value and reference semantics

🐮 In the Swift Standard Library

Implementing 🐮

The Swift Standard Library

Builtins

(Interlude) The Swift Compiler

`T`he Builtin Module