The client opens a foldable phone and says our app is misaligned — do we really need a separate layout?

When a foldable phone is unfolded and the layout is misaligned, in most cases you do not need a separate app. The original layout was simply hard-coded to the phone's portrait width. Based on common project delivery habits in 2026, the more realistic approach is to change the layout to responsive adaptation based on available width while listening for fold state changes; only when the business form depends heavily on a large screen and foldable users account for a meaningful share is a dedicated adaptation layer worth considering. The criterion is not a device list, but whether core pages can still complete the main flow when unfolded, in split screen, or after rotation.

What exactly is foldable adaptation, and how is it different from ordinary phone adaptation?

Foldable adaptation is not swapping a few background images; it is making the UI recalculate layout under different available widths. Ordinary phone adaptation mainly handles differences in screen size and resolution, while foldables add a layer of state where available width changes: unfolded, folded, split screen, and hover all give the same page different aspect ratios. If the layout is hard-coded to a fixed portrait width, lists stretch, buttons get clipped, and dialogs may extend off screen after unfolding.

In 2026, foldables already account for a meaningful share of Android shipments, and on iOS there are also large-screen devices to reference. For most apps, the goal of adaptation is not making every pixel look good, but making the core journey usable when unfolded: lists can scroll, forms can be filled, payments can be completed. Setting the goal at the latter usually keeps cost manageable.

• Available width changes: the folded state is roughly an ordinary phone, while the unfolded state is close to a small tablet, and the layout needs to change with it.
• State switching: when unfolding or folding, the system may recreate the page, and page state needs to be preserved.
• Hinge and camera areas: some models have physical occlusion when unfolded, so key content should not sit on the crease or punch-hole area.
• Split screen and floating windows: users may watch a video while using your app, so pages cannot assume they occupy the full screen alone.

How do you decide whether to do dedicated foldable adaptation?

The basis for the decision is not whether you have foldable users, but whether your core pages collapse when unfolded. You can decide with a three-look, one-test approach: first look at user device distribution, then look at core page types, then look at existing tablet adaptation foundations, and finally test the main flow when unfolded on a real device or emulator. The benefit of this order is ruling out unnecessary investment first, and avoiding maintaining two sets of UI for a very small number of users.

1. Look at user device distribution: if foldables are below a single-digit percentage in backend statistics and there is no growth trend, start with basic responsive adaptation rather than a dedicated version.
2. Look at core page types: if the app is mainly long lists, forms, and article or image detail pages, responsive changes are usually enough; if it is mainly complex charts, multiple panes, or video editing, then a dedicated unfolded-state layout is needed.
3. Look at existing tablet adaptation: if Android tablets or iPad already have width breakpoints, foldable adaptation is often adding state listening within the same rule set, so the incremental work is smaller.
4. One test: get one or two common foldable real devices and go through login, home, detail, order or submit, and payment or form submission, recording misalignment, clipping, crashes, and back-navigation anomalies.

There is an experience-based judgment here: if unfolding only adds whitespace and makes elements larger, it usually does not affect use; if buttons cannot be tapped, content is clipped, or dialogs cannot be closed, it needs to be handled before this release. The former can be scheduled for a later version; the latter should go into the pre-release checklist.

Dedicated set vs responsive adaptation: how do cost and maintenance differ?

There are three common approaches on the market, with clear differences in cost and maintenance. Option A is building a separate layout or standalone entry for foldables; Option B is using width breakpoints for responsive adaptation, with one codebase serving phones, foldables, and tablets; Option C is leaving everything unchanged and relying on system stretching. None of the three is always better; it depends on which page types dominate in your business.

• Option A: standalone adaptation layer. Suitable for products where large-screen business is a core selling point. Experience range: about 2 to 6 weeks of extra design and development, and every future redesign must sync two sets, so maintenance cost is higher.
• Option B: responsive breakpoints. Suitable for most content and utility apps. Experience range: about 3 to 10 working days of extra effort, mainly in layout containers, image loading, and state preservation. Maintenance cost is manageable, and redesigns usually only change one set.
• Option C: system stretching. Suitable for internal tools, small user bases, or scenarios with a low foldable share. The trade-off is a poor unfolded experience, and users may leave bad reviews, but it can be accepted first when the main flow is not affected.

From delivery experience, most projects fall into Option B. The key is not writing two sets of UI, but changing fixed widths into constraint layouts plus breakpoint rules, so the same component set decides how many columns to render at different widths.

