Apple does not hold a keynote for every App Review Guidelines edit. It publishes a short developer news note, updates the page, and a few weeks later people start seeing rejections for things that used to pass.

That is what happened this year. On June 8, 2026, Apple listed the guideline changes in plain terms: a new paragraph in 1.2 on who is responsible for violating user-generated content, clarified 4.3(a) and 4.3(b) on spam and lookalike apps, and an explicit note in 4.5.3 that Live Activities may not be used to spam, phish, or send unsolicited messages. Those are the June changes. A February 6 note had already put random and anonymous chat under 1.2. None of that is “write a new feature.” Most of it shows up in what your product page says, what your screenshots show, and whether a reviewer can tell your app apart from the twenty others in the same category.

This is not a screenshot-size guide or a keyword list. It is what the 2026 text actually says, where it touches the listing, and what is worth fixing this week — without stretching Apple’s words into a panic.

Why the June update is different from a wording tweak

Most guideline revisions are clarifications. The June 8 note is still a clarification, but 4.3(b) now says something the older spam language did not: Apple may remove apps that are already live.

The current text, on Apple’s guidelines page, is specific. Dating, flashlight, sound effects, wallpaper, simple timer, and fortune-telling apps are “well established.” New submissions in those categories are not accepted unless they offer a meaningfully different or improved experience. Apple “may remove these apps from the App Store going forward if they are not updated, improved, or do not attract customers.” A second set — drinking games, Kama Sutra, fart, and burp apps — is called mediocre or low-effort; repeated submissions of that kind may lead to removal from the Apple Developer Program, not just a single-app rejection.

That is a real shift for those categories. It used to be mainly a gate at submission. It is now also a reason an existing app can come down. It is not a rule that every unused listing on the store is about to be purged. Apple named the categories. Stay inside that list when you talk about removal risk.

A separate, older line in Before You Submit still applies to everyone: if the app no longer functions or you are no longer supporting it, it can be removed under App Store Improvements. That is maintenance, not the 4.3(b) saturated-category language.

What actually changed in 2026

Short version, without the legal-document cadence. Each item below is either in Apple’s June 8 changelog, an earlier 2026 news post, or the live guideline text.

Guideline 4.3(b) — spam and lookalike apps (June 8, 2026). Apps that are “indistinguishable from what’s already widely available” can be rejected. Existing apps in the named well-established categories can be pulled if they go stale or fail to attract customers. If your app does the same job as fifty others, the guideline is asking you to prove a different experience — in the binary and in the listing a reviewer opens first.

Guideline 1.2 — user-generated content (February 6 and June 8, 2026). The February note put random and anonymous chat under 1.2. The June note added a paragraph on developer responsibility. The live rule still requires a filter, a report path with timely responses, blocking abusive users, and published contact information. Apple also states it is your responsibility to remove content that violates the guideline, your terms, or your community standards. A report button that nobody monitors is not enough.

Guideline 4.5.3 — Live Activities (June 8, 2026). Apple clarified that you may not use Apple services to spam, phish, or send unsolicited messages, and it named Live Activities alongside Game Center and Push Notifications. If the Lock Screen or Dynamic Island is doing promotional work the user did not ask for, that is the clause to re-read. It is not a ban on legitimate, time-sensitive Live Activities.

Third-party AI disclosure — guideline 5.1.2(i). This sentence is in the current guidelines and was not part of the June 8 changelog: you must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so. Pair that with 2.3 Accurate Metadata, which already says privacy information, the description, screenshots, and previews must match the app. If the app sends user text or photos to an external model, say so in the privacy materials and in the consent flow — not only as “smart AI-powered” in the subtitle.

Subscriptions — guideline 3.1.2(c). This is not a 2026 rewrite. Before a customer subscribes, you still have to describe what they get for the price, and Schedule 2 of the license agreement still covers term length, auto-renewal, the amount billed, and how to cancel. It belongs in a listing audit because reviewers and users both see the mismatch when the paywall is vague and the product page is silent.

Platform and questionnaire requirements (separate from the June guideline edit). Since April 28, 2026, uploads to App Store Connect must be built with Xcode 26 and the iOS 26 (or matching platform) SDK. Beginning September 2026, Apple requires answers to the age rating questionnaire’s social media questions when you submit a new app or an update. That is not a free-form “short questionnaire.” It asks whether the app redistributes, amplifies, or lets people interact with user-generated content through a social feed or similar discovery method.

A reviewer — or an automated check — still starts from the same three questions: what does this app do, who is responsible for what happens inside it, and are you being straight about data and pricing. The 2026 edits make those questions easier to fail if the listing is generic.

