Last Week
Last week was about the infrastructure underneath the release process. My old self-hosted GitHub runner had filled its disk with Docker leftovers, so I replaced the single persistent runner with a fixed pool of disposable runner containers on a larger Proxmox-backed Ubuntu VM. That made the CI/CD setup cleaner, less congested, and better suited for the heavier checks I want to keep adding around Shokken.
The product goal did not change, though. Android is already live on Google Play. iOS is still waiting on App Store production approval. After finishing the fixes from Apple’s second rejection, I submitted the next iOS review request last week. This week, Apple responded much faster than before, but the result was still another rejection.
The important difference is scope. The previous rejection had several issues. This one only repeated one: Apple’s reviewer still objected to the one-day and three-day paid access options.
The App Is Ready; Review Is Not
This week was not really about new development. The development work needed for the current iOS submission is done. The remaining blocker is App Store review.
That is frustrating, but it is also progress. A month ago, Apple’s second rejection included several categories of feedback: metadata cleanup, terms placement, price explanation, account deletion, and the short-duration paid access model. I addressed those items, submitted the app again, and got a response in two or three days. This time, Apple only called out the short-duration access issue.
The repeated objection is that a subscription cannot be shorter than seven days.
That rule exists, but the important distinction is the type of purchase. Apple’s current App Review Guidelines put the seven-day minimum in the context of auto-renewable subscriptions. Apple’s App Store Connect reference also separates auto-renewable subscriptions from non-renewing subscriptions, which are limited-duration products that do not renew automatically.
Shokken’s one-day and three-day options are intended to be short-term, non-renewing access. They are not meant to trap a restaurant into a recurring subscription. They exist because the real-world use case is sometimes short.
A restaurant may only need heavier waitlist tooling for one special event, one busy weekend, one festival, one pop-up, or one seasonal rush. Asking that operator to buy a full monthly plan when the need is temporary makes the product worse. It also creates the kind of subscription behavior I do not want Shokken to depend on: people paying for time they do not need because cancellation friction works in the seller’s favor.
So I responded to Apple again and pointed directly at the relevant distinction. Hopefully the reviewer accepts that explanation. If the next response is the same rejection for the same reason, I will probably stop arguing the point and change the purchase model to fit the review path more plainly.
What does it mean in English?
Apple is treating Shokken’s one-day and three-day paid access like a subscription that renews automatically. If that were true, Apple’s seven-day minimum would apply.
But that is not the product I am trying to sell. The short options are closer to temporary access passes. A business pays for a limited operating window, uses the app for that window, and then access ends unless they buy more time.
The difference matters because Shokken is not a consumer entertainment subscription. It is an operations tool. Some customers may need it every day and should use a monthly or quarterly plan. Others may only need it for a specific event. The app should support both cases without forcing everyone into a long recurring plan.
The practical problem is that App Review does not necessarily preserve all of that context between submissions. If each reviewer sees “one day” and “subscription” and stops there, the app can keep failing even when the intended model is allowed. At that point, the question becomes less about being technically correct and more about choosing the product shape that gets Shokken through review.
Nerdy Details
The rejection got narrower
The first useful signal is that the rejection got smaller.
The second App Store rejection was broad enough that it required a real cleanup pass. Some items were metadata problems. Some were explanation problems. Account deletion required actual app and backend work. The short-duration access issue was always the most ambiguous because it touched product model, App Store product taxonomy, review language, and the way the paywall presents paid access to a reviewer.
This latest response only repeated that last category.
That does not mean everything else is permanently solved, because future reviewers can always notice something new. But it does suggest the previous round of fixes moved the submission forward. The remaining argument is now concentrated around one question: can Shokken sell one-day and three-day non-renewing access on iOS?
That is a much better problem than six unrelated review failures. It is still a blocker, but at least it is now a single blocker.
The short passes are a product decision, not a loophole
The one-day and three-day options exist because of how the product is used.
Shokken is a waitlist management app. It replaces buzzer-style workflows with phone-based notifications and gives hosts a cleaner way to manage waiting guests. That can be a day-to-day operational tool for a restaurant, but it can also be useful for temporary situations:
- a Mother’s Day brunch rush
- a weekend pop-up
- a food truck event
- a tasting event
- a festival booth
- a seasonal rush where paid messaging is only needed briefly
For those cases, a monthly plan is not always the right shape. The customer is not asking for a month of service. They are asking for a short, intense operating window where queue management and guest communication matter.
The short passes also make the pricing more honest. Shokken has real variable costs, especially when SMS notifications are involved. If a business wants the paid communication-heavy features for a short event, a short access product lets me charge for that usage without asking the customer to maintain a recurring plan.
That is the opposite of subscription dark pattern thinking. I am not trying to get someone into a recurring charge and hope they forget about it. I am trying to give them a bounded purchase that matches a bounded need.
The Apple distinction is easy to lose in review
The tricky part is that the word “subscription” carries a lot of meaning inside App Store review.
An auto-renewable subscription is the familiar App Store subscription model. The user buys access for a period, and unless they cancel, it renews. Apple has strict presentation requirements around those products: price clarity, renewal language, cancellation visibility, cross-device availability, and a minimum subscription period.
A non-renewing subscription is different. It gives access for a limited duration, but it does not renew automatically. The app is responsible for managing the access period and making sure the user understands what they bought.
That distinction is exactly why the review response matters. If the reviewer sees the products as auto-renewing subscriptions, the one-day and three-day durations look invalid. If the reviewer sees them as non-renewing access passes, the product model makes sense.
There are a few ways this can go wrong:
- the App Store product configuration may not make the distinction obvious enough
- the paywall copy may use the word “subscription” too broadly
- the review note may not point clearly enough to the non-renewing model
- a new reviewer may not read the previous message thread closely
- the reviewer may apply the auto-renewing rule conservatively whenever paid access is time-limited
That last point is the operational reality. I can write the clearest explanation possible, but I cannot choose the reviewer. Each submission can land with someone different, and that person may not carry forward the whole history of the discussion.
So the response has to be concrete. It cannot just say, “this should be allowed.” It needs to explain that the short products are non-renewing, identify the relevant guideline distinction, and describe the business reason for limited-duration access.
Changing the purchase model has a real blast radius
If Apple rejects the app again for the same reason, the fallback is to change the purchase model.
That sounds like a product decision, but it is also an implementation project.
RevenueCat sits between the app and the store billing systems. It manages offerings, packages, customer entitlements, and purchase state. If I change the product model, the RevenueCat configuration has to change. Product identifiers may need to change. Offerings may need to change. Entitlement durations may need to change. The paywall has to present the new shape clearly and consistently.
Then the app code has to follow.
The client needs to request the right offering, render the right packages, show the right copy, handle purchase success, restore access, and display expiration state correctly. If one-day and three-day products become something else on iOS, I also need to decide how much platform-specific behavior I am willing to carry. Android can already support the current shape, but a product model that differs too much between platforms can confuse users and complicate support.
The backend is involved too. Shokken uses Supabase for the server-side pieces, and the backend cannot simply trust that the client UI is correct. It needs to understand whether a tenant has paid access, when that access expires, and what features should be available. If product durations or entitlement names change, the backend checks and any scheduled cleanup or expiration logic have to remain aligned.
The test surface grows from there:
- purchase flow succeeds on iOS
- restore flow works
- expiration state is correct
- the backend grants and removes access at the right time
- the paywall copy matches the actual billing behavior
- Android does not regress
- the review build does not expose stale product language
That is why I do not want to change the model casually. It is not just editing a label from “three days” to “one week.” It touches the revenue backend, App Store Connect, paywall UX, mobile code, and server-side access control.
Being right may still be slower than being reviewed
The uncomfortable part is that a correct interpretation is not always the fastest launch path.
I believe the short non-renewing access model is the better product. I also believe the App Store rules distinguish between auto-renewing subscriptions and non-renewing limited-duration access. But if the review loop keeps returning the same answer, there is a point where defending the ideal shape becomes less useful than shipping.
That does not mean immediately flattening the product into something worse. It means being pragmatic about the constraint. If Apple will not accept the short passes as currently presented, I need to decide whether to:
- rename and reframe the products more aggressively as passes
- move the short-duration options out of the initial iOS launch
- replace them with a weekly minimum on iOS
- simplify the first iOS release and revisit short access after approval
None of those options is perfect. But review approval is now the gate between Shokken and iOS users. The app cannot help anyone on iPhone while it is sitting in App Review limbo.
That is the tradeoff for next week if Apple does not accept the response.
Marketing cannot wait for perfect platform symmetry
The other decision this week is that I am not delaying marketing any longer.
Android is live. iOS is not in production yet, but TestFlight exists. That is enough to start talking to people.
The plan is to begin making short-form content about why Shokken exists, what problem it solves, and how restaurant operators can try it. For Android users, the path is straightforward: install from Google Play. For iOS users, the path is less elegant, but still workable: join the TestFlight beta until the App Store version clears review.
That is not the perfect launch funnel, but waiting for perfection has its own cost. Marketing is not a switch I can flip after approval and expect immediate results. It is another system that needs iteration: message, format, hook, audience, follow-up, and conversion path.
Starting now lets me learn which explanations actually land. It also gives early iOS users a reason to tolerate the extra TestFlight step. If someone is willing to try Shokken before the production App Store release, I can make that worthwhile with generous early access terms and direct support.
The review process is still important, but it cannot be the only thing happening. If I wait for every platform detail to be perfectly aligned before I start outreach, I lose another week without learning anything from real operators.
Next Week
Next week depends on Apple’s response.
If the reviewer accepts the explanation, the path is simple: keep the iOS submission moving and prepare for production availability. If the app is rejected again for the same one-day and three-day access issue, I will stop spending time on the interpretation fight and change the purchase model enough to get through review.
In parallel, I am starting the marketing work anyway. That means short-form videos, clearer calls to action, and a practical path for Android users, iOS TestFlight users, and early testers who are willing to try Shokken before the App Store story is fully resolved.