Last Week
Last week was about simplifying the iOS review surface. After several rounds of App Store review friction over Shokken’s one-day and three-day paid access options, I removed the short-duration products from the submitted build and kept the iOS purchase path to a monthly subscription. That was not the product shape I originally wanted, but it made the submission easier for Apple to evaluate and reduced the chance that the same subscription-duration argument would keep blocking the app.
That decision worked, but not immediately.
The review process still found a way to stay messy. Even after the app binary no longer referenced the short passes, App Store Connect still seemed to carry stale review state around those products. The result was another round of rejections before the app finally cleared review.
This week, after six rejections and seven total attempts, the iOS app was approved.
iOS Finally Cleared Review
The iOS app is now ready to be published.
That sentence took a lot longer to write than I expected.
Google approved Shokken for Android weeks ago, and the app has been available on Google Play. Apple’s process took much longer. Some of the earlier review issues were straightforward: metadata, required links, account deletion, and explanations around pricing. Those were annoying but understandable. The sticky issue was always the short-duration access model.
The original product idea was simple. Shokken has monthly and quarterly subscriptions for restaurants that use it regularly. But I also wanted one-day and three-day options for businesses or events that only need waitlist tooling for a short window. If someone needs Shokken for a weekend, forcing them into a full month is not ideal.
Google accepted that model. Apple did not.
The disputed part was the difference between auto-renewing subscriptions and non-renewing subscriptions. Apple’s published guidance clearly gives a minimum duration for auto-renewing subscriptions, and that minimum made sense. Charging someone an auto-renewing daily subscription would be a bad product pattern. But the one-day and three-day Shokken products were not auto-renewing. They were meant to be limited access windows.
App Store Connect also allowed those non-renewing products to be created with durations shorter than a week. That made it reasonable to think the model was valid.
Review disagreed. Repeatedly.
After several attempts to explain the distinction, I gave up on preserving the short-pass model for the first iOS release. I removed the one-day and three-day products from the app and submitted the monthly-only flow.
Then Apple rejected it again because their review system still appeared to expect the removed products to be present.
The final fix was more aggressive: I deleted the problematic short-duration product entities from App Store Connect entirely. That burned the product identifiers, which I had tried to avoid, but it also cleared the review path. A couple of days later, Apple approved the app.
What does it mean in English?
Shokken has finally cleared Apple’s review process.
The Android app was already live. The iOS app was stuck because Apple kept objecting to short-term paid access options. I tried to explain why those options should be allowed, then tried removing them from the app, and finally had to delete the old short-pass products from App Store Connect so Apple’s review system would stop treating them as part of the submission.
The first iOS release will be simpler than planned. It will not include the one-day and three-day paid access options. For now, the clean path is monthly access.
That is a compromise, but it is the right one. Shokken needs to reach users. I can revisit short-term access later with a different product setup, but getting the app approved on iOS matters more than continuing to argue about product taxonomy.
Nerdy Details
The seventh attempt was the approval
I counted six rejections before the approval finally landed.
That does not mean every rejection had the same cause. Some review items were legitimate product and compliance requirements. Account deletion needed real implementation. Pricing needed explanation. Store metadata needed cleanup. Those were normal parts of getting a production iOS app through review.
The repeated blocker was the short-duration paid access model.
The frustrating part was not only the rejection itself. It was the mismatch between three different signals:
- Apple’s written guidance described the seven-day minimum in the auto-renewing subscription context.
- App Store Connect allowed short non-renewing subscriptions to be created.
- App Review treated the short non-renewing products as unacceptable anyway.
I still think that mismatch is confusing. If a product type is not allowed in practice, the tooling should not make it look valid. If the tooling allows it, the review response should explain the hidden rule clearly.
Instead, the review loop mostly produced canned responses.
That made the process harder than it needed to be. When I sent a response explaining the distinction and pointing to Apple’s own guidance, the next rejection still came back with the same copied policy text. There was not enough detail to tell whether the reviewer disagreed with the interpretation, missed the distinction, or had an internal rule that was not visible in the public documentation.
Eventually Apple did call, and the reviewer confirmed the stance: for this review, the products needed to be at least seven days if they were represented as subscriptions. At that point, the policy argument was no longer useful.
The product compromise came first
The first compromise was removing the short passes from the app.
That meant the iOS paywall no longer offered one-day or three-day access. The app binary only exposed the monthly subscription. From a product perspective, that is less flexible. From a review perspective, it should have made the submission simpler.
But App Store review is not only the binary. It also includes App Store Connect state: in-app purchase products, subscriptions, metadata, review attachments, and whatever internal submission record Apple is evaluating.
That is where the next problem showed up.
Apple rejected the build because the one-day and three-day products were still associated with the submission somewhere, even though the app no longer showed them. From the reviewer’s point of view, the product list said those products were part of the submission, but the binary did not expose them. That mismatch was enough for another rejection.
That was technically fair if their review record still included those products. The problem was that I was trying to remove them from the submitted product surface, and App Store Connect did not make the remaining hidden association obvious.
Removing from sale was not enough
The next attempt was to mark the short-duration products as removed from sale.
That seemed like the right intermediate step. I did not want to delete the product entities permanently because product identifiers are not reusable. Once an App Store product ID has been created and deleted, that identifier is effectively burned. If I later decide to bring short-term access back, I would need new identifiers.
That matters because product IDs are part of the long-term billing surface. They show up in code, RevenueCat configuration, backend mappings, analytics, support notes, and documentation. I had chosen a naming convention that made sense. Deleting those products meant losing those clean names forever.
So I tried the softer move first: remove the products from sale and remove them from the submission.
Apple still rejected the app with the same response.
At that point, I had removed the references from the app, removed the products from sale, and tried to keep them out of the submitted review package. The reviewer still seemed to be seeing them. That suggested either stale submission state or a product association I could not cleanly reason about from the App Store Connect UI.
Recreating the submission still did not clear it
The next move was the nuclear option: remove the entire app submission and create a new one.
The theory was reasonable. App Store Connect submissions gather a bundle of things for review: the app binary, metadata, in-app purchases, subscriptions, and other associated state. If the old submission had stale references to the one-day and three-day products, then creating a fresh submission should have given me a clean review packet.
So I recreated the submission and made sure not to include the problematic short-duration subscriptions.
It still came back with the same rejection.
That was the point where I stopped trying to preserve the old product records.
The hydrogen-bomb option, as I described it in the transcript, was deleting the one-day and three-day non-renewing subscription entities from App Store Connect entirely. Not delisting. Not removing from sale. Actually deleting the product records.
That finally worked.
Deleted product IDs are a real cost
Deleting the product records was not free.
App Store Connect and Google Play both treat product identifiers as durable. Once an identifier is used, it is not something you can casually recycle later. If I delete a product and later decide I want the same product shape again, I cannot rely on being able to reuse the same clean identifier.
That is why I avoided deletion for as long as I did.
The short-pass identifiers were named deliberately. They fit a pattern. They were easy to search, easy to map, and easy to understand. Throwing them away means any future replacement will have to use a different naming pattern, probably with a suffix or version marker that exists only because of this review fight.
That is annoying, but it is not fatal.
The bigger point is that store configuration has long-term consequences. Product identifiers are not just labels in a dashboard. They become part of the integration contract between the store, the revenue backend, the app, and the server. Even if the current implementation is simple, a messy product catalog can create confusion later.
I still chose deletion because the alternative was staying stuck.
Shipping beat perfect taxonomy
The lesson here is not that the original short-pass idea was bad.
I still think short-term access makes sense for Shokken. A restaurant may need the app every day, but an event operator may only need it for a weekend. A one-day or three-day access product matches that use case better than a monthly subscription.
The lesson is that launch sequencing matters.
Short-term access is valuable, but it is not more valuable than getting the app onto iOS at all. If preserving that pricing option keeps the whole app out of the App Store, then the option is not helping users. It is blocking them from trying the product.
So the first iOS release will be simpler. Monthly access first. Short-term access later, if and when it is worth rebuilding the purchase model in a way Apple will accept.
That later version may use consumable in-app purchases instead of non-renewing subscriptions. The App Review phone call suggested that approach would be acceptable. But implementing it properly would touch App Store Connect, RevenueCat, app code, backend entitlement logic, purchase recording, idempotency, and expiration handling.
That is real work. Now that the app is approved, I can decide whether that work belongs before or after the first real wave of users.
Approval changes the next problem
Now the problem changes.
For weeks, the iOS question was “how do I get past review?” Now it becomes “how do I launch this well?”
That means the marketing work from last week becomes much more urgent. The app needs a better explanation for people who have not followed the build process. It needs a promotional video. It needs website copy that shows the host workflow clearly. It needs social material that can explain the value in a few seconds instead of assuming the viewer already understands waitlist operations.
This is a different kind of work, but it is not optional. Approval is only permission to publish. It does not create users by itself.
The next phase is about turning an approved app into something people can discover, understand, and try.
Next Week
Next week I want to talk about the new promotional-video process I have been developing.
The App Store approval removes the biggest platform blocker, so the focus now shifts toward launch material: website updates, demo clips, short social videos, and a clearer customer-facing explanation of what Shokken does. If everything goes well, the first promotional video should be the center of next week’s update.