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

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

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

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

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

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

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

Sponsored Link

Meet Rico by RevenueCat

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

Contents

• Level 1: Fire-and-Forget

• Level 2: Retry Discipline

  • User-Surfaced Retry

  • Automated Retry

  • Idempotency Keys

• Level 3: Upload Continuity

  • Resumable Uploads

  • Background Modes

• Level 4: Durable Uploads

• Last Orders

Level 1: Fire-and-Forget

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

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

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

Level 1 isn’t just being dumb.

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

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

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

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

Level 2: Retry Discipline

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

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

User-Surfaced Retry

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

Automated Retry

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

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

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

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

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

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

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

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

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

Idempotency Keys

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

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

Unlock Levels 2-4 now

Read more

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

Sponsored Link

Meet Rico by RevenueCat

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

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

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

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

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

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

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

• Your finger taps the capacitive touch sensor.

• The kernel creates a touch event via hardware drivers.

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

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

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

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

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

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

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

Subscribe now

Handling Physical Touch

The Hardware

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

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

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

The Kernel

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

• CPU becomes threads.

• RAM becomes heap memory.

• Flash storage becomes a file system.

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

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

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

backboardd

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

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

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

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

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

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

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

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

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

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
🧑‍🚀 Get a free copy of my new eBook, “Land your iOS Tech Job”
❤️‍🩹 Support independent, sometimes funny, tech writing

Subscribe now

Read more

tl;dr for the busy iOS engineer:

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

I turned 31 today.

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

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

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

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

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

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

Subscribe now

Sneak Preview

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

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

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

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

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

Subscribe now

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

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

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

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

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

Easy to get started.

Straightforward to level up when needed.

Thus the Swift 6.2 Approachable Concurrency story began.

Your concurrency journey now has 3 levels:

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

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

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

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

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

• Approachable Concurrency (Yes/No)

• Default Actor Isolation (MainActor/nonisolated)

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

Clear as mud, right?

It’ll make sense when you read the article.

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

Get the sample project

Level 1: Main Actor 4 Life

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

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

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

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

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

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

*RevenueCat, please sponsor my blog. Oh wait.

**Nice.

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

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

Prove me wrong

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

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

Level 2: Async and Serial

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

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

This is the really important bit:

Subscribe now

Read more

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

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

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

• “You didn’t set translatesAutoresizingMaskIntoConstraints = false”

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

This wistful nostalgia trip got me thinking.

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

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

So today is a theory lesson + case study.

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

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

Sponsored Link

Lessons Learned from Security Incidents in Mobile Apps

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

Sign up here.

Contents

• What is the Internet?

• URLSession and the Application Layer

  • URLSession

  • Resuming the DataTask

  • HTTP, DNS, and Cookies

• Network.framework & the Transport layer

  • Transport Layer Protocols

  • Segments and Reliability

  • Network.framework

  • The Kernel TCP Stack

• IP and the Network layer

  • Network Layer Datagrams

  • Forwarding Datagrams

  • Buffering Datagrams

  • Network Layer in the iOS kernel

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

  • URLSession at this layer ()

• Electrons and the Physical layer

  • iPhone hardware

• Last Orders

Subscribe now

What is the Internet?

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

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

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

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

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

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

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

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

• application

• transport

• network

• link

• physical

The layered model is all about abstractions.

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

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

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

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

URLSession and the Application Layer

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

URLSession

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

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

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

Resuming the DataTask

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

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

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

HTTP, DNS, and Cookies

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

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

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

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

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

Subscribe now

Network.framework & the Transport layer

The transport layer moves messages between end systems.

Transport Layer Protocols

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

IP is unreliable.

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

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

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

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

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

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

Segments and Reliability

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

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

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

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

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

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

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

Network.framework

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

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

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

The Kernel TCP Stack

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

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

IP and the Network layer

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

What does a router do? Two main things:

• Forwarding datagrams.

• Buffering un-forwarded datagrams.

Network Layer Datagrams

First, what is a datagram?

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

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

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

