A layout that breaks on iPhone SE and nowhere else comes down to the SE being the odd one out among current iPhones: at 375 points it is narrower than a modern phone like the iPhone 15 (393 points), at 667 it is the shortest, and it has no notch. So content sized for a wider screen runs off the edge, a fixed-height stack that fits a taller screen clips at the bottom, or inset code written for a notch sits wrong on the home-button safe area. The SE simulator ships free with Xcode, so your first look is to add that runtime or open a SwiftUI Preview at 667 points.
It looks right on your 6.7-inch simulator
You built the screen on a Pro-sized simulator or your own notched phone. Text sat on one line, cards aligned. Nothing was cut off. Then QA attaches a screenshot from an iPhone SE where a price truncates to an ellipsis, the checkout button sits half off the bottom edge, or a pinned footer overlaps the content above it. You open your usual simulator, cannot reproduce it, and start wondering whether the screenshot came from a stale build.
Narrower and shorter than everything else you test on
The SE is the outlier on two axes. It is 375 points wide, narrower than the iPhone 14, 15, and 16 (390 to 393 points), and at 667 points it is the shortest current iPhone. It matches the old iPhone X, XS, and 11 Pro at 375 wide, but if your other test devices are modern, you never see the narrower width. An SE-only break is one of three things.
Horizontal overflow. Content laid out for a 393-point width, a row of fixed-width cards, an HStack that sums past 375 points, or copy that will not wrap, runs off the right edge at 375, so a price truncates to an ellipsis or a control slides under its neighbor.
Fixed heights with no scroll. A VStack of hardcoded .frame(height:) values sums past 667 points and the bottom clips, because a VStack hands each fixed-height child the size it asks for and never scrolls on its own unless you wrap it in a ScrollView. The same stack fits inside the 932 points a 6.7-inch Pro Max gives you, so it looked fine everywhere you tested. That vertical budget is the one thing the SE does not share with the phone on your desk.
Home-button safe area. The SE has a home button: roughly a 20-point top inset when the status bar is visible, and a bottom inset of zero. Notched and Dynamic Island devices carry a larger top inset, 44 to 59 points that stays even when the status bar hides, and a 34-point bottom inset. Code that hardcodes 34 points of bottom padding, or reads insets once on a notched device, floats a pinned CTA in the wrong place on the SE.
React Native and Flutter break on width and height the same way. In RN it is a fixed height in unscaled points, or absolute offsets hardcoded for a taller, wider screen rather than derived from useWindowDimensions. In Flutter it is the yellow-and-black RenderFlex overflow stripe from a Column or Row with no Expanded or Flexible, or a hardcoded SizedBox size you did not compute from MediaQuery.
What a stamped run shows that a screenshot cannot
Layout is inspectable locally, and for iPhone SE it usually is. Add the SE runtime to your simulator list, and the Debug View Hierarchy inspector shows the exact frames and constraints at 667 points; a live SwiftUI Preview pinned to the SE size does the same as you type. If you can install the reported OS on that simulator, that is the shortest path to the SE-only clip, and it costs nothing.
What the free simulator does not give you is regression coverage. The narrow-width clip is one screen on one device you have to remember to open. The same fragility, a fixed height that clips, text that will not wrap, safe-area padding that floats a pinned control, reappears whenever space runs short, including at the largest accessibility text sizes on a full-width phone. Walking every screen at those sizes on every build is the part that does not scale, and it is where an agent that drives the flow and stamps each run earns its place.
See the SE clip locally, then gate the class on cloud devices
Reproduce the SE-only clip on the free local simulator: boot the iPhone SE (3rd generation) runtime, install the reported build and OS, and drive the flow to the screen that clips, product detail then checkout. That is the fastest path to the 375-point width. Revyl’s cloud iOS lineup is the iPhone 15, 16, 17 Pro Max, and Air, so it does not render that exact width for you.
Where the cloud device lab earns its place is the regression gate. Run the same flow as an agent test across the devices Revyl does offer, with the content-size category pushed to the largest accessibility sizes, so a text-driven clip or a stack that overruns its safe area is caught before it ships. You get video of the frame, a step trace tying it to the screen, and the device and OS stamped on the run.
# Reproduce the SE-exact clip locally (free, ships with Xcode)
xcrun simctl boot "iPhone SE (3rd generation)"
open -a Simulator
# Gate the same class on the cloud devices Revyl runs
revyl auth login
revyl test run crate-checkout --build --device-model "iPhone 16" --os-version "iOS 18.5"