Apple’s own App Review Guidelines say the company may remove existing dating, flashlight, wallpaper, sound-effects, simple-timer and fortune-telling apps from the App Store if they are not updated, improved, or do not attract customers. The wording sits in Guideline 4.3(b), the App Store’s spam clause, and it reaches apps already published, not only new submissions.
Key facts
| Item | Detail |
|---|---|
| Guideline | 4.3(b), titled Spam |
| Source | Apple’s App Review Guidelines, developer.apple.com |
| App categories named | Dating, flashlight, sound effects, wallpaper, simple timers, fortune telling |
| What it allows | Removal of already-published apps in those categories, not just rejection of new ones |
| Reported timing | The removal wording is reported to have arrived with a guidelines update around June 8 to 9, 2026 |
| Separate, harsher clause | Repeated low-quality submissions can cost a developer their whole Apple Developer Program account |
What the guideline says, verbatim
Certain kinds of apps, such as dating, flashlight, sound effects, wallpaper, simple timers, and fortune telling, are well established on the App Store and we will not accept new submissions unless they offer a meaningfully different or improved experience. We may remove these apps from the App Store going forward if they are not updated, improved, or do not attract customers. Other kinds of apps, such as drinking games, Kama Sutra, fart, and burp apps, are mediocre, low-quality, or low-effort and do not add value to the App Store. Repeated submissions of this kind may lead to removal from the Apple Developer Program.
That is Apple’s complete text for Guideline 4.3(b) as published on its developer site, which carries no last-updated date of its own.
Two different consequences, not one
| Category | What the guideline allows | Named examples |
|---|---|---|
| Well-established, low-differentiation apps | Removal of the app itself from the App Store | Dating, flashlight, sound effects, wallpaper, simple timers, fortune telling |
| Mediocre or low-effort apps | Removal from the Apple Developer Program if resubmitted repeatedly | Drinking games, Kama Sutra, fart and burp apps |
The first group can lose an app that is already live and already has users, simply for going stale. The second group risks something larger, losing the developer account entirely, but only after repeated low-effort resubmissions rather than for one existing app going unmaintained.
Don’t miss the best of The Mac Observer
Set us as a preferred source and our Apple reporting ranks higher in your Google Search results and Discover feed — one tap, no account changes.
Why this line reads differently in 2026
Dating apps sit in the same removal clause as flashlight and wallpaper utilities, categories with far lower stakes for the companies that make them. Match Group, whose dating apps are among the most widely used on the platform, is one of many members of the Coalition for App Fairness, the advocacy group behind a separate September 8 open letter to the European Commission about Apple’s App Store terms. The guideline text makes no reference to that letter, to Match Group, or to any specific company, and nothing here should be read as Apple targeting a category for that reason.
The guidelines apply worldwide and sit alongside Apple’s other developer-facing changes this year, including the iOS 27 release arriving Monday, September 14, and the platform’s iPhone Duo hardware, which developers are separately adapting apps for.
What Apple has not said
Apple has not published a change log entry singling out the removal language added to 4.3(b), has not defined “attract customers” with a number or metric, and has not said whether any app has actually been removed under this specific clause. Apple’s guidelines page carries no revision history a reader can check independently.
Developers in the named categories can review the current guidelines text directly at Apple’s developer site at any time; Apple typically updates guidelines without a public announcement, so checking the page itself, especially around the September 14 iOS 27 release, is the only reliable way to catch a change before it affects a published app.
