Tap the Version Number Seven Times: Production Diagnostics for Mobile Apps

The hardest bug reports come from production: "the map stopped updating for dad." No console, no debugger, no adb — a release build on a phone in another city, owned by someone who will not be installing a debug APK for you. For North I shipped the old trick properly: tap the version number seven times and a hidden dev menu unlocks. It feels hacky; it's the right call.

Why the seven-tap pattern survives

Android itself uses it to unlock developer options, which means it has exactly the properties a hidden gate needs:

• Zero accidental discovery. Nobody taps a version string seven times by mistake; it costs no UI surface and adds no visible complexity for the 99% of users who'll never need it.
• Trivially communicable. "Go to settings, tap the version number seven times" is a one-sentence support instruction a non-technical family member can execute while you're on the phone with them.
• No auth infrastructure. It's an obscurity gate, which sets the rule for what may live behind it: read-only diagnostics, no privileged mutations. Anything destructive or privacy-relevant needs real auth, not taps. The menu can tell you what's wrong; it shouldn't let a curious teenager break the circle.

What's actually in the menu

The contents are shaped by one question: what would I need to see to diagnose a report without touching the device? For a background-location app, that means the state of every link in the chain — permission states (location, precise vs. approximate, notifications), background task registration, push token presence, last successful upload timestamp, realtime connection state, and the device-level kill switches (battery saver, background restrictions) that silently strangle background work.

Most diagnoses are one glance: "permission says 'While Using'" or "last upload 14 hours ago, background restriction on." The app already knows why it's failing — the dev menu just lets that knowledge out.

The shareable dump is the feature

The menu's real payoff is the diagnostics dump: one button that serializes the full snapshot and hands it to the OS share sheet — WhatsApp, email, whatever the user already uses. The support loop becomes: seven taps → share → send. Thirty seconds of user effort, and you're debugging from data instead of from "it doesn't work."

Two implementation rules earn the trust the feature depends on:

1. Scrub it. The dump describes the device and app state, never the user's data — no coordinates, no circle members, no tokens in plaintext. For a privacy-positioned app, a debug dump that leaks location would be self-sabotage; it's the same data-that-doesn't-exist-can't-leak principle applied to support tooling.
2. Make it human-skimmable. Labeled sections and OK / PROBLEM markers, not a JSON blob — half the time the user reads it back to you over a call, and "it says background restriction: PROBLEM" from a parent's mouth is a complete diagnosis.

Build it before you need it

The meta-lesson is timing. Diagnostics built after a mystery bug arrive too late to debug it — the report that justified the tooling is already stale. The dev menu went into North while the reconnect machinery was being built, on the theory that any system complex enough to need a dead-man's switch is complex enough to need an inspection hatch.

Every app with nontrivial background behavior, permissions, or sync deserves one: a hidden gate, a state snapshot, a share button. It's an afternoon of work, and the first production bug it resolves over a phone call pays for it permanently.