Last Week

Last week was quiet by design, or at least quiet in terms of app progress. I had friends visiting, spent the week showing them around, and did not make meaningful progress on the iOS rejection. The useful part of that pause was that it clarified the next order of operations. First, I needed to come back to the App Store review feedback and handle it directly. After that, I needed to start treating marketing as real launch work instead of something I could postpone indefinitely.

This week was the return to the first part of that plan. Android production access has already been approved, and the app remains live on Google Play. iOS is still the blocked side. The second App Store submission was also the second denial, and this time I went through the feedback line by line so I could separate quick metadata fixes from the issues that require more explanation or app work.

The good news is that most of the feedback now has a concrete answer. The less convenient news is that even a simple-looking review item can have a surprisingly large blast radius once it touches account deletion, subscription language, or release readiness.

Reading The Review As A Checklist

The second App Store rejection looked intimidating at first because it included multiple guideline references. In practice, the feedback groups into a few categories:

  • metadata cleanup
  • legal link placement
  • pricing justification
  • short-duration paid access
  • account deletion
  • release management debt

Some of that is App Store Connect cleanup. Some of it is explanation. One item required app and backend implementation. None of it looks impossible, but the shape of the work matters. App review is not only asking whether the app runs. It is asking whether the product is described accurately, whether paid access is understandable, whether users have required privacy controls, and whether the binary I submit is ready to be judged as the thing customers will actually get.

That last point is the part I feel most sharply this week. I have continued developing while the review loop has been open, and Shokken does not yet have feature flags. So if unfinished work is already in the app, I cannot simply hide it from the production build with a remote switch. Anything included in the binary needs to be ready enough to ship.

That is a release-process problem, not just an App Store problem.

What does it mean in English?

Apple is asking me to make the app easier to understand, easier to trust, and safer for users who decide to leave.

Some fixes are small. I used the app icon as a promotional image for in-app purchases, and Apple does not want that. The solution is to remove it. I also need the license agreement link to be visible in the App Store listing, not only inside the app.

Other fixes need more explanation. Shokken costs more than a typical consumer subscription because it is a business tool and because SMS notifications create real per-use costs. I need to explain that to Apple clearly. I also need to clarify that the one-day and three-day paid options are intended as short-term, non-renewing access for events and busy weekends, not as auto-renewing subscriptions that violate the seven-day minimum.

The biggest product fix was account deletion. If users can create accounts, they need a way to delete them. That is now implemented, including the backend path that verifies the user and removes the right data.

Nerdy Details

Metadata: promotional images are not subscription icons

The first issue was Guideline 2.3.2, accurate metadata.

App Store Connect has a place to add promotional images for in-app purchase products. I did not have separate artwork ready for those items, so I used the Shokken app icon and logo. That was the wrong interpretation of the field.

The promotional image area is not a generic “put a product icon here” box. It is for actual promotional material around an in-app purchase. Since I am not currently running that kind of promotion, the right fix is straightforward: remove those images from the in-app purchase metadata.

This is the easiest kind of review issue because it does not touch the app binary. It is a metadata correction in App Store Connect, and I can include a note or screenshot in the review response showing that the offending images are gone.

EULA placement: inside the app is not enough

The second issue was Guideline 3.1.2(c), subscriptions and terms.

Shokken already has terms available. The paywall includes links to the terms, and the terms are also available on the web. The mistake is that Apple wants the end-user license agreement or terms link visible in the App Store listing description as well.

That distinction matters. A user browsing the listing should be able to find the governing terms before installing the app or starting a purchase flow. It is not enough for the terms to appear later inside the app.

Fortunately, this is also a small fix. Apple provides a standard EULA option, and I can link the appropriate terms in the listing description. The review response then needs to point out the updated description and provide evidence that the link is visible where the reviewer asked for it.

The broader lesson is that “the app has the link” and “the store listing has the link” are different compliance states. I had handled the first one. Apple needed the second one.

Pricing needs a cost-based explanation

The third category is Apple’s question about the business model and subscription pricing.

Shokken has two larger recurring tiers: $200 per month and $500 per quarter. I understand why that looks high compared with many consumer app subscriptions. A lot of apps train users to expect monthly pricing in the single digits or low tens of dollars. But Shokken is not priced like a consumer note-taking app or a filter pack. It is a business operations tool, and its costs scale with real restaurant usage.

There are two ways to justify price:

  • the value the customer receives
  • the cost required to provide the service sustainably

The value argument belongs mostly in marketing. I believe Shokken can reduce host-stand friction, improve guest communication, and help busy restaurants move through waitlists more cleanly. That is the customer-facing story.

For App Review, I think the stronger answer is the cost side.

