For a long time, Android gave developers a quiet way out. If your app wasn’t ready for resizable windows or unexpected orientations, you could declare it in the manifest — lock to portrait, fix an aspect ratio, mark the activity as non-resizable — and the platform would mostly respect it. That arrangement is ending.

In February 2026, Google published a post explicitly framing the changes coming in Android 17 as the next phase of its adaptive roadmap. The headline is straightforward: Android 17 removes the developer opt-out for orientation and resizability restrictions on large screen devices. When you target API level 37, those manifest attributes and runtime APIs — screenOrientation, setRequestedOrientation(), resizeableActivity, minAspectRatio, maxAspectRatio — are simply ignored on any device whose smallest screen dimension is 600dp or larger. There’s no override, no flag to enable the old behavior. It’s gone.

The practical deadline that gives this teeth: Google Play will require apps to target API level 37 starting in August 2027. That’s not far off for teams with large codebases or complex UI work.

This Isn’t New — But Now It’s Mandatory

The groundwork was laid in Android 16, which introduced these changes while still allowing a temporary opt-out to ease the transition. Google says many developers have already made the move when targeting API level 36. Android 17 closes the door for those who haven’t. No new behaviors are being introduced; the opt-out is simply no longer available.

The scope of the change is worth being precise about: it applies to large screens, defined as devices where the smallest display dimension is at least 600dp. It does not apply to smaller phones, and it explicitly carves out apps flagged as games via the android:appCategory manifest attribute. So if your app is a game, you have more breathing room. If it’s anything else and it runs on tablets, foldables, or — as we covered recently — connected external displays, you are affected.

The Failure Modes Google Is Expecting

The February post doesn’t just describe what’s changing — it anticipates the problems teams will hit and names them directly. That specificity is worth paying attention to, because these aren’t edge cases. They’re the natural consequence of assumptions that seemed safe on a phone but break down the moment the window shape becomes unpredictable.

Camera previews that stretch or rotate. This is the first problem the post calls out, and it’s a common one on foldables and landscape tablets. Apps that assume fixed relationships between camera sensor orientation and device orientation produce previews that are cropped, rotated, or distorted when those assumptions no longer hold. In multi-window, desktop windowing, or connected display scenarios, the window the app occupies is only a portion of the screen — which means using screen size to determine camera viewfinder dimensions will produce a stretched preview. The recommended fix is Jetpack CameraX, which handles these transformations automatically. For Camera2 codebases, the CameraViewfinder library is the next best option.

Stretched layouts and unreachable buttons. If you’ve set buttons or form fields to fillMaxWidth or match_parent, they look fine on a phone. On a tablet in landscape, they stretch awkwardly across the full screen. More critically, action buttons — a Save or Login at the bottom of a screen — can end up offscreen entirely in landscape orientation if the container isn’t scrollable. The post offers specific Compose patterns for both: using widthIn to cap component width, and adding verticalScroll to containers so nothing gets pushed out of reach.

Lost state on configuration changes. Removing orientation and aspect ratio restrictions means window size changes will happen more often — when users rotate their device, fold or unfold it, or resize your app in split-screen or desktop windowing. By default, these configuration changes destroy and recreate the activity. If your app doesn’t manage this properly, users lose scroll position, partially filled forms get wiped, and navigation history disappears. The post recommends proper use of saved state APIs, and notes that with Jetpack Compose you can opt out of activity recreation entirely, letting window size changes trigger recomposition instead.

The Testing Tools You Should Know About

Two specific tools get highlighted in the post for verifying your app handles these scenarios correctly.

Compose UI Check is an automatic UI auditing tool built into Android Studio that scans your Compose UI for adaptive issues and surfaces suggestions. It can catch problems — like components that will stretch badly at wider widths — without you having to manually resize an emulator and look for them.

DeviceConfigurationOverride is a testing API that lets you simulate specific display characteristics in your tests — particular window sizes, density values, or font scale configurations — without needing physical hardware or a running emulator session. For teams writing UI tests, this makes it possible to build adaptive coverage into your standard test suite rather than treating it as a manual QA step.

For hands-on testing, Google recommends the Android 17 Beta with the Pixel Tablet and Pixel Fold emulators in Android Studio, targeting sdkPreview = "CinnamonBun". Teams not yet targeting API level 36 can use the app compatibility framework to enable the UNIVERSAL_RESIZABLE_BY_DEFAULT flag and test the behavior ahead of formally bumping the target SDK.

The Underlying Shift

It’s worth stepping back to see what this post represents in context. Android 16 introduced these API changes with an opt-out. The connected display support that reached general availability in Android 16 QPR3 created real-world scenarios where phones run windowed desktop sessions on external monitors. Android 17 removes the opt-out. The adaptive roadmap is progressing in a straight line, and each step makes the previous workarounds less viable.

The post is explicit that the goal is a consistent, high-quality experience across all Android form factors — phones, foldables, tablets, desktop windowing, car displays, XR. That’s a broad mandate. For development teams, the practical takeaway is the same one that keeps showing up across Google’s recent posts: “phone-first” is still a valid starting point, but “phone-only” is becoming an increasingly fragile assumption. The platform is systematically removing the mechanisms that allowed that assumption to survive.

August 2027 sounds distant. For large apps with deep UI debt, it isn’t.

I’ll be honest: when I first saw Google announce Experimental Gems inside Gemini, I assumed it was just a rebrand of their existing Gems feature. Give Gemini a persona, some instructions, call it a day. I nearly skipped right past it.

That was a mistake. Experimental Gems — powered by a Google Labs tool called Opal — are something meaningfully different. They’re not chatbot personas. They’re closer to interactive mini-apps: things with actual structured workflows, multiple steps, and interfaces you can share with your team. You build them entirely in plain English.

No code. No deployment. No infrastructure to manage. You describe what you want, and Opal generates a working app.

What actually changes here

Let me explain why this is different from just writing a very detailed system prompt.

When you create an Experimental Gem, Opal converts your description into a visible step graph — a structured list of stages that you can inspect, edit, reorder, or tweak individually. It’s not a black box. You can see the logic. You can change it without rewriting everything from scratch.

It’s the difference between having a smart assistant who just improvises every time, and having one who follows a documented process you can actually review and improve.

That distinction matters a lot for developers. We like inspectable systems. We like things we can version, adjust, and hand to teammates with confidence that they’ll get consistent results.

The developer use cases that actually make sense

The obvious question is: okay, but what would I actually build with this?

The sweet spot is tasks that are too complex for a one-liner prompt, but too narrow and repetitive to justify building a full app. Every development team has a pile of these.

Here are the ones I’d build first:

None of these are revolutionary tasks. They’re just things that eat time and benefit from consistency. The point of a Gem isn’t to do something impossible — it’s to take something you’d normally do manually, over and over, and package it so anyone on your team can run it in seconds.

The team angle is where it gets interesting

I’d actually argue the biggest benefit isn’t personal productivity. It’s what happens when you share a well-crafted Gem with your team.

