Update on .NET Multi-platform App UI (.NET MAUI)

Scott Hunter [MSFT]

The .NET 6 project started in late 2020 as we were finishing .NET 5 where we started the journey to unify the .NET platform runtimes, libraries, and SDK. .NET 5 proved to be a very successful release, the first of the annual November releases, and due to the pandemic, the first all remote team release. Most importantly, it has been rapidly and broadly adopted. This November, .NET 6 will GA and will complete the unification of the mono runtime into core, have one set of base libraries for all workloads, and provide one SDK and project system with an expanded set of operating system and device targets. We will also release the next version of the C# language with C#10, have made several enhancements to the web stack ASP.NET, and improved the development experience with hot reload everywhere. We are also working on the next major release of Visual Studio 2022. There’s a whole lot more improvements coming with .NET 6 in November. Read the RC1 release posts for .NET 6 and ASP.NET Core in .NET 6.

.NET Multi-platform App UI (.NET MAUI) makes it possible to build native client apps for Windows, macOS, iOS, and Android with a single codebase and provides the native container and controls for Blazor hybrid scenarios. .NET MAUI is a wrapper framework and development experience in Visual Studio that abstracts native UI frameworks already available – WinUI for Windows, Mac Catalyst for macOS/iPadOS, iOS, and Android. Although it’s not another native UI framework, there is still a significant amount of work to provide optimal development and runtime experiences across these devices.

The .NET team has been working hard with the community in the open on its development and we are committed to its release. Unfortunately, .NET MAUI will not be ready for production with .NET 6 GA in November. We want to provide the best experience, performance, and quality on day 1 to our users and to do that, we need to slip the schedule. We are now targeting early Q2 of 2022 for .NET MAUI GA.

In the meantime, we will continue to enhance Xamarin and recommend it for building production mobile apps and continue releasing monthly previews of .NET MAUI. All the features we plan to deliver for .NET MAUI will be available in November when .NET 6 releases, but we will continue to work on quality and addressing customer feedback. We encourage you to give the previews a try. The .NET Upgrade Assistant will also support upgrading Xamarin projects to .NET MAUI.

.NET 6 RC1 is a “Go Live” release, meaning you can use it in production and you will be supported. This excludes .NET MAUI packages. The next release of .NET MAUI packages, when .NET 6 RC2 releases, will indicate “preview” in the version.

Thank you for all the feedback, contributions, and excitement that you have shared with us on this journey. Please keep it coming and we look forward to a high-quality release early next year. Now let’s look at some of the new features in this release.

.NET MAUI Preview 8 Highlights

The September preview of .NET MAUI completes some important Visual Studio integrations, namely installing .NET MAUI as a workload in the Visual Studio 2022 installer, and folding the Windows platform inside our single, multi-targeted project. With Visual Studio 2022 Preview 4 you can now use broader Hot Reload support with C# and XAML, and the new XAML Live Preview panel for a productive, focused development environment. Within the .NET MAUI SDK itself, preview 8 includes updates to the app startup pattern, the ability to extend a handler, and miscellaneous other new control capabilities as we close on feature completeness.

Visual Studio 2022 Preview 4 Productivity

When installing Visual Studio 2022 Preview 4, you can now check .NET MAUI (preview) within the Mobile Development with .NET workload. This will bring in .NET 6 as well as the optional workload dependencies: Android, iOS, and Mac Catalyst. When targeting desktop, you’ll also want to choose the Desktop Development with .NET, UWP, and Desktop Development with C++ workloads.

image of installer

Once installed, the .NET MAUI templates and features of Visual Studio are all available. Live Preview will mirror your running application within the Visual Studio window in a panel you can dock anywhere that’s most convenient to you. The panel supports zooming in and out to focus on every detail of your UI, guides to align elements on both horizontal and vertical axis, and on some platforms you can hover and select UI elements to get sizing and distance information.

Hot Reload for XAML and C# together with XAML Live Preview

XAML Hot Reload now works well on Android, iOS (on Windows via Hot Restart or a remote build host), and Windows. And .NET Hot Restart is working together with XAML Hot Reload on Android, iOS, and Windows too.

