← cd ../writing

case-study ·

Rebuilding the Wolf Golf Scorecard for Android and iPhone

The Wolf Golf Scorecard started as a side project in late 2016. It keeps score for Wolf, a golf betting game where one player each hole (the “wolf”) picks a partner or goes it alone, and the points and money shift with every decision. For nine years the app ran only on Android. In May 2026 I shipped version 3.0: a complete rebuild that runs on both Android and iPhone from a single codebase.

This is the story of that rebuild, written for engineers and for anyone curious about what it takes to bring an app to both app stores.

Where the app started

By early 2026 the Android app was at version 2.0.8, with 268 commits behind it. It had a 2020 redesign with my colleagues at Chariot Solutions, a free version with ads, and a paid Pro version without them. It worked, and people used it, but three things were holding it back.

It only ran on Android. Wolf is a group game, and only one person keeps score. If that person carried an iPhone, the app was useless to the whole group. This was the gap I most wanted to close.

It was built with older Android tools. Each screen was its own piece of Android-specific code, laid out with Android’s older layout system. None of it could be reused anywhere else, so an iPhone version would have meant writing and maintaining a second app from scratch.

Its database had an uncertain future. The app stored games with Realm, a database library whose maker had wound down parts of its mobile offering. It still worked, but it was not something I wanted to build the next ten years on.

I had tried a cross-platform rewrite once before, in mid-2024, and set it aside. In January 2026 I started again with a different plan.

The old Android app (version 2.0, 2020): game setup, a hole in progress, and the results screen

One codebase, two phones

The key decision was Kotlin Multiplatform with Compose Multiplatform. In plain terms: I write the app once, in Kotlin (the language the Android app already used), and the same code produces a real Android app and a real iPhone app. That includes not just the game logic but the screens themselves.

The app is organized in three layers, like floors of a building:

  • The rules and the data (shared). Everything about how Wolf is scored lives here: who won a hole, how lone wolf and blind wolf multiply the stakes, how points turn into money. This layer knows nothing about phones at all, which makes it easy to reason about and test.
  • The screens (shared). Game setup, the hole-by-hole scorecard, and the results screen are written once and drawn the same way on both platforms.
  • The platform shells (separate). A small amount of code per platform handles the things only that platform can do: notifications, sound, ads, purchases, and the database driver.

The numbers show how lopsided that split is. Of roughly 13,000 lines of code, about 80% is shared. The Android-specific entry point is about 200 lines. The iPhone-specific Swift code is about 550 lines.

For storage, I replaced Realm with SQLDelight, which keeps the game in a standard SQLite database on the phone. It works the same way on both platforms. The app also stays fully offline: no account and no cell signal required, which matters on a golf course.

The first iPhone build ran in February 2026, about a month after the first commit.

Working with an AI coding partner

I built this rebuild with Claude, Anthropic’s AI coding assistant, as a working partner from the first week. The early commit history is literally a list of sessions: “Iterating with claude session #2,” “#3,” and so on.

The most useful habit turned out to be writing things down. The repository has two documents written for both me and the AI: an architecture guide that explains the layers, the data model, and the Wolf scoring rules in code, and a project notes file that records every hard-won lesson (especially the iPhone build quirks) plus a full release checklist for both stores. Each new session starts from that shared memory instead of rediscovering the same problems.

The division of labor was simple. I made the product and design decisions and tested release builds on real phones. The AI did much of the typing, explained unfamiliar iPhone territory, and helped track down bugs.

Same business, different rules

The business model stayed the same: a free version with ads and a paid version without them. But each store does this differently.

On Android, there are still two separate listings: the free app with ads and the paid Pro app.

On iPhone, there is one app with a $4.99 “Remove Ads” in-app purchase. The price is read live from Apple, so changing it never requires an app update.

Both versions ask for consent before showing ads where privacy law requires it, and the iPhone app also shows Apple’s tracking prompt. Ads are limited to teen-appropriate content so the app can carry a 12+ rating.

Launch

Android version 3.0.0 went to testing on May 6, 2026, with fixes arriving almost daily through mid-May. The iPhone version, the first in the app’s history, went live in late May 2026.

The rebuilt app today on iPhone: game setup, a hole in progress, and the results with a per-player settle-up

After launch

The shared codebase paid off quickly. Every feature since has been built once and shipped to both platforms:

  • Carryover: an optional pot that rolls forward when a hole is tied.
  • Two payout methods: “One Winner” and “Pay the Difference.”
  • Share Results: send the final standings to the group.
  • Your currency: settle up in your local currency and number format.
  • Usage analytics: to see which features people actually use.

Automated tests now cover the scoring and money logic, which had none at launch. Store screenshots for both platforms are generated by a script instead of by hand. By October 2026 the app had gone from 3.0 to 3.2.5 across roughly a dozen releases.

What I’d tell someone considering the same move

  • Share the rules first. Getting the scoring logic into a phone-independent layer was the best decision of the project. It is the part that has to be right, and now it only has to be right once.
  • Budget real time for the iPhone release process. The code was the easy part. Signing, store validation, privacy prompts, and in-app purchases took weeks of their own.
  • Write down what you learn. The architecture guide and project notes turned every painful lesson into a one-time cost, for me and for the AI working alongside me.