Last Week

Last week Apple came back with the second iOS production rejection, and the review moved from copy cleanup into product-shape questions. The earlier rejection had mostly been about explaining the business model and narrowing the privacy declaration to what the app actually does today. The second round was deeper: Apple questioned parts of the subscription setup, the pricing justification, and how the paid access model fits into the App Store’s subscription primitives.

That left me with a more serious set of problems to work through. The important lesson was that the review process is incremental. Clearing one layer of feedback can simply reveal the next layer underneath it. I ended Week 66 with a clear picture of the work ahead: answer the remaining App Store review issues, decide whether the short-duration paid access model needs to change, and make the iOS submission coherent enough for another production review.

That was the plan. Week 67 did not turn into the work week that plan needed.

A Quiet Week

There is not much app progress to report this week, and that is the main update.

I had friends visiting from far away, so the week went into showing them around, spending time outside, and visiting national parks instead of pushing code. That is not a dramatic technical update, but it is the honest one. The app did not move meaningfully forward this week.

The useful part is that the next step is still clear. The iOS review feedback has not changed. I still need to work through each rejection reason, prepare the fixes and explanations, and resubmit. I believe the remaining review work is small enough to handle in a focused week, but that is only true if I actually give it the focused week. This was not that week.

The other thing this quiet week made obvious is that the work after App Store approval cannot just be more app work. Once the iOS review is unblocked, the next major category is marketing.

That is the part I have been putting off.

What does it mean in English?

The app is not useful just because it exists in an app store. It becomes useful when restaurant owners, operators, and event organizers know it exists and can quickly understand why it matters.

Shokken is already live on Google Play, and iOS is close enough that I need to start treating visibility as real product work. That means improving the store listings, making the screenshots and descriptions clearer, preparing a simple one-page explanation I can hand to people in person, and figuring out how to show up consistently on social platforms without turning that into another expensive monthly service.

In plain terms: after the iOS submission is cleaned up, the next problem is not “can I build it?” The next problem is “can I get the right people to notice it?”

Nerdy Details

The review work still comes first

The first priority remains the iOS App Store rejection.

Apple gave me multiple review issues, and the correct response is not to treat them as vibes. Each one needs a specific answer. Some are likely configuration or metadata fixes. Some require a clearer explanation of the paid model. Some may require a change in how I describe short-term paid access so the reviewer understands the distinction between a standard auto-renewing subscription and a non-renewing or one-time access period.

The challenge with App Store review is that it is partly technical and partly documentary. The app can be correct, but if the metadata, screenshots, pricing language, privacy explanation, or subscription description does not make sense to the reviewer, the release is still blocked. So the next focused week needs to be very deliberate:

  • list every rejection reason
  • separate actual product changes from App Store Connect cleanup
  • make the smallest accurate fix for each issue
  • prepare screenshots or notes that show what changed
  • resubmit without creating a new ambiguity

I still think that is doable in under a week. I just did not have that week available this time.

Marketing is now part of the launch path

Once the review loop is under control, the next large effort is marketing.

That word still feels less natural to me than implementation work. Building the product has clearer feedback. A screen either works or it does not. A backend request either succeeds or it fails. A subscription entitlement either unlocks the paid path or it does not.

Marketing is messier. It asks a different set of questions: does the store listing communicate the value quickly? Do the screenshots show the real workflow? Does the description use the language a restaurant owner would use? Is the first impression credible enough that someone will try the app instead of bouncing?

Those questions are still product questions. They just live outside the codebase.

The first pass is App Store optimization: clean keywords, stronger descriptions, and better screenshots for both store listings. Shokken needs to be discoverable, but it also needs to be understandable once somebody lands on the page. A vague listing will waste the traffic it gets. A clear listing has a better chance of turning curiosity into a download.

The one-page pitch needs to exist

The second marketing artifact I want is a simple one-pager.

The idea is not complicated. I want a letter-size document that explains what Shokken does, who it is for, and why a restaurant should care. It should include a QR code that goes directly to the app or the testing site, and it may include a deep first-user discount as a thank-you for taking a chance on an early product.

That matters because Shokken is not only a search-driven product. The first serious users may come from showing up in person, talking to restaurant operators, and putting a concrete explanation in their hands. For that kind of outreach, the message needs to be short enough to read immediately and specific enough that the owner can picture the workflow:

  • guests scan a QR code
  • staff manage the waitlist
  • guests receive notifications instead of waiting around a buzzer
  • the restaurant gets a cleaner queue and fewer host-stand headaches

That is the product story in its simplest form. If the one-pager cannot explain that, the store listing probably cannot either.

Social posting should start manual

The third area is social media.

I need to be present in more places than the blog: X, Instagram, YouTube, Facebook, and whichever channels turn out to matter for restaurant operators. I originally thought about paying for a service to handle cross-posting, but the monthly cost of keeping the product running is already high enough that I do not want to add another subscription casually.

The more practical path is to start manually, learn the differences between platforms, and only then introduce a self-hosted posting workflow if it still makes sense. I have been looking at tools such as n8n for that eventually, with the idea that publishing one update could feed the relevant channels. But doing that too early would be a mistake.

Manual work teaches the shape of the problem. Each platform has different formats, expectations, link behavior, image dimensions, and audience habits. If I skip that learning and jump straight into a workflow, I will probably just publish mediocre posts faster.

So the order matters:

  1. clean up the store listings
  2. create the one-pager
  3. post manually enough to understand each channel
  4. only then streamline the repetitive parts

That is less glamorous than building features, but it is the practical path from “the app exists” to “people know what the app is for.”

Accountability still matters

This video was recorded late, just a few hours before it needed to go out. It was also a reminder of why I make these updates in the first place.

The point is accountability. Some weeks are feature weeks. Some weeks are bug-fix weeks. Some weeks are review-policy weeks. This was a low-progress week because life had priority, and it is still worth saying that plainly. The useful discipline is not pretending every week is equally productive. The useful discipline is keeping the thread alive so the next week starts with the truth instead of a vague memory.

Next Week

Next week I expect to get back to the iOS App Store rejection and work through the review issues one by one. The goal is to make the necessary App Store Connect fixes, explain the pricing and access model clearly, and resubmit for another production review.

After that, marketing becomes the next real workstream: store listing polish, a one-page handout, and the first round of direct outreach. The app will not matter if nobody hears about it, so visibility has to become part of the build process now.