Apple's review guidelines can add a new rule at any time

The workload

A solo founder shipping an iOS SaaS app has to read and satisfy Apple's App Review Guidelines before every submission and every update, not once, because Apple revises the document without a public changelog. The document is organized into five numbered sections, Safety, Performance, Business, Design and Legal, and a solo team is expected to self-audit each of these before submission, since App Review does not send back an itemized checklist before rejection; it sends one after. For a subscription SaaS app specifically, the workload concentrates in section 3.1, which covers payments, and its subsection 3.1.2 on auto-renewable subscriptions.

What the documents show

Apple's own currently published App Review Guidelines state, verified from the text retrieved 16 September 2026, that the document 'is a living document; new apps presenting new questions may result in new rules at any time,' language that appears in the guidelines' introductory section. Section 3.1.1 requires that any unlocked feature, subscriptions included, use Apple's in-app purchase system rather than an app's own payment mechanism. Section 3.1.2(a) requires that an auto-renewable subscription 'provide ongoing value' and that 'the subscription period must last at least seven days' and work across a user's devices. A second Apple page, its own submissions guidance, corroborates the living-document framing by directing developers to 'get acquainted with the App Review Guidelines early on' during development, implying the rules read while building may not be the rules Apple applies at review.

The operating cost

The guidelines themselves carry no published fee; the cost is compliance labor plus the commission structure Apple enforces through section 3.1.1, a percentage of subscription revenue set out in Apple's separately published terms and not reproduced in this entry. What the guidelines add procedurally, verified, is the requirement that a solo developer build the purchase flow around Apple's own StoreKit APIs rather than a payment processor of their choosing, which is a build cost, not a percentage fee, and one that recurs whenever Apple updates the section.

The stop condition

The guidelines name no expiration or review interval; Apple states only that changes can occur 'at any time.' This is an editorial stop condition, not one the source states directly: a solo operator's practical trigger for re-reading the guidelines is any App Store Connect rejection message that cites a specific guideline number, since that is the clearest notice Apple gives that its interpretation has shifted.

• Does the purchase flow route every unlockable feature through Apple's in-app purchase system, with no exceptions the guidelines would flag?
• Has the guidelines text been re-read since the last submission, given Apple states it can change without a changelog?
• Is the subscription's seven-day minimum period and cross-device availability requirement met before submission, not discovered after rejection?

The guidelines are not a static contract. They are Apple's own account of what it will check for, updated on a schedule it does not publish, and a solo developer's only defense is treating every submission as a fresh reading rather than a repeat of the last one.