The code was done in a few weeks. Getting it through review took longer than building it did, and that turned out to be the part actually worth writing about.
Hogline is a curling scorekeeper and shot tracker that lives entirely on an Apple Watch. You log every stone in three taps and score each end in two, and at the handshake line it hands you the whole game back as numbers. I'll get to what it does. But if you've ever built something small and solo and watched it bounce off the App Store, the app isn't the interesting part. The interesting part is the gap between "it works on my wrist" and "a stranger approved it," and everything I got wrong in between.
What I actually built
Curling is a strange sport to write software for. The people playing are the same people keeping score, in gloves, on ice, with a broom in one hand. So scoring has always happened on a scrap of paper, and a scrap of paper tells you who won but nothing about how you threw. What I wanted for myself was the shot-level record. Which turn was falling apart. Whether my draws or my hits carried the night. Whether I was actually getting better or just remembering the good ends.
That constraint shaped everything: a few seconds of attention, gloves on, in the middle of a game. Three taps to log a stone, draw or hit, in-turn or out, how it landed. A haptic confirms it so you never look down twice. The running score sits in yellow and red like the board at the club. Finish a match and the numbers come out, shot success in points, split by type and turn, your best end, an end-by-end timeline.
Writing for watchOS is a different exercise than writing for a phone. On a phone you can afford to be indecisive. Add a settings screen, a second tab, an onboarding flow, and nobody notices you never made up your mind. On a watch there's nowhere to hide. Every screen has to survive the question "could the user just not open this?" That was the whole design brief, and honestly it was the easy part.
The part with no documentation
The hard part was storage. I wanted the whole season to sync across your devices and survive a lost or upgraded watch, without ever asking anyone to make an account. On Apple's platforms that means using the user’s private iCloud container. No server of mine in the middle, and it's actually private. It was also my first time building anything on it, and the learning curve was steeper than the rest of the app put together.
Syncing wasn't the problem. The schema was. Everything you save has to be modeled up front in a shape iCloud will accept, and once real games are sitting in people's containers, that shape is very hard to change. A curling match nests further than you'd think, a game holds ends, an end holds shots, a shot holds a type and a turn and a result, and I modeled it wrong more than once before it was right.
Then one detail cost me a full day, and there's almost nothing written about it anywhere. iCloud generates the schema from your model the first time you run it. Mine kept refusing to save, silently, with no error. The model was fine. The problem was my own account. I had Advanced Data Protection turned on, and with that end-to-end encryption enabled, the schema will not generate. Nothing tells you this. You just get an app that saves locally and not to iCloud.
The fix is to turn Advanced Data Protection off, let iCloud generate the schema once, then turn ADP back on. I lost a day to that, which is a stupid way to lose a day, and it's exactly the kind of thing that never makes it into the docs. Which is most of why I'm putting it here. If you have Advanced Data Protection on, you cannot generate the schema for production environments.
And then review said no. Twice.
I got rejected two times, but both rejections were fair. The thing that got to me wasn't the notes, it was the long tail of reviews. You submit, you wait days, you get a paragraph of guideline citation, you fix it in ten minutes, then you wait days again. The loop runs in days and the fixes run in minutes, and that mismatch is the whole difficulty. Almost like there should be an MCP that does a pre-review to close the loop quicker.
The icon was black
Guideline 4, Design. My watch icon didn't appear circular, because the background was black.
Since watchOS masks every app icon into a circle, and it does it by cropping, not by drawing a ring. So a black background on a black watch face means there's no circle. There's just a floating logo with no edge. In the simulator, on a white asset grid, the icon looked great. On a wrist, in the dock, it looked like a mistake.
The fix was white instead of black, and the humbling part is that I already had the white version. It was what the beta shipped with. Somewhere on the way to submission I swapped it for the black one because I liked how it looked in contrast. The right asset was sitting in the project the whole time. I resubmitted with a file I already owned. Easy change.
The workout session
Guideline 2.5.1, Software Requirements. The app used HKWorkoutSession, and the reviewer's position was that Hogline had no primary feature that required fitness data. Their suggested fix was blunt. Remove it.
I felt like this was wrong, they didnt understand what I was trying to do. Curling is two hours of sweeping and sliding and squatting down in the hack, and capturing that alongside the match data was half of what I thought I was building. So I added a screen about your workout data to the game thinking just adding the data that was being used and saved in the firness app would get it approved. I resubmitted it and wrote back explaining that the workout data was core functionality, not a side effect, that the app collected it on purpose and put it right next to the shot stats it exists to produce. I lost. The reply came back days later restating the guideline, and at that point I could argue with boilerplate for another week or I could ship.
I removed it. What I didn't appreciate going in is how far a single feature reaches once you start pulling on it. The code was the easy part, an afternoon of deletions. Entitlement out. Usage strings out. Session start and stop out of the match lifecycle. Duration and calories off the summary screen and out of that schema I'd been so careful about.
Everything around the code took longer. The privacy questionnaire had to be answered again, because I'd declared health data collection for an app that didn't collect any anymore. The marketing site was worse. It promised a feature that had stopped existing. A Save as Workout section. A line about how two hours of sweeping should close your rings. Screenshots with heart rate in them. A privacy policy describing how health data was handled, a support page walking you through turning the workout on. All of it had to come down before the build went back in, because a site making claims the binary can't deliver is its own review problem waiting to happen.
Resubmitted without it. Approved.
I still think the feature belongs in the app, and I intend to bring it back. When I do, it'll be built so a reviewer can watch the fitness data come back out somewhere a user actually looks. That's the real lesson if you got here from a search on 2.5.1. The guideline isn't asking whether you use HKWorkoutSession. It's asking whether a user could tell that you do.
Where it is now
Hogline is out. It's on the App Store today for $4.99 once, no subscription and no account, running on Apple Watch with watchOS 10 or later, available in the US and Canada with Europe on the roadmap. You can find it at hogline.app.
Version one is everything you need to track your game. There are a lot of little improvements and features I want to add, like a phone companion that allows you to build and show off a player card with your game data and the fitness/health integration are high on my list for a next version.
There's still room for an app that does one small thing for a few thousand people who care about it. Not everything has to be a platform. Scope Tiny, Ship Anyway