Apple Works to Fix Safari's Narrow-Screen Problem on the Foldable iPhone

Apple is looking for ways to widen Safari's cramped layout on the foldable iPhone's outer screen. The goal is to let web pages extend into the area beneath the browser controls positioned along the side of the screen. But the company hasn't yet decided which method to use.

What happened?

Apple's Jen Simmons described the problem in an October 23 WebKit post. The current version of Safari (27.1) confines web content on the outer screen to the area beside the controls only, filling the remaining strip with the page's background color. That restricts the width available for content. An existing web setting, viewport-fit="cover", could allow a page to spread into that area, but Apple's research shows that many sites don't handle it correctly.

Why does it matter?

The real issue isn't a single browser update. The mobile web has been built for roughly 15 years on one assumption: a vertical, single-column, rectangular screen. Even CSS's safe-area concept only arrived in 2017 with the iPhone X's notch — meaning the idea of managing a screen's "unusable" regions is relatively new. A device that opens like a book, with a short, wide outer screen whose controls are pushed to the side, breaks that assumption outright.

The technical core of the problem is this: viewport-fit="cover" gives the page the entire area, but then the responsibility for leaving padding so that important content doesn't land at the edges shifts to the developer. According to Simmons, many sites don't leave that padding on every edge. The result is that menu buttons or text disappear beneath the controls. That's why Apple is researching a more controlled alternative: a hybrid model where, for example, a header's background covers the whole screen while clickable links stay within the visible area.

This is a familiar pain in the Android world. On foldable Galaxy and Pixel devices, app developers have been wrestling for years with screen continuity, hinge gaps, and posture (opening-position) compatibility. Google tried to clean up this mess with libraries like Jetpack WindowManager. What Apple is doing now is carrying the same problem from native apps to the web layer. The difference is this: the web advances through open standards, not a single company's SDK — meaning the solution can't stay inside WebKit; it needs to be settled at the W3C level.

How does it affect developers and users?

For users, the visible problem is simple: on the outer screen, web pages are squeezed into a narrow strip for now, with an empty color band left on the sides. For developers, the story is more complicated, because the standard hasn't been written yet.

Meanwhile, Safari 27.1 also brings two concrete new features. When the device is held half-folded like a book, PDFs automatically switch to a two-page view; when the device is flattened out, they return to a single page. In addition, detecting the fold posture and placing content around the central hinge can be tested behind experimental feature flags. In other words, Apple is shipping the settled features while deliberately keeping the controversial one in the "research" stage.

What's next?

There are a few things to watch. The first is whether Apple will propose a new CSS mechanism or refine the existing viewport-fit behavior — this will set the direction of the standard that other browsers will adopt as well. The second is how Google and Mozilla will join this discussion, because the foldable web isn't a problem a single platform can solve. The third is how quickly major sites will adapt — the years-long rollout of notch support suggests this, too, will require patience.

Apple's inability to commit to one approach is actually an honest sign. Foldable interface standards haven't been written yet, and freezing the wrong API in haste would create debt that's hard to undo later. A cautious stance looks healthier than a quick fix at this stage.