When you create a new project, you’ll now see the Windows platform is alongside Android, iOS, and Mac Catalyst within the Platforms folder. To use Windows, you first need to install the Windows App SDK extension for Visual Studio 2022, and then uncomment the TargetFramework node at the top of your csproj file. In a future release, this will be available by default with the extension pre-installed with .NET MAUI.

.NET MAUI SDK Updates

The most notable update that you’ll need to migrate existing applications to is how we implement the .NET Host Builder pattern. We are now aligned with how ASP.NET and Blazor do this with a MauiProgram class that creates and returns a MauiApp. Each platform now calls that MauiProgram.CreateMauiApp. Compare an existing project with the new templates, or the pull request, to see these changes to Android/MainApplication.cs, iOS/AppDelegate.cs, and macCatalyst/AppDelegate.cs.

Sample MauiProgram:

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureFonts(fonts =>
            {
                fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
            });

        return builder.Build();
    }
}

Sample of the Android MainApplication:

public class MainApplication : MauiApplication
{
    public MainApplication(IntPtr handle, JniHandleOwnership ownership)
        : base(handle, ownership)
    {
    }

    protected override MauiApp CreateMauiApp() => MauiProgram.CreateMauiApp();
}

Android Updates

Android 12 (API 31) is now the default for .NET 6 applications building for Android. To use Android 12, you’ll need to install JDK 11 manually. Once we update the Android tooling in Visual Studio to use JDK 11, we’ll bundle this dependency by default with .NET MAUI. Until then, JDK 11 may have an unfavorable impact on the Android designer, SDK manager, and device manager.

Android projects now use the MaterialTheme by default. Make sure Platforms/Android/MainActivity.cs specifies @style/Maui.SplashTheme or you may get runtime errors on Android. Review the updated .NET MAUI template for example.

Other Changes

Other notable changes and additions include:

  • MinHeightRequest, MaxHeightRequest, MinWidthRequest, MaxWidthRequest have dropped the “Request” suffix and the layout system now treats them as true values
  • Simplified method for appending behavior to any control mapper – #1859
  • Various improvements to Shell theme styling
  • Added RefreshView for Android #2027 and iOS #2029
  • Added AbsoluteLayout #2136
  • Added Right-to-Left (RTL) FlowDirection #948
  • Added Button.Icon ImageSource #2079

Get Started Today

First thing’s first, remove all previous installations of .NET 6 and Visual Studio 2022 previews from your Windows control panel. Now install Visual Studio 2022 Preview 4 and check .NET MAUI (preview) under the Mobile Development with .NET workload, the Desktop Development with .NET workload, Desktop Development with C++ workload, and Universal Windows Platform.

Now, install the Windows App SDK Single-project MSIX extension. Before running the Windows target, remember to uncomment the framework in the csproj file.

Ready? Open Visual Studio 2022 and create a new project. Search for and select .NET MAUI.

Visual Studio 2022 new project dialog

For additional information about getting started with .NET MAUI, refer to our documentation.

Feedback Welcome

Visual Studio 2022 previews are rapidly enabling new features for .NET MAUI. As you encounter any issues with debugging, deploying, and editor related experiences, please use the Help > Send Feedback menu to report your experiences.

Please let us know about your experiences using .NET MAUI to create new applications by engaging with us on GitHub at dotnet/maui.

For a look at what is coming in future releases, visit our product roadmap, and for a status of feature completeness visit our status wiki.

89 comments

