Does Apple give you 24 hours to remove a reported comment?

That number is not in guideline 1.2. The guideline asks for timely responses to concerns without naming a deadline, so treat the 24 hour figure you see quoted online as a convention rather than a rule. Building a queue you genuinely check daily is a safer reading than promising an hour count you cannot keep.

Should comments be flat or threaded?

Flat or one level of replies for almost every app. Both are a single read, and one level is enough to show who is answering whom on a phone. Unlimited nesting needs a recursive read or a stored path per row, a collapse control and a plan for deep threads, which is a lot of work for a shape most readers never use.

Does a hosted comment service make you compliant?

No. It gives you the tooling, not the obligation. Google Play asks apps hosting user generated content for three things: users accept terms before posting, those terms define and prohibit objectionable content, and the app provides in-app reporting and blocking of content and users. Action has to be taken on what gets reported. That stays attached to your listing whoever renders the comments.

When should you not add comments at all?

When readers do not need to see each other. If you want a signal, reactions give you one with nothing to moderate. If you want feedback, a form only you read has no public abuse surface. Comments are worth their moderation cost when the conversation between users is the product, and not much before that.

Articles · App ExamplesUpdated September 2026

Add comments to an app and you have also signed up to moderate them.

Q: What does Apple guideline 1.2 require for user generated content?

Four things. A method for filtering objectionable material from being posted, a mechanism to report offensive content along with timely responses to concerns, the ability to block abusive users, and published contact information so users can reach you. Apple also states that removing violating content is your responsibility, and that repeated problems can cost you the app and the developer account.

To add comments to an app you need one table, one list screen and one input box. A comment row is an author, a target, a body and a timestamp, and that half is genuinely an afternoon. The other half is what has to exist before Apple will approve the build: a way to filter objectionable material, a report mechanism, a block button and published contact details. That asymmetry is why social app builders ship moderation tooling instead of leaving it to you.

This page covers the four columns a comment row needs and what guideline 1.2 demands before review will pass. Then what reply depth costs you, and when buying a comment system or skipping it beats building one.

See what reply depth costs

The short version

The posting is one table, the removing is the whole job.

A comment needs an author id, a target id, a body and a created timestamp. Add a parent id if you want replies and a soft delete flag so a removed comment does not orphan the ones under it. That schema is an hour of work and it is not where the time goes.

The time goes into everything around it. A signed in author you can ban. A report button on every comment. A block list that actually filters the feed. Something that catches the obvious material before it posts. And a contact address in your store listing. Apple names four of those in guideline 1.2, and review does check for them.

What the stores ask for the day you turn comments on

Start here, because it decides whether the feature is worth building at all. Apple covers user generated content in guideline 1.2 of the App Store Review Guidelines. It names four things an app with user generated content or social networking must include. A method for filtering objectionable material from being posted. A mechanism to report offensive content, with what Apple calls “timely responses to concerns”. The ability to block abusive users. And published contact information so users can easily reach you.

Two details change how you plan. Apple does not name a deadline for acting on a report. The word in the guideline is timely, so the twenty four hour rule people repeat in forums is not in the text. The other detail is that filtering is written as filtering material from being posted. That reads as something running before the comment goes live, not a cleanup you promise later. A word filter plus a hold queue for flagged posts satisfies it. A delete button in your own admin panel, on its own, probably does not.

Apple also puts removal of violating content on you, and says repeated problems can cost the app and the developer account. So the real price of comments is not the screen. It is somebody's attention, every week, for as long as the app is live. Deciding who may delete a comment is the next question after that, and it turns quickly into a permissions model rather than a comments feature.

Apple App Store Review Guidelines, 1.2 User-Generated Content

A comment is four columns, plus one decision about replies

The row itself is small: who wrote it, what it is attached to, the text, and when. Everything else is optional and you can add it later. An edited timestamp if you allow edits. A status field if you run a moderation queue. A soft delete flag, which matters more than it sounds, because hard deleting a comment that has replies under it leaves the replies talking to nobody.