• IPv4, which looks like 192.168.1.10

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

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

Forwarding Datagrams

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

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

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

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

Buffering Datagrams

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

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

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

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

Network Layer in the iOS kernel

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

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

Subscribe now

The link layer (feat. Wi‑Fi)

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

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

For your iPhone, that next link may be:

• a Wi‑Fi access point

• a cellular base station

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

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

This info includes:

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

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

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

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

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

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

URLSession at this layer

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

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

Electrons and the Physical layer

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

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

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

iPhone Hardware

Your URLRequest ultimately becomes energy in the real world.

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

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

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

Recall iPhone 4.

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

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

Last Orders

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

Abstractions allow us to comprehend the incomprehensible without going insane.

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

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

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

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

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

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

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

Sponsored Link

Lessons Learned from Security Incidents in Mobile Apps

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

Sign up here.

Subscribe now

Rate my setup.

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

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

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

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

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

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

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

Our guiding philosophy? Ship bricks.

I hope you find it interesting.

Contents

• Agents running for hours

  • Context Switching

• Feature Workflow

  • Stacked Diffs

  • Planning

  • Letting it Rip

  • Breaking the Bottleneck

  • The Timeline

• Parallel Workflows

  • Product & Design

  • UI work

  • Debugging

  • YOLO-ing

• Handsfree Tooling

  • WisprFlow

  • Slack Integrations

  • UI work & MCP

  • Bash Shortcuts

• Cognitive Debt & Downsides

• Last Orders

Agents running for hours

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

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

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

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

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

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

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

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

Context Switching

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

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

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

Feature Workflow

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

Unlock the full workflow

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

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

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

Advanced Concurrency Training ($25)

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

Land your iOS Tech Job ($19)

Read more

Sponsored Link

How iOS apps actually make money

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

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

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

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

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

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

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

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

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

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

• 👑 Pride: Knowing better than Apple about UI frameworks

• 🤑 Greed: Everything must be available offline

• 🧨 Wrath: My architecture is bigger than yours

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

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

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

• ⛓️ Sloth: Automate all the things!

Subscribe now

👑 Pride

Knowing better than Apple about UI frameworks

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

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

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

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

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

Velocity suicide.

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

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

Subscribe now

🤑 Greed

Everything must be available offline

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

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

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

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

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

Look. Persisting some stuff is good.

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

🧨 Wrath

My architecture is bigger than yours

We’ve all felt like this at some point.

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

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

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

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

Architectural churn destroys this hard-won institutional knowledge.

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

Subscribe now

⚙️ Envy

We must adopt Google’s build system

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

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

This will achieve 3 things:

• It looks phenomenal on your CV.

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

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

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

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

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

Pedro, pls sponsor my Substack 🙏

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

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

🍆 Lust

Let’s make our networking stack polyamorous

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

• REST where you need simplicity

• GraphQL where you need flexibility

• gRPC when you want to minimise latency

Let’s be real.

YOU ARE NOT GOOGLE. You aren’t Google.

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

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

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

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

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

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

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

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

Subscribe now

🤤 Gluttony

Om-nom-nom all the modules

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

But there can be too much of a good thing.

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

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

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

It gets real messy real quick.

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

⛓️ Sloth

Automate all the things!

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

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

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

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

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

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

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

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

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

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

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

Subscribe now

The Golden Rule

When is it okay to Cargo cult?

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

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

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

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

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

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

The golden rule?

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

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

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

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

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

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

Get 33% off group subscriptions

Last Orders

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

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

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

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

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

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

Today we covered the seven deadly sins of cargo culting:

• 👑 Pride: Knowing better than Apple about UI frameworks

• 🤑 Greed: Everything must be available offline

• 🧨 Wrath: My architecture is bigger than yours

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

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

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

• ⛓️ Sloth: Automate all the things!

Which are you most guilty of?

Sponsored Link

How iOS apps actually make money

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

Subscribe now

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

Choose Boring Technology
The Grug-Brained Developer

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

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

I never told you why. Really.

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

But that’s just short-term downside risk.

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

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

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

