They’re related, but they describe two different ways of handling different screen sizes. And the choice affects how much you design, how developers build it and how your product feels on a phone, a tablet or a foldable.
We design websites and iOS apps at OSAM, so we deal with this question on almost every project. Here’s a clear explanation of the difference, what it means for native mobile apps specifically, and how to choose.
The difference in one sentence each
- Responsive design uses one flexible layout that stretches and reflows smoothly to fit any screen width. Think of water taking the shape of any glass.
- Adaptive design uses several fixed layouts, each made for a specific screen size or range, and shows the one that fits best. Think of a wardrobe with a different outfit for each occasion.
In practice, the line is blurry. Most modern products are hybrids: a fluid layout inside each range, with bigger structural changes at a few key breakpoints. A website might reflow cards smoothly, then switch from a top menu to a bottom bar below a certain width. That’s both responsive and adaptive at once.
| Responsive | Adaptive | |
|---|---|---|
| Layout | One fluid layout | Several fixed layouts |
| How it adjusts | Continuously, at any width | Jumps between set sizes |
| Design effort | Fewer layouts, more thinking about rules | More layouts to design and maintain |
| Control per device | Less precise | Very precise for each target size |
| Handles new screen sizes | Well, by default | Only if a layout covers that range |
| Typical use | Websites, content-heavy products | Products where each device needs a tailored experience |
What it means for native mobile apps
On the web, people often talk about responsive vs adaptive as a pure choice. In native apps, the platforms have already made it for you: both iOS and Android are built around a hybrid approach.
- iOS: size classes. Apple describes available space with size classes, compact or regular, for width and height. An iPhone in portrait is compact width. An iPad in full screen is regular width. Layouts flex fluidly within a size class (responsive), and the structure changes between them (adaptive): a list on iPhone can become a sidebar with a detail view on iPad.
- Android: window size classes. Google uses a similar idea with width breakpoints: compact for most phones in portrait (under 600 dp), medium for large phones, small tablets and unfolded foldables (600 to 840 dp), and expanded for tablets and desktop-like windows (840 dp and up). Navigation typically moves from a bottom bar on compact screens to a navigation rail or drawer on bigger ones.
- The screens keep multiplying. Foldables change size while the app is open. iPads and Android tablets run apps in resizable windows and split screens. Phones rotate. A layout designed for one fixed iPhone frame breaks fast.
- Don’t forget text size. Users can increase system text size with Dynamic Type on iOS and font scaling on Android. A truly responsive app handles bigger text without cutting off labels or breaking layouts. It’s also a core accessibility requirement.
How to choose
Instead of picking a side, ask a few practical questions. Lean responsive when:
- the app is phone-first and the main difference between devices is just width
- the content is mostly lists, feeds, articles or forms that reflow naturally
- the budget and timeline are tight and you need one solid layout fast
- you want new devices to work well without extra design work
Add adaptive layouts when:
- tablets or foldables are an important part of your audience
- bigger screens allow a genuinely better experience, like a sidebar with details, a multi-column dashboard or an editing workspace
- the task itself changes by device, such as quick checks on a phone and deep work on a tablet
- you’re building for a platform where users expect it, like a productivity app on iPad
A sensible default for most mobile products: design phone-first with a fluid layout, then add one adaptive layout for larger screens where it really improves the experience. That covers the vast majority of users without designing a dozen screen variants nobody will see.
Tip: check your analytics, or your client’s, before deciding. If almost nobody uses the app on a tablet, a beautiful tablet layout is a nice-to-have, not a priority.
Practical tips for designing it in Figma
- Build with auto layout from the start. Frames that resize properly are the closest you’ll get to how a real responsive layout behaves. Drag the frame wider and narrower to stress-test it.
- Set constraints and min/max widths. Decide what stretches, what stays fixed and where content should stop growing. A text line spanning a whole tablet screen is hard to read.
- Design the extremes. The smallest phone you support, a large phone, and a tablet or unfolded foldable. If those three work, the in-between sizes usually do too.
- Define breakpoints explicitly. Write down where the layout changes and what changes: navigation, number of columns, sidebar on or off. Developers need rules, not just pictures.
- Test with large text. Duplicate key screens with bigger type and check that nothing breaks or gets cut off.
- Use components with variants. One card component with compact and expanded variants keeps phone and tablet layouts consistent.
- Annotate behavior. A short note like "cards reflow from 1 to 2 columns above 600 dp" saves a dozen questions in development.
The goal isn’t to draw every possible screen. It’s to give developers a clear system so the app looks right on screens you never drew.