Tech

In the post about this site’s auth, the admin cookie goes out as sameSite: "lax", and until late September that was the whole defense against CSRF (cross-site request forgery: a page somewhere else getting my browser to send a write to the admin, cookie attached).

A full review of the codebase I ran then flagged exactly that: Lax stops most of it, but not a request from a sibling subdomain, and this site is a subdomain itself, roland.leth.ro.

Apple's built-in way to A/B test App Store screenshots is Product Page Optimization: up to 3 alternate versions of your product page, which Apple calls treatments, measured against the original. Each one goes to a random share (that you configure) of the people who open the page.

It's free and built in. On a small app, though, there probably isn't enough traffic to tell two similar pages apart, so most of the work goes into choosing pages that differ a lot.

An App Store preview is a video of 15 to 30 seconds that autoplays, muted, ahead of your screenshots, both in search results and on the product page. The usual way to make one is to record the app in the simulator or on a device, then cut the clips together in iMovie or something similar, since Apple's guideline 2.3.4 says previews "may only use video screen captures of the app itself".

Reckon, my decision journal, and Digest, a food journal I'm working on, both automate their App Store screenshots from inside the app.

Every screenshot is a SwiftUI view in the debug build, made of the app’s real components over sample data in an in-memory container, and the app draws it into a PNG itself, at the exact size App Store Connect wants; there's no screenshot of the simulator involved. So if I change a component, every screenshot that shows it changes on the next export, in every set.

A test needs an expected output, and most of the time you have one: 2 plus 2 is 4, an empty cart costs nothing and so on. But what do you test against when nobody knows the right answer? Not you, not the person using the app, not anyone who could look at the data.

That was the case with an engine I built for Digest, the food journal I'm working on: it reads a journal and outputs a list of foods that might be behind your symptoms. Give it a journal and a list comes out, but is it the right list?

The person who logged the meals doesn't know, that's the whole reason they'd want the list, and I don't know either. The data is the truth, if you will.

Claude Code writes the code for my iOS apps, tests included, and it's really fast at the tests. Left alone, though, it writes them by reading the code it just wrote, so they check that the code does what it does. Bugs included.

Here’s what iOS testing with Claude Code looks like on Digest, the food journal I'm building: where the tests come from, how the code is split so a test can reach the logic, and a few tests that exist only because 2 files drifted apart.

(Running the tests, and what the simulator does to them, is in the previous post.)

Claude Code can drive the iOS Simulator without any MCP server, skill or plugin, as long as you use the Claude desktop app (and maybe the CLI, but I haven't tried). You have to first attach it, then you'll get a system approval request (for each attach) explaining what will happen and the privacy concerns.

Its iOS Simulator pane (in beta) opens next to the conversation when Claude launches your app. From there, Claude installs it, taps through it and takes screenshots to check its own work, while you watch or tap along. From the CLI, according to the same docs, it goes through computer use instead.

The series on building with AI was about working with the model in general: the rules, the memory, who decides, and what it reports versus what actually happened. This one is the iOS part, the things that only show up once the model has to build, run and ship an app: the simulator, the tests, and everything the App Store wants on top of the app itself.

It comes from 3 apps: Reckon, a decision journal, and Continuum, for keeping track of the people you manage, which are both out, and Digest, a food journal I'm working on. Claude wrote the code for all 3, mostly through Claude Code, while I decided what it should be and checked what came back.

Say we have a list of items, each one with a bit of text and an image, and a details screen that shows the same item with more fields. The details screen refetches the object, because the list response doesn't carry everything, and it draws the same image, only smaller. Same item, same URL, two sizes (I know the server or the CDN could serve a different size, but for the purpose of this post, let's say they don't; and it'll prove to actually be better).

Claude Code has been how I work since the spring, and the short version of what changed is that I type much less and decide much more. That’s a bigger shift than it sounds, because deciding used to happen while I was typing, spread thin across an afternoon and mostly invisible to me. It doesn’t work that way anymore, and the deciding has to happen somewhere.