A mobile-web QA checklist for an AI agent on an iPhone
Disclosure: I make thumbs, one of the options below. I'll say where each option fits, including where mine doesn't.
"Does it work on a phone?" is easy to answer with a quick look at one page and easy to get wrong. A checklist helps, and an AI agent that can drive Safari on an iPhone is good at working through one, tirelessly and in the same order every time. This is the list I'd hand it. Each item is a check, a prompt and what to look for.
For setup and the options (local Simulator MCP, Appium, device clouds, a remote server), see how to test your web app on an iPhone with an AI agent. The first item has its own page: does the keyboard cover your Submit button?
How to run it
Give the agent the page's URL, the list below and a reporting format, so every run answers the same questions:
Open https://your-site.com in Safari on the iPhone. Work through
the checklist. For each item, reply PASS, FAIL or CAN'T TELL, with one
sentence of evidence and the screenshot. Don't submit forms, buy anything
or sign in to a personal account. Stop and tell me if something looks unsafe.
"CAN'T TELL" matters: it lets the agent say that it couldn't check something instead of guessing a PASS.
The checklist
- The keyboard doesn't hide the action. Tap each form field in turn. After each tap, is the keyboard showing, and is the Submit button visible or reachable by scrolling? (Full walkthrough in the keyboard guide.)
- No zoom on focus. Tap a text field. Does the page zoom in? Safari on iOS zooms into text fields with a font size under 16px.
- No sideways scroll. Swipe left and right on the first screen. Does the page move horizontally, or does anything get cut off at the right edge?
- The first screen says what the page is. Without scrolling, can the agent say what the product is and what the main button does? Is the main button visible and not under a banner?
- Tap targets are tappable. Ask the agent to tap the smallest links and buttons by their label. Do neighbouring targets get hit by mistake? Apple's design guidelines suggest at least 44 by 44 points for touch targets, and WCAG 2.2's minimum is 24 by 24 CSS pixels with exceptions; use whichever your team has committed to.
- Fixed headers and footers behave. Scroll down and back up. Does a fixed bar cover content, jump, or sit under Safari's own toolbar? Scroll to the very bottom: can the last line of text be read?
- Safe areas. On a phone with a home indicator, is anything stuck behind it at the bottom of the page? (
env(safe-area-inset-bottom)is the CSS for this.) - Menus and dialogs open and close. Open the navigation menu, a modal and a cookie banner. Can each be closed with a tap? Does the page behind still scroll when it shouldn't?
- The right keyboard for each field. Tap the email, phone and number fields. Does the keyboard match the field (
type="email",type="tel",inputmode)? Are autocapitalisation and autocorrect sensible for an email or a name? - Links go where they say. Tap the main navigation and one external link. Do they open the expected page? Is there a way back?
Making the report useful
- Ask for the screenshot with every FAIL, and look at them. An agent's reading of a picture is a lead, not proof.
- Ask it to name the element ("the 'Continue' button in the footer"), so the report maps to your code.
- Run the same prompt after each fix and compare. A saved prompt is a cheap regression check.
- Test the pages that matter: sign-up, checkout, pricing and a long article, not only the home page.
What an agent can't tell you
- Real-device conditions. thumbs' early access is the iOS Simulator: no real touch hardware, network or battery conditions, and no performance numbers you should trust for a real phone. A real iPhone of your own is planned; it isn't available yet and has no date or price.
- Other browsers and devices. Safari on one simulated iPhone isn't every phone, iOS version or third-party keyboard.
- Your logged-in states. The early-access Simulator is shared between testers, so don't sign in to personal accounts. Test with public pages, staging and test data.
- Payments, banking and Face ID. Not available: no banking apps, no Apple Pay, nothing behind Face ID.
- Accessibility. An agent can flag obvious problems, but it doesn't replace testing with VoiceOver or a proper audit.
It doesn't replace your test suite either. It's good for a "does this look and work right on a phone?" pass before a release.
FAQ
What should I check on a mobile website? At least the keyboard over forms, zoom on focus, sideways scroll, tap targets, fixed bars, safe areas, menus and dialogs, keyboard types for each field, and where links go.
Can an AI agent do mobile web QA? For a quick pass, yes, if it can open your page in Safari on an iPhone or the iOS Simulator, tap, type, scroll and take screenshots. It works best with a fixed checklist and a PASS, FAIL or CAN'T TELL answer per item.
Is the Simulator enough for mobile web QA? It's a good guide to Safari's layout and behaviour, but it has no real touch hardware, network or battery conditions. Check release-critical pages on a real device too.
Does thumbs run on a real iPhone? Not yet. Early access runs on the iOS Simulator, shared between testers, with Safari and Apple's built-in apps. A real iPhone of your own is planned, with no date or price.
Keep reading
- Does the iOS keyboard cover your Submit button?: the first check in depth.
- How to test your web app on an iPhone with an AI agent: setup and options.
- How to give an AI agent an iPhone with MCP: how it works under the hood.