A senior engineer who builds a solid “microservice design review” Gem has essentially packaged their architectural instincts into something a junior engineer can run independently. A DevOps person who builds a “post-incident log analyzer” Gem has turned a manual, expert-intensive task into a self-service workflow anyone on-call can use at 2am.

That’s knowledge transfer that actually sticks. Not a wiki page nobody reads. A tool people actually run.

Gems are also remixable. If your teammate built a documentation Gem tuned for REST APIs, you can copy it, tweak the output format for GraphQL, and save a new variant — all in plain English, all in minutes.

What you should know before diving in

A few honest caveats, because this is still experimental.

Right now, Experimental Gems only work in the Gemini web app, and only in English. Enterprise Workspace accounts and mobile aren’t supported yet. The feature lives in Google Labs, which means it can change, break, or disappear without notice.

Data you send through Opal-powered Gems isn’t governed by the same controls as standard Gemini. Before running anything sensitive — client code, proprietary systems, personal data — check the current data handling policy.

And the usual AI caveats apply: verify the outputs, especially for anything security-adjacent or architecturally significant. Treat it as a strong first draft, not a finished product.

Also worth saying: Gems live inside Gemini, not inside your stack. For anything customer-facing, SLA-bound, or needing real integration with your systems, you still want to build properly via the Gemini Developer API. Experimental Gems are a prototyping and team-enablement layer — not a production deployment.

Is it worth trying now?

Honestly, yes — especially if you’re already using Gemini regularly. The barrier to building a Gem is low enough that you can try one in the time it takes to write a good system prompt. If it works, you’ve got a reusable tool. If it doesn’t, you’ve spent twenty minutes.

The developers who figure out how to build good Gems — specific, well-structured, genuinely useful to their team — will have a real head start as this matures. Right now it’s experimental. It’ll graduate eventually, and when it does, the institutional knowledge your team has built through Gems will travel with it.

It’s not magic. It’s just a smarter way to stop doing the same thing over and over again.

What’s changing now is scope. The major IDE assistants are steadily moving from line-by-line suggestions toward workflows that treat your project as a system: multiple files, navigation edges, refactors that preserve behavior, and task-level planning that resembles how experienced developers actually work.

Three ecosystems show the direction clearly: Android Studio with Gemini, GitHub’s GitHub Copilot and Copilot Workspace, and JetBrains’ JetBrains AI Assistant.

What changed recently: from “suggest” to “act across files”

Android Studio is formalizing agentic, multi-step work inside the IDE. Google’s Gemini experience in Android Studio is no longer framed as “chat plus completions.” The documentation highlights an Agent Mode alongside code completion and a set of actions that touch more than the current line: code transformation, refactoring/renaming, UI transformation, unit test generation, documentation drafting, and commit message generation. [Android Studio]

This matters because it signals a design goal: AI as a tool operator embedded in the coding loop, not just a text predictor. The docs also emphasize that Gemini is “under active development” and updated frequently through Android Studio preview releases—an explicit indication that Google is iterating on capabilities beyond autocomplete as an IDE feature set, not a plugin novelty.

GitHub is pushing Copilot into planning, multi-file edits, and agent workflows. On GitHub’s own blog, “agent mode” is described as a multi-step collaborator that can iterate, recognize errors, and fix issues based on natural-language intent. [GitHub] Separate updates around Copilot “modes” (ask/edit/agent) reflect a product split between quick answers, targeted edits, and longer-running tasks—an explicit move beyond completion toward “do work across the project.”

Copilot Workspace, meanwhile, reads like an attempt to productize codebase reasoning: generating plans, operating on multiple files, improving file search, and adding IDE-like navigation primitives such as go to definition—features that only make sense if Copilot is expected to traverse and modify more than a single buffer. [GitBub Blog]

JetBrains is treating AI as an IDE-native layer, plus “agentic development” as the next step. JetBrains’ AI messaging leans heavily on integration: AI features “directly into JetBrains IDEs” across tasks like explaining code, answering questions about code fragments, generating commit messages, and more—i.e., IDE operations that sit above typing speed. Their 2025 updates also point toward agents (JetBrains references “Junie” and positions it alongside AI Assistant under one subscription), which reinforces the same direction: not just “suggest code,” but help execute development tasks with more autonomy and broader context.

Why it matters: practical wins for experienced developers

Autocomplete is most valuable when you already know what you’re building. Codebase-level assistance helps most when you don’t—or when the cost is in coordination, not keystrokes:

• Refactoring with less dread. Renames and structural refactors are easy to describe (“split this class,” “extract a use-case layer,” “migrate to Compose idioms”) but time-consuming to execute safely. Tools like Gemini’s code transformation/refactor actions aim to compress the mechanical part of that work.
• Navigation that’s closer to intent than grep. “Where is this value set?” “What calls this?” “What breaks if I change the contract?” Copilot Workspace’s file search improvements and “go to definition” hint at AI becoming a higher-level navigation surface over the code graph.
• Multi-file changes as a first-class workflow. When assistants can add files, propose a plan, and update multiple touchpoints, they start to resemble a junior dev who can take a scoped task—especially for migrations, repetitive patterns, and documentation/test scaffolding. Workspace’s multi-file generation focus and Gemini’s unit-test/documentation features both align to that.

Where the ceiling still is: limitations that haven’t gone away

Even as these tools expand scope, their failure modes expand too. The biggest constraints are predictable—and developers will recognize them immediately:

1. Context isn’t comprehension. “Knowing your codebase” often means selectively reading files, guessing intent, and stitching it together. That works for conventional architectures and well-named code. It degrades fast in monorepos, highly generic code, generated sources, or projects with heavy build-time wiring.
2. Refactors need invariants, not just syntax. A tool can rename symbols and rearrange code yet still break behavior (serialization formats, subtle lifecycle ordering, thread confinement, DI graphs). The more “agentic” the tool becomes, the more important it is that it runs tests, builds, and linters—and that developers review diffs like they would a real PR.
3. Project-specific rules are hard to infer. Style guides, architectural boundaries, and product constraints live in human agreements, not code. AI assistants can help enforce patterns once you tell them, but they still struggle to consistently honor implicit rules across a whole codebase.
4. Trust and governance are now part of IDE choice. When tools can traverse files, generate commit messages, and propose multi-file changes, questions about what gets sent to a model, how context is selected, and how changes are audited become practical engineering concerns—not abstract policy debates. (The platform docs emphasize IDE integration and workflows; they also implicitly raise the stakes of how that integration is managed.)

The near-term reality

The shift is real: IDE AI is evolving from “write code faster” to “change code more confidently.” But the value isn’t magic; it’s leverage. The best results come when developers treat these tools like powerful assistants that can draft, refactor, and navigate—while the team still owns correctness, architecture, and review discipline.

In other words: less typing, yes—but more importantly, less mechanical work standing between intent and a clean diff.

That preference isn’t just habit. It reflects how engineers evaluate risk, how software correctness is proven, and where “good enough” is acceptable.

