CLAUDE LABJP
FORK — Claude Code 2.1.212 changes what /fork does: it copies your conversation into a new background session with its own row in claude agents, so you can keep working. The old in-session subagent is now /subtaskLIMITS — WebSearch calls are now capped at 200 per session by default, and subagent spawns get the same 200 ceiling, so a runaway search or delegation loop stops on its ownMCPBG — MCP tool calls running past two minutes now move to the background automatically, keeping the session usable. Tune the threshold with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSPLANFIX — Fixed plan mode auto-running file-modifying Bash commands such as touch and rm without a permission prompt or an SDK canUseTool callbackSONNET5 — Claude Sonnet 5 is running on introductory pricing of $2 per million input tokens and $10 per million output. After August 31 it moves to $3 and $15IPO — Bankers are reportedly lining up investor meetings for Anthropic ahead of a possible public listing as soon as OctoberFORK — Claude Code 2.1.212 changes what /fork does: it copies your conversation into a new background session with its own row in claude agents, so you can keep working. The old in-session subagent is now /subtaskLIMITS — WebSearch calls are now capped at 200 per session by default, and subagent spawns get the same 200 ceiling, so a runaway search or delegation loop stops on its ownMCPBG — MCP tool calls running past two minutes now move to the background automatically, keeping the session usable. Tune the threshold with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSPLANFIX — Fixed plan mode auto-running file-modifying Bash commands such as touch and rm without a permission prompt or an SDK canUseTool callbackSONNET5 — Claude Sonnet 5 is running on introductory pricing of $2 per million input tokens and $10 per million output. After August 31 it moves to $3 and $15IPO — Bankers are reportedly lining up investor meetings for Anthropic ahead of a possible public listing as soon as October
Back to Blog

Three Days, Four Apps, Four New iPhone Resolutions — The Line I Delegated to Claude Code, and the Line I Drew Myself

indie-developerclaude-codeiphone-adaptationworkflowpersonal-story

The morning after Apple announced the iPhone Air, I lined up four apps on my desk and quietly folded my arms.

I have been building wallpaper and healing apps as a solo developer since 2014. The lineup now totals more than 50 million downloads, but every single one of those apps needed the same update. iPhone Air at 420×912. iPhone 17 Pro at 402×874. The 16 and 17 Pro Max at 440×956. Three new screen sizes arriving in one stroke.

Inside each app, DefineManager.h holds a chain of ternary operators that branch on device resolution. Adding the new resolutions meant editing 29 places per app. Times four apps. By a quick count, that is 116 nearly identical edits of the same pattern.

"This is mechanical work," I thought. Which is exactly why I wanted to be deliberate, before touching anything, about what to hand to Claude Code and what to keep for myself. Now that the outline of those two lines feels clearer to me, I want to write down what those three days looked like.

116 ternaries — the line Claude Code quietly took on

When I opened DefineManager.h in Beautiful HD Wallpapers and scanned the lines that needed editing, I felt a small wave of dizziness.

#define ITEM_HEIGHT (IS_IPHONE_17PRO ? 480.0f : \
                     IS_IPHONE_16PROMAX ? 520.0f : \
                     IS_IPHONE_15PROMAX ? 510.0f : \
                     IS_IPHONE_15PRO ? 470.0f : 450.0f)

Ternary chains like this, 29 of them. Each one needed new branches with constants derived from the new screen ratios. I tried doing the first three by hand, and noticed myself letting out a long breath before I even finished.

This was not my work to do, I felt almost immediately. Once the rule is settled — "use the same proportional ratio against the new device width" — the rest is execution. The judgment lives in the rule. The application belongs to the machine.

So I fed Claude Code a table of resolutions, status bar heights, and safe areas first. Then I asked it to compute, for every existing constant, what percentage it represented relative to screen width, and to apply that same ratio to the new resolutions.

The thing I was careful about was this: I gave the rule explicitly. I never said anything like "please interpolate appropriately." I wrote the actual formula in words — "screen width × ratio," "status bar height × multiplier" — and handed that over.

The 29 edits landed in a single commit. I repeated the process across all four apps, and by the afternoon of day one, all 116 places were done.

What I still had to decide myself

This is where the real solo-developer work began.

Adapting to a new resolution is not finished when the size constants are added. For a wallpaper app, the image itself looks different on different screens. iPhone Air is tall and narrow. Pro Max is wider and more relaxed. The same wallpaper image has to choose what to show on each device.

Imagine a wallpaper with Mount Fuji and cherry blossoms in the same frame. On a Pro Max screen, both can sit comfortably in view. On the taller iPhone Air, you have to choose — keep Mount Fuji centered, or favor the cherry blossom branch. One or the other.

