Most comment UI references are drawn for a web page: a wide column, deep indentation, a vote widget on the left, a rich text editor at the bottom. None of that survives a phone. On mobile a comment thread is a sheet that slides over the thing being discussed, with a text column roughly 340 points wide, a keyboard about to take half the screen, and a single reply level before the words run out of room. Our library holds 2,622 revenue-verified iOS apps, 276 of them carrying a community and social flow, and they are not mostly social networks. They are fitness apps with a feed, generators with a gallery of what other people made, and meditation apps with a challenge board. This is what those apps actually ship around a comment.
A comment is a response to something. Push the thread onto a new screen and the thing it responds to is gone, so every comment referring to the image, the workout or the track is now referring to something the reader cannot see. A sheet that covers most of the screen while leaving the content peeking above it solves that for free.
The mechanics are the same ones covered in the bottom sheet piece: a medium detent that shows the top of the thread, a drag to full height when the user commits to reading, and a handle that makes both obvious. The one comment-specific detail is that the sheet should open at medium rather than full, because most taps on a comment count are curiosity rather than intent, and a full-height sheet makes a glance feel like a destination.
The exception is genuinely forum-shaped products, where the thread is the content rather than a reaction to it. There the thread earns its own screen, its own title and its own back button.
Hevy (est. $0.75M/mo) is a workout tracker with a social feed attached, which is the most common shape this pattern takes in the library: an app whose primary job is not social, carrying a feed anyway.
Every indent level costs roughly 16 to 24 points of horizontal space, and a phone starts with about 340. Two levels of nesting is tight. Three is a column narrow enough that ordinary sentences wrap after four or five words, which reads as broken rather than as structure.
So the shape is a top-level comment, its replies indented once, and nothing beyond that. Replies to replies flatten into the same level and carry the name of who they are answering in the body or as a prefix. This loses a little of the tree, and it is the correct trade: a reader can follow a named reply in a flat list, and cannot read a four-word-wide column at all.
Replies should also be collapsed by default behind a count. Show two or three under the parent, then a control that says how many more there are. A thread that expands everything turns a fifteen-comment discussion into a scroll of two hundred rows and buries the other top-level comments entirely.
Author, body, age, one action. The avatar and name say who is speaking, the body is the content, a relative timestamp tells the reader whether this conversation is alive or two years dead, and one visible action carries the interaction, usually reply or a like with a count.
Everything else goes behind a long press or an overflow control: report, block, mute, copy, edit, delete. This matters more than it looks. Comment rows repeat, so every extra element is multiplied by the length of the thread, and a row carrying six affordances reads as a control panel rather than as something someone said. The general case for what a repeating row should carry is in the list UI design piece.
One detail that is routinely missed: the author of the content being discussed should be marked. A small label on their comments is the difference between a creator answering a question and a stranger guessing, and it is the cheapest credibility signal in the pattern.
Lightroom (est. $4.75M/mo) is a creative tool with community features attached rather than a social product, which is a useful contrast to a feed-first app.
The composer belongs pinned to the bottom of the sheet, collapsed to a single line with a placeholder, expanding as the user types. Putting it at the end of the list, which is how the web usually does it, means scrolling past every existing comment before writing one.
The keyboard is where this pattern usually breaks. When it opens it takes roughly half the screen, so the thread has to shrink rather than scroll behind the composer, and the row being replied to should stay visible. A reply that loses sight of what it is replying to is the most common comment bug on mobile, and it is entirely a layout problem.
Reply mode also needs a visible state and a visible exit. A small bar above the composer that says who is being replied to, with a dismiss control, prevents the case where a user thinks they are writing a top-level comment and posts a reply to a stranger three screens up.
Keep the composer honest about length too. If the product caps comments, show the counter only as the limit approaches rather than from the first character, which turns writing into a budget exercise.
Three orders are in common use and they produce different products. Newest first makes the thread a live chat and suits anything happening now, such as a challenge or a drop. Top first, ranked by reactions, surfaces the best answer and suits threads where people are asking questions. Oldest first preserves conversation order and suits long-form discussion.
Most apps should pick one and ship it rather than exposing a sort control. A sort menu on a thread of nine comments is a control that costs a tap and changes nothing. Add it when threads routinely run past fifty comments and not before, and if it is added, the two-option version reads better as a segmented control than as a menu.
The count itself is part of the design. A comment count on the content is the entry point to this whole pattern, and a count of zero should read as an invitation rather than as a number, which is the empty-state problem covered below.
Suno (est. $5.25M/mo) is a generator with a public gallery, where the thing being discussed is something another user produced minutes earlier.
A reaction is a cheap signal that costs one tap and adds no rows. A reply is expensive and makes the thread longer. Products that only offer replies get threads full of agreement, and products that only offer reactions get no conversation at all.
A single like is usually enough. Multi-emoji reaction pickers work in messaging, where the audience is a handful of known people, and tend to fragment signal in a public thread where the only useful question is whether a comment is worth reading. If reactions do drive sort order, that has to be a single dimension, which is another argument for one.
Downvotes deserve one deliberate decision rather than a default. They improve ranking quality and they change the tone of a community permanently, and most apps carrying a feed alongside a non-social product do not need them.
Any app that ships user-generated comments on iOS needs report, block and mute reachable from the comment itself, not buried in settings. That is both an App Store review expectation for user-generated content and the only thing standing between a small community feature and a support queue.
Three things make it work in practice. Reporting should be one long press away and should confirm that something happened, because silent reporting reads as a broken button. Blocking should take effect on the visible thread immediately rather than after a refresh. And a removed comment should leave a marker rather than vanishing, so a reply that no longer makes sense has an explanation.
Deleting your own comment sits in the same family and is the one destructive action that should be plainly reachable. The rules for where destructive actions go and how they confirm are in the button UI piece.
Leonardo.Ai (est. $0.2M/mo) carries a community feed of user output, which is the context where moderation surfaces stop being optional.
In an app whose primary job is not social, most content has no comments. That makes the empty thread the common case rather than the edge case, and shipping a grey magnifying glass and the words no comments yet is a decision to have no comments ever.
The empty state should do one thing: put the composer in focus with a placeholder that suggests what to say about this specific content. Be the first to comment is weak. A prompt tied to the object, asking what someone thinks of a workout or a track, converts far better because it answers the question that stops people, which is not whether to comment but what to say. The wider treatment is in the empty state piece.
Five recurring failures. Nesting past one level, which produces a text column too narrow to read. A composer at the end of the list rather than pinned, so writing requires scrolling past everything. Losing the replied-to comment when the keyboard opens. A row carrying six actions, multiplied by every comment in the thread. And an empty state that describes the absence of comments rather than inviting one.
A sixth is shipping comments at all. A comment thread is a permanent moderation commitment and a surface that looks abandoned when nobody uses it. Plenty of products in this library would be better served by a reaction and nothing else, and that is a legitimate answer rather than a missing feature.
Test the thread with the keyboard open, on the smallest screen you support, replying to a comment near the top of a long list. That single case exposes most of the failures above: the composer position, the lost context, the nesting width, the scroll behaviour. Then test it with zero comments, because that is what most of your users will actually see.
After that, compare against shipping apps rather than concept shots. Every screen in the library sits next to the app’s estimated revenue and downloads, so references can be chosen by outcome rather than by how the shot looks. The adjacent case, where the messages are the product rather than a reaction to it, is covered in the chat UI design study.
A note on the numbers: revenue figures cited here are third-party monthly estimates from our library, useful for comparing magnitude, not audited financials.
One level. A top-level comment and its replies, and nothing below that. Every further level costs horizontal space that a phone does not have, and by the third indent the text column is too narrow to read. Deeper conversations should flatten into a reply that names who it is answering rather than indenting again.
A sheet, in almost every case. Comments are about the thing above them, so keeping the post partly visible preserves the context the comments refer to. A full push to a new screen is only right when the comment thread is the primary content rather than a response to something, which is rare outside forum-shaped apps.
Author, body, age, and one action. Avatar and name identify the speaker, the body is the point, a relative timestamp tells the reader whether the conversation is alive, and one visible action, usually reply or a like, carries the interaction. Everything else, including report, block, edit and delete, belongs behind a long press or an overflow control rather than on the row.
Pinned to the bottom, above the keyboard, and visible without scrolling to the end of the thread. A composer that lives at the bottom of a long list means the user has to travel past every comment to write one. Pin it, keep it collapsed to a single line until focused, and make sure the thread scrolls behind it rather than being covered by it.
The mobileappdesign library holds captured flows from 2,622 revenue-verified iOS apps, including 276 with a community and social flow. Screens are captured in sequence, so a comment thread appears next to the feed screen that led into it rather than as an isolated shot.
Browse captured community and social flows from revenue-verified apps, in the order a real user walks them.
Browse community screens
