Last Week

Last week was the first real lesson in how App Store review works once an app is technically ready but not yet submission-ready. Apple rejected the first iOS production submission with two issues: one about explaining the business model more clearly, and another about how I had described data use in a way that implied present-day marketing behavior the app does not actually perform. I fixed both, resubmitted, and expected that the next step might simply be waiting for the queue to move again.

That was optimistic.

This week Apple came back with a second rejection, and this one was much more substantive. The new review raised several additional issues, including another privacy explanation problem, questions about the pricing structure for the paid subscription tier, and a more structural problem with how I had modeled the shortest subscription duration. So instead of moving from “paperwork cleanup” back into normal product work, I ended up discovering that part of the monetization setup itself needs another round of investigation and redesign before iOS production access is going to happen.

The Review Escalated From Copy To Product Design

The headline this week is not that Apple rejected the app again. The headline is that the shape of the rejection changed.

Last week’s rejection was irritating, but it still felt like the sort of thing that could be resolved by tightening language and being more precise about what the app currently does. This week’s rejection moved deeper into the product itself. Apple now wants clearer explanation of how data is handled, clearer justification for the subscription pricing, and changes to the subscription setup that are not just a matter of editing a sentence in App Store Connect.

That distinction matters because it changes the kind of work in front of me.

If the problem were only wording, the fix would mostly be administrative: revise the explanation, make sure it accurately reflects the current software, and send the submission back. But once review feedback reaches pricing structure, entitlement duration, and in-app purchase configuration, the blast radius gets much larger. Those choices are wired into the app UI, the purchase system, the entitlement logic, and the way the business model is presented across platforms.

So this week became less about “ship a feature” and more about “understand exactly what Apple is objecting to, what is actually required by the platform, and how far the fix propagates through the stack.”

That would already be a meaningful week of work on its own, but it also collided with real life. I have friends visiting now and again over the next several days, which means this was never going to be a big implementation sprint. The result is that Week 66 is mostly a diagnosis week: understand the rejection, map the consequences, and set up the next round of work so the third submission has a better chance of sticking.

What does it mean in English?

Apple is no longer just asking me to explain the app more clearly. It is now questioning whether the paid part of the app is shaped correctly for iOS in the first place.

That does not mean the whole product is broken. It means the business rules I chose for the paid tier do not fit neatly into Apple’s store model yet.

Shokken is not a consumer entertainment app where the price can be detached from operating cost. It is a business tool that can trigger real backend and messaging expenses, especially when SMS is involved. That is why the paid tier exists at all. But Apple still wants that pricing to be legible and justified inside its subscription framework.

The most important practical consequence is that my shortest subscription option was modeled around a one-day minimum, while Apple’s standard auto-renewable subscription system starts at one week. Once that mismatch shows up in review, it is not just a pricing tweak. It forces a rethink of how licenses are packaged, how purchases are represented, and how entitlements flow through the rest of the system.

Nerdy Details

The second rejection is more useful than the first one

The obvious emotional reaction to a second rejection is annoyance, and yes, I felt that. But from a product-delivery perspective, this rejection is also more useful than the first.

The first pass mainly taught me that Apple review is incremental. It did not hand me a complete inventory of everything that still needed work. It handed me the first blocking set of issues. That means a resubmission is not necessarily “one step away from approval.” It may simply unlock the next layer of scrutiny.

That appears to be exactly what happened here.

Once the first two issues were cleared, Apple looked farther into the submission and found the next set of concerns. In one sense, that is frustrating because it stretches the timeline. In another sense, it is helpful because it reveals the real shape of the platform requirements. The dangerous version of this process would be getting approved while still misunderstanding how the paid tier should work on iOS. A rejection is slower, but it is also clearer.

So I am trying to interpret this week correctly. This is not “the app keeps failing mysteriously.” This is “the review system is progressively exposing the parts of the business and subscription model that are still under-specified.”

Privacy review is still about precision, not aspiration

One of the repeated themes from the transcript is privacy explanation.

That is not surprising after last week. Apple wants a very literal accounting of what data the app uses, why it uses it, and how that use maps to the categories in App Store Connect. If I describe the software too broadly, or describe a possible future use instead of a present one, I create obligations I may not actually need yet.

So even though this week’s rejection was more substantive overall, part of the lesson remains the same: compliance language should describe the current app, not the app I might build later.

For Shokken, that matters because the data in question is tied to real restaurant workflows. Phone numbers and account details are not decorative metadata. They exist because the product needs to identify operators, identify guests, and trigger real communications. That makes the justification straightforward in principle, but only if I explain it narrowly and accurately.

The store-review problem starts the moment I get sloppy. If I imply broader tracking, broader marketing usage, or some other future-state behavior that is not part of the current release, then Apple reviews the app against that larger claim. That is how a small wording mistake turns into a much larger compliance surface.