What the reports show

1) Usage is widespread, but trust is not.
In the 2025 Stack Overflow Developer Survey’s AI section, respondents report heavy usage—especially among professional developers who say they use AI tools daily or weekly—while simultaneously expressing low confidence in accuracy. The survey reports that more developers distrust AI output than trust it (46% vs. 33%), and only a small minority “highly trust” results. [Stack Overflow]

That tension (high usage, low trust) is exactly where refactoring becomes the “safe” workload: you can accept help while staying skeptical.

2) Developers want AI for the mechanical parts of the job, not the core reasoning.
JetBrains’ 2025 ecosystem reporting emphasizes that developers are happy to delegate repetitive, low-creativity tasks (boilerplate, documentation, summarizing changes) and prefer to remain in control of complex, higher-risk work—explicitly including debugging and designing application logic.

This aligns neatly with real-world AI behavior: it’s often strong at pattern-based transformations, weaker at domain-specific intent.

3) The tools themselves are shifting toward “maintenance work.”
On the GitHub side, Octoverse signals how central AI has become—e.g., it reports that a large share of new developers adopt Copilot very quickly—and it highlights momentum around “agent” features like automated code review in 2025. [The GitHub Blog] That’s not just about producing new code; it’s about improving and validating existing code. GitHub’s changelog for Copilot code review frames the feature as offloading basic reviews to surface bugs and performance issues and even suggest fixes—again, a maintenance and quality posture rather than greenfield creation.

Taken together, the reported trend is: broad adoption, persistent skepticism, and product investment in workflows that touch existing code and quality gates.

Why this pattern makes sense (interpretation)

The gap between “writing new code” and “refactoring” is basically the gap between unknown correctness and bounded correctness.

Refactoring has built-in guardrails

Refactoring is usually constrained by invariants: behavior should remain the same, tests should pass, types should still check, performance shouldn’t regress. That makes it easier to trust AI conditionally.

Developers can ask for:

• “Extract this method and reduce nesting”
• “Replace this callback chain with coroutines/async”
• “Rename these symbols for clarity”
• “Remove duplication across these two classes”
• “Migrate deprecated API calls to the new API”

Even if the AI isn’t perfect, the outcome is often a diff you can review quickly—then validate with compilation and tests. If it fails, the failure is usually local and diagnosable.

New logic is where mistakes are expensive and subtle

When you ask an AI to write new features, you’re asking it to infer product intent, edge cases, and non-obvious constraints—things that often aren’t present in the code at all.

Examples:

• authorization rules that depend on business policy
• tricky concurrency invariants
• performance budgets in hot paths
• “this must never happen” states enforced by organizational convention
• security implications and data handling requirements

This is exactly where survey respondents report lower trust in AI handling complex tasks. In the Stack Overflow 2025 survey, a meaningful share of developers rate AI tools as bad/very poor at complex tasks, and many avoid using AI for those tasks altogether.

Maintenance work benefits from “good suggestions”, not perfect answers

A lot of refactoring and cleanup work is pattern recognition:

• normalize error handling
• improve nullability/type usage
• apply lint-driven transformations
• convert repetitive code into a shared helper
• modernize language constructs

AI is strong at seeing and applying patterns across files—especially when you can point it at a concrete example (“make the rest look like this”) and then evaluate the patch.

Test generation and legacy-code explanation are “adjacent trust” tasks

Developers often trust AI for tasks that support correctness rather than define it.

Test generation: AI can propose unit tests, edge cases, and fixtures quickly. You still own whether the assertions reflect the intended behavior, but the busywork shrinks. If the tests are wrong, they often fail fast or read as obviously mismatched during review.

Explaining legacy code: Asking “what does this function do?” or “why is this state machine structured like this?” is lower risk than “add a new state.” Even when explanations aren’t perfect, they can accelerate onboarding and guide where to look next—without being the final authority.

The practical takeaway

What’s changing isn’t that developers suddenly “trust AI.” It’s that they’re learning where AI is reliably useful under scrutiny: producing diffs that are reviewable, reversible, and testable.

Refactoring, cleanup, test scaffolding, and legacy-code explanation fit that profile. New feature logic often doesn’t—at least not without tighter specs, stronger verification, and the kind of accountability that surveys suggest developers still reserve for themselves.

I’ve been tracking what actually consumes time in mobile development across multiple teams and projects. Some patterns emerge clearly. More importantly, I’ve seen teams successfully tackle these problems with surprisingly simple solutions. Here’s what’s really wasting your time, and what’s actually working to fix it.

The Build Time Death Spiral

Let’s start with the obvious one: build times. But the real problem isn’t just that builds are slow—it’s that they get progressively slower as your project grows, and most teams don’t notice until it’s painful.

You start with 20-second builds. Six months later, you’re at 45 seconds. A year in, you’re approaching two minutes. It happens gradually enough that you don’t realize how much time you’re collectively losing.

How devs are fixing it: The teams I’ve seen successfully tackle this problem don’t just optimize randomly — they measure first. They use build scan tools (Gradle Enterprise for Android, Xcode build analytics for iOS) to identify actual bottlenecks rather than guessing.

Common culprils they find: annotation processors running on every build, unnecessary clean builds in CI, modules with circular dependencies that prevent parallel compilation, and resource processing on unchanged files.

The fix usually involves modularizing the project more aggressively, moving to incremental annotation processing, and setting up proper dependency management so you only rebuild what actually changed. One team I know cut their build times from 3 minutes to 45 seconds just by properly modularizing their feature modules.

The key insight: Don’t wait until builds are unbearable. Set a threshold (say, 30 seconds for local builds) and treat exceeding it as a P1 bug. Time spent optimizing builds pays itself back within weeks.

Waiting for QA Feedback Loops

Here’s a time-waster that’s invisible in time-tracking tools: the gap between when you think a feature is done and when you get feedback that it’s not.

You implement a feature, mark it ready for testing, move on to something else. Two days later, QA finds an issue. Now you need to context-switch back, remember what you were thinking, fix the issue, and repeat the cycle. The context switching overhead alone kills productivity.

How devs are fixing it: Smart teams are shrinking this feedback loop dramatically. Some approaches that work:

Developers test their own work more thoroughly before marking it ready. This sounds obvious, but it means actually installing the build on physical devices, testing unhappy paths, and checking edge cases—not just verifying the happy path works on the emulator.

Teams are setting up automated testing for common issues: missing error states, broken deep links, accessibility problems, layout issues on different screen sizes. Catching these before QA saves entire cycles.

Some teams do “desk checks” — a quick 5-minute walkthrough with QA before marking something done. It catches obvious issues immediately while the context is still loaded in your head.

The key insight: Every feedback loop iteration costs 1-2 hours of productive time in context switching. Investing 15 extra minutes upfront to catch issues early pays back immediately.

Debugging Device-Specific Issues

