Create Fully Responsive Applications

Enhance the layout to ensure the application is fully responsive.

Although applications built with UI Builder are responsive by default, certain settings should be avoided to ensure full responsiveness.

Fixed Height

Setting a fixed height for a widget may cause display issues on different window sizes.

For example, if you set the Height property to Fixed for a Container widget, the content may become truncated when the window is resized.

Scroll Content

For some widgets, for example the Container widget, you can use the Scroll content property if you want to maintain a fixed size.

Viewport Dimensions with appsmith.ui

This feature is available starting from UI Builder version 1.3.10.

The appsmith.ui property exposes the viewport dimensions at the time the page is loaded. These values are captured once and are not updated when the viewport is resized.

You can use this property to conditionally adjust the layout or hide widgets depending on the device. For example, use {{appsmith.ui.width}} in a widget’s Visible property to hide it on small screens, or switch between layouts based on the viewport width.

Example

  1. Drop a Container widget on the page:

    • Set the Height property to Fixed

    • Disable the Scroll contents property

  2. Drop a Text widget inside the Container:

    • Expand it to the width of the Container

    • Add some text to fill the Text widget

Preview the page and resize the window: you will see that the content is truncated when the window is small:

responsive-container-ko

Now, set the Height property of the Container to Auto Height and preview the page again: you will see that the content is displayed correctly, the Container height adapts to the content:

responsive-container-ok

Quick Comparison Matrix

When deciding how to structure a responsive application, you can choose from several strategies. Each involves a trade-off between development effort, maintainability, and user experience across devices:

  • Two Separate Apps/Pages — dedicated layouts per device

  • Conditional Visibility on Widgets — show/hide individual widgets based on viewport

  • Container Swapping — show/hide entire containers to switch between layouts

  • Hybrid — combine page splitting with conditional containers for the best of both approaches

The following table gives a quick side-by-side rating to help you narrow down your options:

# Strategy Dev Ease Maint. Ease Mobile UX Desktop UX Performance

1

Two Separate Apps/Pages

Low

Low

Very High

Very High

Very High

2

Conditional Visibility on Widgets

Medium

Medium

High

Very High

Medium

3

Container Swapping (Show/Hide Containers)

High

High

High

Very High

High

4

Hybrid: Page Splitting + Conditional Containers

High

High

Very High

Very High

High

To understand these ratings, here are the key trade-offs for each strategy:

Strategy Pros Cons

Two Separate Apps/Pages

Best UX per device: each layout is fully optimized. Best performance: only the relevant widgets are loaded.

Highest effort: every change must be applied in both places.

Conditional Visibility on Widgets

Quick to set up: toggle individual widgets with the Visible property.

All widgets are loaded regardless of visibility, which may affect performance on large pages. Can become hard to maintain when many widgets differ.

Container Swapping (Show/Hide Containers)

Clean separation: group desktop and mobile layouts in distinct containers, toggle them as a whole.

Both containers are still loaded. Requires careful organization to avoid duplication inside containers.

Hybrid: Page Splitting + Conditional Containers

Balances UX and effort: separate pages for radically different layouts, conditional containers for minor adjustments within each page.

More moving parts to coordinate between pages and containers.

Related How-To

For a step-by-step guide on redirecting users based on viewport width, see How to Adapt UI to Viewport Size.