Why an adult classifieds app will never clear App Store review, and what to build instead
Sooner or later, whoever runs a classifieds directory asks the question every mobile founder asks in the first few months: should this have an app. It feels like the obvious next step. An icon on the home screen, push notifications for a new message or a verified listing, something that reads as more serious than a website. Someone on the team wraps the site, files it, and a few days later gets a rejection that has nothing to do with a bug or a missing privacy label. It is rejected for what the business is, not for anything that can be patched and resubmitted.
That is the part worth understanding before any development time goes into it. Apple and Google do not decide app by app whether your particular directory is well run, well moderated, or fully compliant with the law in your country. They decided years ago, in writing, that this category of business does not belong on their platforms, full stop. What follows is what the rules actually say, why there is no configuration of a clean, legal, age-verified marketplace that gets around them, and what a mobile presence looks like that does not depend on either company changing its mind.
What the rules actually say
Apple's App Store Review Guidelines address this directly under Objectionable Content, section 1.1.4. The wording is not vague: apps may not contain "overtly sexual or pornographic material," and the guideline goes on to say this "includes 'hookup' apps and other apps that may include pornography or be used to facilitate prostitution, or human trafficking and exploitation." Notice what that sentence is doing. It is not banning explicit images, which a classifieds directory does not need to show anyway. It is banning apps that facilitate prostitution as a function, regardless of how the listings are worded or cropped. A directory of tasteful, fully clothed profile photos and a booking form is still an app that facilitates the thing the guideline names.
Google Play's policy is, if anything, more explicit about naming the category. Its rule on sexual content states that Google does not allow apps or app content that "promote or solicit a sexual act in exchange for compensation," and the policy lists as a specific example apps that "promote sex-related entertainment, escort services, or other services that may be interpreted as providing or soliciting sexual acts in exchange for compensation." Escort services are named directly, not implied. Google goes a step further and separately bans "compensated dating or sexual arrangements where one participant is expected or implied to provide money, gifts, or financial support to another participant," the arrangement commonly called sugar dating. That extra clause exists because operators tried to describe the same business using softer language, and Google closed that gap specifically rather than leaving it to interpretation.
It is worth seeing why ordinary dating apps are unaffected by any of this. Tinder, Bumble and similar apps stay on both stores because nothing about their advertised function involves compensation for a sexual arrangement. That is the line both platforms draw, and it is a functional line, not a tone-of-voice line. A dating app can be as sexually charged as its marketing wants, and a classifieds directory can be as clinical and business-like as its own founders want, and the outcome does not change, because the question being asked is not "does this look respectable" but "does this facilitate paid sexual arrangements." A directory answers yes to that question by design, which is the entire product.
Why there is no clever way around it
New operators tend to try one of two things before accepting this. The first is describing the app in vague, category-agnostic language in the store listing, calling it a "social discovery" or "premium companionship" app while the actual functionality still matches the banned pattern once a reviewer opens it. This does not work, because review teams for both stores open the app, click through the flows, and in ambiguous categories will typically create a test account and browse listings the way a real user would. A polished description does not change what the reviewer sees on screen thirty seconds later.
The second attempt is a split: a "clean" app that only browses profiles, paired with a web checkout or an external link where the actual booking or payment happens, on the theory that keeping compensation off-app avoids the rule. This misreads what both policies are actually testing for. Apple's guideline on user-generated content apps is written broadly enough to catch apps that exist primarily to funnel users toward the restricted activity even if the transaction itself completes elsewhere, and outbound links get followed during review specifically because this pattern is common across many restricted categories, not just this one. An app that exists to browse a roster of paid companionship listings is the app being reviewed, not the payment step at the end of it.
There is a second cost to attempting either workaround that matters more than a single rejection. A straightforward rejection, where the app is honestly categorized and simply falls under a content rule, is treated by both platforms as exactly that: a rejection. Describing an app one way in its metadata while it functions another way once installed reads differently to a review team, closer to an attempt to mislead them than an honest miscategorization. Apple's developer agreement gives it broad grounds to act against an account for dishonest or deceptive submissions, separate from and more serious than an ordinary content rejection, and a pattern of resubmitting a disguised version of the same rejected app is the kind of pattern that escalates. The realistic risk is not that one rejected app disappears. It is that a developer account tied to a company name, a bank account and every other app registered under it gets pulled at once, over an app that was never going to be approved regardless of how it was described.
None of this is a judgment on the underlying business, which can be entirely legal, well moderated, and properly age-verified in its own jurisdiction and still fail this test, because the test has nothing to do with legality or moderation quality. It is a private company's product policy, and the policy is written to exclude the category outright rather than to evaluate individual operators inside it.
What to build instead
The alternative is not a downgrade chosen for lack of budget. It is the only mobile presence a directory in this category can actually keep long term, because it is not rented from a company that has already stated, in writing, that it will not have you. A mobile web app, built with a web manifest and a service worker, can be added to a phone's home screen with its own icon, opens full screen without browser chrome, and behaves like an installed app from the user's point of view. None of this passes through Apple's or Google's app store review, because it is not distributed through either store. The content rules that apply to apps in their marketplaces simply do not apply to a website, which is governed by far lighter and more general browsing rules on both platforms.
Push notifications close most of the remaining gap with a native app. Web push on Android is mature and works the same way a native notification does. On iOS, home-screen web apps have been able to receive push notifications since version 16.4, which by now covers essentially the entire active iPhone install base. A user who adds the directory to their home screen can get a notification for a new message, a listing approval, or a completed verification step exactly as they would from a downloaded app, without either company ever reviewing, approving, or being able to pull that experience.
This also removes a dependency that is structurally identical to a problem operators already face with infrastructure providers: a platform whose terms are public, whose answer is already known in advance, and which can end the relationship on its own schedule regardless of how the business conducts itself. An app store listing for this category is not a slow-burn risk that might materialize after a policy review. It is a guaranteed rejection with a searchable, quotable rule behind it, which makes it one of the easier infrastructure risks to simply avoid rather than manage.
What operators should actually decide
The first decision is not technical. It is whether an app was ever going to solve the problem it was meant to solve. Founders usually want one of two things: a way to feel discoverable the way mainstream apps are discoverable, or a way to send push notifications without asking a browser for permission. App store search is not a realistic discovery channel for this category regardless of approval, since a listing this specific would be removed before it ranked for anything, so the discoverability argument does not actually hold even in the best case. The organic and direct traffic strategies that already work for a classifieds directory are unaffected by whether there is a native app, because none of them route through app store search in the first place.
There is one narrower category worth knowing about, since it is genuinely different from a public marketplace app and is sometimes viable: an operational tool for verified advertisers to manage their own listing, messages and account, not exposed to public search and not itself displaying a browsable directory of paid companionship to app store users. This sits closer to ordinary business software, and while it still needs a careful read of the current guidelines before anyone submits it, since the line depends on exactly what the app shows and to whom, it is not automatically caught by the same rule that blocks a public-facing directory app.
For everyone else, the answer is to stop treating the missing app icon as something to apologize for or eventually fix. Build the mobile web experience properly instead: a fast, installable site with a real manifest, a working add-to-home-screen prompt shown at a sensible moment rather than on page load, and push notifications a user actually opts into. That is not the fallback option here. It is the only mobile strategy that does not end with a rejection letter and, if pushed hard enough, an account termination notice for a business that was never going to be let in.