• Play defence: Becoming way more knowledgeable than average.

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

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

Introducing…

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

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

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

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

Buy the book now ($19)

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

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

Cheers for reading Jacob’s Tech Tavern! 🍺

Landing a job is never easy.

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

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

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

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

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

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

• Screen building

• Component design

• LeetCode-“lite”

• Fundamentals

• API design

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

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

Master Concurrency for $29

Categories of “iOS Coding” exercise

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

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

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

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

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

• “An interview involving an app building exercise”

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

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

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

Deciphering these is more art than science.

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

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

Screen building

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

Component design

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

LeetCode-“lite”

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

Fundamentals

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

API design

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

Modern tooling makes it easier than ever to drill problems.

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

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

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

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

Upgrade to unlock this article, plus much more:

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

Subscribe now

Read more

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

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

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

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

But you should really decide for yourself.

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

• Design Systems

• The Sample Project

• How to Composition

  • Custom ButtonStyle

  • Shared Components

  • Composition in action

• Progressive Disclosure

  • The Initialiser

  • Progressive Disclosure in action

• The Really Important Things With Design Systems

  • Keeping the design system simple

  • Extensibility

  • Documentation

  • #Preview

  • Is it marginal?

• Last Orders

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

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

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

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

Get the Swift Concurrency Bundle for $29

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

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

Get 30 day free trial

Read more

I love SwiftUI; I hate SwiftUI.

I love UIKit; I hate UIKit.

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

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

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

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

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

Performance.

Specifically, scroll performance.

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

But they do have a point:

Performance is the final bastion of native iOS supremacy.

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

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

Sponsored Link

How iOS apps actually make money

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

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

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

SwiftUI vs UIKit.

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

Subscribe now

• Designing the most ridiculous scroll view I can imagine

• A fair test

• SwiftUI performance (feat. List)

  • Animation performance with Instruments

  • Memory, CPU, and thermal profile with Xcode

  • The SwiftUI Performance instrument

• UIKit performance (feat. UICollectionView)

  • Animation performance with Instruments

  • Memory, CPU, and thermal profile with Xcode

• The Elephant in the Room

• What the future looks like for SwiftUI

• Last Orders

Designing the most ridiculous scroll view I can imagine

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

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

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

What requirements are needed to make a UI truly ridiculous?

• High resolution images.

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

• Permanent autoplaying animations.

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

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

But how can we achieve this?

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

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

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

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

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

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

So.

Once and for all.

Is SwiftUI finally as performant as UIKit?

Subscribe now

A fair test

I’m a scientist.

Well. Kind of. I did a physics degree.

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

I digress.

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

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

Download the project

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

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

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

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

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

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

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

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

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

Now let’s run the experiment.

SwiftUI performance (feat. List)

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

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

Now let’s begin profiling.

Animation performance with Instruments

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

I ran the same test a few times:

• Loaded the app up.

• Scrolled slowly.

• Began scrolling more quickly.

• Scrolling very rapidly, up and down.

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

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

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

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

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

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

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

Memory, CPU, and thermal profile with Xcode

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

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

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

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

The SwiftUI Performance instrument

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

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

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

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

Subscribe now

UIKit Performance (feat. UICollectionView)

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

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

Let’s jump straight into the profiles.

Animation performance with Instruments

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

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

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

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

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

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

Memory, CPU, and thermal profile with Xcode

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

Now don’t I look silly.

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

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

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

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

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

The Elephant in the Room 🐘

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

But why is this performance different?

Perhaps you’re thinking what I’m thinking.

Isn’t List implemented via UICollectionView under the hood?

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

The SwiftUI screen contains a mysterious UpdateCoalescingCollectionView.

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

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

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

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

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

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

Subscribe now

What the future looks like for SwiftUI

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

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

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

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

Spicy stuff.

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

Last Orders

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

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

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

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

“SwiftUI is dead. Long live UIKit.”

Sponsored Link

How iOS apps actually make money

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

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

Subscribe now

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

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

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

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

• Design an SDK fit for a large analytics company.

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