Where this shows up on your listing

Title and subtitle need a specific job. Guideline 2.3.7 already asks for a unique name and accurate keywords, and it bars unverifiable claims in the subtitle. “Photo Editor Pro” or “Simple Notes App” is the 4.3(b) problem in metadata form: a reviewer could swap your name with a competitor’s and nothing would change. Name the audience, the workflow, or the one thing the app does that the template next to it does not. That is title and subtitle work, not a rebrand for its own sake.

The description has to earn its claims. If the app uses AI, say what happens to the user’s input. “Smart AI-powered” with no explanation is both weak conversion copy and a 2.3 accuracy problem. If data leaves the device for a third-party model, 5.1.2(i) is the rule — disclosure and permission — not a marketing adjective.

Screenshots should show the current app. Guideline 2.3.3 says screenshots should show the app in use, not title art, a login wall, or a splash screen. 2.3 also says to keep them up to date. Template-looking carousels with a logo swap do not, by themselves, trigger 4.3(b). They do make it harder to argue the app is “meaningfully different,” and they fail the accurate-metadata test. Retake them on the current OS. How to create App Store screenshots that convert covers layout; the compliance bar is simpler: show the real UI.

App Privacy has to match collection. Users see privacy labels before they download. Reviewers compare them to behavior. A mismatch is a fast 5.1 / 2.3 rejection that has nothing to do with visual design. Audit this when you add SDKs or AI features, not only at launch. If you want a second pass on metadata and listing gaps, Analyze My App scores a live store URL in a few minutes. It will not replace a privacy-legal review; it will flag the obvious listing holes.

Subscription terms belong in the purchase flow. 3.1.2(c) is in-app: price, what you get, that it renews, how to cancel — before the customer pays. 2.3.2 also says the description and screenshots should indicate when featured items need a purchase. Echoing price and period on the product page helps conversion; burying the only honest terms in a legal URL is what gets apps rejected.

Keep supporting the app, and keep the listing current. In the named 4.3(b) categories, Apple’s own words are “updated, improved, or do not attract customers.” For every app, 2.3 says metadata should stay current. Screenshots from two OS versions ago read as abandoned even when the binary still works. That is a conversion problem everywhere, and a removal risk in the categories Apple listed — not a documented auto-takedown for a quiet productivity app.

A practical audit you can run this week

Go through the live listing and answer these honestly:

• Could someone swap my app’s name for a close competitor’s and not notice a difference in the description?
• Does the privacy label match what the app collects today, including any third-party AI?
• If the app uses AI, is that described in plain language — what it does with input, and whether data is shared off-device?
• Do screenshots show the actual current UI, on the current OS, with the app in use (2.3.3)?
• If I sell a subscription, can a user see price, period, auto-renewal, and how to cancel before paying (3.1.2(c))?
• If there is chat, comments, or posts: is there a report path, do we act on reports, can users block people, and is contact information published (1.2)?
• Have I answered the age rating social media questions in App Store Connect? From September 2026, a submission can stall without them.
• When did I last ship an update or refresh the listing? In a 4.3(b) category, a long gap is the thing Apple said it may act on.

Most of this is copy, screenshots, App Store Connect toggles, and a notes-for-review paragraph that actually describes new behavior (2.3.1(a) rejects generic “bug fixes” notes when you shipped real features).

Where this gets tedious (and where a tool actually helps)

Understanding the June 8 note takes twenty minutes. Making title, subtitle, description, keywords, screenshots, and privacy answers say the same accurate thing in every localization takes an afternoon per market if you do it by hand.

That is the part Nakxi is built for — listing work, not App Review lobbying:

• Analyze My App and the metadata audit pull the live listing and show weak or generic metadata.
• Metadata AI drafts titles and descriptions that name a specific job instead of category filler, inside Apple’s character limits. See how to generate metadata with AI if you want the workflow, not just the button.
• The App Store screenshot generator rebuilds screenshots from the current UI so you are not shipping a mockup from last year.
• If you maintain more than one language, App Store localization is where the same accuracy problem multiplies. The localization guide is the longer version of that.

None of those tools approve your app. They shorten the listing pass Apple already expects under 2.3 and 4.3(b).

The takeaway

The 2026 guideline edits are not asking most teams to build a new product. They are asking you to be specific and current about the one you have — especially if you sit in a category Apple named under 4.3(b), ship UGC, use Live Activities, or send data to third-party AI.

Spend an afternoon on the checklist above. Read the live guidelines if a clause in this post might apply to you; Apple’s page is the source, not this article. A listing that matches the app is cheaper than a rejection, and it usually converts better too.