Mobile Responsive Forms

Mobile forms are not a separate deliverable. Form.io renders the same JSON schema on desktop, tablet, and mobile devices. The responsiveness comes from the underlying CSS framework, primarily Bootstrap, which handles viewport adaptation through its grid system and responsive utilities. When you build a form in Form.io, you build it once. The renderer handles the rest.

This is fundamentally different from platforms that require you to design separate mobile layouts or toggle between “mobile view” and “desktop view” in a builder. Form.io forms are schema-driven data capture infrastructure. The schema defines structure and validation. The CSS framework handles presentation across screen sizes.

Bootstrap as the Responsive Mobile Forms Foundation

Form.io uses Bootstrap as its default CSS framework (more will be added). When you embed a form, you include the Bootstrap stylesheet alongside the Form.io library:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap/dist/css/bootstrap.min.css">
<link rel="stylesheet" href="https://cdn.form.io/formiojs/formio.full.min.css">
<script src="https://cdn.form.io/formiojs/formio.full.min.js"></script>

Bootstrap provides the responsive grid system that makes mobile forms work. The grid divides layouts into 12 columns that collapse and stack based on viewport width. On wide screens, multiple form fields can appear side-by-side. On narrow screens, those fields stack vertically. This happens automatically based on how you configure the Columns component.

Form.io supports Bootstrap 3, Bootstrap 4, and Bootstrap 5. You can switch versions based on your application’s existing CSS framework. Mixing Bootstrap versions within a single application creates styling conflicts, so match the version to whatever your application already uses.

The Columns Component and Mobile Forms Behavior

The Columns component is the primary tool for controlling how forms respond to different screen sizes. When you drag a Columns component onto a form, it creates multiple drop zones where you can place other components side-by-side.

Each column has a width property that specifies how many of Bootstrap’s 12 grid units it occupies. Two columns with width: 6 each split the form 50/50 on wide screens. On mobile viewports, these columns automatically stack vertically.

The column configuration schema looks like this:

{
  "type": "columns",
  "columns": [
    {
      "components": [],
      "width": 6,
      "offset": 0,
      "push": 0,
      "pull": 0,
      "size": "md"
    },
    {
      "components": [],
      "width": 6,
      "offset": 0,
      "push": 0,
      "pull": 0,
      "size": "md"
    }
  ]
}

The size property corresponds to Bootstrap’s breakpoint prefixes: xs, sm, md, lg, xl. Setting size: "md" means the columns stay side-by-side at medium viewport widths and above, but stack on smaller screens. This is the behavior most forms need: two-column layouts on desktop, single-column on mobile.

The documentation notes that columns should total 12 to span the full form width. If your widths add up to less than 12, you get empty space. If they exceed 12, columns wrap to the next line. Getting this wrong creates layout issues that appear differently across screen sizes.

Components That Respond Well (and Ones That Do Not)

Not all Form.io layout components handle mobile viewports equally.

Columns adapt well. They stack vertically on narrow screens, preserving the logical order of fields as defined in the schema. First name above last name, not side-by-side when there is no room.

Panels collapse their content gracefully. The collapsible setting is particularly useful on mobile where screen real estate is limited. Users can expand sections they need and keep others collapsed.

Tabs work on mobile but require touch-friendly navigation. The tab buttons remain accessible, and switching between tabs shows different component groups without scrolling through everything.

Tables, however, do not collapse responsively. The Layout Components documentation explicitly warns that tables may not respond well when collapsing to a mobile interface. If you need tabular data entry on mobile forms, consider the Data Grid or Edit Grid components instead, or use Columns to achieve a similar visual layout with proper responsive behavior.

Input Types and Mobile Keyboards

Mobile responsiveness is not just about layout. It includes input behavior. Form.io components automatically set appropriate HTML5 input types that trigger the correct mobile keyboard.

An Email component renders with type="email", which brings up a keyboard with @ and . easily accessible on mobile devices. A Phone Number component uses type="tel" to display a numeric keypad. A Number component uses type="number" to show a number-optimized keyboard.

These input types are set by the component definitions, not configured manually. When you use the correct component type for your data (Email for emails, Phone Number for phone numbers), mobile keyboards optimize automatically. This reduces user friction significantly on mobile forms where typing is already slower than desktop.

CSS Framework Flexibility

Form.io is not locked to Bootstrap. The templating system supports multiple CSS frameworks through the CSS Frameworks module:

  • Bootstrap 3, 4, and 5
  • United States Web Design System (USWDS)
  • UK Government Design System (GDS)
  • Bulma

Each framework has its own responsive grid system and breakpoint definitions. Switching frameworks changes how mobile forms render while keeping the form schema identical. A government application using USWDS gets USWDS-styled mobile forms. Same JSON schema, different presentation layer.

