My AI-Built App Works on Desktop but Breaks on Phones

An AI-built web app that works on desktop but breaks on phones usually has one of seven causes: panels sized with 100vh, fixed widths that force sideways scrolling, menus that need hover, tap targets too small for a thumb, form fields that zoom on iPhone, an on-screen keyboard covering the button, or content under the notch. Each takes minutes to find on a real phone.

If you would rather have your app tested on real phones for you, see how RAITHub would test this below.

The reason is simple. Lovable, Bolt, v0, Cursor and Replit are used in a desktop browser, with the app in a wide preview pane, and the person prompting rarely opens it on a phone until launch. Your users do the opposite: mobile was 58.99% of worldwide web traffic in September 2026, against 39.26% for desktop (StatCounter). AI tools write responsive-looking code; they do not hold a phone. This post is for web apps viewed in a phone browser. For native iOS and Android apps, use the mobile app testing checklist; for browser coverage in general, the cross-browser testing checklist.

What breaks on phones, and how do you fix it?

Symptom on the phone	Usual cause in generated code	Fix
Bottom button hidden behind the browser bar	A full-screen panel with h-screen or 100vh	Use 100dvh or 100svh
Page scrolls sideways	A fixed width, a wide table, a long URL or an image with no max width	Find the overflowing element; wrap tables in a scroll container
Menu or tooltip never opens	Content shown only on hover	Open on tap; do not hide actions behind hover
Wrong item tapped	Icon buttons and links smaller than a fingertip, packed together	At least 24 by 24 CSS pixels, with spacing
Page zooms in when a field is tapped, and stays zoomed	Input text smaller than 16px on iPhone	Set form fields to 16px or larger
Keyboard covers the submit button or the field	Fixed footers and modals sized to the full screen	Let the form scroll; test with the keyboard open
Header or tab bar under the notch or home indicator	Edge-to-edge layout without safe-area padding	Pad with env(safe-area-inset-*)

Why is the bottom of the screen cut off?

Because 100vh on a phone is the height with the browser's toolbars hidden. web.dev explains that elements "sized to be 100vh tall will bleed out of the viewport" on mobile, because vh does not account for toolbars that expand and retract (web.dev on viewport units). Generated layouts love full-height panels: a chat screen with the input at the bottom, an onboarding step with a Continue button, a checkout summary. On the phone, the button sits under the address bar.

The fix is the newer units: svh (toolbars shown), lvh (toolbars hidden) or dvh, which changes as the toolbars move. For a screen with a button pinned to the bottom, 100dvh is usually what you meant.

/* Before: generated full-height layout */
.screen { min-height: 100vh; }

/* After */
.screen { min-height: 100dvh; }

/* Keep pinned bars clear of the home indicator */
.bottom-bar { padding-bottom: calc(1rem + env(safe-area-inset-bottom)); }

/* Stop iPhone zooming into form fields */
input, select, textarea { font-size: max(16px, 1em); }

In Tailwind, which many AI builders generate, the equivalents are classes such as min-h-dvh in place of min-h-screen.

Why does the page scroll sideways?

One element is wider than the screen, and it drags the whole page with it. The usual suspects in generated code are data tables, fixed pixel widths copied from a desktop design, long unbroken strings such as emails and URLs, code blocks, and images without a maximum width. It often appears only with real data: the demo had short names; your customer's company name is forty characters.

A Playwright check finds it on every page, at phone sizes, on every release:

// playwright.config.ts: run every test on two phone profiles
import { defineConfig, devices } from '@playwright/test'

export default defineConfig({
  projects: [
    { name: 'iphone', use: { ...devices['iPhone 13'] } },
    { name: 'android', use: { ...devices['Pixel 7'] } },
  ],
})

// tests/no-sideways-scroll.spec.ts
import { test, expect } from '@playwright/test'

const pages = ['/', '/signup', '/dashboard', '/settings', '/billing']