That was not a decision I could delegate to Claude Code.

Since 2014, the thing I have cared about most in my apps is the composition decision on every wallpaper. In Beautiful HD Wallpapers, in Ukiyo-e Wallpapers, I have tried to ask, image by image, "When the user opens their home screen, where do their eyes land first, and is that the right place?"

On a taller screen, the answer to that question shifts. So I opened the wallpaper database and walked through more than 500 images, one by one. I previewed each on the new resolutions and adjusted the crop point individually.

I did not hand this work to Claude Code. Not because it was incapable of helping, but because I felt it was not the right work to delegate. "Where the user's eye lands" is a developer's call, and it is the personality of the app. The moment I let a machine decide that, my app would stop being my app.

When you delineate what to delegate, your own judgment gets sharper

Looking back on the three days, I noticed something. By being explicit, up front, about what Claude Code would carry, I could see more clearly what I was supposed to carry.

For twelve years of solo development, "think about everything myself" was simply the default. Writing the code, choosing the images, deciding the layout, judging when to release — all of it. Because of that, I sometimes lost track of what I was actually deliberating over versus what was running on autopilot.

Working alongside Claude Code, I find myself asking, before any task, "Can this be turned into a rule, or does it require my judgment?" If it can be turned into a rule, I hand it to Claude Code. If it cannot, I take it on myself.

In the middle of the iPhone Air work, a new crash report came in through Crashlytics. CGContextSetRGBStrokeColor had been called on a nil context. The stack trace pointed to image-composition code I had written three years ago.

For a moment, I thought, "I'll have Claude Code propose a fix." Then I stopped. "No, I need to read this one myself." Only I know what I was thinking when I wrote that code three years ago. If I patched the symptom without understanding the original intent, someone else — including future me — would fall into the same trap.

The ability to make that kind of call is recent. After roughly a year and a half of working with Claude Code, the outline between "what to delegate" and "what to decide" finally feels visible to me.

What my carpenter grandfathers said about handwork — and what it means in the age of AI

Both of my grandfathers were temple carpenters. As a child, I would sit in my grandfather's workshop, surrounded by the smell of wood shavings, watching him plane lumber in silence.

He was not a man of many words, but once he said, almost in passing, "Working with your hands is a kind of devotion." I did not understand what he meant at the time. The phrase just stayed somewhere in my chest.

After I started building apps, I thought of that line more than once. Writing code, adjusting images one by one, replying to user reviews individually — each handwork seemed to me to be a small expression of care for the app. I have quietly believed that for years.

When AI tools first appeared, there was a period when I wondered whether my grandfather's devotion had become irrelevant. "What is the meaning of handwork in an era when things can be made without hands?"

Looking back at these three days, the picture is a little different now.

The place where I actually used my hands was the 90 minutes I spent reviewing 500 wallpapers, ten seconds each, checking the crop point against the new resolutions. Claude Code was rewriting constants in the background, and I was simply looking at images, one at a time, asking where the eye would land.

That, I think, is close to my grandfather's "devotion in handwork." The more the machine can carry, the closer my own handwork gets to the essence of what I make.

Deciding what to delegate is, in the end, the same as asking myself what I am trying to make. The personality of an app is built out of decisions that cannot be mechanized. Continuing to take those decisions on, I think, is the devotion of a solo developer in the AI era.

The night I submitted four apps to App Store Connect

On the evening of May 8, I submitted four apps to App Store Connect.

The new builds support iPhone Air, 17 Pro, and 17 Pro Max. I also retook screenshots for every device, added the Liftoff, InMobi, and Unity Ads partners to the AdMob mediation waterfall, and finished the Firebase Apple SDK SPM migration check. Three days, that much progress.

While waiting for review, I opened the four apps once more in the iPhone Air simulator. I looked at the icons sitting on the first home screen, with the wallpaper I had just set.

"Without Claude Code running alongside me, this work would have taken a week and a half," I thought. And in the same breath, "If I had delegated even the cropping decisions to Claude Code, these apps would not have this shape."

The line I delegate. The line I draw myself.

That boundary is not fixed in advance. It comes into focus, slowly, while I am actually working. If I am bad at delegating, I try to do everything myself and exhaust the day. If I delegate too much, the personality of the app blurs.

I want to carry this feeling into the next round of app updates. Claude Code is an excellent partner. And as with any partner, there are lines it can hold and lines I must hold myself — that ordinary truth is what these three days quietly taught me again.

If you are also building apps as an indie developer, the next time a device adaptation arrives, try asking each task, "Is this rule-able, or does this need my judgment?" I suspect that what you have been quietly caring about all along will come into clearer view than you expected.

Thank you for reading.