For most of the smartphone era, designing a mobile app meant designing for one shape: a tall rectangle held in one hand. That assumption has been quietly breaking down as foldable phones, larger-screen phones, and tablets have become a normal part of the device landscape rather than a niche curiosity. By 2026, a meaningful and growing share of users are opening apps on screens that can change shape or size while the app is running, and apps that were never built with that in mind tend to look broken the moment a user unfolds their device or rotates a tablet.
This is not primarily a visual design problem, though visual design matters. It is an architecture problem about how an app's layout logic responds to changing constraints, and getting it right from the start is considerably easier than retrofitting it after launch.
An app built with a single fixed layout in mind typically assumes a narrow, tall viewport and stacks everything vertically. On a folded device or a standard phone, that assumption holds up fine. The moment a user unfolds the device into a much wider, roughly square screen, that same vertical stack either leaves huge amounts of wasted space on the sides or, worse, stretches individual elements like buttons and cards into awkward, oversized shapes that look unfinished.
The deeper issue is state management during the transition itself. A well-built adaptive app needs to preserve exactly what the user was doing, their scroll position, any text they were typing, their place in a multi-step flow, while the layout underneath them changes shape in real time. Apps that only think about the two end states, folded and unfolded, and not the transition between them, are the ones that tend to glitch or reset when a user actually folds or unfolds their device mid-session.
Consider a note-taking app used by a small business's field team. On a folded phone, the natural layout shows a single list of notes, and tapping one opens it full screen. On an unfolded, wider foldable screen, the same app has enough room to show the note list and an open note side by side, similar to how a desktop email client shows an inbox next to a reading pane.
Building this well means the app needs to detect the available width, not just whether the device happens to be a foldable model, and choose the appropriate layout based on that measurement. This approach is illustrative of the general pattern most adaptive mobile apps follow: design around available space and window class rather than around a specific list of device models, since new screen sizes and shapes will keep appearing after any specific device list goes stale.
Adaptive layout work does not happen in isolation from the rest of an app's technical foundation. Teams that have already tackled reducing cold start time and app size tend to have cleaner, more modular component architectures, which makes adding adaptive breakpoints considerably easier than retrofitting them onto a tangled, monolithic screen structure. Similarly, teams weighing PWA versus native approaches for a new product should factor multi-device screen support into that decision early, since the two paths offer meaningfully different levels of native control over layout behavior during a live fold transition.
Our UI and UX design team increasingly treats screen-size adaptability as a default requirement for new mobile builds rather than an optional add-on, since retrofitting it later is consistently more expensive than designing for it from the first sprint.
Teams new to adaptive design often ask how much extra work it adds to a build. The honest answer is that it depends heavily on how the app was architected in the first place. For example, a project that already uses reusable, composable UI components could typically add a second or third layout arrangement to its highest-traffic screens in a relatively contained amount of extra design and engineering time, while a codebase full of screen-specific, tightly coupled layout code could require a much larger effort just to reach the point where adaptive breakpoints are even feasible. These are illustrative ranges meant to help with planning conversations, not fixed estimates, and any real project should be scoped against its own component architecture.
A useful way to frame the investment for stakeholders is to separate it into two buckets: the one-time cost of restructuring components to be width-aware, and the ongoing cost of designing a second layout for each new high-value screen going forward. The first bucket is usually the larger, harder cost, but it is also a one-time investment that makes every future screen cheaper to make adaptive, since the underlying component system already supports it.
Automated UI tests written for a single fixed layout often do not catch problems that only appear during a live fold transition or when an app is resized inside a multi-window view. A more reliable testing strategy combines three layers: unit tests for the layout logic that decides which breakpoint to use, snapshot tests that render each breakpoint's layout independently to catch visual regressions, and a manual testing pass on real foldable hardware that specifically exercises the transition itself rather than just the two end states.
Manual testing deserves particular attention here because emulators, while useful for early iteration, do not always accurately simulate hinge sensor behavior, fold angle detection, or how the operating system reports available window size during a live transition. A short, structured manual test pass before each release, covering fold, unfold, and window resize while actively interacting with the app, tends to catch the kinds of glitches that automated tests alone would miss.
It is also worth including accessibility checks in this same testing pass. A layout that rearranges itself across breakpoints needs to keep focus order, screen reader navigation, and touch target sizing consistent at every width, since a change that works visually can still confuse a screen reader user if the underlying element order in the layout does not match what is shown on screen. Building this check into the same release process that already covers visual and functional regressions keeps accessibility from becoming an afterthought that only gets addressed after a user complaint.
Multi-device screens are no longer an edge case worth ignoring. Designing for adaptive layouts from the start, using width-based breakpoints, shared components, and careful state preservation through transitions, produces an app that holds up well regardless of what shape screen a user happens to be holding. Teams that treat this as core architecture rather than a late-stage visual tweak consistently end up with a more maintainable app and a better experience for the users who care most about it.