Last Week

Week 47 was recorded at the gate, squeezed in between boarding calls on the final leg of the trip home. I didn’t open the Shokken repo, didn’t touch the feature list, and didn’t change a single line of code. Instead, I used that short update as a promise: once I was back at a real desk, I would stop issuing travel postcards and start delivering actual progress again. The Android alpha stayed exactly where Week 42 left it—published to the Play Store for testers, backed by the same infrastructure, and quietly doing its job while I zigzagged through airports. The only “work” happening was invisible: a month of distance to let the product, roadmap, and rough edges settle in my head so that when I finally sat down again, I could see the app with fresh eyes instead of staring at the same backlog in a daze.

Android Alpha Live, iOS On Deck

This week is the pivot from “founder on the road” back to “founder at the desk.” The headline is simple: the Android alpha is ready for testing and published on Google Play, while iOS and web still trail behind. Under the hood, all three platforms share the same core Kotlin Multiplatform code and a Compose-driven UI layer, but only Android has its platform-specific pieces wired up end to end. The iOS target compiles, links against the shared modules, and renders screens in a simulator, yet the last mile details—packaging, integrations, and system hooks—aren’t in place. Web is even earlier in the pipeline and needs a deeper evaluation before I can make a credible promise about timing.

The last four weeks of travel underscore how much context this project carries. I optimistically packed my laptop and imagined writing Kotlin from hotel rooms and train seats. In reality, the choice was always between staring at a cramped 13–14 inch screen or walking around, eating something memorable, and being present with people I almost never see. Unsurprisingly, the laptop stayed zipped. Nothing moved, and that’s okay to admit. This check-in is me drawing a line under that stretch: the rest was real, the code froze in place, and now it’s time to re-energize the work instead of pretending that “vacation coding” was ever realistic.

From here, the plan divides into two parallel tracks. First, I need to rediscover and tune the development tooling I lean on every day after a month where the ecosystem kept evolving without me. A lot can change in four weeks, and I want to be deliberate about which tools I actually rely on versus which ones I keep around as experiments. Second, I’m going to scope the remaining iOS work: list the platform-specific features that are still missing, rekindle the trivial prototype I built earlier in the year, and turn that into a concrete plan. The year-end goal is clear in my mind: get both Android and iOS into a publishable test state so that hosts can try Shokken from whichever phone they carry.

What does it mean in English?

If you don’t live in Kotlin land, here’s the plain-language version. Shokken is a waitlist app for busy restaurants and other appointment-based businesses. The Android version is already installable through a tester track on the Google Play Store; it’s far from “finished,” but it’s real software you can run on a real phone to manage guests, send notifications, and see how the flow feels in a live shift. The iOS app shares the same “brains” and most of the same screens, but right now it’s more like a project on my development machine than something you can download from the App Store. It starts, renders, and talks to the shared backend in controlled tests, yet it isn’t packaged, signed, or polished enough for everyday use.

The last month didn’t add new features, and I want to be explicit about that. Travel meant no new builds, no fresh onboarding flows, and no shiny screenshots to show off. What it did give me is sharper contrast. It’s very obvious where the gaps are now: cross-platform consistency, iOS parity with Android, and a realistic plan for how the web experience fits into the picture. The next step is to convert that clarity into a concrete project plan instead of vaguely promising “more progress soon.” Week 48 is where I mark that reset and stop pretending that context switching on vacation was ever going to work.

Nerdy Details

Under the hood, Shokken is a Kotlin Multiplatform (KMP) project. The business logic that decides how guests move through the waitlist—creating entries, updating statuses, sending notifications, handling edge cases—lives in a shared module that doesn’t care whether it’s running on Android, iOS, or the web. On top of that shared core, I use Compose Multiplatform so that most of the UI code is written once as composable functions. That lets me define a single “host view” for things like the live queue, guest detail panels, and action menus, then render it on different platforms with relatively minimal per-platform glue.

Android is the furthest along because the glue was the most straightforward to ship. There’s a standard app module that wraps the shared KMP library, wires navigation into the Android activity and fragment lifecycle, and hooks the composables into the system: dark mode, fonts, insets, keyboard, and so on. The alpha build on Google Play is essentially that stack wired end to end. When a tester joins via the Week 42 instructions, they’re running the real shared business logic, the real networking layer, and the same UI components that will eventually power iOS and web. The Play track is “alpha” not because the code is half-baked, but because the edges are still sharp: onboarding copy needs tuning, error states are sparse, and the host workflows need more polish for real-world chaos.

