Rechecking an iOS App on Small iPhones After Looking Only at Large Screens

For a while, the device I used most often to check the Hangangjari iOS app was an iPhone 17 Pro Max. The screen was wide, text had room, and the information on the first screen looked open and comfortable. It gave me the feeling that I had tested the app.

Then I looked again on a small iPhone, and there were moments when it felt like a different app. The numbers fit, but the rhythm felt off. Sentences stayed inside the screen, but their meaning broke. The widget contained every piece of information, but it was not readable at a glance.

The problem was not one particular layout. The problem was mistaking the screen I was looking at for the whole test matrix.

I was only looking at large screens

While polishing a release candidate, I went back through the iOS test records. Testing itself had not been absent. There were unit tests, screenshot captures, and real-device install and launch checks. But the physical device I repeatedly checked by hand was biased toward a large screen.

The device I kept holding was especially the iPhone 17 Pro Max. App Store screenshots were also being prepared around the large-screen size. As a result, the state that looked fine on a large screen naturally hardened into the normal standard.

Looking at the records chronologically made the reason clearer. At that time, release verification mostly meant “does the build install and run on a real device?” and “are supported OS paths unbroken?” Those are important checks, but they are a different question from whether sentences and information density hold up on a small screen. I had grouped the two together.

That combination was risky. A UI that does not break on a large screen is not guaranteed to preserve meaning on a small screen.

Check axis	Previous check	Changed check
Real-device check	Repeated mostly on iPhone 17 Pro Max	iPhone 12 mini and iPhone 13 Pro became final check devices
Screenshots	Mostly large App Store screenshots	SE, mini, standard, and Pro Max families checked together
Meaning of verification	Install/run success was treated like screen-quality confirmation	OS-path checks and screen-density checks were separated
Language and mode	Quick checks on representative screens	Checked combinations of 5 languages with car mode and general mode
Artifact	Pass logs and capture images	Capture images plus measurement records

The old method still had value. It was good for quickly checking overall information structure and basic behavior on a large screen. But it was not enough. A small screen makes the same UI stricter. Spacing, line breaks, button positions, accessibility sizes, and widget density all narrow at the same time.

Bugs take a different shape on small screens

The problems found on small screens could not be summarized as simple clipping. The more uncomfortable cases were often places where everything technically fit on screen but usability dropped.

In the home hero, a four-digit parking count and unit label had to hold together on one line. But fitting the number was not the end. On the narrow hero value area, the space between the park indicator and the large sentence opened up, loosening the vertical rhythm of the first screen.

I did not look at this only as pixel counts. iOS layouts are based on points (pt), a logical unit, more than physical pixels. So I converted the 3x screenshots from real devices into points. Before adjustment, the gap between the indicator and large sentence was 86-87px, or 28.7-29.0pt. After adjustment, it came down to 74-75px, or 24.7-25.0pt. The goal was not to match pixels exactly, but to keep a natural gap inside 22-26pt even on small iPhones.

Notification settings had a more direct problem. On a small screen with the favorite notification row expanded, the parking-space threshold sentence separated from the stepper. The user saw an incomplete sentence like “Notify me when fewer than spaces are left.” The value was not missing in data. The layout removed the sentence’s meaning.

The general-mode medium widget was different again. The narrow right side contained weather, fine dust, ultrafine dust, three event lines, date, and a bottom action button. Even if all the information fit, a widget is meant to be scanned quickly. If it cannot be read at a glance on a small home screen, it is not rich. It is hard to read.

