Solfreaks MultiScreen is how we build apps that work properly beyond a single phone: tablets, foldables, Chromebooks, iPads, watches, TVs and, where the platforms allow it, cars. Each screen gets a layout and inputs designed for it, while the logic underneath is shared wherever that makes sense.
Most of the apps we're asked to look at were built for one phone size and then stretched. That is why they look broken on everything else.
Why most apps fall apart on bigger screens
A phone layout stretched across a tablet gives you buttons as wide as a table, text lines that run the full width of the screen and a bottom navigation bar nobody can reach comfortably. Foldables add another problem: the window changes size while the app is running. Many apps lock to portrait or ignore resizing, and Android keeps narrowing developers' ability to opt out of that on large screens, so the old shortcut is going away.
The fix is to design against window size, not device type. Android's window size classes and SwiftUI's size classes let one screen reorganise itself: a list becomes list and detail side by side, a bottom bar becomes a navigation rail, and content gets a sensible maximum width. It's more design and testing than stretching a phone UI, and we would rather tell you that now.
What you have at the end
- Adaptive layouts. Core screens reorganise by window size and are tested in portrait, landscape, split-screen and resizable windows.
- Deliberate input handling. Touch, keyboard shortcuts, mouse hover and right-click, TV remote focus order and voice actions are each designed for, not inherited by accident.
- Foldable behaviour. Layouts respond to the hinge and to tabletop posture on devices that have them, and the app keeps its state when the device is folded mid-task.
- Extra targets where you want them. A Wear OS or Apple Watch app, an Android TV or Apple TV app, or an Android Auto or CarPlay screen, each scoped as its own deliverable.
- Shared logic, separate screens. Data and rules live in one place, often using Kotlin Multiplatform, and each form factor gets its own interface.
Cars, watches and TVs have their own rules
Not every screen accepts every app. Android Auto and CarPlay allow only certain categories, such as media, messaging, navigation, parking and EV charging, using fixed templates instead of free-form interfaces. CarPlay also needs an entitlement from Apple, which we can apply for but can't promise. TV apps are driven by a remote, so every control must be reachable by focus, which breaks many touch-first designs. Watches suit glanceable tasks; porting a whole phone app to one almost never works.
How the work runs
- Audience check. Which form factors your users actually own decides the scope, and your current analytics usually settle that within a day or two.
- Layout system. Designers and developers agree breakpoints, navigation patterns per size and a maximum content width before screens are built, as in our UI/UX and app design work.
- Build and test as we go. Each screen is checked on resizable emulators and on physical devices as it lands.
- Release per form factor. Tablet, watch and TV listings have separate requirements in Play Console and App Store Connect, so we allow a few days for review and fixes on each.
Testing, honestly
Emulators catch layout errors quickly, but they can't show how a foldable hinge or a TV remote feels in use. We test on a mix of physical devices and emulators and tell you exactly which we covered; if your audience uses something unusual, we'll ask you to lend a unit or rent time on a cloud device service. Our mobile app QA work covers wider device matrices when you need them.
Which apps need this
It fits apps with real tablet or iPad users, such as education, point of sale, field service, media and healthcare, products moving onto TV or watch, and teams whose reviews complain about the tablet layout.
A full multi-screen project is probably not for you if nearly all of your users are on phones in portrait and you have no plan to reach anything else. A modest tablet-friendly pass is plenty then, and the rest would be wasted money.
What drives the quote
Several things move the quote: how many form factors are in scope, how many screens the app has, whether the app is new or being retrofitted, how different the inputs are and how much real-device testing you want. Tablet and foldable support in an existing phone app usually takes three to eight weeks, while a watch or TV app is scoped separately. We work on a fixed scope per form factor, or monthly if you want us alongside your team. The quote follows a short discovery call.
Who designs and builds the screens
You will be talking to the people who write the code, in a small Rawalpindi team on Pakistan time. Our apps published on Google Play mean we have been through Play Console review ourselves, and the code and store accounts end up with you. If your app attracts complaints about tablets, send us the store link and a screenshot and we'll tell you what we'd change first.
Open-source tools and references
A few public projects that come up a lot in this kind of work. They belong to other people and teams. We link to them because they are worth a look, not because anyone pays us to.
- android/platform-samplesOfficial Android samples, including large-screen features.
- android/socialiteSample app showing adaptive layouts across screen sizes.
- android/compose-samplesOfficial Jetpack Compose sample apps.
Frequently asked questions
Do we need a separate app for iPad?
Usually not. iPhone and iPad can share one app and one store listing, with SwiftUI adapting the layout to the screen. A watch app ships alongside the iPhone app, while an Apple TV app is a separate target with its own interface and review. Apple's rules change from time to time, so we confirm the current setup before we scope your project.
Will our existing Android app work on foldables without changes?
It will run, but running and working well are different things. The usual problems are state lost when the window resizes, camera previews that stretch, layouts that leave a gap beside the hinge and screens locked to portrait. We test your current app on resizable emulators first and give you a list of what breaks before anything is quoted.
Can you put our app on Android Auto or CarPlay?
Only if it fits an allowed category, such as media, messaging, navigation, parking or EV charging, and then only through the platform's templates. CarPlay also needs an entitlement granted by Apple. We can prepare the application and build the screens, but approval isn't ours to promise, and a general consumer app usually doesn't qualify.
Which devices will you test on?
We agree a device list at the start, based on your analytics and the form factors in scope, and send you the results of each round. Physical phones and tablets cover most of it. For unusual hardware such as a particular TV box or foldable, we will say plainly if we only used an emulator, and suggest renting cloud devices or borrowing a unit from you.
Does supporting more screens double the cost?
No. The logic is shared, so the added cost is mostly design and testing of new layouts. Adding tablet support to an existing app is a fraction of building it from scratch. A watch or TV app is a separate piece of work because the interface and inputs are so different, and we price each form factor on its own so you can choose what to fund.
Talk it through with us
Tell us what you are building and where it hurts. You get a straight answer, a plan and a price, and if we are not the right people we will say so.
