> For the complete documentation index, see [llms.txt](https://doc.batch.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.batch.com/getting-started/features/customer-engagement-platform/message/in-app.md).

# In-App & Mobile Landing

In-App messages are messages **displayed inside your app**. You can trigger them when users open your app or as contextual reminders when they perform a specific action *(e.g. tapping a button, browsing a page, etc)*. This is great to communicate with all your users, even with users who have **turned off push notifications**.

You can also trigger an In-App message after your users open a push notification. That's what we call a **Mobile Landing**.

**The process for creating content for both Mobile Landing and In-App messages is similar.** Unless specified otherwise, the information in this section applies to both features. Mobile Landing specificities are covered within the [Push](/getting-started/features/mobile-engagement-platform/push.md) section.

{% hint style="info" %}
**SDK Version Requirements:** Using the In-App feature requires SDK version 3.1 or higher. The Mobile Landing feature is compatible with SDK version 3.0 or higher.
{% endhint %}

Messages can be targeted to either both iOS and Android platforms or filtered for a single specific platform.

These messages are designed using the shared drag & drop [composer](/getting-started/features/customer-engagement-platform/content/composer.md).

<figure><img src="https://1464139620-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUIK868wiiK9XOVyETGZS%2Fuploads%2FeHtAuCDn2l0eWSUJLHtE%2Fscreen%20pour%20doc.png?alt=media&#x26;token=739ea68d-f776-493f-889e-1af426d98da5" alt=""><figcaption></figcaption></figure>

## Formats

Available In-App message formats include:

* **Modal**: A pop-up displayed over a portion of the screen. Modals can be positioned at the center, top, or bottom of the screen.

  * **Center Modals:** These appear in the middle of the screen and include a translucent backdrop that prevents interaction with the app content behind them.
  * **Top/Bottom Modals:** They were previously referred to as "**banners**" in the MEP. They are displayed at the top or bottom edge of the screen and do not have a backdrop, allowing users to continue interacting with the app content behind them. These modals can be "attached" directly to the screen edge by setting their margins to zero.

  The vertical size of all modals automatically adjusts to fit their content.
* **Fullscreen:** A message that occupies the entire screen, overlaying the app content.

<div data-full-width="true"><figure><img src="https://1464139620-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUIK868wiiK9XOVyETGZS%2Fuploads%2FhIa9uYPp6eZPLzi1MbN6%2Fmobile_landing_modale.png?alt=media&#x26;token=47c3335b-8668-42db-9515-db50e319d339" alt=""><figcaption><p>Modal</p></figcaption></figure> <figure><img src="https://1464139620-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUIK868wiiK9XOVyETGZS%2Fuploads%2FdRxUApCWvmEKcsKzOYbT%2Fmobile_landing_banner.png?alt=media&#x26;token=4b5a9137-7321-44b7-af06-7b5e64f0b5cd" alt=""><figcaption><p>Banner</p></figcaption></figure> <figure><img src="https://1464139620-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUIK868wiiK9XOVyETGZS%2Fuploads%2F8dsTR0MtJYToqnG11aaM%2Fmobile_landing_fullscreen.png?alt=media&#x26;token=208d3f3e-467a-4db7-8265-49efce9f55da" alt=""><figcaption><p>Fullscreen</p></figcaption></figure></div>

Various visual customization options are available for these formats:

<table><thead><tr><th width="153.0546875">Customization</th><th width="282.24609375">Description</th><th width="150.52734375">Value Type</th><th>Applies to Format(s)</th></tr></thead><tbody><tr><td><strong>Modal Position</strong></td><td>Controls the vertical alignment of the modal pop-up on the screen.</td><td><code>top</code>, <code>middle</code>, <code>bottom</code></td><td>Modal only</td></tr><tr><td><strong>Fullscreen Content Position</strong></td><td>Determines the vertical alignment of the message content block within the fullscreen container if the content does not fill the entire screen.</td><td><code>top</code>, <code>middle</code> , <code>bottom</code></td><td>Fullscreen only</td></tr><tr><td><strong>Background Color</strong></td><td>Sets the background color of the message container, including opacity.</td><td>Color</td><td>Modal, Fullscreen</td></tr><tr><td><strong>Margin</strong></td><td>Defines the spacing between the edges of the device screen and the In-App message content. Can be configured independently for top, bottom, left, and right sides.</td><td>0/XXS/XS/S/M/L/XL/XXL</td><td>Modal only</td></tr><tr><td><strong>Radius</strong></td><td>Controls the roundness of the corners for the message container.</td><td>Pixels</td><td>Modal only</td></tr><tr><td><strong>Border</strong></td><td>Sets the thickness of the border around the message container. (Optional)</td><td>Pixels</td><td>Modal only</td></tr><tr><td><strong>Border Color</strong></td><td>Sets the color of the border around the message container, including opacity. (Optional)</td><td>Color</td><td>Modal only</td></tr></tbody></table>

#### **Close options**

To allow users to dismiss the In-App message, several close options are available. Unless a button action within your message is specifically configured to dismiss the In-App, you must enable at least one of these options:

* **Close icon:** Displays a ‘X’ dismissible icon in the top right corner of the message. You can customize the color and background color of this icon separately.
* **Auto dismiss:** The message automatically disappears after a specified duration. A visual gauge is displayed to show the remaining time. The auto-dismiss duration is customizable (in seconds).
* Platform-specific dismissal methods (like swipe gestures on iOS or the back button on Android) are always possible.

## Blocks

In-App messages are composed with the blocks of the shared composer: Text, Button, Image, Divider, Spacer and Columns. The description of each block, its settings and the color picker are documented in [Composer](/getting-started/features/customer-engagement-platform/content/composer.md). The Field block, used to collect data, is available on [landing pages](/getting-started/features/customer-engagement-platform/content/landing-pages-and-forms.md) only.

One layout behavior is specific to In-App: the `fill space` height of the Image and Spacer blocks, available on Fullscreen messages only.

### Button actions

Every button of an In-App message carries an action, which defines what happens when the user taps it. By default the **Dismiss** action is selected. The built-in actions are the following:

* **Dismiss:** closes the In-App message.
* **Deeplink:** closes the In-App message and opens the specified deeplink or web page.
* **Copy to clipboard:** copies the provided text to the device clipboard. The In-App message is dismissed. Optionally, a deeplink or web page can also be specified to open after copying.
* **Smart Push re-optin:** displays the system push notification authorization prompt to eligible users. If the user has already been asked for push notifications opt-in, it opens the system notification settings instead. If the user is already opt-in, the message disappears after clicking the button but no further action is triggered.
* **Rating:**
  * **iOS:** displays the app rating dialog. The system limits this dialog to a maximum of three displays within a 365-day period. Your automation triggering this action should be rate-limited accordingly.
  * **Android:** displays the Google In-App Review feature. Your automation triggering this action should also be rate-limited. The `play-core` library is required in your application to display the Google In-App review feature. Refer to [SDK integration](/developer/sdk/android/sdk-integration.md#in-app-review).
* **Redirect to settings:** opens the notification settings for the current application, where notification permissions can be managed.

In addition to these built-in options, you can also configure custom actions that are registered within your application. Refer to the corresponding documentation for [Android](https://doc.batch.com/developer/sdk/android/advanced/custom-actions) and [iOS](https://doc.batch.com/developer/sdk/ios/advanced/custom-actions).

Images can carry the same actions as buttons.

## **Additional options**

### **Dark mode**

You can configure a dark mode version for each In-App template to match user device settings. Dark mode is a shared capability of the editor: refer to [Composer](/getting-started/features/customer-engagement-platform/content/composer.md#dark-mode) for how color values are defined per theme.

Note that when using the “Send test option”, the In-App message will render according to the test device's dark mode setting, not the mode selected in the composer preview.

### **Advanced settings**

**Priority**

You can select a priority level between Standard, Important and Critical. Priority works on automations with identical trigger event, and identical label if one is specified. **When two or more automations should be displayed at the same time, the system selects the automation with the highest priority**: this is the one that will be displayed after the trigger event occurred.

If multiple automations have the same priority level, we rely on our automatic priority system to automatically define priority based on multiple criteria.

Default priority value is standard.

Here are a couple of examples of usage of priorities:

* Standard-level priority could be selected for your long-term use cases: onboarding, app review, etc.
* Important level priority could be selected for temporary campaigns: conversion or subscription campaigns, account creation, reopt-in campaign, etc.
* Critical level priority could be selected for emergency campaigns: downtime or out-of-service messages, asking your user to update the app, etc

**Tracking ID**

This setting is only usefull for apps with an **event dispatcher solution setup**.

The tracking ID provides an **additional tracking dimension** at the Orchestration-level in your analytics solution.

**Payload**

An optional JSON string that can contain **additional parameters** that your application can handle when receiving In-app messages if configured to do so. The root of the JSON must be an Object and cannot have the reserved key `com.batch`.

This feature is often used by your technical teams to add data to your in-app messages and retrieve it via SDK APIs.

### Custom fonts

\
By default, Batch uses the system font set on the user's device.

To use a custom font for your brand, it requires **implementation in your application's native code**.

For bold or italic text styles to display correctly, the corresponding **bold** and **italic** font files must be provided and implemented alongside the regular font.

Refer to the documentation for [Android](https://doc.batch.com/developer/sdk/android/mobile-landings#setting-a-custom-typeface) and [iOS](https://doc.batch.com/developer/sdk/ios/mobile-landings#setting-a-custom-font) for custom font platform-specific implementation details.

### Preview and device testing

The In-App composer preview is a useful tool for designing your message, but final appearance and behavior can vary across devices and operating systems. Always test your In-App message on actual devices using the "Send test option" to ensure it looks and works as intended.

## Templates

Templates are reusable blueprints for your In-App message layouts. Saving your In-App structure and styling as a template allows you to quickly create new messages with a consistent look and feel without starting over each time. Saving a message as a template is **optional**; In-App messages function independently of whether they were saved as templates.

Modifications made to a template do not affect existing In-App messages or live campaigns that were created using that template, and vice versa. You can update the structure and styling of an existing In-App message and choose to save these changes by overwriting the original template or by creating a new template.

As a starting point, a selection of pre-built Batch templates is available to showcase various In-App message possibilities. These specific templates are read-only and cannot be modified or overwritten.

A template defines the *structure* and *styling* of an In-App message. This includes:

* The type and position of each block (e.g., Image block, Text block, Button block, Columns block, Divider block).
* The visual customization settings applied to each block (e.g., margins, colors, sizes, corner radius).

Importantly, templates **do not** include the *content* or specific *behavioral configurations*. This means the following are *not* saved in a template:

* The actual text written in a text block.
* The image file uploaded or the image URL used in an Image block.
* The specific action configured for a button or Image block, including the action type (e.g., deeplink, rating, smart re-optin) and any associated parameters (e.g., the target URL for a deeplink, the text for copy to clipboard).

Importantly, when multi-language support is enabled, the template structure and styling are common across all languages while the content is managed separately for each language.

Templates are managed in [In-App Templates](/getting-started/features/customer-engagement-platform/content/in-app-templates.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://doc.batch.com/getting-started/features/customer-engagement-platform/message/in-app.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.