What Are Page Transitions?
A page transition is the animation that plays while the app moves from one page to another. A well-chosen transition reinforces the spatial model of your app — slide-left implies moving deeper into a hierarchy; slide-right implies going back; fade is neutral and works in any direction. Poorly chosen transitions (or too-slow ones) make an app feel sluggish, so UnifyApps lets you tune both the type and duration.
Transitions are configured at two levels: a single app-wide default that applies to every navigation, and per-Navigate action overrides that let specific flows use a different animation. The override always wins when set.
Note: The destination page begins loading immediately when navigation is triggered. The transition animation plays over the top of the loading state and does not add real latency to navigation. Data-heavy pages may finish loading before the animation completes, or vice versa.
Transition Types
The following transition types are available across both web and mobile platforms. Not all feel equally appropriate on every platform — see the platform guidance below.
| Type | Motion | Best used for |
none | Instant cut — no animation | Data-heavy apps where animation feels slow; accessibility preference for reduced motion; programmatic navigations that should be invisible to the user. |
fade | Incoming page fades in over outgoing | General-purpose default on web; neutral feel that works in any navigation direction. |
slide-left | New page slides in from the right; old page exits left | Drilling into a detail view; moving forward in a wizard; following a list item. |
slide-right | New page slides in from the left; old page exits right | Going back in a hierarchy; dismissing a detail view; the back action in a stack navigator. |
slide-up | New page slides in from the bottom | Modal sheets, full-screen overlays, on-boarding flows on mobile. |
slide-down | New page slides in from the top | Dismissing a full-screen overlay; returning from a modal sheet. |
zoom-in | New page scales up from center | Opening a detail from a grid of cards; expanding a preview. |
zoom-out | New page scales down from larger to normal | Returning to an overview from a detail page. |
flip | Card-flip 3D rotation around the Y axis | Used sparingly for "reveal" moments — settings toggle, show/hide a panel. Not suitable for frequent navigation. |
Warning: Use flip and zoom-in sparingly. Applying them to every navigation in your app quickly feels gimmicky and can cause motion sickness in users sensitive to vestibular effects. Reserve them for singular moments.
Configuring the App-Wide Default
The app-wide default transition applies to every Navigate action that does not have an explicit override. Set it once and it propagates to all navigations automatically.
Open App Settings: In the top bar of the builder, click Settings (the gear icon), then select Development.
Navigate to the Navigation section: In the Settings panel, find the Navigation section. It contains both content (menu items) and behaviour settings.
Set Default Transition: Find the Default Transition dropdown. Choose from the nine transition types listed above. The change applies immediately — use Preview mode to verify the feel before publishing.
Optionally adjust duration and easing: The Transition Duration field (milliseconds) and Easing dropdown sit immediately below the type selector. The defaults (300 ms, ease-in-out) work well for most apps. Tighten duration to 200 ms for snappy desktop apps.
Per-Navigate Action Override
Any individual Navigate action — Go to Page, Navigate Back, or Go to URL — can override the app-wide default with a different transition. This lets you use slide-left as your default for drill-down navigation while using slide-up specifically for a sheet-style settings page.
To set an override:
Select the component that triggers the navigation (e.g. a Button).
Open its Events panel and click the Navigate action.
In the action configuration panel, expand the Transition section.
Toggle Override default transition to on.
Choose the
transition,transitionDuration, andtransitionEasingvalues for this specific action.
Transition Properties Reference
The following properties are available both in the App Settings default and as per-Navigate overrides.
| Property | Type | Default | Description |
transition | enum | fade | The animation type to play. One of: none, fade, slide-left, slide-right, slide-up, slide-down, zoom-in, zoom-out, flip. When set on a per-Navigate action, overrides the app-wide default for that navigation only. |
transitionDuration | number (ms) | 300 | How long the animation plays, in milliseconds. Minimum is 0 (equivalent to none). Values above 600 ms are rarely perceptible as faster and can feel laggy. Recommended range: 150–400 ms depending on app type. |
transitionEasing | enum | ease-in-out | The CSS timing function that controls how the animation accelerates and decelerates. Options: ease, ease-in, ease-out, ease-in-out, linear. ease-out is commonly recommended for entrance animations; ease-in for exit animations. ease-in-out (the default) is a safe choice for both. |
Mobile vs Web Considerations
Transitions that feel native differ significantly between mobile and web. UnifyApps uses the same transition engine on both platforms, so the choice of transition type carries more weight on mobile where users compare the feel against native OS behaviour.
| Platform | Recommended transitions | Avoid |
| Mobile (iOS / Android) | slide-left / slide-right for stack navigation; slide-up / slide-down for modal sheets. These mirror native OS patterns users are already trained on. | fade feels slightly unnatural on mobile for standard navigation — reserve it for tab switches. Avoid flip outside of novelty use cases. |
| Web | fade is the safest default — subtly communicates page change without spatial disorientation. slide-left works well for clearly directional multi-step flows (wizards, checkout). | flip and zoom-in can feel heavy in a browser context where users expect more instant feedback. |
Tip: UnifyApps automatically honours the prefers-reduced-motion media query on web. When a user has enabled "reduce motion" in their OS accessibility settings, all transitions are downgraded to none regardless of your configuration. No extra work is needed on your part.
Conditional Transitions
You can bind the transition property on a Navigate action to an expression, making the animation depend on runtime state. The most common use case is matching the transition direction to the user's navigation direction — forward vs back.
📄 Example — Direction-aware transition
In a multi-step wizard, bind the transition property of your Navigate actions to:
{{ nav.direction === "forward" ? "slide-left" : "slide-right" }}
The nav.direction binding reflects the direction of the most recent navigation event. When the user clicks Next, the transition slides left (deeper). When they click Back, it slides right (shallower). The result is a spatial metaphor that mirrors native mobile app behaviour.
Other useful conditional patterns:
Use
fadewhen navigating to a top-level page andslide-leftfor detail pages:{{ page.isDetail ? "slide-left" : "fade" }}Use
nonefor system-initiated navigations (redirects, post-save auto-navigation) andslide-leftfor user-initiated ones.Use
slide-upwhen a modal query param is present,slide-downwhen dismissing.
Disabling Transitions
Set transition to none to make navigation instant — the new page appears with no animation. This is appropriate in several situations:
Data-heavy dashboards where page content changes significantly and the animation does not add clarity.
Programmatic redirects (e.g. authentication guards that bounce unauthenticated users to login) where you want the redirect to feel seamless rather than animated.
High-frequency navigation — if users navigate between pages many times per session, transitions accumulate time and can feel sluggish even at 300 ms.
Initial page load — the very first navigation to any page always uses
noneregardless of your setting, because there is no "previous page" to animate out of.
Note: Setting transition to none skips the transition system entirely. Setting transitionDuration to 0 runs the transition engine with a zero-length animation — the visual result is the same (instant swap) but incurs slightly more overhead. Prefer none when you genuinely want no animation.
Frequently Asked Questions
Can I control the transition when the user presses the browser back button?
The browser back button triggers a popstate navigation, which UnifyApps intercepts and routes through its navigation system. The app-wide default transition applies. If you want a different transition for back-navigations specifically, use a custom Back button component wired to a Navigate Back action and set an override on that action — for example, slide-right. Native browser back cannot be individually overridden at the action level because it bypasses the action system.
Do transitions play when switching tabs in a Tab Navigator?
Tab switches use the app-wide default transition unless you override it on the tab navigator's navigation items. For tab switches, fade or none is generally preferred because slide transitions imply a directional hierarchy that tabs do not have. Set the Tab Transition property in App Settings → Navigation → Navigator Type → Tab Navigator to control this independently of page-to-page transitions.
Transitions are not playing in the builder — is something wrong?
The builder canvas runs in a sandboxed iframe where some animations may be suppressed or simplified to keep editing performance high. Transitions always play correctly in Preview mode (click the play icon in the top bar) and in the published app. If a transition is missing in preview, check that the transition type is not none and that the duration is above 50 ms.