“Works on my device” is the mobile developer’s version of “works on my machine,” and it’s just as problematic. Issues that only appear on specific Android devices, certain iOS versions, or particular screen sizes consume enormous amounts of time.

The worst part? You often can’t reproduce the issue on your development device, so you’re debugging blind or constantly switching between devices.

How devs are fixing it: The most effective approach I’ve seen is maintaining a small device lab that covers the actual devices your users have. Not 50 devices—just 5-6 that represent your real user base.

Check your analytics. Find the top 3-4 Android devices and iOS versions your users actually use. Test on those specifically during development, not just at the end. One team reduced device-specific bugs in production by 60% just by testing on 4 specific mid-range Android devices during development instead of only on flagship phones.

For issues you can’t reproduce locally, teams are getting better at remote debugging. Firebase Crashlytics with proper logging, App Center for distribution with built-in crash reporting, and better error tracking in production means you can often identify and fix issues without reproducing them locally.

The key insight: Your iPhone 16 Pro and Pixel 9 don’t represent your users. Test on what they actually use, and test early.

Unclear Requirements and Scope Creep

Here’s the biggest time-waster that has nothing to do with code: building the wrong thing, or constantly rebuilding things as requirements change.

You implement a feature based on a design mockup and some brief notes. Partway through, you discover the mockup doesn’t cover error states. You make your best guess. Later, you learn your guess was wrong and need to redo it. Then someone realizes the feature needs to work offline, which wasn’t mentioned anywhere.

How devs are fixing it: The best teams I know have a simple rule: no implementation without a spec. Not a 20-page document—a one-page doc that answers: What are we building? Why? What are the success criteria? What are the edge cases? What’s explicitly out of scope?

The spec takes 30 minutes to write. It saves hours of rework. More importantly, writing it usually surfaces questions and assumptions that would have caused problems later.

Some teams do a quick “pre-implementation review” where the developer reads the spec, looks at designs, and comes back with questions before writing any code. This 15-minute conversation often prevents days of wasted work.

The key insight: Every hour spent clarifying requirements saves 5-10 hours of implementation and rework. The fastest code to write is code you don’t have to rewrite.

Fragmented Communication and Context Hunting

How much time do you spend hunting for information? Checking Slack, searching JIRA, looking for that design file, finding the API documentation, locating the decision that was made in some meeting you weren’t in.

This invisible overhead adds up fast. A few minutes here, a few minutes there—but it happens dozens of times per day and completely fragments your focus.

How devs are fixing it: The solution isn’t a better tool – it’s better information architecture. Teams that solve this problem have clear conventions:

All technical decisions go in one place (many teams use ADRs—Architecture Decision Records—in their repo). All design files are linked in the relevant tickets. API documentation is kept in the repo, not in external docs that get out of date. Each feature has a clear owner who’s the go-to person for questions.

Some teams maintain a simple wiki with “Start here” pages for common questions: How do I set up the project? Where are the API docs? How do I test payment flows? Where are our coding standards?

The key insight: If everyone on the team asks the same question twice, document the answer once in a findable place. The ROI is immediate.

Flaky Tests and CI Pipeline Issues

You push code. CI fails. You check the logs — it’s a test that randomly fails sometimes. You restart the build. It passes. You just wasted 20 minutes and eroded trust in your test suite.

Flaky tests are insidious because they train developers to ignore test failures. Once that happens, your entire test suite loses value.

How devs are fixing it: Zero tolerance for flakiness. When a test flakes even once, it gets fixed or disabled immediately. Never restart a flaky test hoping it passes—fix it.

Common causes of flakiness in mobile tests: timing issues (waiting for animations or network calls), order dependencies between tests, shared state that doesn’t get cleaned up, and tests that depend on external services.

Teams that solve this usually invest in better test infrastructure: proper test fixtures, deterministic clocks and schedulers, mock network responses, and isolated test data. They also run tests multiple times locally before pushing to catch intermittent failures early.

For CI pipeline issues, the fix is monitoring and alerts. Set up notifications when builds are taking longer than normal, when certain steps fail repeatedly, or when cache hit rates drop. Treat CI health as a team priority, not an afterthought.

The key insight: A flaky test is worse than no test. It wastes time and destroys confidence. Fix it immediately or remove it.

Manual Deployment and Release Processes

I still see teams where releasing an app involves a checklist of 15 manual steps, takes two hours, and requires someone senior because they’re the only one who knows all the gotchas.

This is pure waste. Every release takes hours, creates anxiety, and creates single points of failure on your team.

How devs are fixing it: Full automation of the release process. Not partial automation—full automation. A single command or button that does everything: version bumping, changelog generation, building release artifacts, running the full test suite, uploading to app stores, creating git tags, notifying stakeholders.

Tools like Fastlane make this achievable in a few days of setup work. Yes, there’s an upfront investment. But once it’s done, releases go from a half-day ordeal to a 5-minute task anyone can do.

Some teams go further and automate the entire deployment pipeline: merge to main triggers tests, successful tests trigger a beta deployment, manual approval triggers production release. Releases become routine instead of events.

The key insight: If your release process takes more than 15 minutes of human time, you’re wasting hours every release cycle. Automate it completely.

The Time Tax Compounds

The insidious thing about these time-wasters is how they compound. Slow builds make you context-switch more. Poor communication leads to building the wrong thing. Unclear requirements cause rework. Flaky tests waste time on every push. Manual deployments create bottlenecks.

A team experiencing all these problems simultaneously isn’t 50% less productive — they’re 70% or 80% less productive. Fixing them doesn’t just save time; it restores momentum and makes development actually enjoyable again.

The good news? You don’t need to fix everything at once. Pick the biggest pain point—the one that makes your team groan the loudest—and fix that first. Build momentum. Then tackle the next one.

Because the real win isn’t just saving time. It’s creating an environment where developers spend their energy solving interesting problems instead of fighting their tools and processes. That’s when great apps get built.

The first thing to break is almost always the layout.

Common symptoms:

• Text lines become uncomfortably wide
• Important actions drift to awkward corners
• Empty space appears with no purpose
• UI feels “stretched” instead of designed

These issues don’t show up on emulators with a few preset sizes. They appear when:

• The app is resized mid-session
• A foldable changes posture
• Multi-window kicks in

Why it happens
Layouts were designed for fixed dimensions, not flexible ranges.

How to avoid it

• Design around size classes or ranges, not devices
• Use max-widths for readable content
• Let layouts reflow, not just scale

Designing apps that actually feel good on phones, tablets, and foldables

If your layout logic can’t explain why something moves, it will feel wrong when it does.

2. Navigation becomes confusing or redundant

Navigation systems that feel fine on phones often fall apart on larger screens.

What breaks:

• Drawers that feel unnecessary on tablets
• Bottom navigation floating awkwardly in wide layouts
• Duplicate navigation controls appearing at once

Users don’t just notice this — they lose confidence in the app.

Why it happens
Navigation was treated as a static component instead of a system that adapts to space.

How to avoid it