Apple is also reviewing whether the pricing makes sense

The new wrinkle this week is that Apple questioned the price tier itself.

From my side, the pricing is not arbitrary. Shokken is a business application, not a mass-market consumer utility, and parts of the paid functionality carry ongoing operating cost. If a restaurant uses SMS notifications, that cost is not hypothetical. Twilio charges money. The backend costs money. Payment infrastructure costs money. A paid tier exists because there is real variable expense underneath the feature set.

That logic makes sense to me because I built the system and I know exactly where the costs come from. A reviewer does not have that context automatically. They see a subscription price and ask the obvious question: why does this app cost this much?

That means the job is not merely “set a number that covers costs.” The job is also “make the pricing legible in the context of the platform.” Apple is effectively asking for the product story behind the number. Why is this not cheap consumer software? Why is the subscription structured this way? What business reality is the tier paying for?

Those are fair questions, even if they are inconvenient.

The deeper lesson is that app-store pricing is partly technical and partly narrative. I can have a defensible pricing model internally, but if I cannot explain it clearly to the platform reviewer, then the submission is still incomplete.

The real blocker is the mismatch between a one-day license idea and Apple’s subscription model

The hardest issue in this week’s rejection is the duration problem.

My shortest paid tier had been modeled as a one-day subscription. That made sense from a business perspective because it creates a low-friction way for a restaurant to pay only when it actually needs the messaging-heavy functionality. But Apple’s standard auto-renewable subscription model does not work that way. The base durations start at one week, not one day.

That is where the review feedback became more than paperwork.

What makes this especially annoying is that App Store Connect exposes shorter durations in other subscription-related screens, which can make it look like “one to three days” is available as a normal product shape. But those short durations belong to introductory offers and related pricing mechanics, not to the core duration of the subscription itself. So from the product-builder side, it is very easy to think the platform supports a shorter base period more directly than it actually does.

Once I realized that, the problem stopped being “Apple is being picky” and became “I need to redesign this around the actual subscription primitives the store provides.”

That redesign is not conceptually impossible, but it has consequences:

  • I can raise the minimum duration to something iOS actually supports, which changes the economics and the value proposition.
  • I can rely more heavily on free evaluation licenses or manually granted access for short-term use cases, which changes the onboarding story.
  • I can revisit whether the public subscription model should be framed around weekly or longer operating windows instead of daily usage.

None of those are one-line fixes. They all affect how the paid tier is explained, sold, and enforced.

Why the blast radius is large

The transcript explicitly mentions that this is not just an app-code change, and that is exactly right.

If I change the minimum subscription duration, I am not just swapping a number in a settings screen. I am potentially changing:

  • the App Store product definitions
  • the RevenueCat configuration and entitlement mapping
  • pricing copy inside the app
  • backend assumptions about how long a paid license lasts
  • any manual support or “trial access” flow I use for serious evaluators
  • cross-platform consistency between Android, iOS, and any website explanation of the pricing model

That last point is especially important.

Cross-platform products get awkward fast when “the same subscription” means different things depending on which storefront you happened to use. If Android allows one model and iOS forces another, I need to choose whether to keep them divergent or normalize them around the stricter platform. Divergence may preserve flexibility, but it also increases support complexity. Normalizing the tiers keeps the product easier to explain, but it may force the Android side to adopt constraints it did not originally need.

That is why I called the blast radius large. The change propagates through product design, technical integration, pricing communication, and support operations all at once.

Week 66 was a scoping week, not a shipping week

The final honest detail is that I did not get much implementation done this week.

Part of that is the nature of the problem. Before changing anything, I need to understand which pieces are genuinely required by Apple, which pieces are configuration mistakes, and which pieces are just ambiguous tooling that I interpreted too generously.

The other part is simpler: my schedule this week was not built for a deep engineering sprint. I had friends visiting, and I expect that to continue into the coming week as well. That means the right move is not to pretend I am about to brute-force a multi-system billing redesign in a couple distracted evenings. The right move is to leave myself a clean, accurate problem statement and then attack it properly once the calendar opens back up.

That is less satisfying than shipping a feature, but it is still real progress. A well-scoped fix beats a rushed, partially understood fix every time, especially when app-store billing and compliance are involved.

Next Week

The next real work window is going to be about turning this rejection into a concrete remediation plan and then executing it without making the subscription system messier than it already is.

That means tightening the privacy explanation again, deciding how the iOS-paid tier should work now that a one-day base subscription does not fit the platform, updating the RevenueCat and entitlement plumbing that depends on that decision, and preparing a third App Store production submission once the model is coherent again. If I can come out of the next normal stretch of work with a cleaner pricing story and a review-ready subscription setup, then this rejection will have been painful but productive.