The repo with the same name was the dead app

FILE 0xD1·THE REPO WITH THE SAME NAME WAS THE DEAD APP

May 25, 2026 · debugging, ios, process

I spent a couple of hours one afternoon making changes to what I thought was the current iOS source tree for a side project, running builds, watching them succeed, wondering why none of my fixes were showing up after I sideloaded to the device. The repo was the right name. The code was the wrong code.

What was happening

The project ecosystem had grown over time:

An old Objective-C iOS app from years ago, depending on a now deprecated third-party SDK that no longer compiles.
A new Swift/SwiftUI iOS app, nested inside a different monorepo with a different name.

The old app's directory was named the obvious thing — the project name with -iOS suffix. The new app lived inside a backend-lambda monorepo at <monorepo>/check-on-mine-ios/Check on Mine/Check on Mine/.

So when I cd'd into the obviously-named iOS directory, opened Xcode, made my changes, and ran a build, everything compiled. The deprecated SDK was loaded from a vendored copy, the app linked, the simulator showed a build of the old app, my fixes were applied to a tree nobody had shipped from in over a year.

What I found

The clue, finally, was a string. I had changed a button label from "Send" to "Send Help" in what I thought was the live code. The build succeeded. I installed it. The button still said "Send." I grepped for the old string across both repos and found it in only one of them — and it wasn't the one I had been editing.

The fix

The fix was just "edit the right repo." But the lesson is worth keeping: when a project name is reused across multiple repos for historical reasons, there has to be one authoritative README or top-level marker that says which one is live. I didn't have that. I have it now: a one-line file in each repo called STATUS.txt:

$ cat <dead-repo>/STATUS.txt
DEAD. This is the old Objective-C build. Live code is in
<monorepo>/check-on-mine-ios/.

$ cat <monorepo>/STATUS.txt
LIVE. iOS source lives at check-on-mine-ios/Check on Mine/Check on Mine/.
Build with `xcodebuild -project ...`.

I also added a build-time check: the dead repo's project.pbxproj won't build clean in any case (the deprecated SDK doesn't compile against modern Xcode), but I added an explicit #error macro in the main .m file that says "This project is archival. See ../STATUS.txt." So any muscle-memory attempt to build it fails immediately and descriptively.

What I'd do differently

Cleaner: archive the dead repo. GitHub's "archive this repository" is a soft delete that makes it read-only and adds a banner. I've procrastinated on this because the dead repo has some commit history with patterns I might want to refer to later. The right move is to archive it now and search the archived repo for those patterns the day I need them rather than leaving it live as a footgun.

The general pattern — old-app-with-good-name vs. new-app-with-bad-name — is one I've now hit twice in different projects. Anywhere a rewrite happens, the new code tends to end up in a directory named after the technical migration rather than the product. "We moved to React Native" becomes <product>-rn/; "we moved to a new build" becomes <product>-new/. A year later the obvious-named directory is the dead one. Worth defaulting to the obvious name for the live thing and naming the archive after the technology that's being replaced.