• Let navigation change position as space increases
• Avoid showing the same controls in multiple places
• Keep destinations consistent even if presentation changes

Navigation should evolve with space, not stubbornly stay the same.

3. State breaks during resizing and multitasking

Multi-device apps live in a world of constant interruption:

• Resizing
• Splitting screens
• Minimizing and restoring
• Folding and unfolding

The first serious bugs many teams hit are state-related:

• Lost scroll position
• Reset forms
• Disappearing selections
• Reloaded screens mid-task

Why it happens
State is tied too closely to layout or lifecycle assumptions.

How to avoid it

• Separate UI state from layout state
• Treat resize events as normal, not exceptional
• Preserve user intent aggressively

If resizing your app feels like restarting it, users won’t trust it.

4. Input assumptions start to fail

Screen size gets attention. Input method usually doesn’t — until things feel off.

What breaks:

• No keyboard navigation
• Invisible focus states
• Hover-dependent UI on touch devices
• Touch-only gestures on desktop

On larger devices, users expect precision and speed. An app designed purely for touch often feels slow and clumsy with a keyboard and mouse.

Why it happens
Input was assumed, not designed.

How to avoid it

• Support keyboard navigation early
• Make focus visible and predictable
• Avoid gestures as the only way to act

If users can’t tell what’s focused, they’ll feel lost.

5. Performance degrades unevenly

Multi-device doesn’t mean equal hardware.

What breaks:

• Smooth phone performance, laggy tablet experience
• Expensive recompositions during resizing
• Animations that stutter on larger layouts

These issues often go unnoticed until late testing.

Why it happens
Performance was tuned for one form factor.

How to avoid it

• Test performance across size classes, not devices
• Watch for layout-triggered re-renders
• Optimize transitions, not just steady states

Consistency matters more than raw speed.

6. Feature parity becomes a trap

One of the fastest ways to hurt a multi-device app is trying to ship everything everywhere.

What breaks:

• Overcrowded phone UIs
• Underutilized tablet space
• Complex flows forced onto small screens

Why it happens
Teams chase symmetry instead of usability.

How to avoid it

• Decide which features benefit from space
• Scale features intentionally, not automatically
• Allow some capabilities to appear only where they make sense

This same selective approach is becoming common with AI features across platforms
Apple, Google, and Samsung Are All Betting on On-Device AI

Not every device needs every tool.

7. Testing misses real-world behavior

Many multi-device issues survive because they’re never tested properly.

What gets missed:

• Resizing during active tasks
• Keyboard-only navigation
• Multi-window workflows
• Long sessions on large screens

Why it happens
Testing focuses on correctness, not experience.

How to avoid it

• Resize while interacting, not just at launch
• Test with different input methods
• Use the app the way users actually will

If it feels awkward for you, it will feel worse for users.

The pattern behind all these failures

Almost every early multi-device failure comes down to one thing:

Assumptions.

Assumptions about:

• Screen size
• Input method
• App visibility
• User focus

Multi-device apps break when those assumptions stop being true.

This is why multi-device success is less about tooling and more about mindset

Final thoughts

When apps go multi-device, the first things to break aren’t exotic features — they’re fundamentals.

Layouts, navigation, state, and input expose whether an app was designed to adapt or merely resized after the fact.

The teams that succeed don’t avoid these problems by accident. They anticipate them, design for flexibility early, and test for feel, not just correctness.

Multi-device doesn’t have to be painful — but it does demand honesty about what usually breaks first.

Related article: Designing apps that actually feel good on phones, tablets, and foldables

The biggest productivity gains in mobile development don’t come from learning the hottest new framework or adopting the latest architecture pattern. They come from tiny workflow adjustments that eliminate friction from tasks you do fifty times a day.

I’m talking about the small stuff: switching between files, running builds, checking designs, testing on devices. Individually, each action takes seconds. Cumulatively, they define whether you’re in flow state or constantly interrupted by tooling overhead.

After years of building mobile apps and obsessively tracking what actually slows me down, I’ve identified workflow micro-optimizations that genuinely add up. These aren’t dramatic overhauls — they’re small changes that compound into hours saved every week. Here’s what actually works.

Master Your IDE’s Navigation (Not Just Search)

Everyone knows Command+Shift+O (or Ctrl+Shift+N) to search for files. But most developers stop there and miss the navigation features that eliminate the search step entirely.

Learn “Go to Last Edit Location” (Command+Shift+Delete on Mac). When you’re bouncing between files—implementing a feature in your ViewModel, updating the UI in your Fragment, adding a network call in your repository—this single shortcut takes you exactly where you were working, with your cursor at the right line. No searching, no scrolling.

Similarly, “Recent Files” (Command+E) with the search filter lets you type a few characters and jump to any recently-opened file instantly. Unlike file search, it’s scoped to your current context, which means fewer keystrokes and faster results.

Set Up Proper Build Variants for Daily Development

How many times a day do you build and run your app? If you’re like most developers, dozens. And if each build includes every feature, library, and build configuration you’ll eventually ship, you’re wasting enormous amounts of time.

Create a “dev” build variant that strips out everything non-essential: analytics, crash reporting, complex animations, heavy background tasks, third-party SDKs you’re not actively working on. Enable R8 only in release builds. Disable unnecessary build steps.

On a mid-sized app, this can cut build times from 45 seconds to 20 seconds. That’s 25 seconds saved per build. If you build 40 times a day (conservative for active development), you’ve just saved 16 minutes daily. That’s over an hour per week, and you get the bonus of staying in flow state rather than context-switching during every build.

Go further: set up a minimal build variant with a single feature for when you’re doing focused work. Building the entire app to test one screen is usually overkill.

Use Template Files for Repetitive Patterns

Every project has patterns you recreate constantly: a new Fragment with the standard setup, a ViewModel with dependency injection configured, a RecyclerView adapter, a network repository class, a SwiftUI view with your team’s standard structure.

Create file templates for these. In Android Studio: Settings → Editor → File and Code Templates. In Xcode: create file snippets or use custom templates.

Now instead of copying an existing file, renaming things, and deleting irrelevant bits (error-prone and surprisingly time-consuming), you generate the structure you need with the correct naming from the start.

This saves 2-3 minutes every time you need to create these files. If you’re actively developing new features and creating 3-4 of these files daily, that’s another 10-12 minutes saved per day, or roughly an hour per week.

Automate Device Testing Setup

How much time do you spend installing builds on test devices, clearing app data between test runs, navigating to the specific screen you’re testing, and setting up test states?

Write scripts. A simple shell script or Gradle task can: uninstall the current build, install the new one, grant necessary permissions, and launch directly to the screen you’re testing. Add flags to your app that let you skip onboarding, bypass login with test credentials, or jump to specific states.

For iOS, create schemes that configure these options. For Android, use custom debug-only intents or deep links.

The setup time for this is maybe an hour. The daily savings when you’re testing a feature 20+ times? Easily 15-20 minutes, often more. That’s over an hour weekly, and it eliminates the tedious manual steps that break your concentration.

