At GitHub, we hear questions all the time that probably sound familiar to you:

• Does AI really help, or are you just trying to get me to use your product?
• Can I trust AI tools with my codebase?
• Are these tools built for marketing, or for real productivity?
• Does AI improve my flow, or break it?

These questions are real and valid. I did a livestream for our regularly scheduled Rubber Duck Thursdays (which you should check out on GitHub’s YouTube, Twitch, and/or LinkedIn weekly!) with Dalia Abo Sheasha, Senior Product Manager for Visual Studio, to talk about these things and more!

Check it out, or read on for the highlights:

Centering developers, protecting flow

If you ask most software engineers what they most want out of a tool, the answer usually isn’t “more automation.” Most developers are looking for a smoother, less interrupted path toward flow, that state where code and ideas come easily. It’s a fragile state.

We’ve seen again and again that anything causing context-switching (even a well-meaning suggestion) can snap that flow. With that in mind, at GitHub, we design and test our AI features where developers already work best: in their editor, the terminal, or the code review process. And we give developers ways to tune when, where, and how these tools make suggestions.

Your tools should support your workflow, not disrupt it. We want AI to help with the stuff that gets you out of flow and keeps you from building what matters. If a feature doesn’t truly make your coding day better, we want to know, because the only good AI is AI that actually helps you.

Chat has its limits

It’s tempting to believe that everything should be chat-driven. There’s power in asking “Can you scaffold a template for me?” and getting an instant answer. But forcing all interaction into a chatbox is, ironically, a fast path to losing focus.

I’m required to switch my attention off my code to a different place where there’s a chat where I’m talking in natural language. It’s a huge burden on your brain to switch to that.

Dalia Abo Sheasha, Senior Product Manager, Visual Studio

For many developers, chat is better suited to on-demand tasks like code explanations or navigating frameworks. If chat panels get in the way, minimize or background them. Let the chat come to you when you actually have a question, but don’t feel pressured to center your workflow around it.

Empowerment, not automation for its own sake

User data and developer interviews show us that effective AI empowers developers, but doesn’t replace their judgment.

Time and again, developers have told us what they really want is a way to skip repetitive scaffolding, boilerplate, and tedious documentation, while still holding the reins on architectural decisions, tricky bugs, and business logic.

As I explained during the stream: Focus on different behaviors for different audiences. Senior developers already go fast, but you’re trying to change their established behavior to help accelerate them. But for students, you’re training a brand new behavior that hasn’t been fully defined yet.

Use AI-generated explanations to deepen your own understanding. They should never be a replacement for your own analysis.

Cassidy Williams, GitHub Developer Advocate

And we want them to learn because the students—the early-career developers of today—are the senior developers of tomorrow, and everything’s changing.

What stage are you in in the learning process? If you are at the very beginning and you are learning syntax and the fundamentals of programming, use it to explain the fundamentals so you can have that strong foundation.

Dalia Abo Sheasha

AI suggestions that blend in

AI truly shines when it works alongside you rather than in front of you.

Developers tell us the most valuable AI experiences come from suggestions that surface contextually, such as suggesting a better function or variable name when you initiate a rename, or autocompleting boilerplate. In these moments, the AI tool feels like a helper handing you a useful snippet, not an intrusive force demanding attention.

Most AI assistants offer ways to adjust how often they pop up and how aggressive they are. Take a few minutes to find your comfort zone.

The human at the center

AI should be your tool, not your replacement. AI tools should empower you, not take over your workflow. We want AI to remove tedium by suggesting improvements, writing docs or tests, catching issues… not to disrupt your creative flow or autonomy.

The most critical ingredient in software is still the human developer: your insight, judgment, and experience.

Learning from failure

Not every AI feature lands well. Features that interrupt editing, flood the screen with pop-ups, or “help” while you’re adjusting code in real time usually end up disabled by users, and often by us, too.

