Last Week
Last week stepped away from the App Store review loop and focused on how I manage AI coding agents while building Shokken. The practical point was simple: agents can be useful, but they have to be treated like contributors, not trusted like deterministic tools. Clear instructions, tests, CI, and review are what make their output usable.
That tooling discipline still matters, but this week moved straight back to the iOS submission path. Android is already released and usable through Google Play. iOS has been stuck behind repeated App Store review rejections, mostly around Apple’s insistence that the short-duration paid access products need to satisfy a seven-day minimum.
After spending several weeks arguing the distinction between auto-renewing subscriptions and non-renewing access, I decided to stop fighting the interpretation and simplify the app for review.
The Third Resubmission Is In
The iOS app has been resubmitted.
This is the third resubmission, and the meaningful change is that I removed the short-duration paid access options from the app. The one-, two-, and three-day passes were the source of the review fight, so they are no longer part of this submission. For now, the app only keeps the monthly subscription path.
That is not the product shape I originally wanted.
The short passes existed for a real reason. Shokken can be useful for restaurants and event operators that only need paid waitlist tooling for one specific service window, one busy weekend, or one short event. A one-day or three-day access product matches that use case more naturally than a full monthly subscription.
But the App Store review process has become the bottleneck. Apple repeatedly rejected the app over the duration issue. I still think there is a disconnect between the written policy and how the review team is enforcing it for this submission, but continuing to argue that point would mean losing more time.
So the review surface is now smaller. One monthly subscription. No short passes. No non-renewing duration debate. No consumable-pass implementation in this build.
The third review request is with Apple now. At this point, the question is whether removing the contested products clears the blocker or whether the review process finds another issue.
What does it mean in English?
I made the iOS version simpler so Apple has less to object to.
The Android version is already live. The iOS version has been delayed because Apple kept rejecting the short-term paid access options. Instead of continuing to debate whether those short passes should be allowed, I removed them from this submission and kept only the monthly subscription.
That means the first iOS release may be less flexible than I wanted. A business that only needs Shokken for one weekend will not have the short-pass option immediately on iPhone. But getting the app approved matters more than preserving every pricing idea in the first release.
Once the app is through review, I can revisit short-term access with a cleaner plan. For now, the goal is to get Shokken onto the App Store.
Nerdy Details
The review problem became a product-scope problem
The original issue looked like a policy interpretation problem.
Shokken had short-duration paid access options. I treated those as non-renewing subscriptions because they represented limited-time access and did not renew automatically. The written App Store language appeared to put the seven-day minimum in the auto-renewable subscription context, and App Store Connect allowed short non-renewing products to be created.
Apple’s review team did not accept that interpretation.
After multiple rejections and a phone call with App Review, the practical reality was clear: whatever the taxonomy says, the iOS submission was not going to pass while those products were represented that way. Last week, the fallback plan was to rebuild the short passes as consumables. That would preserve the short-term access model while changing the App Store product type.
This week, I chose an even smaller first move: remove the short passes from the review build entirely.
That decision changes the problem from “design a more complex billing path” to “reduce the iOS launch surface.” It is not as satisfying from a product perspective, but it is much more direct as a release tactic.
Removing features can be the fastest release strategy
There is a common temptation during review problems to preserve the ideal product shape at all costs.
That can be the right call when the feature is essential. If Apple were objecting to the core waitlist workflow, I would not simply remove waitlists from the app. But the short passes are not the core product. They are a pricing and access option. Useful, important, and worth revisiting, but not required for the app to be valuable on day one.
The monthly subscription still lets a restaurant use Shokken. It still supports the main operational story: managing a waitlist, communicating with guests, and replacing a more awkward host-stand process. The first iOS release can ship with that simpler business model.
That matters because every week stuck in review has a cost. The app cannot collect real iOS user feedback. The website cannot point iPhone users to a production App Store listing. Marketing has to explain around the missing platform. The product looks less finished than it is.
So the release strategy is now pragmatic: remove the contested access paths, get the app through review, and then decide how to reintroduce short-term access once the baseline iOS presence exists.
The simplification still needs to be coherent
Even a simplification has to be done carefully.
If the app only offers monthly access, then every visible piece of the purchase flow needs to agree:
- the paywall should only present the monthly subscription
- App Store Connect should not expose confusing short-duration products for review
- RevenueCat offerings should map cleanly to the monthly option
- app copy should not promise one-day or three-day access
- backend entitlement checks should still recognize the active monthly subscription
- review notes should explain the simplified purchase path plainly
The danger is leaving behind stale product language. If a screen, review note, or metadata field still references short passes, the reviewer may continue down the same rejection path or become confused about what the submitted app actually sells.
This is where the release checklist matters. Removing a product option is not only removing a button. It is making sure the app, store metadata, purchase configuration, and support copy all describe the same thing.
Why not implement consumables immediately?
The consumable-pass idea is still reasonable.
It may end up being the right long-term way to sell short access on iOS. A consumable product can represent a one-time purchase that Shokken turns into a fixed access window on the backend. That model would require server-side purchase recording, expiration handling, idempotency around transaction processing, and careful paywall copy.
But that is exactly why I did not want it to be the blocking change for this resubmission.
Consumable passes are not just a product-type swap. They touch the app, RevenueCat, the backend, and the database. They also create edge cases: buying another pass before the current pass expires, restoring purchase state, handling failed backend recording, avoiding duplicate grants, and making sure the access window behaves consistently across devices.
Those are solvable problems, but they are real implementation work. Doing all of that while the iOS app is still not approved would turn the review blocker into a larger billing project.
For this submission, the simpler move is better. Ship the iOS app with the monthly subscription. Get production access. Then revisit short-term access without making it the thing standing between Shokken and the App Store.
Marketing is becoming the next workstream
With the third resubmission in Apple’s hands, the next major workstream is marketing.
That means the product website needs another pass. The site has to explain Shokken clearly to someone who has not followed seventy-four weeks of development updates. It needs sharper demo material, more focused short-form videos, and clearer social content.
This is a different mode of work from backend code or store review responses. It is not enough for the app to exist. Operators need to understand what problem it solves, why it is worth trying, and how to start.
The marketing material needs to answer practical questions quickly:
- What does Shokken replace?
- How does a guest join the waitlist?
- What does the host see?
- How do notifications work?
- What does paid access unlock?
- Why is this better than the current process?
The website, demo videos, and social posts should all reinforce the same answer. That is the next direction for the project: less internal explanation, more customer-facing clarity.
The next phase is less about building and more about packaging
The app is not done forever, but the shape of the work is changing.
Earlier weeks were dominated by implementation: backend workflows, mobile UI, store submission requirements, CI, account deletion, billing setup, and release infrastructure. Those pieces still matter, and there will be more engineering work, especially around short-term access if it comes back.
But the immediate question is no longer only “can I build the thing?”
It is also:
- can I get it approved?
- can I explain it?
- can I make the first customer journey obvious?
- can I show the value quickly enough for someone to try it?
That is a different kind of product work. It is still concrete, but the output is demo footage, website copy, launch messaging, and social material instead of just code.
The third resubmission gives me a useful point of transition. While Apple reviews the simplified iOS build, I can stop waiting passively and start improving the surfaces that will matter once both platforms are available.
Next Week
Next week depends partly on Apple’s response.
If the simplified monthly-only submission clears review, the focus shifts quickly toward App Store availability and launch communication. If Apple rejects it again, I will have a narrower rejection to respond to because the short-pass issue should no longer be present in the build.
Either way, the next direction is marketing: updating the website, producing demo and short explanation videos, and starting to build social content that explains Shokken to people who have never watched these weekly updates.