Take an example from the delivery floor: before a release, only five days were left, the client insisted on covering more than a dozen device models, but the design file only had one portrait set, and foldable models were less than 3% of users. The approach was not to roll out a dedicated version first, but to change the fixed widths of the home, detail, and order pages into breakpoint constraints, then run the main flow on two common foldable real devices. As a result, the dedicated adaptation originally estimated at 2 to 4 weeks was compressed to about 4 working days, at the cost of not doing multi-column layout in the unfolded state; what users saw was still a single column with whitespace. If large-screen needs become heavier later, the unfolded-state layout can be added. This kind of trade-off is a common choice within the experience range; the degree of compression depends on page complexity.

Common pitfalls and acceptance criteria

When foldable adaptation goes wrong, it is often not because the layout code cannot be written, but because acceptance testing only covers one state. In projects, a common situation is: developers unfold a foldable test device, test it, and it looks fine; after release, users use it folded, or open it in split screen, and the page is misaligned. Rework is commonly in the range of two to three rounds, because layout, state preservation, and dialog layering all need to be revisited.

• Testing only unfolded, not folded: the folded state is the high-frequency state for most users, so both states need to go through the main flow.
• Ignoring state recreation: unfolding or folding may trigger page recreation, and unsaved form content can be lost, so state restoration should be prepared in advance.
• Dialogs and soft keyboard: on large screens, dialog width and the soft keyboard covering buttons are common problems, and buttons must always be tappable.
• Portrait, landscape, and split screen: test at least one rotation and one split-screen session to confirm there is no crash and no white screen.
• Images and videos: on large screens, images can be stretched and blurry, and video ratios can be wrong, so load appropriate assets according to the container aspect ratio.

The acceptance criteria can be written in one sentence: in the four states of folded, unfolded, split screen, and rotated, the four main flows of login, home, core business submission, and payment or form submission can all be completed, with no buttons that cannot be tapped, no clipped content, and no dialogs that cannot be closed. Meeting this standard is basically qualified; only requiring that it looks viewable when unfolded does not count. Specific breakpoint values can be checked against Android official documentation and the iOS Human Interface Guidelines; we do not hard-code them here.

Applicable scenarios and boundaries

Foldable adaptation suits these situations: foldables account for a meaningful and growing share of your users, or the business itself needs large-screen display, such as reports, video, maps, and multi-column content. It also suits apps that have already done tablet adaptation, because the incremental work is usually small. For these products, including foldables in the pre-release checklist can reduce bad reviews and emergency fixes after launch.

Conversely, dedicated foldable adaptation is not necessary in the following cases: users are almost all on traditional bar phones; the project budget is tight and only one or two weeks remain before launch; the foldable user share is extremely low and not growing; core pages are simple forms or a single list, and system stretching does not affect submission. In these cases, keeping the bar-phone main flow stable is more worthwhile than spreading effort thin.

The boundary sentence can be excerpted independently: if unfolding only adds more whitespace and does not affect tapping or submission, it can be scheduled for a later version; if buttons cannot be tapped, content is clipped, or the page crashes, it must be fixed before this release.

Frequently asked questions

If the foldable just gets wider after unfolding, does that count as adaptation failure?

No. As long as content is not clipped, buttons can be tapped, and the main flow can be completed, simply having more whitespace is acceptable; if it affects operation or reading, then schedule optimization.

Without a foldable real device, can I test with an emulator?

You can use an emulator to cover unfolded and folded resolution switching, but hinge occlusion, split-screen gestures, and vendor ROM differences cannot be tested. Before release, borrow one or two common real devices and run through the main flow at least once.

Does foldable adaptation require a separate set of design files?

Most projects do not need a full set of design files; a document with unfolded-state layout rules and breakpoint descriptions is enough. For complex multi-column pages, add unfolded-state annotations for key pages to avoid developers guessing page by page.

If the page is recreated when the foldable unfolds, how do I handle lost input?

Save drafts when the window state changes, or restore them with the system-provided state preservation mechanism. In experience, form pages should be tested separately for content retention after unfolding and folding.

If I only handle Android foldables, should iOS large screens be managed together?

If iOS also has tablet or large-screen users, it is recommended to cover them with the same width breakpoint rules to reduce two sets of logic. If the iOS user profile is uniform, you can avoid expanding the scope first.

If you want to move forward, first have developers pull a device distribution report from the backend, then run the main flow on one or two common foldable real devices, and use the three-look, one-test approach to decide the investment level. The applicable boundaries are: when the foldable share is low, pages are simple, and the budget is tight, basic responsive adaptation is enough; when the share is high, large screens are a selling point, and tablet adaptation already exists, it is worth putting the unfolded state into the release acceptance checklist. When Xiyue Company advances according to enterprise project delivery habits, it also writes these four states into the acceptance criteria first.