There is definitely a lot of AI fatigue right now. But there are also such good use cases, and we want those good use cases to float to the top … and figure out how we can solve those developer problems.

Cassidy Williams

If a suggestion pattern or popup is getting in your way, look for customization settings, and don’t hesitate to let us know on social media or in our community discussion. Product teams rely heavily on direct developer feedback and telemetry to adjust what ships next.

Building with you, not just for you

Whether it’s through beta testing, issue feedback, or direct interviews, your frustrations and “aha!” moments drive what we prioritize and refine.

If you have feedback, share it with us! Sharing your experiences in public betas, contributing to feedback threads, or even just commenting on what annoyed you last week helps us build tools you’ll want to use, not just tolerate. Your input shapes the roadmap, even in subtle ways you might not see.

Making the most of AI-driven coding

To get practical benefit from AI tools:

• Understand and review what you accept. Even if an AI-produced suggestion looks convenient, make sure you know exactly what it does, especially for code that might affect security, architecture, or production reliability.
• Use AI’s “explain” features as a learning aid, not a shortcut. These can help you solidify your knowledge, but don’t replace reading the docs or thinking things through.
• Tweak the frequency and style of suggestions until you’re comfortable. Most tools let you control intrusiveness and specificity. Don’t stick with defaults that annoy you.
• Give honest feedback early and often. Your frustrations and requests genuinely help guide teams to build better, more developer-friendly tools.

Take this with you

AI coding tools have enormous potential, but only if they adapt to developers. Your skepticism, high standards, and openness help us (and the entire software industry) make meaningful progress.

We’re committed to creating tools that let you do your best work, in your own flow, right where you are.

Together, let’s shape a future where AI enables, but never overshadows, the craft of great software development.

The post What AI is actually good for, according to developers appeared first on The GitHub Blog.

Over the past two years, enterprises have moved rapidly to integrate large language models into core products and internal workflows. What began as experimentation has evolved into production systems that support customer interactions, decision-making, and operational automation.

As these systems scale, a structural shift is becoming apparent. The limiting factor is no longer model capability or prompt design but infrastructure. In particular, GPUs have emerged as a defining constraint that shapes how enterprise AI systems must be designed, operated, and governed.

This represents a departure from the assumptions that guided cloud native architectures over the past decade: Compute was treated as elastic, capacity could be provisioned on demand, and architectural complexity was largely decoupled from hardware availability. GPU-bound AI systems don’t behave this way. Scarcity, cost volatility, and scheduling constraints propagate upward, influencing system behavior at every layer.

As a result, architectural decisions that once seemed secondary—how much context to include, how deeply to reason, and how consistently results must be reproduced—are now tightly coupled to physical infrastructure limits. These constraints affect not only performance and cost but also reliability, auditability, and trust.

Understanding GPUs as an architectural control point rather than a background accelerator is becoming essential for building enterprise AI systems that can operate predictably at scale.

The Hidden Constraints of GPU-Bound AI Systems

GPUs break the assumption of elastic compute

Traditional enterprise systems scale by adding CPUs and relying on elastic, on-demand compute capacity. GPUs introduce a fundamentally different set of constraints: limited supply, high acquisition costs, and long provisioning timelines. Even large enterprises increasingly encounter situations where GPU-accelerated capacity must be reserved in advance or planned explicitly rather than assumed to be instantly available under load.

This scarcity places a hard ceiling on how much inference, embedding, and retrieval work an organization can perform—regardless of demand. Unlike CPU-centric workloads, GPU-bound systems cannot rely on elasticity to absorb variability or defer capacity decisions until later. Consequently, GPU-bound inference pipelines impose capacity limits that must be addressed through deliberate architectural and optimization choices. Decisions about how much work is performed per request, how pipelines are structured, and which stages justify GPU execution are no longer implementation details that can be hidden behind autoscaling. They’re first-order concerns.

Why GPU efficiency gains don’t translate into lower production costs