Keep a Running Debug Log (Not In Your Head)

Here’s a workflow change that’s psychological as much as technical: maintain a simple text file where you note what you’re working on, weird behaviors you’ve noticed, and things to investigate later.

When you spot something odd but don’t have time to dig into it right now, you log it. When you make a temporary workaround, you note it. When you change something that might affect other features, you write it down.

This takes 30 seconds when you do it, but saves 10-15 minutes later when you’re trying to remember “what was that weird thing I noticed yesterday?” or when a bug report comes in and you realize you’d already spotted the issue but forgot about it.

It also helps during daily standups or when handing off work—you have a record of what you actually did rather than trying to reconstruct it from memory.

Set Up Automatic Resource Organization

Every app accumulates drawables, string resources, layouts, and assets. When these aren’t organized, you waste time hunting for the right file or accidentally duplicating resources that already exist.

Create a simple naming convention and folder structure, then enforce it automatically with lint rules or git hooks. For example: ic_feature_action_size.xml for icons, organized by feature in subdirectories if your project supports it.

Add a custom lint check that flags resources not following your naming convention. Set up a git pre-commit hook that warns about unused resources or duplicates.

This prevents the “where did I put that icon?” problem and the “we have three versions of the same drawable with different names” problem. Small savings each time, but over a week of active development, this easily saves 30-60 minutes of resource hunting and cleanup.

Use Keyboard Shortcuts for Build Actions

Most developers click the “Run” button or use a single shortcut to build and run. But you’re not always running on a device—sometimes you just need to compile, or sync Gradle, or clean the build.

Learn these distinct shortcuts:

• Build module (usually faster than building everything)
• Run without building (when you know the code hasn’t changed)
• Clean build (only when actually needed)
• Sync Gradle (faster than full build when you only changed dependencies)

Using the right action for the moment saves 5-30 seconds per build cycle. If you’re building conservatively 30 times a day and using the right action saves 10 seconds average, that’s 5 minutes daily, or 25 minutes weekly.

Batch Similar Work Together

Context switching is expensive. Your brain needs time to load the mental model for each type of work: UI implementation requires different thinking than business logic than network integration than testing.

Instead of jumping between different types of work throughout the day, batch similar tasks together. Spend a focused hour on UI implementation, then switch to an hour of business logic, then an hour of testing.

This isn’t a workflow tool change, but it’s a workflow pattern change. The time savings come from reduced context switching overhead. Most developers find they complete tasks 20-30% faster when batching similar work, which translates to 1-2 hours saved weekly.

Create Quick Access to Common Commands

How often do you run the same complex commands? Starting your backend locally, running specific test suites, cleaning build caches, deploying to test environments, generating code from protobuf or GraphQL schemas?

Create shortcuts for these. Use IDE tasks, shell aliases, or custom Gradle tasks. Put frequently-used commands in a README or a scripts folder with memorable names.

Instead of remembering (or searching Slack for) the exact command with all its flags, you type run-backend or test-auth or clean-all. Each command execution saves maybe 20-30 seconds. Run 10 of these per day and you’ve saved 3-4 minutes daily, or about 20 minutes weekly.

The Compounding Effect

None of these changes are dramatic. None will double your productivity tomorrow. But they compound.

Let’s be conservative and say these optimizations collectively save 30 minutes per day. That’s 2.5 hours per week, or roughly 120 hours per year. That’s three full work weeks.

But the real benefit isn’t just time—it’s maintaining flow state. When you eliminate the small friction points that constantly interrupt your thinking, you stay in the zone longer. You solve problems faster. You make fewer mistakes.

The best workflow optimizations are the ones you stop noticing because they’ve become natural. They’re not tools you use, they’re patterns you’ve internalized that let you focus on what actually matters: building great apps.

Start with one or two changes this week. Stick with them until they’re habitual. Then add another. Within a month, you’ll wonder how you ever worked any other way.

PS: Once again:

This wasn’t an experiment in replacing human developers or seeing if AI could build an entire app. It was about finding the boundaries: what kinds of coding work benefit from AI assistance, and what kinds still demand human expertise and judgment?

The results surprised me. AI excelled in areas I expected it to struggle, and failed in ways I didn’t anticipate. Here’s what I learned from letting AI write part of my code.

Where It Worked: Data Transformation Logic

The single biggest success was using AI for data transformation code—the unglamorous work of converting API responses into domain models, formatting data for display, and mapping between different representations.

I’d paste an API response structure and describe what I needed, and the AI would generate parsing logic, null handling, type conversions, and edge case handling. For a recent project involving a complex nested JSON structure, AI wrote about 80% of the transformation layer, and it was mostly correct.

Why this worked: these tasks are mechanical and pattern-based. Given clear input and output types, there’s usually one obvious correct approach. AI has seen thousands of similar transformations in training data.

What I still had to do: verify the edge case handling was actually correct, not just plausible. AI might add null checks, but it doesn’t know which fields should never be null in your domain. I caught several cases where AI was too defensive (checking for nulls that couldn’t exist) or not defensive enough (missing validation for optional fields that business logic treats as required).

Where It Worked: UI Layout Boilerplate

Building UI layouts in Jetpack Compose and SwiftUI involves a lot of structural repetition. Container views, modifiers, spacing, accessibility labels—it’s tedious but straightforward work.

AI excels here. I’d describe a layout (“two-column grid of cards, each with an image, title, subtitle, and action button”) and get working code that was 90% of what I needed. The structure was right, the components were appropriate, and basic styling was sensible.

For a settings screen with a dozen different row types, AI generated all the layout code in minutes. I just refined the styling and wired up the actual actions.

Why this worked: UI layouts are highly constrained by framework conventions. There are only so many ways to build a card layout or a form screen, and AI has seen them all.

What I still had to do: the generated layouts often lacked attention to detail. Spacing wasn’t quite right, accessibility support was basic, and responsive behavior for different screen sizes was missing. The structure was there, but making it actually good required human polish.

Where It Partially Worked: Network Layer Implementation

AI did reasonably well at generating network request code following established patterns. Given an API endpoint specification and an example of existing network code in my project, it could create new endpoints with proper error handling, request/response models, and retry logic.

But “reasonably well” meant I still spent significant time reviewing and correcting. About 60% of the generated code made it to production as-written.

Why this partially worked: network code follows predictable patterns, but the details matter enormously. Error handling, timeout values, retry strategies, authentication token handling—all of these require context-specific decisions.

What I still had to do: verify authentication was handled correctly, adjust timeout values based on endpoint characteristics, ensure error messages were user-facing appropriate, add proper logging for debugging, and validate that the retry logic wouldn’t cause issues in edge cases.

AI would sometimes generate technically correct code that didn’t fit the app’s error handling philosophy or made assumptions about network reliability that weren’t appropriate for mobile.

Where It Worked Surprisingly Well: Test Case Generation

I was skeptical about AI-generated tests, but this turned out to be one of the more valuable use cases. Given a function or component, AI could generate a comprehensive set of test cases covering happy paths, edge cases, and error conditions.

