Where the screen folds and opens
iPhone Duo Support
We make sure your layout does not break when the screen folds open, and that what the user was writing is still there
Code that branches on device names breaks again on the next device.
Not one new resolution, but several new states
A foldable carries an outer screen you use folded and a larger inner screen you use open. Your app now sits in several states: folded, unfolded, rotated, in split view, and in the short moment of moving between them. A screen pinned to one of those states goes wrong in the rest. Text gets clipped, buttons drift out of thumb reach, and half written messages disappear.
What we do
-
Decide by window size, not device name
We rewrite layout decisions to read the window size and safe area available right now. Device name branches need a new branch for every new device, and they miss the cases where the size changes while the app is open, such as split view.
-
A structure that suits the open screen
Instead of stretching one column across the extra width, we move to a two column layout with the list and the detail side by side. The same screen folds back to one column when the device is closed.
-
Keep the fold line clear
When a tab bar, a text field, or a primary button sits on the crease running down the middle, it becomes hard to read and hard to press. We check what lands there in each state and move it.
-
Nothing lost when the device opens
We verify that text in progress, scroll position, and playback position survive the transition. Folding is not the same event as rotating, so this only holds if it is tested on its own.
-
One pass per state
We go through folded, unfolded, rotated, split view, and mid transition one at a time and record how every screen behaves in each.
A record of the work
You get a written record of what went wrong in which state and how it was fixed, with screenshots. The next time you build a screen, the state list in that record is the checklist to reuse.
How it runs
-
Send the app and the screens that matter
Read access to the repository or an installable build, plus the handful of screens that absolutely have to hold up.
-
A pass per state
We take folded, unfolded, rotated, split view, and mid transition one at a time and record where things break.
-
Agree on scope and time
We settle what gets fixed and how long it takes before anything starts. Nothing is billed before that.
-
Fixes and handover
We fix the layout and the state preservation, then hand it back with the work record.
This fits
- An iOS app already on the store whose layout was built for one screen size
- An app that already looked off on iPad or in split view
- A team still carrying branches keyed to device names or fixed dimensions
Frequently asked
- Is this only for the iPhone Duo?
- No. Because the layout reads the window size available right now instead of a device name, the same code also covers other foldables, iPad, and split view. Adding a branch for one device means doing the whole thing again for the next one.
- Do we have to rebuild the app?
- Usually not. The work sits in the layout and in state preservation. If an app genuinely needs its screen structure reworked, we tell you during the review pass and set the scope again.
- Do you need a physical device?
- No. We change states in the simulator. If a device is available we also check what actually falls under the thumb when it is held.
- Does this work for React Native or Flutter apps?
- Yes. The principle is the same. Each framework exposes window size and safe area differently, so tell us which one you use and we will confirm what is possible first.
- How is this different from app store requirement work?
- Store requirement work raises your target version so the build passes review. This is unrelated to review: it keeps the layout and the user's work intact when the screen grows and folds. Hand us both and we do them in one pass.
It starts by opening the device once
Send the app name and the few screens that have to hold up, and we will start by finding which states break them.