Discussion is closed. Login to edit/delete existing comments.

  • Mike Luczak 0

    When trying to deploy and run on Windows, I am getting the error:

    DEP0700: Registration of the app failed. [0x80073CFD] Windows cannot install package 1F8C50E9-6DE8-422F-911C-8EFBE129D587_1.0.0.0_neutral__9zz4h110yvjzm because this package is not compatible with the device. The package requires OS version 10.0.19041.0 or higher on the Windows.Desktop device family. The device is currently running OS version 10.0.18363.1734.

    Is it possible to deploy on 10.0.18363.1734 or do we really need 10.0.19041.0 or higher? Some organizations are not running versions that new.

    • Mike Luczak 0

      I added the following line to the project:

      <TargetPlatformMinVersion Condition=”$(TargetFramework.Contains(‘-windows’))”>10.0.17763.0</TargetPlatformMinVersion>

      Now it deploys with 10.0.18363.1734.

  • Vincent Thorn 0

    MS never learn the lesson. Hey, how long you will push the sand in our eyes?? Your MAUI simply NOT READY! And won’t be ready AT LEAST for 2 years. I’m engineer, I know what I say. You just push RAW , BUGGY CODE as a some sh%%%t with name “release candidate”. STOP IT! You’re behind the “release” AT LEAST for 2 years!! WTF you cheat with us?? You’re NOT READY and don’t spread false promises. We know how far you’re behind, don’t play fool games.

    • saint4eva 0

      You talk runbish all the time.

    • Jorge Morales Vidal 0

      What are you talking about? Your comment looks like what a troll would say. .NET MAUI will still be in preview, .NET 6 will be released in November. Please stop.

  • James Hancock 0

    It’s really sad to see the continual failures with Xamarin/MAUI and everything C# on end user other than web (and even that is collapsing into irrelevance):

    1. ASP.NET developer love is super high. Usage and want is SUPER low (78/8% in the latest stack overflow metrics). You’re down from 28% to 2.8% usage share on the web. So even on web you’re losing now.

    2. Microsoft has no answer to Flutter. Flutter is growing like crazy while Xamarin/MAUI is dying. The reasons are obvious if anyone cared to look and it starts with: Web, Android, iOS, MacOS, Linux and Windows support pixel perfect, and goes from there. You still haven’t wrapped your heads around the fact that you lose 100% of your non-enterprise developers when you make us write the same app multiple times in multiple programming languages. For an enterprise with dozens if not hundreds of developers that can all specialize on a single language having to write React for Web/Electron, Xamarin for android and iOS and WinUI for Windows, while the API team writes C# isn’t a big deal. For small teams where you have developers working across the entire vertical and horizontal stack that’s a deal breaker. But even internally, your Office team has told you exactly this. That’s why they’ve dumped .NET and have standardized on React in electron/WebView2. They’ve realized that they can respond faster and develop quicker on the platforms that their customers use when they have the same app written in as few languages as possible for as many languages as possible.

    3. Microsoft has spent all of this time rebuilding Xamarin with a net effect of slightly faster code, and a single project in vs.net. We still have the same platform limitations and we’ll still have the same plugin support problems for windows. Nothing is changing. And worse, because of how it’s still designed with all of this effort, every platform renders differently and looks different and thus testing is still a PITA, and you have to write every single base control from scratch on every platform which ensures that even if some day 10 years from now (at this pace) we actually did get Web and Linux support, we’d still have horrific cross compatibility because of incomplete implementations from 3rd parties.

    4. Microsoft is all but gone in end user software development, especially where the developers are (don’t tell me that WPF et. al. are doing well, they’re not, virtually no one is writing new apps for these platforms and you know it. It’s all legacy apps that survive through inertia). There’s now more new quality applications being written for MacOS than for Windows even though MacOS has 7% market share on desktop versus 89% for Windows. Why? Because iOS won (with Android) and Apple recognized that if they wanted MacOS to survive, that they had to allow iOS apps to easily work on Mac. The result is incredible and obvious.

    5. Windows is quickly becoming irrelevant to developers (probably already is for most) and that’s a massive problem for Microsoft because no amount of great Surface devices by Panos Pany fixes that disaster even if they run Android. You can’t create great hardware if the OS it’s running has crap software (or someone else’s OS with primarily someone else’s software) because no one is writing for it. And no, PWAs do not make a platform no matter how good they are. I can buy a Chromebook or a Linux desktop and avoid the windows tax if that’s all Windows is going to become and that’s exactly what schools and now enterprises are doing.

    6. As Microsoft loses developers (DEVELOPERS! DEVELOPERS! DEVELOPERS!) it will absolutely hurt Azure because there will be no reason for developers to recommend Azure if Azure is just another cloud like all of the rest. You’ll be caught in a cost competition death spiral instead of having a compelling narrative of the ROI that Azure has as a result of the tight .NET integration.

    7. The CEO doesn’t seem to see the link between all of this, which centers on Microsoft’s failure to create a viable, truly cross platform development tool and the failure of Windows and the inevitable dangers to Azure as a result. (We know this despite his half measures and comments to the contrary, he still hasn’t handed down the edict to get this right which tells you that he’s a server guy that doesn’t understand consumer, which he’s basically said outright.)

    Meanwhile, even the half measures from an understaffed team are delayed. And there is no clear guidance on if you’re going to extend support for Xamarin Forms or if you’re going to pull a .NET Core 2.2 which you depreciated on schedule while .NET 3 was unusable and incompatible with Azure Functions (among other things) and EF Core was busy creating runtime crashes without a tool to fix them automatically costing teams months while their code was insecure because the patching window wasn’t extended despite Microsoft’s own missteps being responsible. If you pull this with Xamarin Forms, you’ll lose the few thousand developers that still bother to use it while you’re rebuilding it as MAUI with the same feature set so there will be no one left to use it.

    The .NET End user teams (Win UI, Xamarin, WPF Legacy, WinForms) need to all be pulled into a room with Panos Panay and have a come to Jesus moment. This is the same emergency as the internet presented before Windows XP and the same emergency that caused Windows XP SP2 that completely rethought security. Don’t come out until you have a plan to:

    1. Run WinUI everywhere. That means Web, Windows, Android, iOS, MacOS and Linux, pixel perfect and cross platform.
    2. Directly compete with Flutter or co-opt Flutter like you did with Edge and Chromium by using it’s open-source rendering engine and bolting .NET on it and taking the best parts of Xamarin and using that to create great plugin implementations on Windows and allow a single C# language to build plugins on all other platforms too.
    3. A plan for one-click migrations from WPF, UWP and Xamarin Forms to this new platform. Figure out how to get as close as possible with instructions to get the rest of the way. Don’t burn the few diehard developers you have left by creating yet another platform (TM Microsoft Circa, WPF, Silverlight, MVC, UWP, Xamarin Forms, MAUI, WinUI, .NET core… nea .NET 5…)
    4. A plan to provide the baseline plugins necessary just like Google does with Flutter (or adopt flutter’s rendering engine and contribute to the Windows plugins there.) and a rich ecosystem of packages that fill the rest of the gaps. That means Microsoft must provide direct access to all of the low level devices on all platforms as a baseline and provide things like biometrics, video with drm etc. Everything else can easily be built on top of that without platform code in most cases, but without those you’re going nowhere.

    I STRONGLY suggest you invite the people at UNO to the meeting (and buy them) because they have you WAY more than halfway there.

    You all need to be laser focused on this. Failure isn’t an option because the fall of .NET is the fall of windows and will be the fall of Azure. And it all circles directly back to the failure of the .NET team to create a truly cross platform, pixel perfect rendering engine like Flutter (which before Flutter was even a thing, I told your Xamarin people you needed to do for the record, so I know whereof I speak.). You knew how to do it before Flutter, because Blazor was built so you have the tooling to get there on Web which is the single most important missing target. Now you have a competitor that has shown you exactly how to do it. The only question left is if you’re going to keep deflecting from the problem while more and more developers flee, or if you’re going to finally understand the problem and set out on a path that actually fixes that problem instead of these half measures of reinventing the wheel for no reason and almost no real benefit as you’re doing now with MAUI.

    The .NET Core spin cycle back to unified .net 5 with everything of .net 4.8 and then some wasting years and causing redevelopment by DEVELOPERS(!) for nothing is happening again. You wasted 5 years going about it exactly upside down with that, but at least you knew where you wanted to get to: .NET everywhere. It’s clear that even that, a clear goal, isn’t obvious with MAUI and the wasted time is the same from the day you bought Xamarin to now, you haven’t moved the goal posts appreciably forward for developers. From the start, the Xamarin acquisition was screwed up royally because you let James Montenegro and co keep it as their pet project building Taj Ma Halls instead of building marketable products that did what developers wanted. For whatever reason, Microsoft decided to indulge this short-sighted thinking even though Xamarin was the ticket Microsoft needed to relevance on Mobile. You need to stop this insane cycle and this behavior in this team and apply the same approaches we’re seeing in the Microsoft Teams continual integration and improvement, and a relentless, take no prisoners laser focus on being the very best end user development environment there is for all platforms. Instead your relegating .NET Core and MAUI to the same servicing cycles that your enterprise customers demand ensuring that iteration is all but impossible in the platform that needs weekly updates just like Microsoft Teams.

    It’s time you think long and hard about what MAUI is, what it’s actual value prop should be, and why the hell anyone would use it. (because, virtually no one is using Xamarin to build apps compared to your competitors, it’s a niche of a niche with a few tens of thousands of apps in the stores versus millions for Flutter in a few years.) And then think about how you get there. Hint: It starts by acquiring Uno and then putting every single last developer you can on supporting and perfecting that effort while providing upgrade/conversion tools that help existing developers get there.

    PS
    While you’re at it, please, please, please end XAML and go to code only style like Flutter, Swift UI and JetPack. It needs to die. Yesterday. The day that I don’t have to see XAML binding tags and can write it as part of the C# code definition inline like Flutter is the day I throw a party. (and yes, everyone telling you that they like XAML and you should keep it is just being inflexible and leading you astray. The market is telling you exactly what new developers demand and what old stick in the mud developers will love once they get over themselves. See below for why you have your feedback loop wrong.)

    PPS: (note I’ve worked in Enterprises and lead teams there. What I am saying comes from experience. I’m not working from a bias position)
    The #1 reason that I’d guess that you haven’t figured all of this out or at least keep avoiding this reality is because your Enterprise customers have WAY too big a say on the direction of .NET, Windows, and Microsoft as a whole. They get an outsized voice because there is a huge revenue move from a single source AND your sales people make their quotas on the Enterprise sales not on small and medium so they’re pressuring you to build to the Enterprise demands. You see it everywhere. This has infected Microsoft everywhere. I get why this has occurred and it is directly driven by the CEO who is a server guy that sells to big customers and doesn’t understand the little customer and is ignoring them and expecting that they’ll accept what the enterprise likes. IBM should be a massive warning to you as to what occurs when you make that assumption: Irrelevance and an ever-tinier portion of the pie.

    And guess what? Enterprises don’t actually want what they claim they do. Tone deaf IT people in Enterprises, got you where you are now with Windows being largely irrelevant and nothing more than a web browser. They’re the same people that advise their family members not to upgrade to Windows Vista, 7, 10 etc. too. They’re inflexible and adverse to change, because of the nature of their jobs. But IT doesn’t drive companies. Sales and marketing drives companies. People getting things done in the real-world drive companies. IT is a cost center, not a profit center. They accommodate what the profit centers demand. If you don’t agree, look at Chrome’s servicing model which ultimately won the browser war for Google. The IT departments were telling you to slow down and not improve Internet Explorer and bundle it in windows and service it through windows. Google said, “Screw that, that’s stupid, we need better and faster, and we need to iterate quickly”. They did, and they built in the updating system directly and told the IT departments to pound salt by subverting the status quo and ensuring that IT couldn’t stop them because END USERS installed Chrome ignoring the IT department. They won, because the actual customer that Google correctly identified is the actual USERS not the IT department in the Enteprises.

    Microsoft needs to rediscover what made Visual Basic so popular and recognize that Windows won because of Visual Basic and what made Visual Basic the go to choice, at the time for software developers. You marketed the product to small and medium and enterprise adopted it as a side effect. You accommodated enterprise when possible, but you built a tool for the rest of us. You enabled a massive wave of apps that solved problems in the profit centers of organizations quickly and easily. You think now that that is low code stuff. It isn’t. That solves maybe 10% of those problems. But you know what does? A single intuitive language with a single intuitive environment that works across all of the platforms that the profit centers in companies and their end users are using with single click deploy to all of those platforms that makes software developers heros in organizations by solving real problems, really quickly, where users need it to be solved. That’s why Flutter is eating the app world for breakfast. And if you added all of the Xamarin tooling and the superior C# on top of that, you’d have a massive competitive advantage over Google. Xamarin’s iOS remote emulators (which you should be giving away in the cloud so no one has to own a mac) and Xamarin’s ability to directly publish to Android and iOS stores without ceremony and a ton of steps will win the day and win you developers back to Windows. Nothing else will.

    The enterprises don’t know it, but that’s exactly what they want too. Listen to users, not IT. Azure and Office 365 should be living proof that I’m right. As soon as you gave companies the ability to downsize and eliminate their IT departments and serve the end users what they wanted, that’s exactly what companies have done to your great success. IT in companies is a necessary evil much like Lawyers. Start treating it as such. They are not your customer, they’re your obstacle to win over while you serve the people that get things done. IT can facilitate, but the second it starts dictating you lose and so do those enterprises.

    Start listening to your real customers again.

    • Hadrian Tang 0

      This is the single most important comment on the whole blog.

    • John 0

      I’d like to reply to a few things in your post.

      Re 2: Apps don’t need to be pixel perfect unless they are games. Testing should occur on all supported platforms regardless, in different form factors where possible.

      Re 3: If a control you want exists on all the platforms and doesn’t already exist in XF, then wrap it in a custom renderer on each platform. This is actually really simple and easy to do. Users are happy as they get controls that look and feel native (because they are native and thus natively support the platform accessibility features). If a control doesn’t exist and you want to create something new, great! You know you can create controls in Xamarin Forms without going native as well, right?

      Re PS: XAML, you know you can write coded UI in Xamarin, right? Why drop something that works perfectly fine for developers that work with app designers or are XAML proficient? I personally prefer coded UI’s as you do, but I wouldn’t suggest dumping XAML because of my own bias.

      > Start listening to your real customers again.
      I agree with that, but you don’t speak for all customers.

      > Xamarin’s iOS remote emulators (which you should be giving away in the cloud so no one has to own a mac)
      Funniest thing Ive heard in a while. If you want to write iOS apps, get a Mac. Individual developers, small business and up to enterprise level understand this.

      > directly publish to Android and iOS stores without ceremony and a ton of steps
      Those steps are defined by the Android and iOS app stores, and they change over time. You expect MS to do that (and maintain it!) for you?

    • anonymous 0

      this comment has been deleted.

    • Paulo Pinto 0

      It pretty much sums up my experience and feelings as well.

      During the last year I have been part of an Asterix like business unit, trying to keep .NET relevant in the context of business decisions that end up selecting other stacks for the most part.

      The whole mess of .NET Core migration, and how the GUI stacks on the desktop have been managed since Windows 8 play a big role in going with other stacks instead of .NET.

      Additionally, for some key persons, even though it is orthogonal to .NET, the way Microsoft has killed C++/CX and replaced it with C++/WinRT without any kind of comparable Visual Studio tooling, even after 4 years pushing for it, also plays a role how they view Microsoft’s management of recent technologies pushed by the company.

    • Maximo Piva 0

      Does the management know, or do they just pretend not to? Do we wait a few years, and see how heads will roll?

      MS: Hey guys, the master plan is falling, execute Plan B. ASAP. and Hire the poster, as the new head of the division. Cleary he grasped the current situation.

  • Dave L. 0

    I want to run Blazor on desktop Windows in WebView2 with ASP.NET Core backend (leveraging native code) as a single desktop executable. Is MAUI going to be the best solution for this? I don’t need any cross platform at all as we’re modernising an existing legacy Win32 app and most of the backend will be MFC. Will there be minimal bootstrapping example available to create this stack?

  • John 0

    FIXED : Unable to get Windows app working. I expect this was user error, I double checked the install procedure and now is working correctly, with hot reload!

    FIXED: Unable to run with iOS simulators. Fixed by using the latest prerelease of Xamarin.iOS that works with Xcode 13.

    Unable to use Android as Im in Windows VM and can’t be ar$ed creating an ADB bridge right now. 🙂

  • Rafael Veronezi 0

    This is a mess! Not for the delay itself that honestly was to be expected, but how this is being handled from the tooling perspective.

    I haven’t seen through all this previewing process a single mention on how to do MAUI through macOS, which is a shame not only because Xamarin developers are a huge part on this operating system, but also because the promise was that this platform would be developable through any operating system and just from a text editor and CLI if that was the developer wish.

    Now, all the efforts are in trying to push devs to Visual Studio 2022 (typical Microsoft) by saying that the workload should be installed from there and dropping the freaking Maui-check tool. This is ludicrous and a disrespect with the fellows that was expecting this to be a more open and flexible platform than Xamarin was!

    I’m not a Windows user and developer and won’t be just to use MAUI and I feel very disappointed because I was expecting the platform to be available to start a multi-platform project with my team of macOS users and developers. Not only the platform is delayed but we don’t see any effort in bringing this the Mac audience.

    It’s no surprise why so many developers want to get away with Microsoft platform from their projects and companies. This so 90’s practices of trying to force devs to use specific platforms and tools is unacceptable nowadays, and windows 11 and it’s deliberate drop of support on perfectly capable hardwares is another sign of this lack of respect from Microsoft to its user and developer base.

    Shame on you! We are assessing more open alternatives like Flutter because we don’t feel we can trust on Microsoft anymore as a platform provider.

    • John 0

      You want VS2022 developers to NOT have install workflows? That is nonsense. Maui-check still exists and hasn’t gone away if that’s what floats your boat.

      Regarding Mac, you know you need VSforMac for that, right? The new 2022 version is currently in private beta and doesn’t have any of the maui workloads available yet, but that will be how you do Mac app development. That wasn’t going to change so why would they need to announce anything? Mac is a first class citizen for .net maui and has been since it was announced.

      Don’t forget , this is is still the preview phase. They are developing, refining, fixing. Let them get the first real release out first, yeah?

      • Eric Blankenburg 0

        Maui-Check:

        Fix failed – Workload Install failed: dotnet workload install --no-cache --disable-parallel android-aot ios maccatalyst tvos macos maui wasm-tools
        --skip-manifest-update --source "https://api.nuget.org/v3/index.json" --source
        "https://pkgs.dev.azure.com/dnceng/public/_packaging/6.0.100-rc.1.21458.32-shipping/nuget/v3/index.json"

        Now what???

  • Manoj Kumar 0

    Following action to handle server certificate validation is throwing operation not supported error in MAUI, is this expected? if so any other alternative provided.

    HttpClientHandler httpClientHandler = new HttpClientHandler();
    httpClientHandler.ServerCertificateCustomValidationCallback += OnCertificateCustomValidation;

  • Eric Blankenburg 0

    Followed your instructions. Tried to build. Results:

    The non-generic type ‘MauiUIApplicationDelegate’ cannot be used with type arguments

    The type or namespace name ‘IStartup’ could not be found

    The type or namespace name ‘IAppHostBuilder’ could not be found

    ‘App’ does not implement inherited abstract member ‘MauiWinUIApplication.CreateMauiApp()

    ‘App.OnCreateStartup()’: no suitable method found to override

    Could not find android.jar for API level 31. This means the Android SDK platform for API level 31 is not installed. Either install it in the Android SDK Manager (Tools > Android > Android SDK Manager…), or change the Xamarin.Android project to target an API version that is installed.

    • Steve 0

      Use maui-check first to ensure you’ve installed right workloads and sdks.

  • Rod Macdonald 0

    With MAUI being delayed, could we have a BlazorWebView control to run Blazor on the desktop via WinForms and WPF? Thank you.

  • Alex Midnayt 0

    Can’t run MAUI project
    PS D:\Xamarin\HelloMaui> dotnet restore
    Determining projects to restore…
    C:\Program Files\dotnet\sdk\6.0.100-rc.1.21463.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(112,5): error NETSDK1139: The target platform identifier ios was not recognized. [D:\Xamarin\HelloMaui\HelloMaui.csproj]
    PS D:\Xamarin\HelloMaui> dotnet build -t:Run -f net6.0-android
    Microsoft (R) Build Engine version 17.0.0-preview-21460-01+8f208e609 for .NET
    Copyright (C) Microsoft Corporation. All rights reserved.

    Determining projects to restore…
    C:\Program Files\dotnet\sdk\6.0.100-rc.1.21463.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(112,5): error NETSDK1139: The target platform identifier ios was not recognized. [D:\Xamarin\HelloMaui\HelloMaui.csproj]
    PS D:\Xamarin\HelloMaui>

Feedback usabilla icon