While GPUs continue to improve in raw performance, enterprise AI workloads are growing faster than efficiency gains. Production systems increasingly rely on layered inference pipelines that include preprocessing, representation generation, multistage reasoning, ranking, and postprocessing.

Each additional stage introduces incremental GPU consumption, and these costs compound as systems scale. What appears efficient when measured in isolation often becomes expensive once deployed across thousands or millions of requests.

In practice, teams frequently discover that real-world AI pipelines consume materially more GPU capacity than early estimates anticipated. As workloads stabilize and usage patterns become clearer, the effective cost per request rises—not because individual models become less efficient but because GPU utilization accumulates across pipeline stages. GPU capacity thus becomes a primary architectural constraint rather than an operational tuning problem.

When AI systems become GPU-bound, infrastructure constraints extend beyond performance and cost into reliability and governance. As AI workloads expand, many enterprises encounter growing infrastructure spending pressures and increased difficulty forecasting long-term budgets. These concerns are now surfacing publicly at the executive level: Microsoft AI CEO Mustafa Suleyman has warned that remaining competitive in AI could require investments in the hundreds of billions of dollars over the next decade. The energy demands of AI data centers are also increasing rapidly, with electricity use expected to rise sharply as deployments scale. In regulated environments, these pressures directly impact predictable latency guarantees, service-level enforcement, and deterministic auditability.

In this sense, GPU constraints directly influence governance outcomes.

When GPU Limits Surface in Production

Consider a platform team building an internal AI assistant to support operations and compliance workflows. The initial design was straightforward: retrieve relevant policy documents, run a large language model to reason over them, and produce a traceable explanation for each recommendation. Early prototypes worked well. Latency was acceptable, costs were manageable, and the system handled a modest number of daily requests without issue.

As usage grew, the team incrementally expanded the pipeline. They added reranking to improve retrieval quality, tool calls to fetch live data, and a second reasoning pass to validate answers before returning them to users. Each change improved quality in isolation. But each also added another GPU-backed inference step.

Within a few months, the assistant’s architecture had evolved into a multistage pipeline: embedding generation, retrieval, reranking, first-pass reasoning, tool-augmented enrichment, and final synthesis. Under peak load, latency spiked unpredictably. Requests that once completed in under a second now took several seconds—or timed out entirely. GPU utilization hovered near saturation even though overall request volume was well below initial capacity projections.

The team initially treated this as a scaling problem. They added more GPUs, adjusted batch sizes, and experimented with scheduling. Costs climbed rapidly, but behavior remained erratic. The real issue was not throughput alone—it was amplification. Each user query triggered multiple dependent GPU calls, and small increases in reasoning depth translated into disproportionate increases in GPU consumption.

Eventually, the team was forced to make architectural trade-offs that had not been part of the original design. Certain reasoning paths were capped. Context freshness was selectively reduced for lower-risk workflows. Deterministic checks were routed to smaller, faster models, reserving the larger model only for exceptional cases. What began as an optimization exercise became a redesign driven entirely by GPU constraints.

The system still worked—but its final shape was dictated less by model capability than by the physical and economic limits of inference infrastructure.

What began as an optimization exercise became a redesign driven entirely by GPU constraints. This pattern—GPU amplification—is increasingly common in GPU-bound AI systems. As teams incrementally add retrieval stages, tool calls, and validation passes to improve quality, each request triggers a growing number of dependent GPU operations. Small increases in reasoning depth compound across the pipeline, pushing utilization toward saturation long before request volumes reach expected limits. The result is not a simple scaling problem but an architectural amplification effect in which cost and latency grow faster than throughput.

Reliability Failure Modes in Production AI Systems

Many enterprise AI systems are designed with the expectation that access to external knowledge and multistage inference will improve accuracy and robustness. In practice, these designs introduce reliability risks that tend to surface only after systems reach sustained production usage.

Several failure modes appear repeatedly across large-scale deployments.

