.svg)
An engaging in-app message is one whose response you can use afterwards. In Braze, that decision comes before the design, because only some interactions are recorded in a form you can segment on. Choose the follow-up first, give it a button or a logged survey answer, then build the pages, check the SDK floor and test with a realistic profile.
Key Takeaways
- Decide the follow-up before the design: name the segment, campaign or Canvas that should exist because someone responded.
- Button clicks are segmentable for up to two buttons, identified for reporting as "0" and "1". Body clicks aren't collected automatically for drag-and-drop messages.
- A Liquid error on one page of a multi-page message breaks Liquid on every page, so test the message as one template.
- The drag-and-drop editor has minimum SDK versions, which makes the SDK floor a targeting decision.
- Survey answers logged as custom attributes can drive segmentation; long text answers can't.
- Braze recommends avoiding in-app messages for critical, time-sensitive updates.
Which Braze editor should you build an in-app message in?
Start in the drag-and-drop editor unless you need a slideup or custom HTML. Braze recommends it for modal and fullscreen messages, and it adds rows, Content Blocks, templates and multi-page flows on top of the core layouts.
The traditional editor stays the right choice for slideups and hand-written HTML. Existing HTML templates don't move across automatically, so they're rebuilt in the new editor, or dropped into a Custom code block as raw HTML, CSS and JavaScript.
What should you decide before you open the editor?
Decide what the message is for after the user taps. We'd make that the first line of every in-app brief, above the copy and the imagery.
The reason is how interactions get recorded. Body clicks aren't collected automatically for drag-and-drop messages. Button clicks are segmentable for up to two buttons, identified for reporting as "0" and "1". That gives each message two actions you can build a follow-up on, and everything else on the screen is presentation.
So we work backwards. Name the segment you want to exist once the message has run, then wire the one or two buttons that create it. A third button can still be useful to the user, but nothing downstream should depend on it.
- Write down the follow-up: the campaign, Canvas or segment that should exist because someone responded.
- Map it to button identifiers "0" and "1", or to a survey answer logged as a custom attribute.
- Only then choose the template, the layout and the number of pages.
How do you build a multi-page in-app message that works?
Pages turn a single screen into a short sequence, which suits onboarding or a welcome flow. The editor enforces a few rules that are easier to design around than to discover at launch.
| Rule | What it means for the design |
|---|---|
| Up to 10 pages per message | Plan the flow on paper first and keep it short enough to finish |
| Every page must link to another | An orphaned page stops the message launching |
| Pages connect through a button or image set to Go to page | Every step needs a tappable element, not just a swipe |
| The close X can't be removed | Assume users can leave at any page, and put the key action early |
| A Liquid error on one page breaks Liquid on every page | Treat the whole message as one template when you test |
The last row changes how we'd test. A broken preview on page three can come from a typo on page one, so we check every page's Liquid together, and give each variable a default for profiles where it's empty.
Which SDK versions does the drag-and-drop editor need?
The drag-and-drop editor has minimum SDK versions, and Braze lists recommended versions as well. Check the floor before you assume the message reaches everyone, because it's a targeting decision as much as a technical one.
| Platform | Minimum | Recommended |
|---|---|---|
| Swift | 5.0.0+ | 6.5.0+ |
| Web | 2.5.0+ | 4.8.1+ |
| Android | 8.0.0+ | 26.0.0+ |
Two features depend on newer builds. Text links that don't dismiss the message need Swift 6.2.0 or later, or Android 26.0.0 or later. The button action that requests a push primer needs Swift 6.5.0, Web 4.8.1 or Android 26.0.0, or later.
On the web, set allowUserSuppliedJavascript to true at initialisation. The older enableHtmlInAppMessages option still works but is deprecated.
// Web SDK initialisation, drag-and-drop in-app messages
// Replace the placeholders with the values for your workspace.
braze.initialize("YOUR-API-KEY-HERE", {
baseUrl: "YOUR-SDK-ENDPOINT-HERE",
allowUserSuppliedJavascript: true
});
Before choosing a feature that needs the recommended builds, check how much of your active audience is already on them. That call is yours, and it differs by app.
How do surveys turn an in-app message into a signal?
Braze surveys collect feedback in in-app messages and landing pages. For in-app messages, you choose Survey as the message type on the composition page before the editor opens.
Surveys suit the work-backwards approach well, with one caveat. Answers logged to custom attributes can drive segmentation, and a completed survey can trigger a campaign or Canvas. Long text answers, up to 1,000 characters, can't be logged as attributes, so they're for reading rather than routing.
- Use radio buttons, checkboxes, dropdowns or the rating scale for anything you'll act on.
- Keep long text for context you'll read in the Responses tab or a CSV export.
- Give every form block an Identifier for Reporting before launch.
How should you test an in-app message before launch?
Preview as a user whose profile looks like the audience, not a random one. Braze notes that delivered messages can differ from the dashboard preview when your integration applies custom styling, or when templated content resolves differently at send time.
Our minimum checklist is simple. Check each device, check that media loads, check Liquid defaults and check that every button goes where it should. Then check timing: Braze notes that templated in-app messages can add a short delay, typically under 100 ms on a stable connection.
When is an in-app message the wrong channel?
When the update is critical and time-sensitive. Braze recommends avoiding this channel for critical, time-sensitive updates. In-app messages are delivered at session start, so they suit moments inside a session better than alerts. That's our reading.
The trigger setup decides which moment, and deep links decide where a button takes the user next. A push primer in-app message pairs naturally with push segmentation. Onboarding flows are where multi-page messages earn their place, and personalisation is what keeps each page relevant.
Frequently Asked Questions
1. Can I build a slideup in the drag-and-drop editor?
The drag-and-drop editor builds modal and fullscreen messages. Slideups are built in the traditional editor.
2. Can I segment users by which button they tapped?
Yes, for up to two buttons. Set their Identifier for Reporting to "0" and "1", then segment on those button clicks.
3. Why is my Liquid showing as plain text in a multi-page message?
A syntax error on any page affects Liquid on all pages. Check every page, not only the one that looks broken.
4. Why didn't some users receive my drag-and-drop message?
Check their SDK version against the minimums for the drag-and-drop editor, shown in the table above.
5. Can I add a text link that does not close the message?
Yes, on newer SDK builds. Braze lists Swift 6.2.0 or later and Android 26.0.0 or later for text links that don't dismiss the message.
Sources
- Braze, In-app messages. Retrieved 01 Oct 2026.
- Braze, Create an in-app message with drag-and-drop. Retrieved 01 Oct 2026.
- Braze, In-app message FAQ. Retrieved 01 Oct 2026.
- Braze, In-app message surveys. Retrieved 01 Oct 2026.
- Braze, SDK integration, Web. Retrieved 01 Oct 2026.
- Written by CustomerIK, a Braze implementation partner.
CustomerIK is a Braze implementation partner working across onboarding, technical integration, marketing operations and customer data management.
If you're planning in-app messages and want the follow-up mapped before the design starts, let's talk.
.svg)