The decision that is painful to reverse is reply depth. Flat is one read and one ordered list. One level of replies is still one read, grouped by parent id in memory and indented once. That covers almost everything a phone screen can usefully show. Unlimited nesting needs a recursive read or a stored path on every row, plus a collapse control, plus an answer for what the twelfth level looks like on a narrow screen. Pick one level unless you know you need more.

Counts are the other quiet cost. A comment count next to every item in a feed is one extra query per item. The fix is a counter on the parent row that you adjust when a comment is written or removed. Skip it and a list that was fast with test data takes four seconds with real data, which is the same trade you meet all over mobile app database design.

Sort order deserves ten minutes too. Newest first is cheap and honest. Best first needs votes, votes need their own table, and votes bring their own abuse story with them.

Try it

What reply depth costs you

Depth is the one comment decision that is expensive to change later.

Signed in, rate limited, and live only if you need it

A comment needs an author you can act on. Anonymous posting is not a shortcut, it is a moderation problem deferred, because a block button needs something to block and a ban needs something to ban. Accounts come first, so if that part is not built yet, add user login is a prerequisite rather than a follow up.

Rate limiting is the cheapest protection you will write. One comment every few seconds per account, a cap per hour, a length limit, and a rule that a brand new account waits before it can post. None of that needs machine learning and all of it fits in an afternoon. It handles the flood case, which is the abuse pattern you are most likely to meet first.

Live updates are optional and most apps do not need them. Pull to refresh, plus inserting your own comment into the list the moment you send it, feels live enough for a comment thread. A realtime subscription per open thread costs a connection per reader and a bill that grows with attention, which is the worst moment for a surprise. Add it when people ask for it, not before.

Build it, buy it, or ship without it

There are three honest options. Build the table and the screens yourself, which is roughly a week once the report and block flows are in, and leaves you owning the data. Buy a hosted comment service, which gives you moderation tooling on day one and puts your users' text in somebody else's database. Or ship no comments at all, which is the right answer more often than it sounds.

Buying does not move the obligation off you. Google Play's user generated content policy asks apps that host UGC for three things. Users accept terms of use before they can post. Those terms define objectionable content and prohibit it. And the app runs moderation that includes in-app reporting and blocking of both content and users, with action taken on what gets reported. It is your listing and your developer account whichever vendor renders the list.

Skipping is a real option, not a cop out. If what you want is a signal, reactions carry most of it and there is nothing to report or block. If what you want is feedback, a form only the author reads has none of the public abuse surface. Comments earn their cost when readers need to see each other. They do not earn it when you just need to hear from people.

Google Play, User Generated Content policy

What each way of adding comments actually gives you

Approach	Working in a day	You own the comment data	Report and block included	Still your compliance job
Your own table and screens	about a week	Yes	No	Yes
Hosted comment service	Yes	No	Yes	Yes
Reactions only, no free text	Yes	Yes	nothing to report	little to moderate
Comments on your website only	Yes	Yes	your web stack	not in-app UGC
Ship without comments	Yes	none to own	not needed	No

Building the comment feature into your own app

Build order matters more than the stack here. Get the row, the list and the post box working first, because that is the part you can demo. Then add report, block, soft delete and a rate limit before anyone outside the team sees it. Those are the parts a reviewer looks for, and the parts you cannot retrofit calmly at two in the morning.

Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own. It runs that project on a cloud iPhone or Android simulator while it builds, then ships it to TestFlight and to Google Play internal testing. It is $25 a month with no free plan, and iOS builds need your own Apple Developer account. Where the comments are stored is a choice you make rather than something bundled, so settle that before you describe the screens.

What Newly is good for here is the boring half at speed: the list, the input, the empty state, the report sheet, the block confirmation, the moderation queue nobody enjoys drawing. The code comes out as a ZIP from Settings, or through two way GitHub sync from the Deploy tab, so nothing is trapped if the feature outgrows the first version.

Questions people ask about adding comments

Store one row per comment with an author id, the id of the thing it is attached to, the body and a created timestamp. Add a parent id if you want replies. Then build the list screen, the input box, a report action, a block action and a soft delete. The storage is an hour. The moderation half is most of the week.

Describe the thread, including who gets to delete a comment

Write down the reply depth, the report flow and the block rule before the first screen, then build the comment feature with all three in it from the start.

Start building