Temporal drift in knowledge and context

Enterprise knowledge is not static. Policies change, workflows evolve, and documentation ages. Most AI systems refresh external representations on a scheduled basis rather than continuously, creating an inevitable gap between current reality and what the system reasons over.

Because model outputs remain fluent and confident, this drift is difficult to detect. Errors often emerge downstream in decision-making, compliance checks, or customer-facing interactions, long after the original response was generated.

Pipeline amplification under GPU constraints

Production AI queries rarely correspond to a single inference call. They typically pass through layered pipelines involving embedding generation, ranking, multistep reasoning, and postprocessing, each stage consuming additional GPU resources. Systems research on transformer inference highlights how compute and memory trade-offs shape practical deployment decisions for large models. In production systems, these constraints are often compounded by layered inference pipelines—where additional stages amplify cost and latency as systems scale.

Each stage consumes GPU resources. As systems scale, this amplification effect turns pipeline depth into a dominant cost and latency factor. What appears efficient during development can become prohibitively expensive when multiplied across real-world traffic.

Limited observability and auditability

Many AI pipelines provide only coarse visibility into how responses are produced. It’s often difficult to determine which data influenced a result, which version of an external representation was used, or how intermediate decisions shaped the final output.

In regulated environments, this lack of observability undermines trust. Without clear lineage from input to output, reproducibility and auditability become operational challenges rather than design guarantees.

Inconsistent behavior over time

Identical queries issued at different points in time can yield materially different results. Changes in underlying data, representation updates, or model versions introduce variability that’s difficult to reason about or control.

For exploratory use cases, this variability may be acceptable. For decision-support and operational workflows, temporal inconsistency erodes confidence and limits adoption.

Why GPUs Are Becoming the Control Point

Three trends converge to elevate GPUs from infrastructure detail to architectural control point.

GPUs determine context freshness. Storage is inexpensive, but embedding isn’t. Maintaining fresh vector representations of large knowledge bases requires continuous GPU investment. As a result, enterprises are forced to prioritize which knowledge remains current.
Context freshness becomes a budgeting decision.

GPUs constrain reasoning depth. Advanced reasoning patterns—multistep analysis, tool-augmented workflows, or agentic systems—multiply inference calls. GPU limits therefore cap not only throughput but also the complexity of reasoning an enterprise can afford.

GPUs influence model strategy. As GPU costs rise, many organizations are reevaluating their reliance on large models. Small language models (SLMs) offer predictable latency, lower operational costs, and greater control, particularly for deterministic workflows.
This has led to hybrid architectures in which SLMs handle structured, governed tasks, with larger models reserved for exceptional or exploratory scenarios.

What Architects Should Do

Recognizing GPUs as an architectural control point requires a shift in how enterprise AI systems are designed and evaluated. The goal isn’t to eliminate GPU constraints; it’s to design systems that make those constraints explicit and manageable.

Several design principles emerge repeatedly in production systems that scale successfully:

Treat context freshness as a budgeted resource. Not all knowledge needs to remain equally fresh. Continuous reembedding of large knowledge bases is expensive and often unnecessary. Architects should explicitly decide which data must be kept current in near real time, which can tolerate staleness, and which should be retrieved or computed on demand. Context freshness becomes a cost and reliability decision, not an implementation detail.

Cap reasoning depth deliberately. Multistep reasoning, tool calls, and agentic workflows quickly multiply GPU consumption. Rather than allowing pipelines to grow organically, architects should impose explicit limits on reasoning depth under production service-level objectives. Complex reasoning paths can be reserved for exceptional or offline workflows, while fast paths handle the majority of requests predictably.

Separate deterministic paths from exploratory ones. Many enterprise workflows require consistency more than creativity. Smaller, task-specific models can handle deterministic checks, classification, and validation with predictable latency and cost. Larger models should be used selectively, where ambiguity or exploration justifies their overhead. Hybrid model strategies are often more governable than uniform reliance on large models.

