Foldable phones are still a minority of the Android market, which is exactly why most apps handle them badly - they weren’t tested on the hardware, and it shows the moment a user unfolds their device mid-session and the layout doesn’t adapt gracefully. As foldable adoption grows, particularly in premium segments, this stops being a minor edge case and starts being a visible quality signal for anyone who happens to be testing on one.
What’s actually different about foldable hardware, technically
Unlike a simple screen size difference, a foldable device changes its actual screen dimensions and aspect ratio dynamically, mid-session, while your app is running - a user can fold or unfold the device while actively using a feature, and the app needs to respond to that change in real time, not just render correctly at two fixed sizes independently. This is a fundamentally different problem than responsive design for different device sizes, which typically doesn’t need to handle the screen changing shape while the user is actively interacting with a specific screen state.
There are three states to design for, not two
Most teams that do think about foldables think in terms of closed and open. The hardware has a third state, and it is the one that produces the strangest bugs: partially folded, with the device resting on a surface and the hinge somewhere near ninety degrees. In this position the operating system reports a hinge or fold boundary running across the middle of the display, and the sensible interpretation is two logical halves rather than one tall screen - a video in the upper half and controls in the lower one, a viewfinder above and a shutter below.
The failure mode when this is ignored is not a crash. It is a dialog, a keyboard, or a primary action that lands exactly on the hinge, where it is either visually broken by the crease or physically awkward to press. The same applies to the fold boundary on a fully opened inner display: content is readable across it, but a control centred on it is not a control anyone enjoys using. Treating the boundary as something to lay out around, rather than something to ignore, removes a whole class of complaints that are otherwise difficult to reproduce from a bug report.
What this actually breaks if you don’t account for it
- Layout that doesn’t reflow on fold state change - content that was correctly laid out for the folded (phone-sized) screen looking cramped or oddly spaced when unfolded to the larger tablet-sized display, because the layout logic never accounted for the transition.
- Lost state or scroll position during the transition - a jarring experience where unfolding mid-scroll or mid-form-entry resets or breaks the user’s current state, because the transition wasn’t handled as a continuous experience.
- Wasted screen real estate on the larger unfolded display - an app that just scales up phone-sized layout to fill a tablet-sized unfolded screen, rather than taking advantage of the additional space for a genuinely better multi-column or richer layout.
Why state loss on unfold is the bug you will actually hit
Of those three, lost state is the one that generates real complaints, and it is worth understanding why it happens, because the cause is not specific to foldables at all. On Android, a change in screen configuration destroys and recreates the running screen by default. The same mechanism fires on rotation, on entering split-screen, and on being resized in a desktop-style window. An app that loses a half-completed form when the device is unfolded would also lose it if the user rotated the phone; foldable hardware simply makes the problem far easier to trigger, because unfolding is a natural thing to do precisely when a user wants more room for the task they are in the middle of.
This is why we treat foldable defects as a symptom rather than a category. If unsaved input, scroll position, media playback position, and in-flight network requests survive a rotation, they will generally survive a fold. If they do not, the fix belongs in how the screen holds its state, not in anything foldable-specific, and fixing it there improves the app on every device rather than on the small number that fold.
What building for this properly actually involves
Using responsive layout techniques that already handle dynamic viewport changes well (the same flexible, container-based patterns that make good responsive web design work generally) rather than hardcoded, fixed layouts per device size. Testing the actual fold and unfold transition, not just the two end states independently - the transition itself needs to feel smooth, not just the before and after screenshots. And deliberately designing for the larger unfolded state as a genuine opportunity, not just an inconvenience to accommodate - multi-column layouts, side-by-side content, richer information density that a small phone screen never had room for.
How to test this without buying the hardware
The most common reason foldable defects ship is not disagreement about their importance, it is that nobody on the team has the device. That is a smaller obstacle than it looks, because the behaviour that breaks is reproducible in an emulator and, for the most important case, on hardware every team already owns.
- Use the foldable and resizable emulator profiles in Android Studio. They expose fold and unfold as an action you can trigger while the app is running, which is the event you actually need to test, and they report the hinge position the same way physical hardware does.
- Test rotation on an ordinary phone first. Because it triggers the same configuration change, rotation catches most state-loss bugs at zero cost, and it belongs in the regression pass whether or not foldables are a priority.
- Turn on the developer option that clears background activities to simulate the system reclaiming your screen. Restoring correctly from that is the same discipline that makes a fold transition safe, and it also fixes a category of “the app forgot what I was doing” reports from ordinary devices under memory pressure.
- Check the two awkward sizes deliberately - the very narrow outer display some devices have when closed, and the near-square inner display when open. Layouts tuned only for typical phone proportions tend to break at both ends rather than in the middle.
How big a priority this should actually be
For most apps today, foldable-specific optimization is a real but secondary priority - worth genuinely good responsive fundamentals that happen to handle foldables gracefully as a side effect, rather than dedicated foldable-specific engineering effort, unless your specific user base skews toward premium devices where foldable adoption is meaningfully higher. The honest recommendation: build with genuinely flexible, adaptive layout patterns as a baseline practice (which pays off for regular responsive design too), and foldable support comes largely for free rather than needing to be a distinct initiative.
The same work covers a much larger set of devices
The reason we are comfortable recommending this even to teams with almost no foldable users is that the work is not really about foldables. An app that handles a changing window size correctly is also the app that behaves properly in Android’s split-screen mode, on a tablet, on a Chromebook running Android applications in resizable desktop windows, and in the desktop modes some manufacturers offer when a phone is connected to an external display.
Each of those individually may be a small share of your users, but they share one requirement: the app must treat its window as something that can change size at any moment rather than as a fixed canvas chosen at launch. Build for that once and the foldable question mostly answers itself, which is a considerably better argument for the budget than the size of the foldable market on its own.
What we’d actually recommend
Audit your app’s responsive layout fundamentals first - if your app already handles orientation changes and varied screen sizes gracefully using flexible layout patterns, foldable support is mostly a testing and refinement exercise, not a rebuild. If your layouts are hardcoded per device size, that’s the deeper problem worth fixing regardless of foldable-specific considerations.
We build adaptive, genuinely flexible layouts as standard practice in our mobile app development work. Get in touch if you want your app tested against foldable and unusual form factors.