On iOS, things are fuzzier. The KMP module already targets iOS, and I’ve run a trivial prototype that proves I can host Compose-based screens inside an iOS shell. That prototype spun up a simple list, pushed some data through the shared view models, and confirmed the basics: input works, state flows back and forth, and performance on a modern device is acceptable. What’s missing is everything that turns that prototype into a real TestFlight build. I still need to finalize how the root view controller integrates with the Compose runtime, how navigation and deep links map into the shared routing, and how to neatly bridge platform services like notifications, haptics, and background tasks without sprinkling conditional code all over the place.

There’s also the distribution side. On Android, the current alpha rides on top of an existing CI pipeline that signs, uploads, and tracks builds in the Play Console. The iOS equivalent requires a slightly different mental model: provisioning profiles, signing certificates, App Store Connect configuration, and the distinction between ad hoc builds, internal testing, and external TestFlight groups. Before I left, I made a conscious choice not to half-wire that pipeline while traveling, because debugging signing issues from a hotel Wi‑Fi connection is a special kind of misery. Now that I’m home, the plan is to set up the iOS build chain once, document it thoroughly, and wrap it in scripts so that future releases feel as boring—as in, as predictable—as the Android alpha track.

The other major thread for the coming week is rediscovering my toolchain. Before November, I had settled into a rhythm: specific IDE builds, command-line utilities, and project scripts that I trusted enough to lean on during long refactor sessions. While I was away, the ecosystem moved: new versions shipped, defaults changed, and a month’s worth of changelogs accumulated. Dropping back into that environment cold is a good way to break momentum or, worse, to quietly introduce subtle bugs. So the first “nerdy” task is to slow down and rebuild trust: upgrade deliberately, read release notes, re-run the sample projects I use as smoke tests, and confirm that my everyday tools still behave the way I remember.

One example from before the trip drove this home. I ran into a UI bug that only surfaced under a narrow combination of state and navigation, and some of the tooling I rely on happily said “looks fine” while missing the actual glitch. The fix came from stepping back, simplifying the reproducer, and reasoning through the state graph by hand instead of blindly trusting any single diagnostic readout. That experience changed how I think about my setup. Tools are there to accelerate my understanding, not replace it. As I re-evaluate the updated stack this week, I’ll be looking less at marketing claims and more at whether a given tool helps me spot genuine issues in my own code without sweeping edge cases under the rug.

All of that sits on top of the simplest but most important task: context reloading. A month away from a codebase means function names feel unfamiliar, TODOs lose their original urgency, and half-finished branches stop making sense. To rebuild that mental model, I’ll do a slow walkthrough of the core flows: spin up the Android alpha, run through the full host journey from an empty waitlist to a busy dinner rush, and cross-check what I see on-screen against the KMP module that powers it. From there, I’ll sketch the iOS-specific work as a sequence of small shippable milestones—“render the host queue on-device,” “hook up authentication,” “send the first notification from a TestFlight build”—so that I can measure progress week over week instead of treating iOS as a single giant cliff.

The stretch goal for the rest of the year is to have both Android and iOS in a state where I can reasonably hand them to early adopters: not polished, not perfect, but coherent and stable enough that a busy host can run a night on them without fearing data loss or crashes. Web will likely lag behind that milestone, and that’s okay. Right now, the priority is to make sure the mobile experience feels solid on the two platforms people are most likely to carry in their pockets. Once that foundation is in place and I’m no longer playing catch-up from a month-long trip, I can revisit how the web front-end fits into the story—whether as a lightweight dashboard, a full host console, or something in between.

Next Week

Next week’s plan is intentionally focused. On the tooling side, I’ll pick a stable stack, upgrade what needs upgrading, and write down anything that surprised me so I don’t have to rediscover it a month from now. On the product side, I’ll map out the iOS implementation work in enough detail that future weeks can be about execution instead of hand-waving. That means revisiting the earlier prototype, validating how Compose Multiplatform wants to live inside an iOS shell today, and translating that into a concrete checklist tied to a TestFlight target. If I keep that scope tight and realistic, the year-end goal of having both mobile platforms in a publishable test state stays within reach instead of being just another optimistic bullet point on a roadmap.