Measure pipeline amplification, not just token counts. Traditional metrics such as tokens per request obscure the true cost of production AI systems. Architects should track how many GPU-backed operations a single user request triggers end to end. This amplification factor often explains why systems behave well in testing but degrade under sustained load.

Design for observability and reproducibility from the start. As pipelines become GPU-bound, tracing which data, model versions, and intermediate steps contributed to a decision becomes harder—but more critical. Systems intended for regulated or operational use should capture lineage information as a first-class concern, not as a post hoc addition.

These practices don’t eliminate GPU constraints. They acknowledge them—and design around them—so that AI systems remain predictable, auditable, and economically viable as they scale.

Why This Shift Matters

Enterprise AI is entering a phase where infrastructure constraints matter as much as model capability. GPU availability, cost, and scheduling are no longer operational details—they’re shaping what kinds of AI systems can be deployed reliably at scale.

This shift is already influencing architectural decisions across large organizations. Teams are rethinking how much context they can afford to keep fresh, how deep their reasoning pipelines can go, and whether large models are appropriate for every task. In many cases, smaller, task-specific models and more selective use of retrieval are emerging as practical responses to GPU pressure.

The implications extend beyond cost optimization. GPU-bound systems struggle to guarantee consistent latency, reproducible behavior, and auditable decision paths—all of which are critical in regulated environments. In consequence, AI governance is increasingly constrained by infrastructure realities rather than policy intent alone.

Organizations that fail to account for these limits risk building systems that are expensive, inconsistent, and difficult to trust. Those that succeed will be the ones that design explicitly around GPU constraints, treating them as first-class architectural inputs rather than invisible accelerators.

The next phase of enterprise AI won’t be defined solely by larger models or more data. It will be defined by how effectively teams design systems within the physical and economic limits imposed by GPUs—which have become both the engine and the bottleneck of modern AI.

Author’s note: This article is based on the author’s personal views based on independent technical research and does not reflect the architecture of any specific organization.

---

Join us at the upcoming Infrastructure & Ops Superstream on January 20 for expert insights on how to manage GPU workloads—and tips on how to address other orchestration challenges presented by modern AI and machine learning infrastructure. In this half-day event, you’ll learn how to secure GPU capacity, reduce costs, and eliminate vendor lock-in while maintaining ML engineer productivity. Save your seat now to get actionable strategies for building AI-ready infrastructure that meets unprecedented demands for scale, performance, and resilience at the enterprise level. O’Reilly members can register here. Not a member? Sign up for a 10-day free trial before the event to attend—and explore all the other resources on O’Reilly.

This article walks through the full Android OS architecture, explaining each system layer—from the Linux kernel up to apps—and how developers interact with them in practice.

What Exactly Is the Job of an Operating System?

Well, as the name states, it operates the entire system, and by ‘operate the entire system’ we mean the device that it is running on, in this case, the Android device. So you can really think of an OS as a conductor that makes sure that all the components, both hardware and software, that the device consists of, work together smoothly. It is really just a bridge between hardware and software.

To give you a clearer technical understanding of what all this means at a lower level, let’s walk through the specific roles an operating system plays.

\

• Process and Thread Management: It is the job of the operating system to decide which thread runs, when which thread runs, and to make sure that multiple applications can work efficiently together, even in parallel.

  \

• Memory Management: An Android device has a specific amount of RAM, and deep down in the RAM, we have a big amount of storage space where we can just write 1s and 0s. It is important in such a device to have clear boundaries of which memory belongs to what process, for example. So that one app does not accidentally override the RAM in the memory usage of another app, which would definitely lead to issues.

  Memory management on Android specifically has a kind of special role, because on mobile devices, resources are just typically a bit more scarce than on servers and better devices like desktops, etc., where we have a consistent power supply, while on an Android device, we have a battery, which typically don’t have that much memory available as on these larger devices. So the Android OS specifically also always needs to make sure that there’s always enough memory for what the user wants to do, for example, killing apps that are not frequently used or that the user will probably not use again. This internal logic to decide what should be done if a lot of the memory is used is a part of the operating system.

  \

