How Responsive Navigation Works

UnifyApps apps run on a single codebase across mobile, tablet, and desktop. Navigation is one of the most visible differences between these form factors — a bottom tab bar that works perfectly on a phone feels cramped and out-of-place on a 1440 px wide monitor. The responsive navigation system lets you configure a completely different navigation structure per breakpoint, with the same pages, links, and content underneath.

The navigation system applies breakpoint-specific settings automatically based on the current viewport width. No JavaScript or conditional logic is needed on your part — you configure each breakpoint once and the platform handles the switching.

Breakpoints

UnifyApps uses four breakpoints for navigation configuration. These are the same breakpoints used across the rest of the platform.

Note: Navigation settings cascade from larger to smaller breakpoints. If you configure XL and SM only, MD and LG inherit from XL (the next larger breakpoint that has settings). You do not need to configure all four breakpoints — configure the ones that need different behaviour and let others inherit.

Auto-Adaptation Rules

UnifyApps includes built-in auto-adaptation for the two most common navigator types. These rules apply automatically — you do not need to explicitly configure them unless you want to override the default behaviour.

These defaults follow industry-standard responsive navigation patterns and cover the majority of use cases without configuration. Override them only when your design intentionally diverges from these conventions.

Configuring Responsive Overrides

To set a different navigator type or style at a specific breakpoint:

1. Open App Settings → Navigation → Appearance: The Appearance tab shows the current navigator configuration. The breakpoint selector (SM / MD / LG / XL) at the top lets you switch between breakpoint views.

2. Select the target breakpoint: Click the breakpoint you want to override. The panel updates to show that breakpoint's current settings (inherited settings are shown in grey; explicitly set values are shown in the accent colour).

3. Change the Style: From the Style dropdown, choose the navigator style for this breakpoint. Options: Standard, Bottom Bar, Drawer, None, Custom. Setting it here overrides the auto-adaptation default for this breakpoint only.

4. Configure breakpoint-specific appearance: With the breakpoint selected, all appearance properties (colours, sizes, label visibility) are now being edited for that breakpoint specifically. Set only the properties that need to differ — unset properties inherit from the next larger breakpoint.

5. Preview at each breakpoint: In Preview mode, use the viewport size controls in the preview toolbar to test each breakpoint. The builder's device simulation shows the navigation adapting in real time as you resize.

Hiding Navigation at Specific Breakpoints

Set the navigation style to None for a breakpoint to hide the navigation chrome entirely at that size. This is useful when:

• Your app has no navigation at the smallest screen size — a single-page or wizard-style app.

• You supply a fully custom navigation component in a page layout slot instead of using the platform nav.

• You want to disable navigation on specific breakpoints during onboarding flows, using a conditional override.

You can also bind the navigation's navVisible property to an expression for dynamic visibility:

navVisible: {{ viewport.width > 768 }}

This hides the nav when the viewport is narrower than 768 px, while still using the SM breakpoint's style when it is shown. Unlike setting Style to None, this approach hides the nav dynamically based on runtime viewport width rather than at the breakpoint boundary.

Collapsing the Sidebar

The Drawer Navigator's persistent sidebar mode on desktop supports a collapsed state — the sidebar narrows to icon-only width, hiding the text labels. This is common in complex enterprise tools where users want maximum content area without hiding navigation entirely.

To enable sidebar collapsing:

1. Select the LG or XL breakpoint in the Appearance tab.

2. In the Drawer settings, enable Collapsible.

3. Set collapsedWidth (default 56 px — just wide enough for icons) and expandedWidth (default 260 px).

4. A collapse toggle button appears at the bottom of the sidebar automatically. Users can click it to collapse/expand.

5. The collapsed state is saved to localStorage per user — the sidebar remembers its state across page loads.

Tip: Use {{nav.sidebarCollapsed}} in your page layout to adjust content that needs to respond to the sidebar width — for example, a chart that should use full width when the sidebar is collapsed. This binding is reactive and updates as the user toggles the sidebar.

Tablet Breakpoint Considerations

The MD breakpoint (768–1023 px) is the most nuanced in terms of navigation, because tablets are held in both orientations and used with both touch and keyboard/mouse input. Common approaches:

Custom Responsive Navigation

For apps where the auto-adaptation and breakpoint settings are not flexible enough, you can build fully custom responsive navigation using a combination of Layout containers and conditional slot visibility.

The recommended approach:

1. Set navigation Style to None for all breakpoints.

2. In the app's root page layout, add a Layout component that acts as the navigation shell.

3. Inside it, add both a Tab Bar component and a Sidebar component.

4. Bind the Tab Bar's visible property to {{viewport.width < 768}}.

5. Bind the Sidebar's visible property to {{viewport.width >= 768}}.

6. Wire both components' navigation events to Navigate actions pointing to your pages.

Warning: The platform's standard navigator automatically highlights the active tab/item based on the current URL. When you use a custom navigation layout, you are responsible for computing and applying the active state yourself — typically by binding an active indicator to {{page.path === "/app/target-page"}}. This is manageable but requires more maintenance as your page structure evolves.

Frequently Asked Questions

Can individual navigation items be hidden at specific breakpoints?

Yes. In the Appearance tab, select a breakpoint and find the Item Order section. Each item has an eye icon toggle — click it to hide that item at the currently selected breakpoint. The item remains visible at other breakpoints. This is the recommended way to show a subset of items at mobile (where space is constrained) and a fuller set at desktop. Note that this is different from the item's global visibility setting in the Content tab — the per-breakpoint eye toggle is only about rendering at that breakpoint, not about access control.

Can I make the Drawer Navigator always open (persistent) on all screen sizes?

Yes — set the Drawer Navigator's variant property to persistent at the breakpoints where you want it always visible. On SM (mobile), a persistent drawer takes up a fixed portion of the screen width alongside the content, rather than overlaying it. This is unconventional on mobile (most mobile apps use overlay drawers) and requires a content area wide enough to accommodate both the drawer and the page. It works well on large tablets in landscape. Most apps only set persistent at LG/XL breakpoints.

Can I show different navigation items on mobile vs desktop?

You can control which items appear at each breakpoint using the per-item breakpoint eye toggle in the Appearance tab. However, you cannot show fundamentally different sets of navigation items at different breakpoints — the item list is shared across breakpoints, and you can only show/hide items within it. If you need truly different navigation structures (e.g. a different information architecture for mobile vs desktop), use the Custom navigation style and build separate Tab Bar and Sidebar components, each wired to their respective destinations.