Until now.

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

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

• A framework to structure every interview

• A full worked example based on my recent interviews

• Miscellaneous practical tips to help you prepare

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

• Last Orders (and a handy cheat sheet)

A framework to structure every interview

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

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

• Scoping

• Functional requirements

• Non-functional requirements

• Data model

• API design

• High-level design

• Drill-down questions

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

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

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

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

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

Upgrade to unlock this article, plus much more:

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

Subscribe now

Read more

Writing online is a lot like creating content on OnlyFans.

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

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

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

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

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

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

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

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

• Webscraping a third party service

• Long-running downloading jobs

• Parsing and storage for ~200MB of data

• Real-time data analysis

• High-volume data upload and polling

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

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

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

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

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

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

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

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

Subscribe now

Read more

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

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

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

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

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

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

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

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

But things have moved really fast.

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

I need to optimise my workflow some more.

So.

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

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

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

Sponsored Link

RevenueCat Paywalls: Build & iterate subscription flows faster

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

Contents

• The State of the Art

  • The Best Models

  • MCP, Verification, and Xcode 26.3

  • Multi-agent and Orchestration

  • AGENTS.md and Skills

  • Teleporting Sessions to the Web

  • Tab Completion

  • The Ralph Loop

  • OpenClaw (aka Clawdbot)

• Cargo-Culting the Creator of Claude Code

• Building Maxwell in an afternoon

• Last Orders

The State of the Art

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

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

Let’s cover some:

The Best Models

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

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

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

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

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

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

I guess I need to upgrade my plan.

MCP, Verification, and Xcode 26.3

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

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

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

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

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

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

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

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

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

Multi-agent and Orchestration

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

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

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

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

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

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

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

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

AGENTS.md and Skills

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

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

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

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

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

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

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

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

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

And it will follow this to the letter!

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

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

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

Teleporting Sessions to the Web

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

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

The win here isn’t immediately obvious.

But consider the workflow it unlocks:

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

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

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

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

Tab Completion

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

But I kind of always felt iffy about it.

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

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

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

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

The Ralph Loop

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

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

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

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

OpenClaw (aka Clawdbot)

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

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

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

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

Cargo-Culting the Creator of Claude Code

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

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

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

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

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

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

What is he doing?

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

2. Regularly teleporting to sandboxed web sessions for background processing

3. Sticking religiously to the slowest, smartest thinking model

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

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

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

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

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

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

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

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

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

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

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

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

What now?

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

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

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

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

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

6. Utilise these pro prompts:

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

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

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

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

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

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

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

Building Maxwell in an afternoon

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

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

Maxwell was born.

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

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

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

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

Until now.

Er, hold on.

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

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

I also found my old logo!

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

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

• I did all this work in Codex using the gpt-5.2-codex high model.

• I set up XcodeBuildMCP with the intention of verifying all my work autonomously via tests and simulator runs.

• The repo contains some open-sourced AGENTS.md, slash commands, and skills for SwiftUI and concurrency review.

• I’m going to aim to run 5 instances of Codex in parallel, numbered, with each CLI window pinging me via system notification when they finish.

• For each instance, I’ll carefully plan each feature before trying to one-shot.

• I’m going to set up web sessions via the ChatGPT app and attempt to ship some QA fix PRs while eating dinner.

• If I have time, I might install Cursor and implement some manual fixes, with my fingers, like it’s the 1970s.

Here’s the full project!

The sample project on GitHub

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

Last Orders

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

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

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

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

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

Subscribe now

Sponsored Link

RevenueCat Paywalls: Build & iterate subscription flows faster

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

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

Yeah, I thought so too.

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

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

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

• My Going Indie Scorecard

• The job market

• CV optimisation

• Recruiter screening

• First technical round

• Take-home test

• The Panel Interview™

• Offer & Onboarding

• Last Orders

My Going Indie Scorecard

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

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

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

Riding high, I deigned to actually do a budget.

And… f*ck.

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

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

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

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

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

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

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

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

Overall Grade: B. Must try harder.

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

