Android tablet and foldable apps
Android tablet app development company for adaptive, large-screen apps
We are an Android tablet app development company in Lahore that builds apps which fill tablets, foldables and desktop-style windows properly, instead of showing a phone layout with black bars. With Android 16 now ignoring most orientation and resizability locks on large screens, this is no longer optional polish. This page goes one level below our Android app development service and covers only large-screen work.
You get two-week sprints with a Play internal testing build each sprint, tested on real tablets and foldables.
- Ready for Android 16 and API 36
- Adaptive layouts in Jetpack Compose
- Foldable postures tested on device
- Keyboard, mouse and stylus support
The Android 16 large-screen rule, and why it affects every app on Play
For years many Android apps locked themselves to portrait and a phone-shaped aspect ratio. On a tablet they appeared letterboxed, and nobody complained loudly enough to fix it. That shortcut has now closed.
According to Android 16’s behaviour changes, for apps targeting API 36 the system ignores orientation, resizability and aspect-ratio restrictions (screenOrientation, resizableActivity, minAspectRatio and maxAspectRatio, and setRequestedOrientation()) on displays whose smallest width is 600dp or more. Your app is stretched to fill the window, whatever the manifest says. Games declared through android:appCategory are exempt.
The timing makes this urgent. Google Play requires new apps and app updates to target Android 16 (API 36) from 31 August 2026, with an extension available to 1 November 2026. So the rule now applies to every app update you ship to Play. A temporary opt-out property exists, but it stops working once you target API 37, so it buys months, not a strategy.
In practice this means an app that was never designed for tablets will suddenly be shown at tablet width on its next update. Layouts stretch, images blur, buttons drift to the edges, and screens that assumed portrait can lose state on rotation. We audit for exactly this before raising your target API.
Google’s adaptive app quality tiers, explained for buyers
Google grades large-screen support in three tiers. According to its adaptive app quality guidelines, each tier builds on the one below. We agree the target tier in discovery, because it drives design effort more than any other decision.
| Tier | What it requires | Who should aim for it |
|---|---|---|
| Tier 3: Adaptive ready | Runs full screen in multi-window, no letterboxing, basic keyboard, mouse and stylus support | Every app on Play now, given the Android 16 rule. This is the floor. |
| Tier 2: Adaptive optimized | Layouts designed for all screen sizes and device configurations, such as list-detail on wide screens | Consumer apps with real tablet usage: shopping, media, reading, travel, education |
| Tier 1: Adaptive differentiated | Multitasking, foldable postures, drag and drop, stylus input built into the experience | Productivity, creative, field-work and enterprise apps where the large screen is the point |
Most of our tablet projects target Tier 2 for the whole app and Tier 1 for the two or three screens where it matters most.
What we build into an Android tablet app
These are the features that separate a real tablet app from a phone app at a bigger size. Most are built with Jetpack Compose’s adaptive APIs, which our Jetpack Compose app development team uses by default.
Window size class layouts
Compact, medium and expanded layouts chosen by the window’s actual size, not the device model. The same code serves a phone, a split-screen tablet and a desktop window.
List-detail and supporting panes
Inbox, catalogue and settings screens that show a list and its detail side by side when there is room, and fold back to one pane when there is not.
Navigation that adapts
A bottom bar on phones, a navigation rail on tablets and a drawer on wide windows, all from one navigation graph.
Multi-window and state
Correct behaviour when the app is resized, split or rotated: no lost form data, no reloaded lists, no duplicate network calls. This is where most retrofits find bugs.
Keyboard, mouse and stylus
Keyboard shortcuts, tab focus order, hover and right-click menus, and stylus handwriting or drawing where it helps. Tablets with keyboard covers and ChromeOS devices are used like laptops.
Drag and drop
Dragging images, text and files between your app and another app in split screen. For document, chat and content apps this is often the most visible tablet feature.
Foldables: two devices in one
A foldable is a phone when closed and a small tablet when open, and users switch between the two mid-task. The app must carry its state across that change without restarting the screen or losing what the user typed. That is the first thing we test on every foldable.
Book-style foldables also support postures. Half-opened like a laptop (tabletop posture), a video app can show the picture on the top half and controls on the bottom. Half-opened like a book, a reading or shopping app can put a list on one side and a detail on the other. Jetpack WindowManager tells the app where the fold is and whether it separates the screen, so layouts avoid placing a button across the hinge.
Not every app needs posture-specific layouts. For most clients, solid continuity between folded and unfolded states plus a good two-pane layout delivers the bulk of the value. We add posture features only where the use case is clear, such as video, camera or presentation modes.
Worried about what API 36 does to your app on tablets?
Send us your Play Store link or a build. We reply within one business day, then run it at tablet and foldable sizes with the Android 16 rule in effect and tell you what breaks and what a fix would include.
Large-screen test checklist we run every sprint
Emulators are fine for quick layout checks; we use resizable emulators heavily. Real devices still find the problems that matter, so every release candidate goes through this list on physical tablets and at least one foldable.
- Portrait and landscape on a 10 to 13 inch tablet, with no letterboxing
- Split screen at different ratios, and as a free-form desktop window where supported
- Rotate, resize and fold mid-form: no lost input, no reloaded data
- Folded to unfolded and back during video playback and during checkout
- Tabletop and book postures on screens that use them
- Full keyboard navigation with a visible focus indicator
- Mouse hover, right-click and scroll-wheel behaviour
- Stylus input on drawing, signature and handwriting fields
- Drag and drop to and from another app in split screen
- Images and video sharp at tablet resolution, not upscaled phone assets
- Text at the largest font size with layouts that still fit
Retrofit an existing app or design tablet-first?
Most of our tablet work is on apps that already exist. The right approach depends on how the phone app was built.
| Your starting point | What we usually recommend | Typical scope |
|---|---|---|
| Compose app with clean state handling | Add window size classes and adaptive panes to key screens | Smallest retrofit; mostly layout work |
| XML Views app locked to portrait | Fix state and configuration-change handling first, then build new tablet screens in Compose | Medium; state bugs usually surface first |
| Cross-platform (Flutter or React Native) | Adaptive layouts in the shared UI, native checks for foldable and window behaviour | Medium; depends on framework support for the features needed |
| New product for tablets or kiosks | Design for expanded width first, then compact | Full build; tablet is the main target |
If raising the target API is the real driver, our Android app upgrade and migration service handles the wider SDK move at the same time.
How our Android tablet app development company runs a project
The delivery model matches the rest of our Android work, with large-screen decisions made early.
Discovery and tier target
One to two weeks of workshops to agree the device matrix, the target quality tier per screen, and whether foldable postures or stylus input are in scope. A fixed price follows.
Adaptive design
Our mobile app UI/UX design team designs each key screen at compact, medium and expanded widths, plus folded and unfolded states.
Build and state hardening
Compose adaptive layouts, configuration-change handling and keyboard focus built alongside each feature, with screenshot tests at several window sizes.
Sprint demos on real hardware
Every two weeks a Play internal testing build goes to tablets and foldables, reviewed against written acceptance criteria.
Release
Tablet screenshots for the Play listing, a staged rollout, and Android vitals monitoring on large-screen devices after launch.
Related services
If your app is behind on target API levels more broadly, our Android app upgrade and migration service covers the full SDK move. Building for Apple tablets too? Our iPad app development page explains the iPadOS 26 windowing changes, which push in the same direction. For deeper device coverage and automated tests, see mobile app testing and QA, or hire Android developers with large-screen experience to join your team, starting with a two-week trial.
Android tablet apps we have shipped
[[Case study: app name, client industry and country, starting state, quality tier achieved, devices tested, and a verified result. Confirm with the client before publishing.]]
[[Client testimonial with name, role and company, used with written permission.]] Until these are ready, see our portfolio.
Android tablet app development company FAQs
What changes for tablets when my app targets API 36?
On displays with a smallest width of 600dp or more, Android 16 ignores orientation, resizability and aspect-ratio restrictions for apps targeting API 36, so your app fills the window. Because Google Play requires API 36 for new apps and updates from 31 August 2026, this affects your next update. Phone-only layouts can stretch, misplace controls or lose state on rotation.
Can we just opt out of the Android 16 large-screen rule?
Only for a while. Android 16 offers a temporary opt-out property, but it stops working once your app targets API 37, and Play raises the target level every year. Using it can buy time for a proper fix on a large app. We treat it as a bridge while adaptive layouts are built, not as a long-term solution.
Do games have to follow the same rule?
No. Apps that declare themselves as games through the android:appCategory attribute are exempt from the Android 16 orientation and resizability change. Games still benefit from testing on tablets and foldables, since aspect ratios vary widely, but they can keep a fixed orientation. The exemption only applies if the app is declared as a game through that attribute.
What are Google’s adaptive app quality tiers?
Google grades large-screen support in three tiers. Tier 3, adaptive ready, means full screen without letterboxing and basic keyboard, mouse and stylus support. Tier 2, adaptive optimized, adds layouts for every screen size. Tier 1, adaptive differentiated, adds multitasking, foldable postures, drag and drop and stylus features. We agree a target tier per screen during discovery.
Do you test on real foldables?
Yes. Resizable emulators are good for fast layout checks, but folding and unfolding mid-task, hinge position and posture changes need a physical device. Every release candidate goes through our large-screen checklist on real tablets and at least one foldable, including continuity tests during video playback and form entry.
How much does it cost to make an Android app tablet-ready?
It depends on how the phone app was built and the quality tier you want. A clean Compose app may need mostly layout work on key screens; a portrait-locked XML app usually needs state fixes first. As market context, 13 of the 16 Pakistani firms with a stated rate on page one of Clutch’s directory list $25 to $49 an hour. We give a fixed price after a short audit.
Make your Android app look right on every large screen
Book a 30-minute call. We will review your app on tablets and foldables with the API 36 rule in mind, agree a target quality tier, and outline a sprint plan.