One of the core principles in Microsoft Foundry is giving customers flexibility to choose the right model for the right job. As we've continued to expand the Microsoft AI (MAI) model family, we've heard a consistent theme from developers and enterprises: they want more choice based on their specific workload requirements. Some need the highest possible quality, fidelity, and consistency for professional production workflows. Others prioritize responsiveness and cost-efficiency for frequent, real-time responses.
Today, we're introducing two new additions to the MAI portfolio:
MAI-Image-2.5 Pro, designed for customers who need maximum visual fidelity and creative control
MAI-Voice-2 Flash, built for low-latency voice applications where every millisecond matters.
Together, these models extend the MAI family with specialized options that help developers optimize for the jobs they need to do. Let’s dive in.
MAI-Image-2.5 Pro: Built for professional creative workflows
MAI-Image-2.5 Pro is our newest high-fidelity image generation model, designed for scenarios where visual accuracy, consistency, and creative control are critical. The model delivers stronger object consistency, improved alignment with creative intent, and enhanced visual reasoning and world knowledge, making it the ideal choice when quality and fidelity matter more than throughput.
As generative AI moves from experimentation to production, creative teams increasingly need models that can reliably generate assets that meet professional standards without extensive manual editing. MAI-Image-2.5 Pro was built to address those needs. Here are some of the scenarios it best fits:
Campaign Hero Assets & Multi-Frame Storytelling. Creative agencies and marketing teams can create polished campaign visuals while maintaining consistent products, characters, and brand elements across every asset. Whether producing launch campaigns, social media variants, retail signage, or digital advertising, Image-2.5 Pro helps ensure visual consistency throughout the customer journey.
Product Photography & E-Commerce Catalogs. Retailers and consumer brands can generate high-quality product imagery with accurate rendering of packaging, labels, materials, and reflections. The model's improved object consistency helps maintain identical product representation across multiple angles, color variations, and lifestyle settings.
Storyboarding & Pre-Visualization. Film studios, game developers, and creative production teams can rapidly develop visual concepts while maintaining consistency across characters, environments, props, and scenes. Enhanced visual reasoning enables more accurate interpretation of camera direction, lighting, and staging instructions.
Regulated Industry Content Creation. Organizations in healthcare, financial services, manufacturing, and other regulated industries can generate imagery that requires greater real-world accuracy and domain understanding, reducing the effort needed to correct inaccuracies before customer-facing use
When should customers use MAI-Image-2.5 Pro vs. MAI-Image-2.5?
Both models deliver high-quality image generation capabilities, but they are optimized for different priorities.
Choose MAI-Image-2.5 Pro when:
You need maximum image fidelity and creative quality.
Object consistency across multiple images is critical.
Your workflow depends on visual reasoning, world knowledge, and close adherence to creative direction.
You are producing professional marketing, advertising, product design, or enterprise creative assets.
MAI-Voice-2 Flash: Real-time voice experiences at scale
We're also introducing MAI-Voice-2 Flash, a new low-latency text-to-speech model that extends MAI-Voice-2 with faster response times and greater cost efficiency across more than 15 supported languages.
As voice becomes a critical interface for AI applications, responsiveness is increasingly important to the end-user experience. Whether a customer is speaking with an AI-powered support agent, interacting with a voice assistant, or navigating a self-service phone system, long pauses can make experiences feel slow and unnatural. MAI-Voice-2 Flash was built to address those scenarios. Here are some of the scenarios on when to choose MAI-Voice-2 Flash:
Call Center Agents: Customer support organizations can generate spoken responses in real time, minimizing delays between conversation turns and enabling more natural customer interactions. Low latency helps improve customer experiences while supporting AI-powered service, support, and sales workflows.
Conversational Voice Assistants: Developers can build voice-enabled copilots, assistants, and intelligent applications that respond nearly instantly. The result is a more fluid, natural conversation that feels interactive rather than turn-based.
Interactive Voice Response (IVR) Systems: Organizations can modernize traditional phone systems with dynamic AI-generated speech that responds contextually to customer requests while maintaining a responsive user experience.
When should customers use MAI-Voice-2 Flash vs. MAI-Voice-2?
The distinction between the two voice models comes down to whether customers are optimizing for voice identity or real-time responsiveness.
Choose MAI-Voice-2 Flash when:
Low latency is a primary requirement.
You are building conversational assistants, IVR systems, or call center experiences.
Users expect immediate spoken responses as part of a live interaction.
Cost efficiency and responsiveness are more important.
Get started today in Microsoft Foundry
MAI-Image-2.5 Pro is available through Microsoft Foundry, providing developers with access to Microsoft's latest advancements in image generation. Pricing starts at $5 per 1M tokens for text input, and $106 per 1M tokens for image output.
MAI-Voice-2 Flash is available through Azure Speech, allowing customers to leverage Azure Speech's enterprise-grade reliability, scalability, and ecosystem while benefiting from Microsoft's latest voice technology. Pricing starts at $15 per 1M characters.
If MCP is becoming the “USB-C for AI,” enterprises need something equally familiar on the other side of that port: a control plane. The Model Context Protocol (MCP) gives AI applications a standard way to discover tools, retrieve context, and call capabilities from external systems. But once you move beyond a single local server and start connecting multiple remote tools across teams, environments, and data domains, the protocol alone is not enough, you also need a way to manage identity, access, traffic, visibility, and lifecycle consistently.
That is where Azure API Management (APIM) becomes strategically important. APIM is not “MCP instead of APIs.” It is the layer that can sit in front of MCP servers or even turn existing REST APIs into MCP-compatible tool surfaces so that organizations can apply the same security, policy, and operational controls they already use for business APIs. In other words, MCP standardizes how agents talk to tools; APIM helps standardize how the enterprise governs those tool endpoints at runtime.
What MCP actually is and why it changes AI integration
At its core, MCP defines a host / client / server model. The host is the AI application or agent experience, the client manages the MCP connection, and the server exposes capabilities to that client. Those capabilities are commonly expressed as tools (actions an AI model can call), resources (context or data an application can read), and prompts (reusable interaction templates). The same model works whether the server is local or remote, which is one of the reasons MCP is becoming an attractive way to make tool integrations reusable across many AI surfaces.
That portability matters because most teams do not want to rebuild connector logic for every host, model, or IDE. Microsoft’s Azure guidance explicitly describes two broad ways developers work with MCP: consume existing MCP servers, or build their own when they need custom tools, resources, or prompts.
Why MCP sprawl becomes an enterprise problem
MCP is easy to love in a demo because a single server can make an agent instantly smarter. It is harder in production because success creates sprawl. One team wraps an inventory API. Another exposes compliance rules. Another adds DevOps data. Soon, you have multiple remote MCP endpoints, different authentication models, inconsistent rate limits, uneven logging, and no clear answer to “which tools are approved, versioned, and discoverable?” This is the anti-pattern of a monolithic, over-privileged MCP server, and instead one must align server boundaries to business capabilities so access, observability, and ownership remain tractable.
This is exactly the point at which centralization becomes valuable. Microsoft’s MCP ecosystem organizes the landscape into three layers: a foundation of built-in servers, a build/govern layer that includes Azure Functions, APIM, and API Center, and a consumption layer where agents and runtimes use those tools. That framing is useful because it shows MCP management is not only about building servers; it is equally about establishing how those servers are exposed, governed, and discovered across the enterprise.
APIM as the front door for MCP
Azure API Management supports two especially important patterns for MCP centralization. The first is exposing an APIM-managed REST API as a remote MCP server, which lets you turn selected REST operations into MCP tools without rebuilding the backend. The second is putting APIM in front of an existing MCP server, so APIM acts as a facade or proxy that applies policy and governance to a server you already run somewhere else such as Azure Functions, App Service, Container Apps, or another HTTP host.
This is why APIM is best understood as the front door rather than the destination. It can route requests, apply transformations, enforce policy, and mediate access while preserving the standardized MCP interaction pattern for clients. MCP server endpoints can be described as “backend APIs” from a governance perspective, which is precisely the enterprise advantage: once a remote MCP endpoint is treated as an API surface, you can bring familiar controls, security, reliability, monitoring, and access policy to an otherwise fast-spreading agent/tool ecosystem.
Authentication and authorization: where APIM earns its keep
Remote MCP servers need a strong authorization story because they are not just returning text, they are gateways to systems, data, and actions. MCP authorization guidance uses OAuth 2.1, Protected Resource Metadata (PRM / RFC 9728) for discovery, dynamic client registration (RFC 7591) where supported, and resource indicators (RFC 8707) so tokens remain bound to the intended resource. The practical flow is clear: a client tries the server, gets a 401 with metadata, discovers the authorization server, requests consent with PKCE and the resource parameter, exchanges for a token, and then includes that bearer token on subsequent calls.
APIM becomes powerful here because it can be the authorization gateway in front of the MCP server. Internal security guidance and APIM-focused enablement both converge on the same pattern: use APIM to validate JWTs, apply OAuth/Entra-based access policies, and avoid unsafe token-handling shortcuts such as token passthrough. In practice, this means the caller authenticates against Microsoft Entra ID, APIM validates the token and audience, and only then forwards the call to the MCP backend, optionally with credential mediation patterns such as managed identity, On-Behalf-Of (OBO), or backend credential management depending on the scenario.
For Azure builders, the authentication options are already familiar. Microsoft’s Foundry guidance for custom MCP tools maps server authentication patterns to key-based auth, Microsoft Entra authentication, and OAuth identity passthrough (OBO). That same guidance explicitly recommends requiring authentication, treating credentials as secrets, applying least privilege to downstream APIs, and logging tool calls for troubleshooting. If you already think in terms of Entra ID, managed identities, audience validation, and OBO, centralizing MCP behind APIM lets you use those same patterns at the agent-tool boundary rather than reinventing them server by server.
Logging, monitoring, and observability without losing the plot
Observability is where many MCP deployments discover that a protocol is not the same thing as an operations platform. Internal field guidance is explicit that MCP monitoring today is often product-specific rather than fleet-wide: enterprise MCP usage can show up in Graph activity logs, Foundry uses OpenTelemetry-based tracing through Application Insights, and custom servers hosted in Azure Functions can rely on standard Function/App Insights diagnostics. The practical implication is that you can get strong telemetry, but you still have to stitch it together intentionally rather than expecting a single universal “MCP operations” pane out of the box.
APIM improves that picture because gateway traffic becomes a consistent choke point for diagnostics. That makes APIM valuable not only for security but also for operational visibility: which tools are being called, how often, by whom, with which response codes, and where latency or backend errors are emerging.
There is, however, an important streaming caveat. MCP transports, especially remote ones can depend on streaming-friendly behavior, and response buffering can break MCP interactions. In other words: yes, centralize observability, but do it in a way that respects streaming transports and does not accidentally make the MCP server stop working while you are trying to observe it.
Governance: from “cool tool” to managed platform capability
If authentication answers “who can call this?”, governance answers “what is this server, which version is trusted, and how should anyone discover it?” That is where Azure API Center matters. API Center is centralized location for registering and discovering MCP servers, including those exposed through APIM and those hosted elsewhere. Microsoft’s Foundry guidance similarly describes API Center registration as the path to creating a private organizational tool catalog, where authentication and access settings can be configured consistently and users can discover approved servers rather than trading raw URLs in chat threads.
This matters more than it sounds. Governance is not only about storage of metadata, it is about versioning, lifecycle, access management, tags, and exposure policy. Recommendation is to version MCP endpoints, document usage patterns, and using API Center to make discovery enterprise-ready.
A practical Azure reference pattern
A useful way to think about the architecture is this: MCP hosts and agent runtimes stay at the edge of user experience, while APIM becomes the edge of enterprise control. The agents or developer tools speak MCP. APIM governs the runtime surface. MCP backends provide tools, and API Center catalogs them. Azure Monitor and Application Insights provide telemetry. Entra ID provides identity. The protocol stays standardized; the operations model becomes centralized.
Centralizing via APIM vs. letting clients call MCP servers directly
Dimension
Direct access to MCP servers
Centralized through APIM
Authentication model
Each server must implement and enforce auth consistently, which can drift across teams.
Central token validation, Entra/OAuth policy, and consistent gateway enforcement become possible across servers.
Access control
Per-server controls can be fragmented and harder to audit centrally.
Products, subscriptions, access policies, and gateway rules create one place to enforce who can use what.
Observability
Logs depend on each backend platform, and MCP-wide visibility is often fragmented.
APIM adds a common telemetry point for traffic, errors, and policy outcomes, while backend telemetry still remains available.
Reuse of existing APIs
Existing REST APIs stay REST APIs unless you build/host a separate MCP layer yourself.
APIM can expose existing REST operations as MCP tools, reducing incremental engineering work for standard tool surfaces.
Registry / discovery
Teams often share endpoints ad hoc, which does not scale well organizationally.
API Center provides a governed private registry for cataloging, access, and discoverability.
Trade-offs
Fewer moving parts and potentially lower latency for a single, tightly scoped use case.
Adds a gateway hop and policy/configuration overhead, and APIM’s REST-to-MCP mode focuses on tools rather than full MCP resources/prompts, so some scenarios still benefit from a dedicated MCP server behind the gateway.
Design guidance and best practices
1) Treat MCP servers as business capability boundaries, not as a giant “AI super-endpoint” Monolithic, over-privileged MCP servers are an anti-pattern; separate servers improve least privilege, ownership clarity, and observability. A focused capability boundary also gives the model clearer tool descriptions, which improves invocation quality and reduces collisions between unrelated tools.
2) Prefer a no-code APIM path when you already have good REST APIs; use a pro-code MCP server when you need custom orchestration, transformation, or non-API-native logic. Implement No-Code via APIM for existing REST interfaces and Pro-Code for scenarios requiring more control, custom logic, or deeper integration patterns. This is one of the cleanest ways to make the architecture pragmatic instead of ideological: not every MCP server should be handwritten if the backend capability already exists in API form.
3) Use Entra ID and avoid token passthrough. Token passthrough creates audit gaps, bypass risks, and lateral movement opportunities. A better pattern is for APIM to validate and mediate identity at the edge, with audience/resource validation and downstream access configured explicitly. When you need delegated access, use OBO or equivalent identity-aware patterns rather than forwarding arbitrary bearer tokens through the stack unchecked.
4) Design for observability from day one, but keep streaming in mind. Log tool invocations, failure paths, latency, and correlation identifiers. Use Azure Monitor / Application Insights on the backend and APIM diagnostics at the gateway. But for remote MCP transports, avoid diagnostics or policy configurations that introduce response buffering and unintentionally break stream-oriented behavior.
5) Make discovery a governance problem, not a tribal-knowledge problem. Register internal MCP servers in API Center when you want them discoverable across projects or teams. Use metadata, access management, and lifecycle conventions to decide what is visible, what is approved, and which versions are current. That gives platform teams a catalog to govern and developers a trusted place to discover servers without guessing which endpoint is “the right one.”
The bottom line
MCP standardizes how AI applications talk to external capabilities. APIM standardizes how the enterprise protects and operates those capabilities. Put differently: MCP solves interoperability, while APIM helps solve operability. When organizations start treating remote MCP endpoints like first-class API assets with identity, policy, telemetry, registry, and lifecycle attached, tmhey move from isolated agent demos to something that can actually survive production.
That is why centralizing MCP management in Azure is not really about “putting a gateway in front of servers.” It is about giving your emerging agent ecosystem a governed front door: one place to authenticate, authorize, observe, version, discover, and evolve the tools your models depend on. And for enterprises already invested in Azure, APIM plus API Center is one of the clearest ways to build that front door without throwing away the APIs and security patterns they already trust.
Patrol has come a long way from being “just another Flutter testing tool.” Today, it powers end-to-end testing across Android, iOS, and Web, integrates with native testing infrastructure, runs on cloud device farms, offers AI-powered testing capabilities, and continues to push the boundaries of what’s possible in the Flutter ecosystem.
No matter if you’ve been following Patrol for a while or you’re simply looking for the best way to handle Flutter E2E testing, this article is the perfect place to catch up.
What exactly is Patrol? Let’s break it down
Developed by LeanCode, Patrol is a powerful, open-source, multiplatform E2E UI testing framework for Flutter apps that overcomes the limitations of integration_test by handling native interactions. Let’s dig deeper into that.
Flutter’s greatest strength also creates one of its biggest testing challenges.
Unlike native apps, Flutter renders its entire UI using its own graphics engine instead of platform-native components. This enables a consistent, pixel-perfect experience across devices, but it also means that native UI automation tools often see a Flutter app as little more than a single canvas. They simply cannot interact with Flutter widgets.
The official solution is the integration_test package, which gives tests direct access to the Flutter widget tree. As long as everything happens inside Flutter, it works well. But real apps rarely stay there. System permission dialogs, biometric prompts, notifications, WebViews, and other native UI all exist outside the Flutter runtime, making them inaccessible to integration_test.
Patrol bridges this gap. It lets tests interact with both Flutter widgets and native UI elements in a single test. Because Patrol builds on native frameworks such as JUnit and XCTest, it also integrates seamlessly with existing CI pipelines, device farms, and the broader mobile testing ecosystem.
If you are new to automating E2E testing in Flutter, you can start by watching the “How to Automate E2E Testing in Flutter” webinar, where our LeanCode team discusses existing market solutions, their limitations, and proven practices to help you strengthen your testing process.
Patrol works by combining Flutter’s testing APIs with the platform’s native UI automation frameworks. Your test code runs inside the Flutter application, giving you full access to the widget tree through flutter_test, while a native test runner executes the tests using XCUITest on iOS and UIAutomator on Android.
Patrol Architecture Overview
The two processes communicate over localhost, allowing a single test to seamlessly switch between interacting with Flutter widgets and native UI elements such as system dialogs, permission prompts, notifications, or even other apps. Because Patrol builds on the native testing infrastructure, it also remains compatible with existing CI pipelines, device farms, and reporting tools.
We described it in more detail in our article about Patrol Web.
Over the past few years, Patrol has earned the trust of the Flutter community and the numbers speak for themselves: more than 350K monthly downloads, 1300+ GitHub stars (you can star as too ;), talks about Patrol on Flutter conferences and meetups all around the world, and adoption by companies ranging from startups to global brands such as Sennheiser, easyJet, Couchsurfing, Tide, Miles & More, AlloFresh and more.
For users, Patrol’s inclusion in the official Flutter documentation is a signal of maturity and credibility. It demonstrates that the framework is recognized by the Flutter team as a valuable solution for end-to-end testing and has earned a place among the ecosystem’s recommended testing tools.
Patrol aligns with Flutter’s best practices and is trusted by the broader community.
Getting started with Patrol: the key things to know
Patrol has been evolving since 2022, and today it offers far more capabilities than its early versions. What began as a solution for bridging Flutter and native mobile testing has evolved into a comprehensive end-to-end testing platform across Android, iOS, and Web. One of the biggest milestones on that journey was the release of Patrol 4.0.
In the sections below, we’ll explore some of Patrol’s most important capabilities and recent additions, including Patrol Web, the VS Code extension, Patrol MCP, native tooling integrations, cloud device farm support, and other features that make Patrol one of the most comprehensive testing solutions in the Flutter ecosystem.
NOTE:
If you’re evaluating Patrol for your project, you can check Patrol’s Feature Parity page. It provides a comprehensive overview of supported capabilities across Android, iOS, and Web, helping you quickly evaluate whether Patrol meets your testing requirements.
Ready to try Patrol yourself? The Patrol documentation includes a comprehensive Patrol setup guide that walks you through installation, configuration, and writing your first tests. Whether you’re starting a new project or adding end-to-end testing to an existing Flutter application, it’s the best place to begin your Patrol journey.
If you would like to implement Patrol in your company, as Patrol creators, we can help you with Patrol Setup & Patrol Training.
Patrol vs patrol_finders package
Writing E2E tests mostly means finding widgets and interacting with them. If you’re doing something regularly, it should be fast and easy to use. However, the original Flutter finders don’t match this description. They require complex, deeply nested widget lookups with an unintuitive API, forcing you to write verbose code.
That’s why we’ve built the patrol_finders package on top of flutter_test. Patrol Finders gives you custom methods to target elements by text, key, icon, or visibility properties, greatly reducing boilerplate and improving code scannability with a jQuery-style syntax.
Flutter finders:
Patrol finders:
Beyond simplifying syntax, the package excels at handling asynchronous and dynamic UI behaviors seamlessly. It introduces advanced finding mechanisms that automatically wait for elements to settle or appear on the screen, which effectively eliminates “flaky” tests caused by loading animations, network delays, or rendering lag. By combining selector logic with built-in timeouts, Patrol Finders ensures that automated tests mirror real user interactions much more closely and reliably.
But there’s more! Even if you don’t have E2E tests in your app yet (although you should 😉), you can still benefit from Patrol open source. You can replace Flutter finders with Patrol Finders in your golden tests or widget tests, making all your tests compact and highly readable. And lots of people are already doing this — patrol_finders monthly downloads outperform Patrol’s downloads by around 10%.
Patrol makes a smooth Flutter web testing possible
Patrol 4.0 brings full support for Flutter Web.
As Flutter Web matures, teams have been missing the same testing reliability they have on mobile. But before now, it wasn’t possible — integration_test on Web meant missing browser interactions and flaky CI runs.
While Flutter’s built-in tooling made web testing possible, achieving a smooth end-to-end testing experience remained a challenge. The demand for a better solution was impossible to ignore. In fact, Flutter Web support became the most requested feature in Patrol’s GitHub repository.
The release of Patrol Web was also covered in an episode of Observable Flutter titled “Patrol 4.0 & Marionette MCP.”
Adding Web support was far more complex than simply enabling another platform. Patrol’s developer-friendly API hides a significant amount of infrastructure behind commands such as patrol test and the familiar $ syntax. Under the hood, Patrol relies on several core components that make its testing experience different from traditional Flutter integration tests.
What actually happens under the hood?
A native bridge that lets you control real native features
Test bundling to speed things up
A custom test runner (not just integration_test)
True E2E flows — not mocked, not faked
The result is a unified testing framework that now spans Android, iOS, and Web, allowing teams to use the same tooling, workflows, and testing philosophy across platforms.
Curious how we actually developed Patrol Web? Read the full story of how we mapped Patrol’s mobile architecture to the Web, what had to change, and the hard decisions along the way.
A better DX with the Patrol VS Code extension
Patrol 4.0 brings a huge upgrade: a VS Code extension.
Patrol has always focused on making Flutter end-to-end tests more reliable and closer to real user interactions. However, until recently, one part of the developer experience still felt unfinished: working with Patrol directly inside the IDE.
Patrol 4.0 changes that with the introduction of the official VS Code extension.
The extension brings Patrol into the editor where most Flutter developers spend their day, making it easier to run, debug, and manage tests without constantly switching between the IDE and the terminal. Tests can now be launched directly from VS Code, and one-clickdebugging eliminates the need to manually enter test paths or remember CLI commands.
This may seem like a small improvement, but it significantly streamlines everyday workflows. Less context switching means faster feedback, easier debugging, and a smoother testing experience overall. For teams running Patrol tests regularly, these quality-of-life improvements can save a surprising amount of time throughout a project.
If you use Patrol for Flutter E2E testing, this can make your workflow much smoother. Read more about Patrol’s VS Code extension.
Patrol MCP: bringing AI-powered testing to Flutter
One of the most exciting additions to the Patrol ecosystem is Patrol MCP, which closes the communication gap between AI and Patrol.
Patrol MCP allows AI to run and re-run tests on demand, capture emulator screenshots, and read native device trees. By accurately pinpointing what fails, it saves tokens by reducing code reading and reruns. Consequently, the AI can write and fix tests autonomously, without human supervision.
This opens the door to AI-assisted Patrol test writing, automated test healing, and faster workflow debugging. Built on the Model Context Protocol (MCP), Patrol MCP enables developers to use tools such as Claude, Cursor, Copilot, and Antygravity to efficiently work with Patrol.
Imagine describing a test scenario in natural language and having an AI agent write code, execute it against a live application, observe the results, identify potential issues, and report its findings. That’s the experience Patrol MCP makes possible.
As AI becomes increasingly important in software development, Patrol MCP offers a glimpse into the future of Flutter testing, where developers, automated tests, and AI agents work together to improve application quality.
Want to learn more? Here’s everything you need to know about Patrol MCP.
Run Flutter tests like native tests: Patrol & Native tooling
Let’s talk about native tooling, something Flutter Testers don’t have nearly as much access to as teams building fully native mobile apps.
Flutter’s built-in integration testing doesn’t support native interactions, while native testing tools can’t directly interact with Flutter widgets. While many platforms now offer Flutter support, the native testing ecosystem remains the foundation for device farms, advanced test runners, reporting, analytics, monitoring, and test management.
That’s why we designed Patrol to run on top of native test frameworks. It bridges Flutter with native test tooling without forcing you to rewrite tests.
Rather than creating yet another isolated testing ecosystem, Patrol acts as a bridge between Flutter tests and native testing infrastructure. With Patrol, your favorite device farm doesn’t need a special “Flutter integration.” If it supports Android and iOS — that’s enough. You keep writing tests in Dart, and Patrol automatically exposes them to native test frameworks.
Whether you’re shipping a consumer Flutter app and want to run tests on Firebase Test Lab, or your company already uses BrowserStack, Patrol plugs right in. No migration. No new workflow. Your Flutter UI tests suddenly behave like native UI tests.
Need a Test Management System? Most of them ingest JUnit reports, and Patrol generates them out of the box. So you can integrate with tools your QA team already trusts, without bending your Flutter setup.
Patrol’s deep native integration is why it works on real farms, real devices, and real workflows — not just emulators. It closes the gap between “Flutter testing” and “mobile app testing” altogether.
Testing at scale: Patrol + Device farms
One of the biggest challenges in automated testing is shortening the feedback loop. When tests fail, developers need fast and reliable information about what went wrong.
Running automated tests on CI using local emulators or simulators can be slow and resource-intensive. They may require powerful build machines, increase execution time, and cannot cover every device-specific scenario. Some features, such as push notifications, are difficult or impossible to test on emulators alone.
This is where cloud device farms come in.
Cloud device farms provide access to large fleets of real devices and virtual (emulators or simulators), allowing teams to run tests across different screen sizes, operating system versions, hardware configurations, and network conditions. They help uncover issues that may never appear on a local emulator while significantly accelerating the testing process.
Patrol’s native testing architecture makes it compatible with many of the industry’s most popular testing platforms, including:
Firebase Test Lab
BrowserStack
LambdaTest
Marathon
emulator.wtf
AWS Device Farm
How Patrol works with device farms
Patrol tests run as native Android and iOS tests under the hood. This allows device farms to execute them just like any other native test suite, without requiring a separate integration or a custom execution flow. Your Flutter test code stays the same while the underlying infrastructure remains fully compatible with existing mobile testing pipelines.
One particularly valuable feature of Patrol is test bundling. Instead of rebuilding the app for every test case, Patrol can execute multiple tests from a single application build. For larger test suites, this dramatically reduces execution time and CI/CD costs.
Patrol also includes features designed for large-scale test execution, such as test sharding, parallel execution, artifact collection, and accurate test duration reporting — without requiring custom workarounds or manual test splitting.
Extra powers you can use: Patrol & Test sharding
UI tests are powerful — but might be slow at scale. That’s why test sharding matters. With Patrol, Flutter teams can finally use sharding on Android on real or virtual device farms. If you’ve never heard of test sharding, it’s time to change that. Here’s how it works.
Test sharding is a mechanism used by device farms to parallelize test execution. Instead of running your entire test suite on a single device, tests are split into smaller groups and executed simultaneously on multiple devices.
How does sharding usually work? On some device farms like BrowserStack, Firebase Test Lab, Marathon Cloud, or emulator.wtf you simply pass an extra parameter to the test command, and the farm handles the rest.
Sounds great… but what about Flutter UI tests? This is where Patrol enters the picture.
Since many device farms are dedicated to native platforms, Patrol acts as a bridge between the Flutter world and native tooling, making it possible to run Flutter UI tests on any device farm, even those that don’t officially support Flutter.
So, how does sharding actually work with Patrol? Your test suite is automatically divided into chunks. Each chunk is executed on a separate device in parallel, using native runners under the hood while still testing a real Flutter app. The result? The same tests, just finished much faster.
Why does this matter? UI tests take longer than other automated tests, about 3–5 minutes to complete, with dozens of tests, and as apps grow, so does the number of scenarios you need to cover. Sharding can speed up the process, and Patrol makes it accessible.
If you would like to implement Patrol in your company, as Patrol creators, we can help you with Patrol Setup & Patrol Training.
Wrapping up
What makes Patrol stand out is not just its feature set, but its focus on solving real-world testing challenges. Whether you’re looking to run reliable tests on real devices, scale execution across cloud infrastructure, improve developer productivity, or explore AI-assisted testing workflows, Patrol provides the tools to make it happen.
If you’re already using Patrol, check out the webinar, “Mastering Patrol & AI: Next-Level E2E Testing.” In this session, Patrol’s creators share practical strategies for reducing test flakiness, accelerating test development, and using Patrol MCP to enhance testing with AI. Based on lessons learned from large-scale Flutter projects, it’s the perfect resource for teams looking to unlock Patrol’s full potential.
This episode of The Modern .NET Show is supported, in part, by RJJ Software's Strategic Technology Consultation Services. If you're an SME (Small to Medium Enterprise) leader wondering why your technology investments aren't delivering, or you're facing critical decisions about AI, modernization, or team productivity, let's talk.
Show Notes
"In the agentic world that makes a lot of people really uncomfortable because what ends up happening is the agent has it, the agent has its own ID and then interacts with your data database."— Jerry Nixon
Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I'm your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.
Today, Jerry Nixon returned to the show to talk about SQL MCP Server, something of a new product _and_ the evolution of Data API Builder; which we talked to Jerry about back in episode three of this season (there'll be a link in the show notes). Jerry does a much better job of introducing it than I can, but suffice it to say that SQL MCP Server is an MCP Server which abstracts away intracting with a SQL database... of almost any flavour. SQL Server, CosmosDB, Postgres, you name it.
"I mean there is nothing better for any agent than saying "new session." That is how you like create better answers all the time. You might feel like you have this session, you've been training it so long and you've told it so much, it has so much context that now when you ask it, it'll finally have the answer that you're looking for."— Jerry Nixon
Along the way, Jerry shared a lot of solid gold nuggets of advice about MCP servers, best practices for interacting with agents and models, and even context management. And, of course, we talk about how simple is almost always the best solution (and how SQL MCP Server might be one of the ways for you to achieve that).
Before we jump in, a quick reminder: if The Modern .NET Show has become part of your learning journey, please consider supporting us through Patreon or Buy Me A Coffee. Every contribution helps us continue bringing you these in-depth conversations with industry experts. You'll find all the links in the show notes.
So let's sit back, open up a terminal, type in `dotnet new podcast` and we'll dive into the core of Modern .NET.
Remember to rate and review the show on Apple Podcasts, Podchaser, or wherever you find your podcasts, this will help the show's audience grow. Or you can just share the show with a friend.
And don't forget to reach out via our Contact page. We're very interested in your opinion of the show, so please get in touch.
Long before the announced EOL of HoloLens 2, I was on the lookout for alternative devices. The writing was on the wall after January 2023, when a lot of the staff involved was laid off and Microsoft started to abandon the Mixed Reality market they themselves created out of the blue in 2016 with HoloLens 1 back in 2015. Magic Leap 2, by Magic Leap, Inc, seemed to be a viable alternative but they decided to stop selling their device as well, mentioning the same support cutoff date as HoloLens 2. So this left us XR professionals looking for alternative devices. You have seen me play with Quest and Spectacles over the past few years. Recently the MetaLense 2 came to my attention. This seems to be a device that gets some fair use in Korea, but is nearly unknown in what I would call for lack of a better world ‘the West’.
First things first: what’s in a name
First things first: the device name suggests a relation with the company Meta, the parent company of Facebook, Instagram and WhatsApp, with Mark Zuckerberg as CEO. It has nothing to do with that. I assume the device’s name is a vestigial remnant of the Metaverse baloney hype of 2021-2023 (just as the name of Meta-the-company, which is now stuck with the name of a failed hype). It is designed and manufactured by P&C Solution from Seoul, and it’s a fully fledged Mixed Reality device that remarkably looks like a HoloLens 2, proving that the quote “Good artists copy, great artists steal” (attributed to Pablo Picasso) still holds true.
Notable physical differences
Although the physical appearance looks remarkably similar, closer inspection yields some striking differences.
Visor
It looks like the device has a flip-up visor like the HoloLens 2, but it doesn’t. If you try to flip up the visor - which I did a couple of times, force of habit being strong - you suddenly end up holding the visor in your hand. This is by design: the visor shield is detachable, and the device comes with two visor plates: one clear plastic, one tinted, apparently to enhance outdoor experiences.
Power button and USB port
The power button and USB port are on the left side of the battery pack (as opposed to the right side on HoloLens 2), and there is only one LED that shows multiple colors and blinking patterns. I’m sure they all mean something, but I haven’t gotten to the bottom of it.
Visor buttons
HoloLens 2 has two buttons on the visor. The one on the right adjusts audio volume, the one on the left adjusts display brightness. The MetaLense 2 also has a volume button on the right, but no brightness button - you set brightness using a setting in the launcher.
Head band
The headband is thicker, and notably stiffer and more rugged. That last part is a great boon. The HoloLens 2 headband is more flexible, but also considerably more fragile. After years of use it tends to tear. Case in point: the right side of my company HoloLens 2’s headband now sports a piece of duct tape to keep it from tearing any further, the result of me being right-handed and always picking it up with my right hand. The MetaLense 2 band is thick, hard, almost 5mm plastic.
A potential minor drawback is that the maximum size of the adjustable headband is slightly smaller. I always have to adjust a HoloLens 2 to a wider setting to accommodate my apparently oversized skull when it’s handed over from someone else - for the MetaLense 2 to fit over my head, I have to turn it all the way up to the maximum setting.
Display
In the HoloLens 2, the visor is a kind of hollow clear plastic box with a rounded front and a flat backside (the part facing your eyes). The actual see-through part appears to be a slightly irregular trapezoid, but the waveguide display - the piece that creates the actual image - is actually a truncated rectangle, which you can see when you hold the device so that light reflects off it at a shallow angle. The MetaLense 2 sports two clearly visible transparent boxes, one for each eye, about 14mm thick. This is because the MetaLense 2 doesn’t use waveguide but the much older birdbath technology. This is basically a projector at the top of the eyepiece, using a half-transparent slanted mirror to display the image to your eyes. This has a few consequences. First, you can’t see the user’s eyes at all when you look at someone wearing a MetaLense 2, because they’re hidden by the slanted mirror just mentioned. Second, the display lacks all the artifacts and chromatic aberrations the HoloLens 2 suffers from. The image is very bright, very clear, much less translucent, and not pixelated at all. The image quality looks really stunning, especially up close. Goes to show older isn’t necessarily worse. There are some caveats, though - more on that later.
Bits & pieces
The inside front of the headband reveals another difference: a little rectangle that I assume is a presence sensor. The device very aggressively turns its display off when you take it off, and it comes back on within seconds of putting it on again. Around the eyepieces (the ‘black boxes’) are sensors that emit a dimly visible red light, but I’m not sure what their function is.
Notable differences in device usage
The MetaLense 2 is an Android-based device, so it can only run apps compiled for Android. It uses a Qualcomm Snapdragon XR2-class chip, if I’m correct, which is an ARM chip. This means you don’t run into Android libraries that aren’t compiled for x86, an issue you sometimes had when porting to the Magic Leap 2 (which uses an AMD Ryzen chip). What’s also different is the launcher. It looks very big at 2-3 meter distance, and is basically a horizontal grid of icons. You can start an app with it, but it also has controls for settings. The annoying part is that it doesn’t always appear in front of you - sometimes even at the side or behind you - and it’s hard to move.
The MetaLense 2 also doesn’t have anything like a central store, unlike HoloLens 2, Quest, Spectacles or Apple Vision Pro. You can only sideload apps onto it, using their bespoke PC apps, or (as I usually do) using ADB commands. They do have OTA updates for firmware, though.
Also, and this is very strange: there is no general ‘go home’ gesture. HoloLens 1 had bloom, HoloLens 2 has the wrist tap, Magic Leap 2 the thumb-index-finger gesture, Quest the thumb-index-middle-finger snap, Snap Spectacles the palm buttons - the MetaLense 2 has none. If your app doesn’t have an exit button, you can’t exit a running app in any way, short of using the power button.
Shortfalls of the device
Unfortunately, and this is hard to believe, there are still things the 7-year-old HoloLens 2 excels at, or does better than the MetaLense 2.
Hand tracking
First, and most notable, is hand tracking. The HoloLens 2’s hand tracking is superb, and the MetaLense 2 doesn’t quite meet that standard. A pinch works fine when viewed from the side, but if you pinch away from you, you’re basically looking at the back of your hand, and often the MetaLense doesn’t register that half-obscured pinch. On the other hand, if you do a poke movement - for instance, pushing a button with your index finger - it registers so aggressively that you often end up double-punching the button, which is highly annoying when operating a toggle button, since it immediately untoggles itself again. This also happens in the system menu, so I assume it’s a systemic issue (that hopefully can be fixed in firmware). Another weird thing: if you move your hand out of view, because you are watching something that does not need interaction, wait some time, then move your hands back into view, hand tracking often needs time to ‘wake up’ again. I find myself often do some ‘hand waving’ until I see the device has found my hands again in that situation.
Display sharpness when moving
The display, although much brighter, sharper and less suffering from ‘rainbow artifacts’ than the HoloLens 2’s, still leaves something to be desired. There’s a kind of barrel distortion at the edges of the view. That itself isn’t so bad; what I do find annoying is that the imagery gets blurry when you rotate your head somewhat fast - it instantly becomes sharp again as soon as you stop rotating, but looking from side to side is what humans naturally do when looking around.
Viewpoint drift
The third shortfall, although minor in most cases, I’d call viewpoint drift. If you place a virtual object on a recognizable spot while viewing it from the front - for instance, on a coin - then look at the virtual object from the left side, it will seem to drift a bit to the right. Looking from the right, the virtual object will drift to the left. In both cases, the object ends up seemingly behind the coin. HoloLens 2 has this too (HoloLens 1 allegedly did not), but the MetaLense 2’s drift is significantly larger. Note this only happens when you look from relative close distance to the virtual object, like 1 meter (3ft).
Spatial awareness
Although I feel the spatial awareness of both devices is more or less on par, HoloLens 2 is notably faster at regaining tracking when it gets ‘lost’. Usually (but not always) HoloLens 2 regains its tracking almost instantly, whereas the MetaLense 2 needs a few moments to find its bearings again - I notice a bit of a delay. You can also see this when you make the spatial map visible: the MetaLense 2 builds it slower, while the HoloLens 2 builds it fast and aggressively. This may be a result of Microsoft dedicating a special chip to it - the famous HPU - or simply that P&C decided spatial loss doesn’t happen often enough to warrant diverting a lot of the device’s resources to
Field of view
HoloLens 2 sports about 52° FOV, MetaLense 2 allegedly 40°, which is smaller than HoloLens 2. That said, it doesn’t feel that way - the image stays bright and clear even at the edges.
Eye tracking
HoloLens 2 has eye tracking. MetaLense 2 does not. Period. Using MRTK3, it will default to head tracking, and most scenarios will work, but not all.
Spatial mapping
The MetaLense 2 has no depth sensor. It uses cameras to build a spatial map, just like Snap Spectacles do. Other devices, like HoloLens 2 and Magic Leap 2, have active depth sensors to build up a spatial map. This is usually more accurate and faster, but is also notably bad at handling dark objects or areas (black objects don’t reflect light, so also not the near-infrared photons that HoloLens 2 uses, leading my black sofa to appear as a black hole in HoloLens spatial maps). Also, active depth sensors are releatively power hungry, which is a concern for any battery powered device
Advantages over HoloLens 2
Next to the display advantage already mentioned, which also makes it better usable outdoors, it has the following advantages:
And the most important one: you can actually buy it new from the manufacturer - whereas HoloLens 2’s death warrant, like Magic Leaps 2’s, has been signed and dated.
It also has another advantage, although not over HoloLens - but over a lot of other devices - you can actually wear it while wearing your own glasses. No inserts, no contacts, just your normal corrective glasses - even bifocals work. That’s something I dearly miss in a lot of devices these days.
If it looks like a duck…
The million-dollar question, of course, is: if it looks so much like a HoloLens 2, and it’s apparently possible to port HoloLens 2 applications so easily - as I recently did with HoloATC - can it replace HoloLens 2, a device that, as you probably know by now, has been out of production for almost two years and can only be purchased second-hand now? The question is, as always, it depends on your use case.
For most cases I think it can - but so can the Meta Quest 3, which is considerably cheaper. However, I also recently learned from a fellow XR community member that a lot of people struggle with VR sickness on the Meta Quest 3, even in see-through scenarios. I haven’t experienced that myself, but I have to take her experiences into account. In an industrial setting I can definitely see this device working as safety compliancy almost rules out pass-through video devices (because you are suddenly blind when they fail, and they block peripheral vision). But you have to realize: this is not a HoloLens 2, it can’t do all its tricks, but it’s a bit cheaper (I’ve seen quotes of about €2400-€2900 incl. VAT), you can actually buy it, and it apparently has a future. If you’re looking for a successor, and pass-through VR won’t do, it’s certainly worth considering contacting P&C Solution and run a few trials.
Verdict?
As you might have gathered by now: this is not a 1:1 replacement for HoloLens 2. But it is a very capable and usable device for a lot of scenarios that required a HoloLens 2, and porting is not hard. It is also very encouraging P&C Solution are very open and communicative, extremely open to feedback, they keep improving, and I wonder - given the fact that this device is from late 2025 - whether a MetaLense 3 is already in the works. Time will tell. At this point in time, anyone making a decent see-through XR device is more than welcome.
Disclaimer: I have no affiliation with P&C Solution, I was not paid or compensated in any way - nor is there any agreement about future compensation. I got a loaner device, examined it, did some development with it, gave feedback, and ported my HoloATC app for it.
Performance benchmarks usually compare milliseconds. In production systems, however, milliseconds become processing queues, infrastructure requirements, cloud costs, and waiting time for users. This article shows how to measure the real impact of faster document processing in C# .NET applications.
Log in