For a complex validation function, AI generated 15 test cases that I wouldn’t have thought to write manually. It caught edge cases like empty strings, extremely long inputs, special characters, and boundary values.

Why this worked: AI is good at thinking through permutations and combinations. Test case generation is partly about imagining what could go wrong, and AI has seen countless bug reports and test suites.

What I still had to do: verify the assertions actually tested meaningful behavior, not just that code executed without errors. AI would sometimes generate tests that passed but didn’t actually validate correctness. I also had to add tests for business-logic-specific scenarios that AI couldn’t infer from just looking at the code.

Where It Failed: State Management Logic

This was the biggest failure point. Anything involving complex state transitions, lifecycle management, or coordinating multiple pieces of state—AI consistently produced code that looked plausible but had subtle bugs.

I tried having AI implement a feature with multiple interdependent states (loading, loaded, error, refreshing) and user interactions that affected those states. The generated code compiled and mostly worked, but had race conditions, missing state transitions, and edge cases where the UI could get stuck.

Why this failed: state management requires understanding temporal relationships and all possible sequences of events. AI generates code that handles the cases it “thinks about” but misses the interactions between states and the edge cases where multiple things happen simultaneously.

What I learned: never accept AI-generated state management code without thorough review and testing. Even code that appears correct often has subtle timing bugs or missing transitions that only appear in specific scenarios.

Where It Failed: Performance Optimization

AI can suggest optimizations, but it doesn’t actually understand performance in context. I asked it to optimize a RecyclerView implementation that was causing frame drops, and it suggested several changes that sounded reasonable but didn’t address the actual problem.

It recommended view recycling patterns that were already implemented, suggested caching that wouldn’t help, and missed the real issue (complex measurement calculations in onBind).

Why this failed: performance optimization requires profiling, understanding what’s actually slow, and knowing the platform-specific characteristics of the runtime. AI generates generic optimization advice, not targeted solutions to real performance problems.

What I learned: use AI to generate optimization ideas to investigate, but don’t trust its solutions without measuring. Performance is empirical, not theoretical.

Where It Failed Spectacularly: Architecture Decisions

I tried asking AI to help design the architecture for a new feature involving offline-first data synchronization. The suggestions sounded sophisticated but were actually problematic.

AI suggested patterns that would work in a backend service but created issues in a mobile context—unnecessary complexity, battery drain from background work, and patterns that conflicted with Android’s lifecycle constraints.

Why this failed: architecture decisions require understanding tradeoffs specific to your app, platform, and constraints. AI has knowledge of patterns but no judgment about when to use them.

What I learned: AI can explain existing patterns and suggest approaches, but architectural decisions require human judgment about priorities, constraints, and long-term maintainability. Don’t outsource these decisions to AI.

Where It Failed Subtly: Memory Management

AI generated code that worked correctly but had memory leaks—capturing strong references in closures, not properly cleaning up observers, creating retain cycles.

The code functioned perfectly in testing but would gradually consume more memory over time. These are exactly the kinds of bugs that are hard to catch in review and even harder to debug in production.

Why this failed: memory management requires understanding ownership and lifecycles. AI knows the syntax but doesn’t reason about object graphs and reference cycles.

What I learned: any AI-generated code that involves closures, callbacks, or observers needs careful review for memory management. Run it through memory profilers, not just functional tests.

The Pattern That Emerged

After six months, a clear pattern emerged: AI excels at generating code where correctness is locally verifiable and fails when correctness depends on broader context.

AI works well for:

• Transforming data with clear input/output contracts
• Generating structural code following established patterns
• Creating test cases for isolated functions
• Implementing well-defined, self-contained logic

AI struggles with:

• Code where correctness depends on timing or sequence
• Decisions requiring platform-specific knowledge
• Optimization requiring empirical measurement
• Architecture requiring tradeoff analysis
• Anything involving memory management or resource lifecycles

The New Development Rhythm

My workflow evolved to leverage AI’s strengths while protecting against its weaknesses:

For mechanical tasks (data models, boilerplate, standard layouts), I let AI generate first drafts and spend my time reviewing and refining rather than typing.

For complex logic (state management, business rules, performance-critical paths), I write it myself but use AI as a rubber duck—explaining my approach and asking for potential issues.

For testing, I let AI generate initial test cases, then add my own tests for business-specific scenarios and integration cases.

For architecture and design decisions, I make them myself but sometimes ask AI to critique my approach or suggest alternatives I might not have considered.

The Honest Assessment

Did AI make me more productive? Yes, but not as much as the hype would suggest. I’d estimate a 15-20% productivity gain, concentrated in specific types of work.

The time I saved on boilerplate and mechanical coding, I partially spent on more careful review and debugging of subtle issues in AI-generated code. I’m faster at producing code, but not proportionally faster at producing correct, production-ready code.

The bigger benefit wasn’t speed—it was being able to focus my cognitive energy on the interesting problems. When AI handles the boring parts competently, I have more mental bandwidth for the complex parts that actually matter.

What This Means for Mobile Development

AI is genuinely useful for mobile development, but it’s not a replacement for expertise—it’s an amplifier. It makes experienced developers more productive at certain tasks, but it won’t make inexperienced developers suddenly capable of building production apps.

The developers who benefit most are those who can quickly distinguish between “this AI-generated code is good” and “this looks good but is subtly wrong.” That distinction requires the exact expertise AI is supposedly replacing.

We’re not headed toward a world where AI writes apps and humans just review. We’re headed toward a world where humans focus more on architecture, optimization, and complex logic, while AI handles more of the mechanical translation of intent into code.

For mobile developers, that’s actually good news. The work that’s being automated is the work most of us would rather not do anyway. The work that remains is the interesting part—solving hard problems, making smart tradeoffs, and building apps that genuinely work well.

Just don’t trust AI to make those decisions for you. It can’t.

Here’s what rarely gets discussed in those breathless product announcements: while you’re optimizing for a foldable that 2% of your users might own, your app probably looks broken on the iPad someone’s grandmother actually uses, renders poorly in split-screen mode on Android, and has an awkward layout when someone tilts their phone to landscape.

After building apps that need to work across every device users actually have, I’ve learned a hard truth: getting the basics right matters infinitely more than chasing the cutting edge. Here’s why responsive layouts still deserve far more of your attention than any new form factor.

The Devices People Actually Use

Let’s ground this in reality. Pull up your analytics. What do you actually see?

For most apps: 60-70% phones in portrait, 15-25% tablets, 5-10% phones in landscape, and maybe—maybe—1-3% foldables or other exotic form factors. The bulk of your users are on “boring” devices that have existed for a decade.

But here’s what your analytics might not show clearly: how many of those users encounter broken layouts? How many people on a standard iPad see your app stretched awkwardly because you designed only for iPhone sizes? How many Android users in split-screen mode see half your UI cut off?