To switch frameworks, you configure the renderer globally:

import { Formio } from '@formio/js';
Formio.use(uswds);

The Modules documentation explains how to create custom template modules if your organization uses a CSS framework Form.io does not support out of the box.

Styling with Bootswatch Themes

For applications using Bootstrap, Bootswatch themes provide pre-built design variations that remain fully responsive. The Form.io examples demonstrate using Bootswatch’s Materia theme for a Material Design aesthetic:

<link rel=”stylesheet” href=”https://cdn.jsdelivr.net/npm/bootswatch/dist/materia/bootstrap.min.css”>

<script src=”https://cdn.form.io/js/formio.embed.js?src=https://examples.form.io/example”></script>

Bootswatch themes do not change responsive behavior. They change colors, typography, and visual styling while inheriting Bootstrap’s grid system. Your mobile forms look different but respond the same way across screen sizes.

Custom CSS for Mobile Adjustments

The Customize With CSS feature allows adding custom styles to forms. For mobile-specific adjustments, use CSS media queries:

@media (max-width: 768px) {
  .formio-component-textfield input {
    font-size: 16px; /* Prevents iOS zoom on focus */
  }
  
  .formio-component-button button {
    width: 100%;
    padding: 12px;
  }
}

A common mobile issue: iOS Safari zooms the page when users focus on input fields with font-size smaller than 16px. Setting font-size: 16px on mobile prevents this zoom behavior.

Custom CSS classes can be added to any component through the component settings. This lets you apply mobile-specific styling to individual fields without affecting the entire form.

Testing Mobile Forms

Form.io does not provide a built-in mobile preview in the form builder. To test mobile forms:

Browser DevTools offer device emulation. Chrome and Firefox let you simulate specific devices and viewport sizes. This catches most layout issues but does not perfectly replicate mobile browser behavior.

The Launch feature in the Developer Portal creates a standalone URL for any form. Open this URL on actual mobile devices to test real touch interactions, keyboard behavior, and scrolling.

Embedded testing in your actual application is the most accurate. Mobile forms should be tested in context, with your application’s navigation, headers, and other UI elements present.

Offline Mode on Mobile Devices

Mobile forms often need to work without connectivity. The Offline Mode feature caches forms and submissions locally using IndexedDB, which works in mobile browsers. Users can fill out forms while offline, and submissions sync when connectivity returns.

Offline mode is particularly relevant for field workers using mobile devices in areas with unreliable network coverage. The form renders from cached data, submissions queue locally, and the sync happens automatically. The mobile form experience remains consistent regardless of network state.

What Mobile Forms Require from Your Application

Form.io provides responsive rendering, but your embedding application must support it properly.

Viewport meta tag is required. Without it, mobile browsers render pages as if they were desktop-width, then scale down. Include this in your HTML head:

<meta name="viewport" content="width=device-width, initial-scale=1">

CSS framework loading must happen before form rendering. If Bootstrap loads after the form renders, you get unstyled forms that later flash into styled state.

Container width affects form layout. If you embed a form in a fixed-width container, the form cannot be wider than that container. Mobile responsiveness works within the container bounds, not the full viewport.

What Mobile Forms Do Not Include

Form.io mobile forms are responsive web forms. They are not native mobile applications.

Native components like iOS date pickers or Android-specific UI elements are not used. Form.io uses HTML5 form elements styled by CSS. On mobile, these get browser-native input behaviors (like date picker interfaces) but not platform-native components.

Push notifications, camera access, or device features are outside Form.io’s scope (though the camera access is achievable with the file component). If your application needs these capabilities, you build them in your application layer and integrate with Form.io through the API orSDK.

Native mobile app embedding is possible through WebViews. React Native, Flutter, and other mobile frameworks can render Form.io forms in embedded web views. The forms remain web-based but display within native app containers.

When to Avoid Multi-Column Mobile Forms

The safest mobile form layout is single-column. Every field stacks vertically, matching how users scroll on mobile devices. Multi-column layouts work when fields are logically grouped (first name next to last name), but they add complexity.

Consider single-column layouts for:

  • Long forms where vertical scrolling is unavoidable
  • Forms with complex conditional logic that shows/hides fields
  • Forms used primarily on mobile devices
  • Public-facing forms where you cannot control device diversity

Use multi-column layouts for:

  • Internal applications with known device constraints
  • Forms where desktop usage dominates
  • Short forms where everything fits above the fold on most screens
  • Forms with obviously paired fields (address line 1 and 2, city and state)

The Columns component gives you control, but restraint often produces better mobile experiences.

Related Resources