Case	What I missed	What changed	What I verified
Home hero	On large screens the number and big sentence looked relaxed, but the vertical gap on narrow screens loosened	Stabilized the four-digit parking count and unit label, and tightened the top spacing of the hero value area	5 languages, car/general modes, real-device point-gap measurement on iPhone 12 mini and iPhone 13 Pro
Notification settings	On 375pt and 390pt screens, the threshold sentence separated from the stepper and lost meaning	Rewrote narrow-screen copy as a complete sentence and adjusted choice/scroll spacing	SE, mini, standard, and Pro Max simulator captures plus required real-device final checks
General-mode widget	The right side of the medium widget was too dense to scan	Reduced weather/air quality into compact indicator groups and limited events to two lines	WidgetKit #Preview sizes, accessibility text sizes, focused widget tests, and real-device final checks

These three cases were useful because they pointed in the same direction. The standard became not “make it visible on small screens,” but “make it read with the same meaning and priority on small screens.”

I made visual QA a release gate

After that, I changed the verification method. If the fix were only “look once more,” I would likely repeat the same mistake. So small screens became a gate that release candidates must pass.

For the home screen, I tied captures and measurement into one check flow. First I opened the app with the same data state and saved screens for each device, language, and mode combination. Then I measured important positions on the first screen and kept those measurements as records.

The important unit here was points, not pixels. Capture files are PNGs with pixel width and height. But iOS layout is based on points. So I read captured pixel coordinates after converting them into iOS point units.

I also recorded PPI and native pixel resolution, but I did not use them as a spacing formula. Pixel density explains which device produced the capture. The actual space occupied by UI on screen is judged by points and position relative to screen height.

The matrix became:

• Real devices: iPhone 12 mini, iPhone 13 Pro
• Simulators: iPhone SE 3, iPhone 12 mini, iPhone 17, iPhone 17 Pro Max
• Languages: Korean, English, Japanese, Simplified Chinese, Traditional Chinese
• Modes: car, general

This produced 60 screenshots for home-screen density checks. Then I measured the gap between the indicator and hero sentence, where the hero begins, and where the forecast area and first section begin, using points and screen-height ratios. The goal was not making every pixel identical. It was keeping information density and hierarchy consistent across small, standard, and large screens.

I did keep numeric criteria where useful. For example, the gap between the indicator and hero sentence should stay within 22-26pt. But not every value became an absolute rule. Text height changes by language, and some position ratios can exceed 1 percentage point slightly. In those cases, I looked at the captures directly for clipping, unintended line breaks, or loss of first-screen context.

Automation does not replace judgment. It makes sure the screens that need judgment are not skipped.

Each test type caught different failures

What I felt again this time is that no single test style covers all SwiftUI and WidgetKit UI failures.

Unit tests were good at fixing display state and large-number inputs. Rules before rendering, such as four-digit parking counts, hero value areas by mode, and widget display-value construction, can be locked by tests.

#Preview and simulator screenshots were good for quickly expanding screen size and Dynamic Type combinations. Medium widgets in particular had to be checked in small point sizes such as 329x155pt, 338x158pt, and 364x170pt, plus XXXL and Accessibility2 text sizes. This was not a matter of preparing higher-resolution images. It was a matter of reducing information inside a small point space.

Real devices reduced the remaining uncertainty at the end. Even if simulators cover many screen families, installing and opening the app on real devices still matters. This time, iPhone 12 mini and iPhone 13 Pro became required physical devices, while the large-screen device was removed from the automatic final-check path. The device I use every day is convenient, but too forgiving as a release standard.

After splitting the checks this way, “there are many tests” mattered less than “I know what each test does not catch.”

My main device is not the test matrix

The conclusion is simple. The device I look at often is not the test matrix.

A UI that passes on a large screen may not have passed. It may only have passed on a large screen. Especially in an app like Hangangjari, where the home screen, settings, and widgets contain dense information, small screens are a more honest standard. If meaning holds on a small screen, large screens usually gain room. If the UI is tuned only for a large screen, sentences, density, and hierarchy can collapse together on small screens.

When I review iOS release candidates from now on, I want to start with the screen sizes most likely to fail rather than the most representative size. A good test matrix does not stop at imagining the average user. It has to force me to look at the environments I am likely to miss.