These aren’t edge cases. A tablet in landscape is not an edge case — it’s how millions of people use their iPads daily. Split-screen mode on Android isn’t exotic – it’s a standard feature people expect to work. Font size accessibility settings aren’t niche—they’re essential for a significant portion of users.

Your responsive layout problems affect more users than all the new form factors combined. They’re just silent failures that people work around rather than report.

The Foldable Paradox

Here’s the irony about foldables: if you’ve actually built proper responsive layouts, supporting foldables is straightforward. If you haven’t, adding foldable support won’t fix your underlying layout problems—it’ll just give you more variants to maintain.

Foldables don’t need special magic—they need apps that properly adapt to different screen sizes and aspect ratios. The same principles that make your app work well on phones, tablets, and in multi-window mode make it work on foldables. Master responsive layouts, and foldable support largely comes for free.

The reverse isn’t true. Build a foldable-specific layout without mastering responsive design, and you’ve just created another fixed-size variant that breaks when users resize the window or rotate the device.

We mentioned some of this in more detailed article: Do We Really Need Foldable Phones Anymore?

What Responsive Actually Means in 2026

Responsive layout isn’t just about phone versus tablet anymore. It’s about handling the reality of how people actually use devices.

Dynamic window sizing: On Android, users resize app windows freely in multi-window mode. On iPadOS, Stage Manager means your app might occupy any size from a small side panel to full screen. Your layouts need to reflow gracefully at any width, not just at specific breakpoints.

Orientation changes: People still rotate their phones, especially for media, forms, and games. If your layout breaks in landscape or you force portrait-only, you’re making a choice that frustrates users daily.

Accessibility text sizes: When someone increases their system text size, your carefully pixel-perfect layout shouldn’t explode. Elements should resize appropriately, text shouldn’t truncate, and the UI should remain usable. This isn’t optional accessibility—it’s basic functionality for a huge number of users.

Keyboard and external input: iPads with keyboards, Android tablets with mice, Samsung DeX mode—users increasingly expect desktop-like interactions on mobile devices. Responsive layouts need to accommodate these usage patterns, not just different screen sizes.

These scenarios affect 30-40% of your users easily. Contrast that with even the most optimistic foldable adoption projections.

The Maintenance Burden Nobody Talks About

Every form factor you specifically target creates maintenance overhead. Special layouts for foldables, custom flows for watches, dedicated designs for large tablets—each one is code you need to maintain, test, and debug.

When you change a feature, you need to update it across all these variants. When you fix a bug, you need to verify the fix works on every form factor. When you add a new screen, you need to design and implement it multiple times.

Compare this to truly responsive layouts: you define flexible constraints and let the system adapt. Change your component once, and it works across all sizes. Fix a bug once, and it’s fixed everywhere. Add a new feature once, and it scales automatically.

I’ve seen teams with separate layouts for phones, tablets, and foldables spend 40% more time on UI work than teams with properly responsive layouts that handle all sizes with the same components. The responsive approach isn’t just better for users—it’s more maintainable for developers.

When Small Screens and Large Screens Diverge

This doesn’t mean every screen should look identical at every size. There are legitimate cases where you want different layouts for different contexts—a list view on phones and a grid on tablets, a single column on small screens and multiple columns on large ones, compressed navigation on phones and expanded navigation on tablets.

The difference is whether you’re designing responsive components that adapt fluidly, or creating separate implementations for specific devices.

Good responsive design uses adaptive layouts: components that change their presentation based on available space, not based on detecting specific device models. SwiftUI’s adaptive stacks, Jetpack Compose’s adaptive layouts, and proper constraint-based designs all work this way.

Bad responsive design uses device detection: if iPad, show this layout; if phone, show that layout. This approach breaks down the moment someone uses your app in an unexpected context—and people always find unexpected contexts.

The Real Innovation in Layout Systems

The actually innovative layout work happening in mobile development isn’t about supporting weird new hardware—it’s about making truly adaptive UIs simpler to build.

SwiftUI’s grid system that automatically adjusts column counts based on available width. Jetpack Compose’s adaptive navigation components that seamlessly transition between bottom navigation, navigation rail, and permanent drawer based on screen size. Modern constraint systems that let you define relationships rather than fixed positions.

These tools make it easier to build UIs that work everywhere, not harder to build separate UIs for each device type. That’s the real innovation—reducing complexity while expanding capability.

Developers who master these systems can build apps that handle any screen size with less code than it used to take to support just phones and tablets separately. That’s the kind of advancement that actually matters.

What About AR and Wearables?

You might be thinking: “But what about genuinely different form factors like watches or AR glasses? Those need different UIs entirely.”

Absolutely. And here’s the thing—those contexts are so fundamentally different that they require completely different interfaces anyway. You’re not adapting your phone UI to a watch; you’re building a companion experience with limited, focused functionality.

That’s different from responsive layout work. When someone uses your app on a tablet versus a phone, they expect the same features and capabilities, just better optimized for the screen size. When someone uses your app on a watch, they expect a completely different, simplified experience.

Don’t conflate “different device category requiring a different UI paradigm” with “different screen size requiring responsive layout.” They’re separate problems with separate solutions.

The Boring Work That Matters

Here’s what I wish someone had told me earlier in my career: the boring, foundational work of making your layouts truly responsive pays dividends forever. Every new device that comes out, every new window mode, every new way users interact with their devices—your app just works.

Meanwhile, teams that chase specific form factors are constantly playing catch-up. Foldables arrive, and they scramble to support them. Multi-window mode becomes popular, and they realize their layouts break. Users start increasing text sizes more often, and suddenly their carefully designed screens are unusable.

The developers I respect most aren’t the ones showing off demos of their apps on the latest foldable prototype. They’re the ones whose apps work flawlessly on any device, in any orientation, with any text size, in any window configuration—because they built properly responsive layouts from the start.

The Practical Path Forward

If you’re maintaining an app right now, here’s what to prioritize:

First, audit your app on the devices people actually use. Not the flagship phone in your pocket—the three-year-old mid-range Android phone, the base model iPad, your app in split-screen mode. Find the broken layouts. Fix those first.

Second, test with accessibility text sizes and different orientations. Make sure your layouts adapt gracefully, not catastrophically.

Third, refactor toward truly adaptive components. Replace device-specific layouts with constraint-based designs that adapt to available space. This is the work that scales.

Then — and only then — if you have specific evidence that your users are on new form factors in meaningful numbers, optimize for those. But you’ll find that if you’ve done the responsive work properly, most of that optimization is already done.

The Bottom Line

New form factors make for exciting demos and compelling tech journalism. Responsive layouts make for apps that work properly for millions of users every day.

The developers who understand this distinction spend their time on work that compounds—building foundations that make every future device easier to support. The developers who don’t understand it spend their time chasing the latest hardware, always one step behind.

Your users don’t care whether your app has a cool unfolding animation on a device they don’t own. They care whether it works properly on the device they’re holding right now, in the way they’re using it right now.

Master responsive layouts. The rest will follow.