• File Handling and I/O Operations: Another job of the operating system is handling the file system and I/O operations (writing to files and reading from files). This is a good example of how the operating system acts as a bridge between hardware and software. The hardware is just a disk where we persistently write data to, and the software is then maybe our app, where we can use high-level APIs to easily write data to disk.

  \

• Security and Permissions: No matter what kind of operating system you are running, there will be some sort of security and permission set up, which will just make sure that it enforces strict boundaries to protect core functionalities of the OS, so that our app can’t suddenly break the functioning of the operating system itself and therefore potentially destroy how the entire workings of the device are like, but also things like protecting user’s data.

  This is important on Android devices because they have access to the camera, microphone, sensor data, and GPS, which is, of course, data that has to be protected. Of course, certain apps need to access that data, but many apps clearly don’t. The operating system needs to make sure that there are clear permissions for accessing such sensitive data.

  You’ll know this from Android, where we always have those permission dialogues that the user has to grant a certain permission, like accessing the camera. These kinds of permissions are managed by the operating system because our apps don’t really have access to them.

  \

• Hardware Abstraction Layer (HAL): The OS is a bridge between hardware and software, as earlier stated, but interacting with the hardware itself is, in the en,d a super low-level thing. Our Android device may be made out of a lot of different components, the camera might be from manufacturer A, the microphone from manufacturer B, and then all those different hardware components are manufactured together to a working Android device. But each hardware manufacturer decides how their certain hardware is programmed, and how other components need to interact with it, this is, in the en,d what a hardware driver does.

  This low-level interaction of controlling a device’s hardware is something we developers typically don’t need to deal with in our day-to-day work, so the operating system would abstract that away from us, which is the hardware abstraction layer, and then provide very high-level accessible APIs to us developers that we can easily use. An important example of this is a network interface where you and your app can just make an HTTP request by using a library such as Retrofit or Ktor. But that’s, of course, not how things work on a lower level.

  On a lower level, all those HTTP calls have to be transformed into some sequence of zeros and ones, with clear boundaries that the zeros and ones still contain where they will be sent to, the actual data, and all kids of metadata around that, which are then being sent to the device’s network chip and then distributed.

  \

• UI Management: All Android devices, of course has a user interface (UI) that a user interacts with; that is not something all operating systems need to do. There are lots of Linux instances running on servers that do not have an actual UI, where you just interact with a pure terminal.

  The touchscreen is of course also a hardware component that needs to transform the user’s touches into clear coordinations on the screen, into forwarding this information to the app that is currently running, so we can process that input, but also making sure that UI can be rendered on the screen, that there is a rendering pipeline, that we can draw multiple layers on our app.

  On Android specifically, that includes notifications, so that no matter where we are on our device, we will always get a pop-up for a notification. UI management on Android may also include navigation between multiple apps.

\ So you see that there are lots of different jobs and purposes of an operating system that we typically don’t even think about in our day-to-day work. With this overview, we will be diving into those aspects of the Android OS Architecture that actually have practical relevance for our typical work-life.

\

The work we do, and the way we do it, is always changing. Each of us has a memory of how we once did a task regularly, the tools we used and how both the task and the tools have since changed so much they are nearly unrecognizable. Because we are living and working in the “now,” change feels both personal and fast, so it is always worth remembering that this has happened before, maybe not in just this way or with this speed.

And it is true. AI is rewriting work. How we do our jobs. How roles change. How careers are built. The skills we need. Some of that is exciting. Some of it can feel overwhelming. What we remember and have learned from previous times is that in moments like this, people are open to work and don’t just need new tools. They need a new mindset, a clearer understanding of what’s changing and a path forward.

