Guideline 4.3
Guideline 4.3(b) - Design - Spam: Drinking Game App Without Significant Value
Our Take
Apple is applying its categorical enforcement stance against drinking games, not making a judgment about your app's quality or polish.
Since 2022, App Review has folded "alcohol-encouraging party apps" into the 4.3(b) spam bucket — the same catch-all it uses for saturated, low-differentiation categories (fart apps, flashlights, wallpaper dumps, basic BMI calculators). The subtext is that Apple already considers the drinking-game category oversupplied and reputationally risky, and it overlaps with Guideline 1.4.3 (Physical Harm), which prohibits apps that encourage excessive alcohol consumption. The phrase "we encourage you to reconsider the app concept and submit a new app" is Apple's strongest template language short of removal — it signals that no amount of polish, age-gating, or disclaimer will make the current concept approvable.
This is largely a semi-automated / pattern-driven rejection. Review tooling and reviewers flag on surface signals: the words "drink," "shot," "sip," "chug," "beer," "boozy," "Kings Cup," "Ring of Fire" in your app name, subtitle, keywords, description, screenshots, icon, and in-app card text; a 17+ rating with "Frequent/Intense Alcohol, Tobacco, or Drug Use" declared; and category placement in Games > Party or Entertainment.
Setting a 17+ rating does not create a safe harbor here — it actually increases detection probability. Note also that the rejection cites 4.3(b), not 4.3(a): Apple is not saying you cloned another app; it is saying the concept itself lacks differentiated value on the store.
The root cause is the business model, not the implementation. So the guiding question — what is the fastest compliant path to approval that preserves the business model? — entails a repositioning, not an appeal.
The underlying value you actually sell is social party entertainment: prompts, dares, group play, custom decks. Alcohol is the theme layer, not the product. If you strip the drinking mechanic and replace penalties with neutral forfeits (points, dares, truth-or-dare, mini-challenges, elimination), you keep the retention loop, the paywall, and the content library intact while removing the one element Apple categorically refuses. Most successful recoveries in this category ship as a general party/social game with genuinely added depth (multiplayer sync, user-generated decks, moderation) rather than as a re-skinned drinking app.
One critical warning: do not ship a "clean" build and re-enable drinking content post-approval via remote config, a server-side flag, or a downloadable content pack. That converts a 4.3(b) rejection into a 2.3.1 hidden-features violation, which carries app removal and, in repeat cases, developer account termination. Whatever you remove must stay removed, including strings sitting unused in the binary and in non-English localizations, which reviewers do search.
Resolution Guide
Decide honestly whether the app is "primarily" a drinking game
Open your own app and count: of the default game modes shown on first launch, how many instruct users to drink? If the answer is most or all of them, Apple is factually correct and appealing will burn a review cycle. If drinking is one optional mode behind a toggle among many, you have a legitimate Path B clarification. Choose one lane before writing anything.
Strip alcohol from all store metadata first
Remove "drink," "drinking," "drunk," "shots," "beer," "booze," "boozy," "pong," "Kings Cup," "Ring of Fire," "pre-game," "power hour" from the app name, subtitle, keyword field, promotional text, description, and What's New. Replace the icon if it depicts bottles, cans, cups, or shot glasses. Re-shoot every screenshot that shows drinking prompts.
Replace the drinking mechanic with a neutral forfeit system
Change every "Take 3 sips" / "Everyone drinks" / "Finish your drink" card into a non-consumption consequence: points, a dare, a truth question, a mini-challenge, a timed task, or elimination. Keep the same card count, pacing, and social loop — you are changing the penalty layer, not the product. Audit every content pack, including IAP-locked decks and every localization; reviewers search binary strings.
Purge residual alcohol references from the binary and assets
Search your codebase for alcohol-related strings, asset names, analytics event names, deep links, achievement titles, push notification copy, and Localizable.strings across all languages. Unused-but-present strings have triggered repeat rejections. Also remove any external links to drinking-game websites, TikTok/Instagram accounts branded around drinking, or a support site whose copy still sells the app as a drinking game.
Reset the age rating and content declarations
In App Store Connect, set "Alcohol, Tobacco, or Drug Use or References" to None (or Infrequent/Mild only if genuinely present as passing reference). Leaving a 17+ alcohol declaration on a supposedly clean build is a direct contradiction that guarantees re-rejection.
Add genuine differentiation so 4.3(b) doesn't re-fire on "low value"
Even a clean party game can be re-rejected as generic. Ship at least one substantive capability before resubmitting: real-time multiplayer or cross-device sync, user-created custom decks with sharing, player profiles and progression, an AI-generated prompt engine, accessibility support, or moderated community content. Document these in the reviewer notes as the app's unique value.
Decide: same app record or new app record
If the change is a reposition (same bundle ID, new positioning), keep the record and submit as a new version with a thorough reviewer note explaining the change. If Apple has rejected the same bundle two or more times under 4.3(b) with "submit a new app" language, a fresh app record with a new name, icon, and positioning has materially higher approval odds — but never as a duplicate alongside the old one.
Write reviewer notes that pre-empt the objection
In App Review Information → Notes, state plainly: what the app is now, that all alcohol references and drink-based penalties have been removed, what the differentiating features are, and exact steps to reach them. Include a test account if any feature is gated.
If you are taking Path B (misclassification), reply in Resolution Center instead of resubmitting blind
Provide numbered reproduction steps to the core, non-alcohol experience, name the specific screens, and attach screenshots. Ask for re-evaluation of whether the app is "primarily" a drinking game. Do not argue about other apps on the store.
Escalate only after one clean, substantive attempt
If a genuinely repositioned build is rejected again under 4.3(b), file an appeal at the App Review Board (developer.apple.com/contact/app-store/?topic=appeal). Lead with the concrete diff — what was removed, what was added — not with fairness arguments.
Prevention
Example Rejection Email
Consider Appealing
Appeal as a first step ONLY if drinking is genuinely not the primary experience — for example, the app is a party/trivia/prompt game with many modes and a single optional alcohol-themed toggle that is off by default, and the reviewer generalized from one screen. In that narrow case, reply in Resolution Center with: (1) a one-line statement of the app's core purpose, (2) a list of default game modes with the count that involve alcohol, (3) numbered reproduction steps to the core non-alcohol experience, (4) screenshots of the default first-run flow, and (5) a request for re-evaluation of the 'primarily' determination. Offer to remove the optional mode entirely as a same-day fix — signalling flexibility often resolves it in one cycle. If drinking penalties are the central mechanic, do not appeal; Apple's stance is categorical and an appeal will only cost a review cycle. Reposition and resubmit instead.
Before & After
App name is "Drink Roulette – Party Drinking Game" with keywords including "drinking game, shots, beer pong, kings cup" and screenshots showing cards that read "Take 3 sips."
App name is "Roulette Party – Group Game Night" with keywords like "party game, dares, group games, icebreaker" and screenshots showing cards that read "Take 3 points" or "Do a 10-second dare."
What changed: Metadata and screenshots are the primary detection surface for 4.3(b) alcohol enforcement, so removing them stops the rejection from re-firing automatically.
Card deck penalties are drink-based: "Everyone drinks," "Finish your drink," "Take a shot," "Waterfall," distributed across all 300 cards including the paid deck.
The same 300 cards keep their setup and humor but end in neutral forfeits: point deductions, timed dares, truth questions, or elimination — applied consistently across free and IAP decks.
What changed: The social loop, content volume, and paywall are preserved while the specific mechanic Apple prohibits is eliminated.
Build ships clean but a Settings toggle labeled "Classic Mode" or a remote config flag re-enables drinking cards after approval.
All alcohol content is fully removed from the binary, content packs, and server responses, with no toggle, promo code, or remote flag capable of restoring it.
What changed: Hidden or remotely re-enabled prohibited content escalates a design rejection into a 2.3.1 violation carrying app removal and potential account termination.
App Store Connect age rating is set to 17+ with "Frequent/Intense Alcohol, Tobacco, or Drug Use" declared, while reviewer notes claim the app has no alcohol content.
Age rating questionnaire updated so alcohol references are set to None, matching a build and metadata that contain no alcohol content.
What changed: A contradiction between declared content and claimed content is treated as inaccurate metadata and triggers immediate re-rejection.
The repositioned app is a generic prompt-card party game with no features beyond shuffling a static deck.
The app adds user-created custom decks with share codes, real-time multiplayer sync across devices, and player profiles with session history, all called out in reviewer notes.
What changed: 4.3(b) also covers low-differentiation apps, so removing alcohol without adding substance can produce a second rejection under the same guideline.
Community Solutions · 0
Sign in to share your solution.
More Guideline 4 (Design) rejections
- Guideline 4.0 - Design: App Does Not Include iOS Features
- Guideline 4.0 - Design: App Looks Like a Website
- Guideline 4.0 - Design: Apple Pay Button Not Following Guidelines
- Guideline 4.0 - Design: Blurry Icons or Low-Resolution Assets
- Guideline 4.0 - Design: Broken Layout on iPad
- Guideline 4.0 - Design: Content Clipped by Notch or Safe Area