App Development

Android app development best practices in 2026: architecture, Compose and Material 3

Updated 5 min readBy Jaskirat Singh Talwar

Stacked phone-shaped layers with orange edges on a dark navy background

A well-built Android app in 2026 separates its code into clear layers, drives the screen from data held in one trusted place, builds its interface with Jetpack Compose and Material Design 3, adapts to phones, tablets and foldables, and stays under Google Play's stability thresholds. None of this is exotic; it is what Google's own architecture and quality guidance recommends, and it makes the app easier to test, change and keep within store rules.

Key takeaways

  • Google recommends at least two layers, a UI layer and a data layer, with an optional domain layer "only when needed".
  • Core principles: separation of concerns, driving the UI from data models, a single source of truth and unidirectional data flow.
  • Jetpack Compose is "Android's recommended modern toolkit for building native UI".
  • Material Design 3 is "an open source, adaptable system of guidelines, components, and tools"; use compact, medium and expanded window size classes for different form factors.
  • Keep the user-perceived crash rate under 1.09% and the ANR rate under 0.47% overall, and under 8% on any one phone model, to protect visibility on Google Play.
  • New apps and updates on Google Play must target Android 16 (API level 36) or higher from 31 August 2026, with some exceptions.

How should you structure the app?

Google's architecture guide recommends layers with clear responsibilities:

Layer Purpose
UI layer Displays application data on the screen; built with Jetpack Compose and state holders such as a ViewModel
Domain layer (optional) Use cases, "only when needed - for example, to handle complexity or favor reusability"
Data layer Business logic and data, made of repositories, one per type of data, each data source working with one source such as a file, network or local database

The guide warns that "It's a common mistake to write all your code in an Activity".

What principles should the code follow?

  • Separation of concerns. Clear responsibilities and boundaries between classes, modules and layers.
  • Drive the UI from data models, preferably persistent ones. Users do not lose data if the operating system ends your app to free memory, and the app keeps working when the network is intermittent or unavailable.
  • A single source of truth. One owner of each piece of data, which alone can change it and exposes it as an immutable type.
  • Unidirectional data flow. State flows one way, down to the UI; events flow back up to the owner of the data.
  • No data in app components. Activities, services and broadcast receivers are short-lived, so they should not be sources of data.
  • Dependency injection. Google recommends the dependency injection pattern and the Hilt library.

Why use Jetpack Compose?

Google describes Compose as its recommended modern toolkit for native UI, with less code, a description of the UI that updates as state changes, live previews and built-in support for Material Design, dark theme, animations and adaptive layouts across phones, tablets, foldables, ChromeOS and Wear OS. It is compatible with existing code, so an older app can adopt it screen by screen. Those are Google's claims for its own toolkit; judge by building a real screen in your team.

How should you use Material Design 3?

Material 3 supplies components (small, reusable, interactive building blocks) and styles (colour, type, motion and theming). Use its components and theming instead of drawing custom controls, so the app feels familiar and picks up accessibility support. Android's guidance also tells designers to include accessibility from the start, noting that it benefits everyone. For more on how the two platforms' design systems differ, see Android or iOS first in 2026.

How do you handle many screens?

Use the window size classes (compact, medium and expanded) to choose layouts for phones, foldables and tablets, and test with resizable windows. Our article on mobile app development challenges covers this in more detail.

How do you keep quality high?

Google's quality pages group guidance into core value, user experience, technical quality, and privacy and security. In practice:

  1. Add crash reporting from the first build and watch Android vitals, where Google's thresholds are 1.09% crash rate and 0.47% ANR rate overall; Play may reduce visibility above them.
  2. Test on real devices across sizes and Android versions, and on slow networks.
  3. Follow OWASP's MASVS for security; see Mobile app technologies in 2026.
  4. Request only the permissions you need and explain why.
  5. Update every year for the target API level requirement and library changes.

How should AI features fit in?

On supported devices, Gemini Nano can run through Android's AICore system service and ML Kit GenAI APIs, with hybrid fallback to cloud models when it is unavailable. Treat AI output as something to label and check. See our mobile technologies article for the on-device and cloud trade-offs.

Where do we come in?

Our Android development page describes the native work we do, and app development covers the wider service.

FAQ

Should new Android apps use Jetpack Compose?

Google calls it Android's recommended modern toolkit for native UI. Existing apps can adopt it gradually.

Do I need a domain layer?

Not always. Google says it is optional and should be used only when needed, for complexity or reuse.

What is a single source of truth?

One owner of each piece of data, which is the only place that can change it and which exposes it as an immutable type.

What stability thresholds does Google Play use?

A user-perceived crash rate of 1.09% and an ANR rate of 0.47% overall, and 8% for each on any single phone model, measured over 28 days.

Which API level must I target?

From 31 August 2026, new apps and updates on Google Play must target Android 16 (API level 36) or higher, with exceptions for some device types.

Sources (6 links)
Share this article