That’s why today we’re announcing Open to Work: How to Get Ahead in the Age of AI, LinkedIn’s first book, by CEO Ryan Roslansky and Chief Economic Opportunity Officer Aneesh Raman. The book explores how AI is reshaping work and what that shift means for the people navigating it every day.

Microsoft and LinkedIn sit at the intersection of how work is done and how careers are built. We share a belief that the future of work will be driven by human creativity and ingenuity, not technology alone. When humans stay at the center, AI amplifies what people do best and creates new economic opportunity. Open to Work is grounded in that belief and focused on what’s happening now, not abstract predictions about the future.

Ryan’s leadership at LinkedIn and as head of engineering for Microsoft 365 Copilot gives him a rare perspective on this moment. He sees how AI is built, how it shows up in everyday work and what it takes to adapt. Aneesh’s role gives him unique insight into how together we can use this moment of change to create economic opportunity for every member of the global workforce.

The book is backed by real data — insights from experts, LinkedIn’s global network, Microsoft customers and the Work Trend Index. The goal isn’t hype. It’s clarity about how work is changing and how people can respond in practical, meaningful ways.

For professionals, Open to Work is about agency — what you delegate to AI, what skills to deepen and how you stay relevant as roles evolve. For leaders, it’s about rethinking how work gets organized and cultivating a Frontier mindset: the conviction that the most important innovations happen at the edges, where uncertainty is highest and the opportunity to shape what comes next is greatest. And for Microsoft and LinkedIn employees, it’s a reminder of the responsibility we share to shape the future of work in a thoughtful, human-centered way.

Open to Work publishes March 31 and is available for pre-order today.

Frank X. Shaw is responsible for defining and managing communications strategies worldwide, company-wide storytelling, product PR, media and analyst relations, executive communications, employee communications, global agency management and military affairs.

Top image: Aneesh Raman, left, LinkedIn chief economic opportunity officer, and Ryan Roslansky, LinkedIn CEO. Photo provided by LinkedIn.

The post Announcing Open to Work: How to Get Ahead in the Age of AI appeared first on The Official Microsoft Blog.

Compose Multiplatform 1.10.0 has been released! We’re continually developing our multiplatform APIs and expanding support for Jetpack libraries commonly used on Android.

Here are the highlights of this release:

• One common @Preview annotation to rule them all
• Navigation 3 is available on non-Android targets
• Stable and bundled Compose Hot Reload

Get Started with Compose Multiplatform

For a complete overview of the changes, check out What’s new in Compose Multiplatform 1.10.0 or the release notes on GitHub.

Common @Preview annotation

Previously, we had three separate @Preview annotations across different packages, which made it challenging to figure out the correct combination of annotation, platform, and IDE.

With this release, we’ve unified previews under a single @Preview annotation that works in your commonMain source set:

All other annotations have been deprecated. But fear not – IDE quick-fix suggestions will help you easily update your dependencies to androidx.compose.ui.tooling.preview.Preview.

Navigation 3

We’ve introduced support for Navigation 3, a new library for managing navigation. With Navigation 3, you can manipulate your navigation stack directly, making tasks like adding or removing destinations more straightforward.

To help you get started, we’ve compiled a set of Navigation 3 recipes with examples of common usage patterns for Compose Multiplatform.

Compose Hot Reload

Compose Hot Reload is designed to speed up UI iteration by letting you instantly see changes without restarting the application:

The Compose Hot Reload plugin is now stable – check out this deep-dive blog post to learn more about how it works. It’s now bundled with the Compose Multiplatform Gradle plugin and enabled by default, so no additional configuration is required.

Try Compose Hot Reload

---

These are just the highlights – this release includes numerous updates across platforms, including the introduction of more transparent dependency management for Compose Multiplatform libraries with direct library references.

Make sure to check out the full version in our documentation. If you encounter any issues, please report them on our issue tracker.