Messaging on mobile
What chat looks like for your clients in the branded mobile app — what they can read, how they send and manage messages, and the one difference from the web composer.
Basic Your clients live in the mobile app, not the web dashboard. Here’s how messaging works on their side — useful both for supporting clients and for knowing how what you send will land.
What clients can read
Everything renders in full on mobile. Clients see your formatting (bold, italic, links, code), your @mentions, inline photos and videos, documents, and voice notes they can play back. Edited messages show the “edited” label, and live typing indicators work both ways.
See @Jordan — full plan's in Week 3.
The one difference: clients send plain text
There’s a single deliberate difference from the web composer:
Clients read rich formatting in full, but currently send plain text.
So a client’s replies arrive as clean plain text, while everything you compose on the web renders richly for them. Nothing is lost either way — it’s the same graceful-by-design model from Formatting & mentions. Richer mobile composing is on the roadmap.
Managing messages: press and hold
Mobile actions live behind a long-press on a message bubble:
| On their own message | On anyone’s message |
|---|---|
| Edit — fix it, any time | Copy — grab the text |
| Delete — with a confirm prompt |
This mirrors the web actions — see Editing & deleting.
Read-only groups on mobile
In an announcement group, a read-only client sees the same quiet “Only admins can post” notice in place of the composer. They read everything and open your links, forms, and media — they just can’t post into the channel.
Notifications
New messages arrive as push notifications that deep-link straight into the conversation; an @mention adds a targeted nudge. If the client already has that conversation open, the message just appears live instead. See Notifications.
That’s the full tour. Back to the Messaging overview.