The backend is not a single free hobby server. Shokken uses Supabase, and I maintain multiple environments so development, testing, and production are separated. That costs more than pointing every change straight at production, but it is also the responsible way to run software that businesses may depend on. The product also has web surfaces hosted through Netlify and deployed through GitHub workflows, and those costs are part of keeping the guest-side QR experience available.

The largest variable cost is SMS.

When a guest joins a waitlist, Shokken may send a welcome notification. When a table is ready, it sends another notification. When the waitlist entry is called, canceled, or otherwise resolved, there may be another notification. For a busy restaurant, that can become hundreds of guests and potentially thousands of messages across busy service windows.

Consumer phone plans make text messaging feel free because they flatten normal personal use. Business transactional messaging does not work that way. At volume, text messages are paid per message. Shokken’s customer sees a flat subscription, but I absorb the variance underneath it.

That is the explanation Apple needs: the price is not a vanity number. It is an attempt to provide predictable billing to restaurants while covering backend, hosting, deployment, and messaging costs on my side.

Short-term access is not meant to be an auto-renewing subscription

The fourth review category is the minimum subscription duration.

Apple’s feedback says the minimum duration for a subscription is seven days. That matches the standard auto-renewable subscription options in App Store Connect. The confusing part is that Shokken also offers shorter one-day and three-day access options for users who do not need a full month.

The product reason is simple. A restaurant or event organizer may only need the paid messaging-heavy features for one busy event, one weekend, or one short operating window. Asking that user to buy a $200 monthly subscription just to cover one event is not the product experience I want to create.

I also do not want Shokken’s business model to depend on people forgetting to cancel something they do not use. If a customer has recurring need, a monthly or quarterly subscription makes sense. If the use case is temporary, short-term access should exist.

After rereading the guideline, I believe the issue may be terminology. The seven-day minimum applies to standard auto-renewing subscriptions. The shorter Shokken options are intended as non-renewing, short-term access. So my plan is not to remove them just to slip through review. My plan is to explain the distinction clearly, and if needed, adjust the wording so the reviewer understands that these are one-time access products rather than auto-renewing subscriptions.

That may still come back for another round. But the difference matters enough that I want to defend the product shape instead of immediately flattening everything into a weekly minimum.

Account deletion had the largest implementation footprint

The most concrete product requirement was Guideline 5.1.1(v), data collection and storage.

Apple requires that if an app allows account creation, it must also provide a way for users to delete their account. Shokken requires accounts because an operator needs an identity to manage restaurants, waitlists, paid access, and the associated data. So the requirement applies.

The simple version of the task is “add a delete account button.” The real version is larger.

The app has to initiate the request from an authenticated user. That request has to include a bearer token. The backend has to ingest the token, verify it, authorize the request, identify exactly which user is asking for deletion, and then delete the right records.

The deletion itself also cannot be a careless database wipe. Some records should go because they are user-owned account data. Some records may need to remain for auditing, billing, or operational integrity. So the implementation has to distinguish between “data that belongs to this user and should be removed” and “records the system must retain for legitimate reasons.”

That creates a bigger blast radius than the review text suggests:

  • app UI for starting account deletion
  • authenticated request handling
  • backend token verification
  • authorization checks
  • cascade deletion of user-owned records
  • retention of records that should not be removed blindly
  • testing the unhappy paths, not only the success path

That work is now done. It is also a feature the app should have had eventually anyway. Apple just moved it from “later” to “before iOS production.”

Feature flags are the release-process debt

The remaining complication is not one of Apple’s guideline bullets. It is my release process.

While the review loop was happening, development did not stop. I started adding new functionality. That is normal, but Shokken currently does not have feature flags. Anything that lands in the app is effectively on. If I submit a corrected binary to Apple, any half-finished feature inside that binary needs to be ready, tested, and acceptable for production review.

That is the cost I am paying now.

The immediate goal is to finish the in-progress work quickly enough that I can submit a clean binary without dragging the review loop out much longer. After that, I want to add configuration management and feature flags. I am looking at ConfigCat for that role, similar to how RevenueCat handles the revenue side of the product.

With feature flags in place, I can ship a binary that contains code for future functionality while keeping unfinished paths disabled in production. That would make future review cycles less brittle, because a submission fix would not have to wait for every unrelated in-progress feature to become user-ready.

That is the release-management lesson of the week: store review is easier when the app can separate “included in the build” from “enabled for users.”

Next Week

Next week is about getting this review response over the line. I need to finish any in-progress app work that is already in the binary, submit the corrected build and metadata, and give Apple clear answers for the pricing, access-duration, terms, and account-deletion items.

After that, feature flags become the next infrastructure priority. I do not want future App Store fixes to be blocked by unrelated unfinished features. Once iOS review is moving again and release controls are cleaner, I can return to the broader launch work: store listing polish, outreach material, and getting Shokken in front of real operators.