Bolt mobile layout broken: fixing a Bolt web app on phones, and when you need Expo

Bolt builds two kinds of project, and "broken on mobile" means something different for each. A web app is a website that has to work in a phone browser. An Expo project is a mobile app that runs in Expo Go and can be published to the App Store and Google Play. The fixes overlap less than you'd think, so check which one you have before you prompt for "make it responsive".

Symptom

On a Bolt web app:

• The page scrolls sideways, or content is cut off on the right.
• Tables and dashboards are unreadable, or modals open off-screen.
• A full-height section jumps or leaves a gap when the browser bar shows and hides.
• Buttons and links are too small or too close to tap.

On an Expo project:

• Content sits under the notch or status bar, or behind the home indicator.
• The keyboard covers the input you're typing into.
• Device Preview won't open in Expo Go. Bolt's docs quote the message you see on the phone:

Why it happens

The preview isn't a phone. Bolt's preview sits in a desktop browser at whatever width your window allows. Bolt has Responsive mode above the preview for this, but it's easy to build a whole app without opening it.

Visual edits apply everywhere. The Select tool's toolbar covers font size, alignment, colours, opacity and similar properties. It has no screen-size option, so a font size that looks right on desktop is the same size on a phone.

Broad prompts give broad changes. "Make it mobile friendly" asks Bolt to touch every screen at once. Bolt's own troubleshooting says large, multi-part prompts are the usual reason it only does part of what you asked.

Web and native are different builds. Bolt's Expo docs say projects created for web don't easily switch to mobile. A web app squeezed onto a phone is still a website, and app stores need the Expo route.

Expo Go needs Bolt's terminal signed in. Expo Go expects the terminal running your preview to be signed in to the same Expo account as your phone, and Bolt's terminal isn't your computer, so browser-based login gets stuck.

The fix

1. Reproduce it properly

1. Above the preview, click Responsive mode and check the narrowest phone size.
2. Publish, then open the live site on a real phone. Bolt's published site is what users get, and real browser bars and keyboards only show up there.
3. In the browser on your computer, find the culprit for sideways scrolling by pasting this into the DevTools console:

[...document.querySelectorAll("body *")]
  .filter((el) => el.getBoundingClientRect().right > document.documentElement.clientWidth)
  .forEach((el) => console.log(el));

2. Pin each problem with a comment

Open Comments in the project header, click the exact spot in the preview, and describe the fix: "On phones, stack these cards in one column and let the table scroll sideways inside its card." Then select the comments and send them to Bolt. Bolt includes the visual context from each pin, which beats describing the element in words. Comments work in the preview, not on the published site.

3. Fix the common causes in code

If your project uses Tailwind CSS (check Code view for a Tailwind config file, or classes like px-4 and md:flex in components), these patterns fix most web layout breaks:

// Wide tables: scroll inside their own box, not the whole page
<div className="w-full overflow-x-auto">
  <table className="min-w-[640px] w-full text-sm">{/* rows */}</table>
</div>
 
// Flex children that refuse to shrink: allow text to wrap
<div className="flex items-start gap-3">
  <img src={avatar} alt="" className="h-10 w-10 shrink-0 rounded-full" />
  <p className="min-w-0 break-words">{message}</p>
</div>
 
// Full-height screens: use dynamic viewport units (Tailwind 3.4 or later)
<main className="min-h-dvh">{children}</main>
 
// Stack on phones, side by side from the md breakpoint up
<section className="grid grid-cols-1 gap-4 md:grid-cols-3">{cards}</section>
 
// Tap targets: at least 44px tall (min-h-11 needs Tailwind 3.4 or later)
<button className="min-h-11 px-4">Save</button>

Also check index.html has a viewport tag. Without it, phones render the page at desktop width and shrink it:

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

4. Fix Expo layouts with safe areas

For an Expo project, wrap screens in a safe area so content clears the notch and home indicator, and move inputs above the keyboard:

import { KeyboardAvoidingView, Platform, TextInput } from "react-native";
import { SafeAreaView } from "react-native-safe-area-context";
 
export default function NoteScreen() {
  return (
    <SafeAreaView style={{ flex: 1 }}>
      <KeyboardAvoidingView
        style={{ flex: 1 }}
        behavior={Platform.OS === "ios" ? "padding" : undefined}
      >
        <TextInput placeholder="Write a note" style={{ marginTop: "auto", padding: 16 }} />
      </KeyboardAvoidingView>
    </SafeAreaView>
  );
}

Expo's docs say react-native-safe-area-context comes with Expo Router projects. Otherwise install it and add SafeAreaProvider at the root.

5. Get Device Preview working

Click Device Preview next to Responsive mode and scan the QR code with Expo Go. If you get the sign-in message, Bolt's fix is a personal access token: create one at expo.dev, then add it under the database icon, Secrets, as EXPO_TOKEN (or in .env). Run npx expo login again in Bolt's Terminal tab.

6. Decide if you need an app at all

If customers mostly use the product in a phone browser, fix the web layout. If you need to be in the App Store or Google Play, that is an Expo project. Bolt's docs say web projects don't easily switch over, and that saying mobile app in the very first prompt sets up the right foundation.

How to prevent it

• Open Responsive mode after every screen Bolt builds, not at the end.
• Add a project skill with your layout rules, for example "every table scrolls inside its own container" and "tap targets are at least 44px". Bolt applies skills automatically when a prompt matches, and project skills are stored in the code.
• Bolt also has a curated Web Design Guidelines skill, off by default. Its docs don't say what it contains, so read what it changes before relying on it.
• Fix one screen per prompt.

When to get help

Patching breakpoints screen by screen gets you to usable. A layout that feels designed for phones usually needs the navigation and information hierarchy rethought. Fixing mobile layout in AI-built apps goes into that, and if phones are also slow, see Bolt app slow. The fix guide for vibe-coded apps covers the other common failures, and taking a Bolt app to production has the launch checklist.

Run the free vibe-code health check first. If the layout needs a proper phone-first pass, a Rescue Sprint is an audit plus fixes at a fixed price agreed after a technical assessment (from £750).