DOSBTS: Fork to TestFlight in One Session

The following content is AI-assisted and being rewritten.

Why fork a diabetes app?

The vision: a diabetes management tool with a DOS amber CGA aesthetic. Black backgrounds, amber text, retro terminal vibes — but tracking real blood glucose data from a Freestyle Libre 3.

Here's the pitch I kept coming back to: make diabetes UX feel like a dedicated instrument you own, not a service you rent. Continuous glucose monitor apps mostly compete on glanceability—how fast the number lands when you check it mid-conversation—and they nearly all reach for the same vocabulary to get there: sans-serif cards, gradient pills, soft shadows. A DOS terminal gets to glanceability another way. Amber on black, monospace, sharp corners: one high-contrast number you read at arm's length and can't mistake for anything else. The nostalgia is the hook. The legibility is the point.

Building from scratch would take months. GlucoseDirect, an open-source app by creepymonster, already does the hard part: reading CGM data, displaying trends, managing alerts. It's MIT licensed, built with SwiftUI, and uses a clean Redux-style architecture. Fork it, rebrand it, transform the UI later.

First build: it just works

Opened the Xcode project. Let Swift Package Manager resolve GRDB.swift 6.29.3. Hit build.

BUILD SUCCEEDED. Zero errors on the simulator.

That's the sign of a well-maintained codebase. The upstream project is solid — GRDB for persistence, SwiftUI for the interface, a single SPM dependency. Respectfully built software.

The Great Rename

GlucoseDirect was already taken on TestFlight (it's the upstream app). We needed our own identity: DOSBTS — DOS Blood Testing System.

The audit found 149 files with references to "GlucoseDirect", "LibreDirect", or "Glucose Direct":

• 119 Swift files (header comments)
• 26 localization files (display names in 13 languages)
• 35 references in the pbxproj
• Scheme files, xcconfig files, class names

The renaming strategy had to be systematic:

1. Localization strings: "Glucose Direct" to "DOSBTS" (26 files)
2. Swift classes: GlucoseDirectApp to DOSBTSApp, delegate to match
3. Header comments across all 119 Swift files
4. Config files: GlucoseDirect.xcconfig to DOSBTS.xcconfig
5. Xcode project internals: pbxproj (longest strings first)
6. Scheme files renamed and contents updated
7. .xcodeproj directory renamed last

148 files changed, 236 insertions, 236 deletions. Build succeeded on the first try.

The code-signing fight

Then the first archive hit a wall. Xcode refused outright: "Personal development teams do not support Time Sensitive Notifications, NFC Tag Reading, and HealthKit Access."

This is the part a fork inherits whether you want it or not. GlucoseDirect earns those three entitlements honestly — it reads Libre sensor tags over NFC, writes readings to HealthKit, and fires Time Sensitive Notifications when glucose is heading somewhere urgent. All reasonable for the upstream app. All unavailable to a free personal signing team. And all unnecessary for a DOSBTS that, right now, reads no sensors and fires no alerts.

So the wall was really a question in disguise: which of these does this build actually need? The honest answer was none of them — not yet. I stripped the three unsupported entitlements and kept only App Groups, which personal teams do support and the widget genuinely needs. Archive again.

Success.

The milestone

Product > Archive > Distribute > App Store Connect > Upload.

Created the app record as "DOSBTS" with bundle ID com.cinimody.eatthisidie. Uploaded. Waited for processing. And there it was in TestFlight.

DOSBTS is live on the phone. It's still GlucoseDirect under the hood — same UI, same features, same everything. But it builds, it signs, it distributes. The foundation is laid.

What's next

The real work starts now:

• Audit — decide what to keep from GlucoseDirect, what to strip
• DOS aesthetic — black backgrounds, amber text, SF Mono, the full CGA treatment
• Eidotter alignment — bring it into the design system
• Food logging — the feature GlucoseDirect doesn't have, the whole reason for this fork

The fork-to-TestFlight pipeline took a single session. The transformation into something distinctly DOSBTS will take many more. But every session starts with a working app on a real device, and that changes everything about how you iterate.