for (const path of pages) {
  test('no sideways scroll on ' + path, async ({ page }) => {
    await page.goto(path)
    const overflow = await page.evaluate(
      () => document.documentElement.scrollWidth - document.documentElement.clientWidth,
    )
    expect(overflow).toBeLessThanOrEqual(0)
  })
}

Pages behind a login need a saved session; Playwright's authentication setup handles that. Playwright's device profiles simulate "user agent, screen size, viewport" for a given device (Playwright emulation docs), which makes them good at catching layout bugs on every change. They are not a real phone, so keep a manual pass on hardware too.

Why do menus and tooltips not work?

Phones have no hover. A dropdown that opens on mouse-over, an edit button that appears when the pointer is over a row, or an explanation in a tooltip simply does not exist for a phone user. Desktop previews never show the problem because the builder always has a mouse. Test every menu, row action and info icon by tapping. If an action matters, it should be visible or one tap away, not revealed by hover. The CSS hover media feature lets you adjust styles for devices without hover, but the safer fix is not to depend on it.

Why do users tap the wrong thing?

Icon buttons in generated UIs are often small and tightly packed: edit, delete and share, side by side in a table row. WCAG 2.2 success criterion 2.5.8, Target Size (Minimum), at level AA, asks for targets of at least 24 by 24 CSS pixels, with exceptions such as enough spacing around a smaller target (W3C, Understanding SC 2.5.8). That is a minimum, not a comfortable size; a destructive action next to a harmless one deserves more room and a confirmation. The full accessibility pass is in the accessibility testing checklist.

Why does the page zoom when I tap a field?

On iPhone, Safari zooms into a form field when its text is smaller than 16px, and the page often stays zoomed after the field loses focus. Component libraries that default to 14px inputs trigger it; one example is a 2025 issue raised against HeroUI's input components (HeroUI issue #5326). The fix is a 16px minimum on form fields, as in the CSS above. Do not "fix" it by disabling zoom in the viewport tag; people who need to zoom then cannot.

Does Chrome on iPhone need separate testing?

Usually not as a separate engine. Outside the EU, browsers on iOS use Apple's WebKit engine; Apple allows alternative browser engines only for EU users, on iOS 17.4 and later (Apple developer support). So a bug in Safari on iPhone usually appears in Chrome on iPhone too, and testing on an Android phone in Chrome tells you little about iPhones. Test one of each.

What else breaks only on phones?

• The keyboard covers the form. Open every form on a phone, tap the last field, and check you can still see what you type and reach the submit button.
• Content under the notch. Edge-to-edge headers and bottom bars need safe-area padding. MDN describes the safe-area-inset-* values as the space where content will not be "obscured by device notches or rounded corners" (MDN on env()).
• Uploads. Uploading a photo from the camera or the photo library can fail where a desktop file worked, because phone photos are large and may come in a format your code did not expect. Try both.
• Payment pop-ups. 3-D Secure challenges and wallet sheets behave differently on phones; see testing payments in an AI-built app.
• Slow networks. A phone on mobile data shows every oversized image and every blocking script. Check key pages against Google's Core Web Vitals on a throttled mobile profile.
• Rotation and split screen. Turn the phone sideways mid-form; nothing should reset.

How do you test this on real phones without a device lab?

1. Start with what you own. One iPhone and one Android phone cover most issues. Run each core journey, sign-up to the main action to payment, on both.
2. Add browser developer tools. Responsive mode in Chrome or Firefox, at 360 and 390 pixels wide, catches overflow quickly. It does not show toolbars, keyboards or notches.
3. Automate the layout checks. The Playwright test above, run in CI, stops a later prompt from bringing the bug back.
4. Use a device cloud for the long tail. Older iPhones, small Androids and tablets, rented by the minute. Real devices, emulators or a device cloud compares the options.

How long does this take to fix yourself?

Finding the problems takes 1–2 hours on two phones for a small app. Fixing them takes from an hour, for viewport units and input sizes, to a couple of days if tables and dashboards need a real phone layout. The main risk of asking your AI tool to "make it responsive" is that it rewrites layouts you already checked and breaks a page you did not look at. Ask for one fix at a time, and re-run the overflow test after each.