My Job Application Journey

Thus began my first foray into job applications since 2015.

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

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

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

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

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

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

Upgrade to unlock this article, plus much more:

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

Subscribe now

Read more

I love working on app performance.

It just sounds cool. Performance. Performance.

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

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

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

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

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

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

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

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

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

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

Sponsored Link

Substack, which powers my newsletter, is hiring iOS engineers!

The team is small, close-knit, and provides ample opportunities for mentorship, growth, ownership, and autonomy. You can apply for either the growth team or the enterprise team. Check out their jobs page for the full list of technical and non-technical openings.

The Xcode Organizer

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

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

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

Oh dear.

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

Stand by.

☎️ Thomas, help me out please! 📡

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

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

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

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

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

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

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

Upgrade to unlock this article, plus much more:

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

Subscribe now

Read more

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)

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

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.

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:

1. 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.

2. 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:

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.

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.

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:

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.

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.

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:

1. Log everything on the critical path to catch errors and hit that 99.99% SLA.

2. We should also profile times and performance for our metrics.

3. Handle both legacy SK1 and SK2 transactions, while abstracting this choice away from the developer.

4. Wrap #available conditionals around APIs younger than the minimum deployment target to ensure backwards compatibility.

5. 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:

1. Verifies this transaction using the StoreKit transaction listener, another friendly wrapper around StoreKit APIs.

2. If the transaction returns, it hands off the data to other SDK services.

3. Tracks and logs a lot more stuff.

4. 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.

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.

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.

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

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?

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

1. 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.

2. 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.

Contents

• The 10 Techniques

  • Hashmaps

    • LeetCode Diary: #383 Ransom Note

  • Two pointers

    • LeetCode Diary: Linked List Cycle

  • Sliding windows

    • LeetCode Diary: #3 Longest Substring without Repeating Characters

  • Stack-based and queue-based parsing

    • LeetCode Diary: #150 Evaluate Reverse Polish Notation

  • Binary search

    • LeetCode Diary: #704 Binary Search

  • Trees, Recursion and DFS

    • LeetCode Diary: #98 Validate Binary Search Tree

  • Graphs, Traversal, and BFS

    • LeetCode Diary: #200 Number of Islands

  • Backtracking

    • LeetCode Diary: #46 Permutations

  • Sort-and-sweep

    • LeetCode Diary: #57 Insert Interval

  • Dynamic Programming

    • LeetCode Diary: #322 Coin Change

• Staying sane in The Grind™

• Last Orders

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

Read more

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…

Read more

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.

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

  • Our isKnownUniquelyReferenced Compass

• The Abstract Syntax Tree

  • Builtins on the AST

  • Synthesising a Builtin Function

  • The Builtin Module

  • AST Recap

• Swift Intermediate Language

• LLVM Intermediate Representation

• The Swift Runtime

  • Checking the Docs

  • SwiftObject

  • HeapObject

• SwiftShims

• The isKnownUniquelyReferenced Meme

• Last Orders

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.

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

1. .swift files are parsed and turned into a data structure known as an Abstract Syntax Tree (AST), making it easy for algorithms to traverse.

2. Semantic analysis is performed on the AST, performing tasks such as type-checking, evaluating protocol conformance, and checking variable scopes.

3. 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.

4. This SIL is optimised through various passes. ARC is optimised, generics are specialised, code is inlined, and devirtualization replaces dynamic dispatch.

5. Optimised SIL is transformed into LLVM IR (Intermediate Representation). This is a high-level, language-independent kind of assembly language.

6. 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.

7. 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.

8. 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:

1. Find out how the isUnique Builtin function is applied to the Abstract Syntax Tree.

2. Work out how isUnique looks when it is transformed into SIL (Swift Intermediate Language).

3. Determine how isUnique behaves when converted to LLVM Intermediate Representation.

4. 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:

1. 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.

2. The generic inout parameter for isUnique and the result type, Int1, are defined here, to synthesise the signature of the FuncDecl.

3. 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.

The 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.

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:

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.

(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: