Field Note · BRYKK

A CloudKit permission silently broke 80% of every BRYKK family.

Stepfather couldn't get notifications. Map showed him stuck at the wrong location. Family chat had eight stacked duplicate "Location downgraded" messages.

Started
April 11, 2026
Project
BRYKK
Shipped
April 11, 2026
Time
One evening, solo. ~2 hours to ship the diagnostics, ~5 minutes to verify the fix once the logs surfaced.

Setup

BRYKK uses a CloudKit record called `FamilyPulse` as a shared bell — anyone in the family can ring it, and ringing it triggers a silent push that wakes every other family device so they refresh state. Without that bell, devices fall back to a 30-second poll, burning battery and lagging behind real events. I'd been testing on my own family the whole time, where I was always the creator.

What I tried first

Traced through the location update handler, identified three plausible causes for the "stuck on Price Chopper" symptom, and shipped fixes for the most likely two — force a fresh GPS fix on app foreground (`78551a5`), reject stale cached locations from CoreLocation (`5f5ba31`). I told the user to update and try again. Standard founder reflex: ship the most-likely fix and ask the user to retest.

Why that wasn't going to work

I was about to ask the same non-technical user to test the same blind fix a third time. He'd already given three different symptom descriptions across the day. There was no path from "please try again" to "we know what's wrong." The only way out was to read his phone's actual logs.

What I built instead

An in-app debug log uploader plus a password-protected admin dashboard at `brykk.app/diag`. 1000-line timestamped ring buffer in `BRYKKLogStore`, persisted to Application Support so logs survive a force-quit. 7-tap unlock on the version row in Settings (the same Apple pattern as the iOS Build Number Easter egg). "Send debug logs to BRYKK team" button with a privacy-aware confirmation listing what's being sent — and what isn't (no chat content, contacts, photos, or passwords). Public POST endpoint, Vercel Redis storage, admin viewer with auth via header so the password never lands in a URL or server log. About two hours of focused work.

What the first log showed

`WRITE operation not permitted` on the `FamilyPulse` record. Nine times in one log. I'd never seen that error before because nothing in my own testing had ever triggered it.

The reframe

Before changing anything in CloudKit Console, I asked: is this stepfather-specific, or universal? I got a second debug log from a different joiner in a different family — same error, three times. Two data points across two families with two different creators. Not a user bug. Structural.

The fix

One checkbox in CloudKit Console: `FamilyPulse` Write permission changed from `_creator` (only the family creator can update it) to `_icloud` (any signed-in iCloud user). Save. Wait 60 seconds for production propagation. The next debug log from the same user came back with zero pulse errors. Verified end-to-end in under five minutes.

What had actually been broken

From day one, every joiner in every BRYKK family had been operating in degraded mode. The CloudKit Console default for shared records is `_creator`-only Write. So whoever bumped the pulse first became the only person who could ever update it again. Every other family member's bumps were silently rejected. In a typical 5-person family with one creator and four joiners, 80% of the family was running on stale poll-cycle data instead of fresh just-pushed state. The symptom on joiner devices was soft — "app feels a little laggy on my wife's side, sometimes I miss her departure notification" — exactly the kind of complaint a founder testing on their own creator account would file under "iOS quirks" and move on.

Lesson

Don't ship blind fixes when you can build a way to read the truth. The diagnostics system was the actual win — it caught a bug that had been live since day one and would never have shown up from the creator's seat. The fix was one checkbox; the leverage was the system that surfaced it.

References