Page Layout
Every page in UnifyApps is divided into three layout regions that appear on the canvas. Each region is independent — it holds its own block tree, and you can place any component in any region.
| Region | Position | Typical use |
| Header | Fixed band above the body | Navigation bar, logo, breadcrumb, global search, user account menu. |
| Body | Central scrollable content area | Main page content — tables, forms, dashboards, charts, cards, detail views. |
| Footer | Fixed band below the body | Legal text, secondary links, status bars, sticky action buttons on mobile. |
Header and footer are optional. A page with neither renders the body region at full height. You can show and hide individual regions by toggling them in Page Settings.
Tip: If you want a consistent header or footer across many pages, consider building it as a module and embedding the module in each page's header or footer region. Changes to the module propagate to all pages that use it without individual edits.
Drawer Layout
In addition to the standard three-region layout, each page has a Drawer layout — a separate arrangement used when that page is presented as a drawer (a slide-in panel) rather than a full-screen navigation target.
The Drawer layout has its own block tree, independent of the standard layout. This lets you design a compact, focused view of a page for drawer context while maintaining a separate full-page layout for direct navigation.
Note: Do not confuse the Drawer layout with the Drawer component. The Drawer component is a block that overlays content on the current page — the underlying page stays mounted and its variables are untouched. The Drawer layout is an alternate view of a separate page, shown when that page is navigated to in drawer mode.
Custom Head Content
The Custom Head section in Page Settings lets you inject content into the HTML <head> of the page without writing full HTML. This is the recommended way to add SEO metadata and lightweight third-party integrations.
Meta Tags
Add meta tags as name-and-content pairs. Each pair produces a <meta name="…" content="…"> tag in the rendered page. Common uses:
description— the snippet text shown in search engine results.og:title,og:image— Open Graph tags for social sharing previews.robots— control crawler indexing behavior (noindex,nofollow).
Extra Stylesheets
Add stylesheet URLs to load external CSS files. The platform injects a <link rel="stylesheet"> tag for each URL. Use this for lightweight third-party CSS libraries that do not warrant a full custom component.
Extra Scripts
Add script URLs to load external JavaScript files. Each URL becomes a <script src="…"> tag in the page head. This is appropriate for analytics snippets, consent management tools, or other scripts that must load early.
Warning: Scripts and stylesheets added via Custom Head run for every visitor who opens the page, including visitors to pages with Public access. Avoid placing scripts that require authentication or that expose sensitive credentials in this slot.
Custom Code Slots
Beyond the head, each page provides two custom code slots:
| Slot | Position in HTML | Typical use |
| Header code | End of <head> (after platform-injected content) | Inline styles, early-loading analytics initialization, custom fonts via @font-face. |
| Footer code | End of <body> (after all page content) | Deferred analytics, third-party chat widgets, scripts that depend on the DOM being ready. |
Like head scripts, custom code slots ship with the page and run for every visitor. There is no platform-provided sandboxing for custom code — you are responsible for ensuring it does not conflict with the UnifyApps runtime.
Export Layout
The Export Layout is a separate header and footer shown on each page of exported output (such as a PDF export). It is completely independent of the on-screen header and footer and is designed for printed or downloaded output rather than interactive use.
Configure the export layout in Page Settings under the Export section. You can place page number placeholders, a company logo, document titles, and any static content that should repeat across exported pages.
Mobile System Bars
On mobile devices, the operating system renders a status bar at the top (showing time, battery, and signal) and a navigation bar at the bottom (showing home, back, and recent apps gestures). UnifyApps lets you control the color scheme of both bars per page.
| Setting | Values | Effect |
Status Bar | Light / Dark / Auto | Controls the color of text and icons on the status bar. Light = white icons (use on dark headers). Dark = dark icons (use on light headers). Auto = follows OS preference. |
Navigation Bar | Light / Dark / Auto | Same as status bar, but for the bottom system navigation bar. |
Note: System bar style settings have no visible effect on desktop browsers. They apply only when the app is accessed from a mobile browser or rendered as a progressive web app on a mobile device.
Page Folders
Folders let you group related pages into a nested tree. A folder becomes a URL segment, so the folder structure directly determines the URL hierarchy of your application.
Folder Basics
A page belongs to at most one folder.
Folders can be nested inside other folders to arbitrary depth.
Each folder adds a path segment to the URLs of all pages inside it.
Changing a folder's name or parent changes the URLs of every page inside it.
🌎 URL structure from folder nesting
App base URL: https://yourapp.com/ Folder: settings (static) Page: profile → https://yourapp.com/settings/profile Page: billing → https://yourapp.com/settings/billing Folder: orders (static) Folder: :orderId (dynamic, mock: "12345") Page: detail → https://yourapp.com/orders/:orderId/detail Page: timeline → https://yourapp.com/orders/:orderId/timeline
Folder Settings Panel
Click a folder in the Navigator to open its settings panel. Changes save immediately — there is no separate publish step for folder settings.
| Setting | Description |
Name | The URL-safe folder slug. Lowercase letters, digits, and hyphens only. No spaces, slashes, or leading/trailing hyphens. |
Parent | Which folder contains this folder, or Root for a top-level folder. |
Type | Static or Dynamic — see below. |
Redirect | Optional. When set, visitors who navigate to the folder's path are redirected to the specified page. Can carry path params. Useful when the folder itself has no content. |
Static vs. Dynamic Folders
The most important folder setting is its type. This controls whether the folder's URL segment is a fixed literal or a captured value.
| Type | URL segment | Behavior |
| Static | A fixed literal (e.g., settings, admin) | The folder only matches that exact path segment. Visitors must know the literal name to reach pages inside. |
| Dynamic | A named parameter (e.g., :orderId, :userId) | The folder matches any value in that URL position and captures it as a named parameter. Pages inside can read the captured value as a page parameter. |
Dynamic Folder Mock Value
Because the builder cannot know the real runtime value of a dynamic parameter, dynamic folders have a Mock value field. The mock value is used only in the builder and preview environments to construct a valid preview URL. It is never used in the published application.
Tip: A good mock value mirrors the shape of real data. If the dynamic parameter is an order ID like ORD-00123, use that format as the mock rather than a placeholder like 123. This makes the builder URL more representative and reduces confusion when sharing preview links with teammates.
Folder Redirects
A folder redirect sends visitors who navigate to the folder path to a specific page instead. This is useful when:
A folder contains multiple pages but has no natural "landing" page at its own path.
You have reorganized pages and want old folder paths to forward to new locations.
A dynamic folder should always drop visitors into a specific child page.
The redirect target can be any page in your app. For dynamic folders, you can pass the captured path parameter to the target page as an input so it carries the value through the redirect.
Folder Constraints and Warnings
Warning: Any bookmarks, external links, or integrations that point to pages inside the renamed folder will stop working. There is no automatic redirect from old URLs to new ones. Plan folder renames carefully in production applications.
| Constraint | Detail |
| Cannot delete a non-empty folder | The platform shows a panel listing all pages inside the folder. Move or delete each page first, then delete the folder. |
| Folder name validation | Letters, digits, and hyphens only. Spaces, slashes, leading hyphens, and trailing hyphens are rejected immediately. |
| Concurrent editing | If a collaborator is editing the same folder settings simultaneously, the platform warns you before overwriting their changes — but only if your local form has unsaved edits. |
| Folder settings save immediately | There is no draft state for folder settings. Saving applies the change immediately to the published URL structure. |
Organizing Pages Effectively
Well-organized page folders make your application's URL structure intuitive for users and easier to maintain for your team. Here are practical guidelines:
Group Pages by Domain, Not by Feature
Prefer grouping pages by the data entity or user task they relate to rather than by the feature that generates them. For example, group all order-related pages under an orders folder, rather than separating them by the team that owns each page.
Limit Nesting Depth
URLs longer than three segments become unwieldy and harder to share. A depth of two or three folder levels (e.g., /orders/:orderId/timeline) is usually sufficient. Deeper nesting should be justified by a genuine hierarchy in the data model.
Use Static Folders for Named Sections
Top-level application sections — settings, reports, admin — are good candidates for static folders. They communicate the app's structure at a glance in the URL bar and in the Navigator tree.
Use Dynamic Folders for Records
Any folder that exists to scope pages to a specific record — an order, a user, a project — should be dynamic. The captured parameter flows into the pages inside it, so each page can fetch and display the right record without additional routing configuration.