Phone or tablet: one app, different screens

The same app can work well on a phone and on a tablet, just not with a phone screen stretched to ten inches. Google and Apple say the same thing here: don't ask what device someone has, ask how much room the app has right now. Past a certain width, the list and the detail sit side by side and the buttons stop drifting into the corners.

The window matters, not the device

On Android, Google sorts the available space into width classes. Under 600 dp is "compact," which covers almost every phone held upright. From 600 to 840 dp is "medium," where most tablets held upright land. Above 840 dp is "expanded": a tablet turned sideways. A dp doesn't depend on how many pixels the screen has; it's about how big something looks to the eye.

The key point is that Google says outright these classes aren't meant for "is this a tablet?" logic. On a tablet in split screen, your app may get a window the size of a phone. On a foldable, the width changes the moment you open it.

Apple has the same idea under different names: "compact" and "regular" size classes, horizontal and vertical. Their design guidelines tell you to pick the layout based on the size class, not on the device type or orientation.

What actually changes on a big screen

• List and detail side by side. On a phone, opening an order hides the list. On a tablet, the list stays on the left and the open order on the right.
• The bottom bar becomes a side rail. On a wide screen, buttons along the bottom are too far from your thumbs and your eyes.
• Text and forms don't stretch edge to edge. A name field as wide as a tablet looks like a bug.
• Keyboard and mouse. Plenty of tablets get used with a keyboard, so Tab should move between fields and Enter should submit the form.

Take a table ordering app: the guest orders from a phone and the order shows up live on the restaurant's tablet. Same product, two screens with different jobs, so two different layouts.

On Android, rotation is no longer your call

For apps targeting Android 16, on screens whose smallest width is at least 600 dp, the system ignores orientation locks and aspect ratio limits. An app locked to "portrait only" will fill the whole tablet, sideways included. You can delay this for now with a setting, but Google says that opt-out stops working for apps targeting API 37. Games are exempt.

Why this matters now: starting August 31, 2026, new apps and updates submitted to Google Play must target Android 16. Your first update after that date may also be the first time your app shows up sideways on a tablet. One more thing: rotating the screen always rebuilt the screen, but now it happens more often. If the app doesn't save its state, people lose what they typed into a form.

How we test before launch

Google recommends that once the phone screens exist, you optimize for the "expanded" width first, where you have the most room, and only then decide what to do at medium width. We test on emulators and real devices, using this list:

1. Phone, upright and sideways.
2. Tablet, upright and sideways.
3. Split screen next to another app.
4. Rotating in the middle of a half-filled form.
5. A connected keyboard: does Tab work, does Enter?

What drives the cost

You don't rebuild the app for tablets. Usually it means a handful of key screens get a two-pane layout and the rest adjusts on its own. The cost depends on how many screens need their own layout, whether the app has long forms and whether it has to work with a keyboard. The price goes in the quote, once we've seen the screens. More on how we work is on our App Dev services page.