How to Make a Settings Menu That Works Everywhere

A settings menu that adapts to any screen needs three things: controls that work with both touch and pointer input, a layout that reflows without breaking, and a save system that persists correctly on every platform. Getting these right once is far less work than maintaining separate settings screens per device.

Why settings menus break across platforms

Settings menus break because they are usually built for one input method and one screen size, then stretched to fit others.

The common failures are predictable. Sliders that are too small for fingers. Toggles that do not respond to keyboard navigation. Scroll areas that clip on short screens. Text that overflows on narrow ones.

These all come from building to a specific device first and adapting second. The fix is to design for the constraints simultaneously.

Controls that work with touch and pointer

Every control in the menu needs to handle two input modes without separate code paths.

Toggles. Use a tap or click target of at least 44 by 44 points. This is large enough for thumbs and not too large for a mouse. The visual element can be smaller as long as the hit area is not.

Sliders. The track needs enough height for a finger drag, and the thumb needs enough width to grab. Add a numeric display beside the slider so players know the exact value without needing pixel-perfect positioning.

Dropdowns and pickers. On touch, these should open a full-width panel or a native picker. On desktop, a standard dropdown works. The behaviour difference can be driven by input detection rather than platform detection.

Design for the largest input method first, then verify it works with the smallest. A control sized for a thumb always works with a mouse. The reverse is not true.

Back and close buttons. Place them where the platform expects. Top left on most mobile platforms, top right or escape key on desktop. Support the system back gesture on Android.

Layout that reflows without separate builds

A single-column layout with a scrollable body handles every screen size.

Three rules for the reflow.

1. Labels above controls on narrow screens, beside them on wide. This single change handles most of the difference between phone and desktop.
2. Group related settings with clear headers. On a narrow screen, groups stack. On a wider screen, groups can sit side by side.
3. Never rely on horizontal scrolling. Every row fits the narrowest supported width.

Keep the categories list short. Audio, Graphics, Controls, and Account cover most games. Adding more categories to look thorough creates navigation cost without adding value.

Safe areas and notches

Modern phones clip content behind notches, camera cutouts, and rounded corners. Settings menus are particularly vulnerable because they are full-screen and text-heavy.

Respect the safe area insets on every edge. The top and bottom matter most, but some devices also have lateral insets.

Place close buttons and top headers inside the safe area, not at the physical edge. A close button hidden behind a notch makes the menu feel broken.

Test on at least one device with a notch and one without. The difference surfaces immediately and the fix is usually a single padding value.

Saving settings correctly

Settings need to persist across sessions and survive interruptions. The implementation varies by platform, but the principles do not.

Save on change, not on close. Players expect a toggle to take effect immediately. A settings menu with a save button feels outdated and creates a failure mode where changes are lost.

Use the platform's preferred storage. PlayerPrefs on Unity, SharedPreferences on Android, UserDefaults on iOS. These survive updates and are backed up appropriately.

Handle missing values gracefully. When a setting has no saved value, use a sensible default rather than throwing an error. This covers first launch, cleared data, and platform migration.

Validate on load. A graphics quality setting saved as "Ultra" on a device that no longer supports it should fall back to the next available level rather than crashing.

Three edge cases that cause bugs.

1. The player changes a setting and immediately backgrounds the app. If saving is async, the write may not complete.
2. Two settings conflict. Enabling vibration on a device without a motor should either hide the option or show it as unavailable.
3. A setting requires a restart. Tell the player before they change it, not after.

Accessibility in settings

Settings menus are where accessibility matters most, because this is where players go to fix problems.

• Text size. If the game has a text size option, it should apply to the settings menu itself. A player who needs larger text cannot read a normal-size menu to find the setting.
• Colour. Use sufficient contrast for every text and control element. A settings menu styled to match a dark game theme often fails contrast checks.
• Screen readers. Label every control. A toggle labelled "Sound" reads correctly. A toggle with no label reads as "toggle, off" and tells the player nothing.
• Motor. Ensure every action is reachable without precise gestures. Settings should work with switch control and keyboard navigation.

Accessibility in the settings menu is not a feature. It is the minimum required for the rest of the accessibility features to be reachable.

What we would do

Build the settings menu before the rest of the UI, not after. It is the simplest full-screen menu in the game, and solving layout, input, and persistence here establishes patterns that every other menu reuses.

Start with a single scrollable column, four categories, and controls sized for touch. Verify it on your narrowest and widest target screens. Then add platform-specific polish like native pickers and keyboard navigation after the core works everywhere.

Test the save system by changing a setting, killing the app from the task switcher, and relaunching. That one test catches most persistence bugs.

The short version

• Size every control for touch input first: 44 by 44 point minimum hit areas.
• Use a single-column layout that reflows based on width, not platform.
• Respect safe area insets on all edges, especially for close buttons.
• Save on change, not on close, and validate saved values on load.
• Make the settings menu itself accessible, since it is where players go to fix problems.
• Build settings first and let it set the patterns for every other menu.

Build your settings menu as the first screen and test it on two screen sizes. If you want a cross-platform UI review, get in touch.