What should you test first on a small budget?

The sign-up flow and the one action users pay for, on one real iPhone and one real Android phone, with the keyboard open. Those are the screens where a phone bug costs you a customer. Then add the overflow test to CI. The rest of the pre-launch list is in the AI-built SaaS launch checklist, and the other bugs users find first are in the bugs users find first in AI-built apps.

Buy, build or hire?

Option	Choose this when	Trade-off
A tool or SaaS testing platform (Playwright device profiles, a device cloud)	A developer can maintain layout tests and run a device cloud before releases	Catches overflow and layout on every change; misses keyboards and real-world feel
Freelancers or crowdtesting	You want many real phones on the app for a launch	Wide device coverage; report quality varies
An in-house QA hire	Most of your users are on phones and you ship weekly	Owns the device shelf; slow to hire
A managed QAaaS team or a one-off launch audit	You want every journey checked on real iPhone and Android devices before launch	An outside dependency; keep the tests and reports

Costs are compared in mobile app testing cost, which also applies to mobile web.

Why RAITHub for this

• Real devices and device clouds. RAITHub tests on real iOS and Android phones, combining exploratory testing with automated layout checks.
• Bug reports you can paste back into your AI tool. Each bug comes with the device, OS and browser, steps, expected and actual results, and a screenshot or recording, plus the likely cause in the code.
• Engineering habits. RAITHub's own products run large automated suites: 1,024 tests on PropDesk, 750+ on TheSkinProof (the founder's own venture) and 400+ on this website. There is no AI-built-app case study yet.
• Testing, not mobile app development. RAITHub tests mobile web and native apps; it does not build native mobile apps.

When you don't need us

• Your users are all on desktop, for example an internal tool used at work stations. Check your analytics first.
• You own an iPhone and an Android phone and can spend an afternoon on the steps above.
• The app needs a native rebuild rather than layout fixes. That needs a mobile development team.

How RAITHub would test this

• Scope: confirm your core journeys and the phones your users carry, from analytics if you have them, on a free 15-minute call.
• Manual pass: every journey on real iPhone and Android devices, with the keyboard, rotation, slow network, uploads and payments.
• Automation: overflow and layout checks at phone sizes in your CI, so the next prompt cannot reintroduce the bugs.
• Report: bugs ranked by how many users they block, each with device details, evidence and a suggested CSS or component fix.
• What you receive: the report, the tests in your repository and a handover note. IP is yours; an NDA is standard.

The audit is fixed-price, quoted in writing after the call. See AI-built app testing, mobile app testing and the QA as a service overview, or ask for a launch audit on real phones.

Frequently asked questions

Why does my app look fine on desktop but broken on my phone?

Because it was built and previewed on a desktop. The common causes are full-height layouts using 100vh, fixed widths that overflow, hover-only menus, small tap targets, input zoom on iPhone, the keyboard covering buttons and content under the notch.

How do I fix 100vh on mobile?

Use the newer viewport units: 100dvh follows the browser toolbars as they show and hide, and 100svh assumes they are shown. In Tailwind, use min-h-dvh instead of min-h-screen.

Why does iPhone zoom in when I tap a text field?

Safari on iPhone zooms into form fields whose text is smaller than 16px. Set inputs, selects and text areas to at least 16px. Do not disable zoom in the viewport tag, because people who need zoom lose it.

Is Chrome's mobile view in developer tools enough to test?

It catches sideways scrolling and broken layouts quickly, but it does not show real toolbars, the on-screen keyboard, notches, touch behaviour or real network speed. Do a final pass on at least one real iPhone and one Android phone.

Can I just ask my AI tool to make the app responsive?

You can, but ask for one specific fix at a time and recheck every page afterwards. A broad "make it responsive" prompt can rewrite layouts that already worked. An automated overflow test in CI catches regressions.

Does RAITHub build mobile apps?

No. RAITHub tests mobile web apps and native iOS and Android apps on real devices and device clouds, and can fix web layout bugs, but does not develop native mobile apps.